Logical Domains Information API and ldminfo [PSARC/2010/004 FastTrack timeout 01/14/2010]
fyi. This case is approved in today's psarc meeting.
Logical Domains Information API and ldminfo [PSARC/2010/004 FastTrack timeout 01/14/2010]
Mike, Thanks to you and the team for following up on this, and making the interfaces general to virtualization, rather than LDOMs specific. I believe that will lead to a better user experience. I have re-reviewed this, and offer a +1. -- Rick Mike Christensen wrote: On 01/13/10 15:55, Rick Matthews wrote: There was no meeting scheduled for Jan. 13. I believe a question was asked (and if not, I'll ask it) as to why an LDOMs specific virtualization query? Would there be a query that could give the caller generic virtualization information (working for both Zen and LDOMs)? Was this considered? Could a generic call identify the virtualization technology, and then, if needed, technology specific queries could be made? -- Rick After discussions with the Xen group, I have reworked this proposal to cater to Xen (and other virtualization technologies) implementing this. This involved mostly name changes (e.g. libldoms in the original proposal is now libv12n, function names are now v12n_* rather than ldoms_*, and manifest constants are now V12N_*) and new bit(s) in the v12n_capabilities function to return virtualization implementation technology. The case materials in the directory have been updated and attached is the new case. Thanks. Mike -- - Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USAmain: +1(651) 554-1500 -
Logical Domains Information API and ldminfo [PSARC/2010/004 FastTrack timeout 01/14/2010]
On 01/13/10 15:55, Rick Matthews wrote: There was no meeting scheduled for Jan. 13. I believe a question was asked (and if not, I'll ask it) as to why an LDOMs specific virtualization query? Would there be a query that could give the caller generic virtualization information (working for both Zen and LDOMs)? Was this considered? Could a generic call identify the virtualization technology, and then, if needed, technology specific queries could be made? -- Rick After discussions with the Xen group, I have reworked this proposal to cater to Xen (and other virtualization technologies) implementing this. This involved mostly name changes (e.g. libldoms in the original proposal is now libv12n, function names are now v12n_* rather than ldoms_*, and manifest constants are now V12N_*) and new bit(s) in the v12n_capabilities function to return virtualization implementation technology. The case materials in the directory have been updated and attached is the new case. Thanks. Mike -- next part -- An embedded and charset-unspecified text was scrubbed... Name: virtinfo.arc URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20100126/1963e406/attachment-0001.ksh
Logical Domains Information API and ldminfo [PSARC/2010/004 FastTrack timeout 01/14/2010]
On 01/13/10 15:55, Rick Matthews wrote: There was no meeting scheduled for Jan. 13. I believe a question was asked (and if not, I'll ask it) as to why an LDOMs specific virtualization query? Would there be a query that could give the caller generic virtualization information (working for both Zen and LDOMs)? Was this considered? No, we didn't really consider Xen support. I'm engaging the Xen group right now to see if there's easily achievable common ground. Could a generic call identify the virtualization technology, and then, if needed, technology specific queries could be made? Yes, if it's not easy to converge with Xen, we can supply that. It's probably going to take me a couple of days to resolve these issues. Mike -- Rick On 01/04/10 17:00, Huay-Yong Wang wrote: I am sponsoring this fasttrack for Michael Christensen. The project team is requesting a patch/micro release binding. The 3 manpages (ldminfo.1m, libldom.3lib ldoms_capabilities.3ldoms) and the libldoms.h include file are placed in the case directory. The timer is set to expire on 1/14/10. --- 1. Introduction 1.1 Project/Component Working Name Logical Domains Information API and ldminfo program 1.2 Name of Document Author/Supplier Michael Christensen 1.3 Date of This Document 18-DEC-2009 1.4 Name of Major Document Customer(s)/Consumer(s) 1.4.1 The PAC or CPT you expect to review your project 1.4.2 The ARC(s) you expect to review your project PSARC 1.4.3 The Director/VP who is sponsoring this project jerriann.meyer at sun.com 1.4.4 The Name of Your Business Unit Solaris Core OS 1.5 Email Aliases 1.5.1 Responsible Manager:jay.jayachandran at sun.com 1.5.2 Responsible Engineer:michael.christensen at sun.com 1.5.3 Marketing Manager:duncan.hardie at sun.com 1.5.4 Interest List:ldoms-internal at sun.com 2. Project Summary 2.1 Project Description This project will implement Logical Domains Information API and ldminfo program on Solaris. The API and ldminfo program will provide information about the currently running domain. Among the items that may be provided are: - Domain type (control, guest, I/O, service, root) - LDom Manager's LDom name for this domain (Domain name) - Domain Universally Unique ID (UUID) - Domain's control domain network nodename - Chassis Serial Number the domain is running on. None of the above items are currently easily obtainable from within a guest domain. As an example, many customers have expressed a desire to run LDom manager scripts on the control domain initiated from a guest domain. However, there is no easy way to either identify the network nodename of the control domain or to identify the LDom Manager's name for the current domain, which would be required for LDom Manager commands. Further, many customers have requested a means of uniquely identifying each domain and also identifying the hardware platform that the domain is running on for accounting or resourcing. On the Solaris operating system, the Logical Domains Information API will be implemented as a library (libldoms) using information from the Guest Domain's Machine Description provided by FWARC 2005/115 (sun4v machine description), the sun4v MD uuid property from FWARC 2009/680 (Domain UUID property), the libds library provided by PSARC 2008/568 (Logical Domain's Domain Services) and using domain services provided by the logical domain agent daemon provided by PSARC 2009/459 (Logical Domains Agents on Solaris) and FWARC 2009/426 (Logical Domains Agents). The ldminfo program will utilize the libldoms library to display the various items of information provided. 2.2 Risks and Assumptions None. 3. Business Summary 3.1 Problem Area In an LDoms system, a user program or user has no easy way to identify what type of domain the program is being run on (e.g. control domain, guest domain, I/O domain, service domain). Also a guest domain has no easy way to identify the network nodename of its control domain, what name the LDoms Manager running on the control domain uses to identify this domain, what is the domain's Universally Unique Identifier that The LDoms Manager uses to identify this domain or what the Chassis Serial Number of the platform it is currently running on. 3.2 Market/Requestor See FWARC 2005/633. 3.3 Business Justification See FWARC 2005/633. 3.4 Competitive Analysis The problems listed in 3.1 have been the subject of bug reportsfrom customers. Virtualization solutions provided by competitors have equivalent functionality. 3.5 Opportunity
Logical Domains Information API and ldminfo [PSARC/2010/004 FastTrack timeout 01/14/2010]
There was no meeting scheduled for Jan. 13. I believe a question was asked (and if not, I'll ask it) as to why an LDOMs specific virtualization query? Would there be a query that could give the caller generic virtualization information (working for both Zen and LDOMs)? Was this considered? Could a generic call identify the virtualization technology, and then, if needed, technology specific queries could be made? -- Rick On 01/04/10 17:00, Huay-Yong Wang wrote: I am sponsoring this fasttrack for Michael Christensen. The project team is requesting a patch/micro release binding. The 3 manpages (ldminfo.1m, libldom.3lib ldoms_capabilities.3ldoms) and the libldoms.h include file are placed in the case directory. The timer is set to expire on 1/14/10. --- 1. Introduction 1.1 Project/Component Working Name Logical Domains Information API and ldminfo program 1.2 Name of Document Author/Supplier Michael Christensen 1.3 Date of This Document 18-DEC-2009 1.4 Name of Major Document Customer(s)/Consumer(s) 1.4.1 The PAC or CPT you expect to review your project 1.4.2 The ARC(s) you expect to review your project PSARC 1.4.3 The Director/VP who is sponsoring this project jerriann.meyer at sun.com 1.4.4 The Name of Your Business Unit Solaris Core OS 1.5 Email Aliases 1.5.1 Responsible Manager: jay.jayachandran at sun.com 1.5.2 Responsible Engineer: michael.christensen at sun.com 1.5.3 Marketing Manager:duncan.hardie at sun.com 1.5.4 Interest List:ldoms-internal at sun.com 2. Project Summary 2.1 Project Description This project will implement Logical Domains Information API and ldminfo program on Solaris. The API and ldminfo program will provide information about the currently running domain. Among the items that may be provided are: - Domain type (control, guest, I/O, service, root) - LDom Manager's LDom name for this domain (Domain name) - Domain Universally Unique ID (UUID) - Domain's control domain network nodename - Chassis Serial Number the domain is running on. None of the above items are currently easily obtainable from within a guest domain. As an example, many customers have expressed a desire to run LDom manager scripts on the control domain initiated from a guest domain. However, there is no easy way to either identify the network nodename of the control domain or to identify the LDom Manager's name for the current domain, which would be required for LDom Manager commands. Further, many customers have requested a means of uniquely identifying each domain and also identifying the hardware platform that the domain is running on for accounting or resourcing. On the Solaris operating system, the Logical Domains Information API will be implemented as a library (libldoms) using information from the Guest Domain's Machine Description provided by FWARC 2005/115 (sun4v machine description), the sun4v MD uuid property from FWARC 2009/680 (Domain UUID property), the libds library provided by PSARC 2008/568 (Logical Domain's Domain Services) and using domain services provided by the logical domain agent daemon provided by PSARC 2009/459 (Logical Domains Agents on Solaris) and FWARC 2009/426 (Logical Domains Agents). The ldminfo program will utilize the libldoms library to display the various items of information provided. 2.2 Risks and Assumptions None. 3. Business Summary 3.1 Problem Area In an LDoms system, a user program or user has no easy way to identify what type of domain the program is being run on (e.g. control domain, guest domain, I/O domain, service domain). Also a guest domain has no easy way to identify the network nodename of its control domain, what name the LDoms Manager running on the control domain uses to identify this domain, what is the domain's Universally Unique Identifier that The LDoms Manager uses to identify this domain or what the Chassis Serial Number of the platform it is currently running on. 3.2 Market/Requestor See FWARC 2005/633. 3.3 Business Justification See FWARC 2005/633. 3.4 Competitive Analysis The problems listed in 3.1 have been the subject of bug reports from customers. Virtualization solutions provided by competitors have equivalent functionality. 3.5 Opportunity Window/Exposure See FWARC 2005/663. 3.6 How will you know when you are done? The work will be completed when the final code changes to implement Logical Domains Information API and ldminfo program are
Logical Domains Information API and ldminfo [PSARC/2010/004 FastTrack timeout 01/14/2010]
I am sponsoring this fasttrack for Michael Christensen. The project team is requesting a patch/micro release binding. The 3 manpages (ldminfo.1m, libldom.3lib ldoms_capabilities.3ldoms) and the libldoms.h include file are placed in the case directory. The timer is set to expire on 1/14/10. --- 1. Introduction 1.1 Project/Component Working Name Logical Domains Information API and ldminfo program 1.2 Name of Document Author/Supplier Michael Christensen 1.3 Date of This Document 18-DEC-2009 1.4 Name of Major Document Customer(s)/Consumer(s) 1.4.1 The PAC or CPT you expect to review your project 1.4.2 The ARC(s) you expect to review your project PSARC 1.4.3 The Director/VP who is sponsoring this project jerriann.meyer at sun.com 1.4.4 The Name of Your Business Unit Solaris Core OS 1.5 Email Aliases 1.5.1 Responsible Manager: jay.jayachandran at sun.com 1.5.2 Responsible Engineer: michael.christensen at sun.com 1.5.3 Marketing Manager:duncan.hardie at sun.com 1.5.4 Interest List:ldoms-internal at sun.com 2. Project Summary 2.1 Project Description This project will implement Logical Domains Information API and ldminfo program on Solaris. The API and ldminfo program will provide information about the currently running domain. Among the items that may be provided are: - Domain type (control, guest, I/O, service, root) - LDom Manager's LDom name for this domain (Domain name) - Domain Universally Unique ID (UUID) - Domain's control domain network nodename - Chassis Serial Number the domain is running on. None of the above items are currently easily obtainable from within a guest domain. As an example, many customers have expressed a desire to run LDom manager scripts on the control domain initiated from a guest domain. However, there is no easy way to either identify the network nodename of the control domain or to identify the LDom Manager's name for the current domain, which would be required for LDom Manager commands. Further, many customers have requested a means of uniquely identifying each domain and also identifying the hardware platform that the domain is running on for accounting or resourcing. On the Solaris operating system, the Logical Domains Information API will be implemented as a library (libldoms) using information from the Guest Domain's Machine Description provided by FWARC 2005/115 (sun4v machine description), the sun4v MD uuid property from FWARC 2009/680 (Domain UUID property), the libds library provided by PSARC 2008/568 (Logical Domain's Domain Services) and using domain services provided by the logical domain agent daemon provided by PSARC 2009/459 (Logical Domains Agents on Solaris) and FWARC 2009/426 (Logical Domains Agents). The ldminfo program will utilize the libldoms library to display the various items of information provided. 2.2 Risks and Assumptions None. 3. Business Summary 3.1 Problem Area In an LDoms system, a user program or user has no easy way to identify what type of domain the program is being run on (e.g. control domain, guest domain, I/O domain, service domain). Also a guest domain has no easy way to identify the network nodename of its control domain, what name the LDoms Manager running on the control domain uses to identify this domain, what is the domain's Universally Unique Identifier that The LDoms Manager uses to identify this domain or what the Chassis Serial Number of the platform it is currently running on. 3.2 Market/Requestor See FWARC 2005/633. 3.3 Business Justification See FWARC 2005/633. 3.4 Competitive Analysis The problems listed in 3.1 have been the subject of bug reports from customers. Virtualization solutions provided by competitors have equivalent functionality. 3.5 Opportunity Window/Exposure See FWARC 2005/663. 3.6 How will you know when you are done? The work will be completed when the final code changes to implement Logical Domains Information API and ldminfo program are integrated into the Solaris Nevada gate and Solaris 10 Update gates. 4. Technical Description 4.1 Overview On the Solaris operating system, Logical Domains Information API will be implemented as a user library libldoms.so.1 and a user program ldminfo will be provided to display this information. This information will be provided either via the sun4v Machine Description (FWARC/2005/115 and FWARC 2009/680)
