1. Introduction 1.1 Project/Component Working Name Logical Domains Agents 1.2 Name of Document Author/Supplier Alexandre Chartre 1.3 Date of This Document 02-AUG-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 FWARC 1.4.3 The Director/VP who is sponsoring this project jerriann.meyer@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@sun.com 1.5.2 Responsible Engineer: alexandre.chartre@sun.com 1.5.3 Marketing Manager: duncan.hardie@sun.com 1.5.4 Interest List: ldoms-internal@sun.com 2. Project Summary 2.1 Project Description This project will implement Logical Domains Agents and a framework to provide additional agents. A Logical Domains Agent is an entity running in a domain and able to provide information or to interact with the control domain. The following Logical Domains Agents will be initially provided: - A "system" agent which provides information about the system, such as the nodename, or the release and version of the system. - A "device" agent which provides information about devices, such as the existence of a disk or network interface. These agents will be used by the control domain to gather information about other domains, in particular service domains, in order to better evaluate the capabilities of these domains. More agents are expected to be delivered in the future to increase the capability of the control domains to interact with other domains. On the Solaris operating system, Logical Domains agents will be implemented as a SMF service and a userland daemon using the libds library provided by PSARC 2008/568 (Logical Domain's Domain Services). 2.2 Risks and Assumptions None. 3. Business Summary 3.1 Problem Area In an LDoms system, the control domain has no way to query information about the system configuration of another domain. For example, it is unable to validate a device path which is associated with (i.e., local to) another domain, or to know what release of an operating system another domain is running. This causes various operational problems when creating virtual device services in other domains which in turn are exported to guest domains, or to know if domain is able to support a particular LDoms operation. For example, an LDoms system allows the creation of "service domains" which provide services to other guest domains, such as a domain with a vds (virtual disk service) which can export virtual disk devices to other domains. When exporting devices hosted by a vds in another domain, the user specifies a backend (a simple file, a disk slice, a disk drive, etc.) for the vds device by supplying the filesystem path of that backend. If the user supplies an invalid backend path, the LDoms Manager has currently no way to determine if the path to the backend is valid. Even at the time the service domain is bound, such an error remains undetected. A similar situation occurs when specifying the physical network interface associated with a virtual switch. An example of the type of problem this can cause is when the virtual disk which relies on an invalid backend path is the boot device. In that case, the boot of the domain will fail in a such a way that the cause of the problem is difficult for the user to determine. 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 do not suffer this type of problem. 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 the LDoms "device" and "system" agents are integrated into the Solaris Nevada gate and Solaris 10 Update gates. 4. Technical Description 4.1 Overview Each Logical Domains Agent will be implemented as a virtual domain service as defined in FWARC 2008/563 (Virtual Domain Service MD nodes and misc. properties). As a virtual domain service, each agent will be identified by a domain service id. An agent will be able to send and receive messages to and from the control domain using the virtual domain services framework. Any message sent or received by any agent will have the same common structure. However the message structure will have fields whose content and interpretation can be different for each agent. See the "Logical Domains Agent Specification" document for a description of the message structure. An agent will use the versioning mechanism available in the virtual domain framework (major.minor). The major number of the version is associated with the common structure of messages, which is used by all agents. This agent message specification document defines version 1 of this structure. The minor number of the version is private to the agent and is used by the agent to track changes in the usage of fields inside the common message structure. The project will initially deliver two agents identified with the following domain service names: Service Name Description ------------ ----------- agent-device Device Agent agent-system System Agent Each agent defines its own set of messages, based on the common message structure, to provide a set of services and features to the control domain. Each agent is described in the "Logical Domain Agents Specification" document. On the Solaris operating system, Logical Domains agents will be implemented as a SMF service "svc:/ldoms/agents" and a userland daemon "/usr/lib/ldoms/ldmad" using the libds library provided by PSARC 2008/568 (Logical Domain's Domain Services). To simplify Logical Domains installation and deployment and for ease of use, the Logical Domains agents SMF service will be enabled by default. The Logical Domains agents service has to be enabled to ensure proper functionality of all features provided by the domain manager on the control domain. 4.2 Bug/RFE Number(s) 6813200 Logical Domains Agents 6734518 LDoms needs Domain Service to allow device paths to be validated across domains 6447740 Ldom Mgr should validate specified vdsdev & net-dev entries 6669994 Add a domain service to support OS identification (Solaris) 6506767 Add a domain service to support OS identification (LDoms Manager) 4.3 Scope Not Applicable. 4.4 Out of Scope Not Applicable. 4.5 Interfaces 4.5.1 Interfaces The new interface is embodied in the format of the messages passed between the control domain and the different agents. For a detailed description of the interface see the Logical Domain Agents Specification document. 4.5.2 Imported Interfaces Interface Classification Comments ================================================================= Domain Services Sun Private Domain Services protocol and messages formats FWARC/2006/055 Domain Services API Sun Private Logical Domain's Domain Services API PSARC/2008/568 4.5.3 Exported Interfaces Interface Classification Comments ================================================================ Domain Services ID Sun Private service id ("agent-device" and "agent-system") to represent the new agents. Agent Message Sun Private Describes format of Formats messages exchanged between the LDoms Manager and the agents. 4.6 Doc Impact Man page for the Solaris LDoms agent daemon, ldmad(1M). 4.7 Admin/Config Impact Current behavior: Pathname errors when specifying devices in certain LDoms Manager CLI commands go undetected until a guest domain attempting to use the corresponding service encounters a problem. New behavior: Such pathname errors will be detected by LDoms Manager when binding a domain which references a service for which an invalid path was specified. 4.8 HA Impact None. 4.9 I18N/L10N Not affected. 4.10 Packaging & Delivery This project defines a generic interface and is not tied to a particular architecture. The Solaris implementation will be delivered as part of Solaris LDoms and LDoms manager packages. 4.11 Security Impact None. 4.12 Dependencies None. 5. Reference Documents FWARC 2005/633 LDoms: Project Q Logical Domaining Umbrella FWARC 2006/055 Domain Services FWARC 2008/563 Virtual Domain Service MD nodes and misc. properties PSARC 2008/568 Logical Domain's Domain Services 6. Resources and Schedule 6.1 Projected Availability Q4FY10 (S10U9) 6.2 Cost of Effort 2 person month 6.3 Cost of Capital Resources 6.4 Product Approval Committee requested information 6.4.1 Consolidation Or Component Name OS-Networking (ON) LDoms Manager (project private) 6.4.3 Type of CPT Approval Expected FastTrack 6.4.4 Project Boundary Conditions 6.4.5 Is this a necessary project for OEM agreements: No. 6.4.6 Notes 6.4.7 Target RTI Date/Release September 2009 6.4.8 Target Code Design Review Date: 6.4.9 Update approval addition: Not applicable 6.5 ARC review type FastTrack 6.6 ARC Exposure open 7. Prototype Availability: 7.1 Prototype Availability A prototype is already available. 7.2 Prototype Cost: A prototype is already available.