Part I Oracle VM Server for SPARC 3.1 Software
Part II Optional Oracle VM Server for SPARC Software
Chapter 14 Oracle VM Server for SPARC Physical-to-Virtual Conversion Tool
Oracle VM Server for SPARC P2V Tool Overview
Installing the Oracle VM Server for SPARC P2V Tool
Prerequisites for using the SPARC P2V Tool
Limitations of Using the SPARC P2V Tool
How to Install the Oracle VM Server for SPARC P2V Tool
Chapter 15 Oracle VM Server for SPARC Configuration Assistant (Oracle Solaris 10)
Using the Configuration Assistant (ldmconfig)
Installing the Configuration Assistant
Prerequisites for Running the Configuration Assistant
Limitations and Known Issues of the Configuration Assistant
Chapter 16 Using Power Management
Viewing Power-Consumption Data
Chapter 17 Using the Oracle VM Server for SPARC Management Information Base Software
Oracle VM Server for SPARC Management Information Base Overview
Logical Domains Manager and the Oracle VM Server for SPARC MIB
Parsing the XML-Based Control Interface
Providing Fault and Recovery Information
Oracle VM Server for SPARC MIB Object Tree
Installing and Configuring the Oracle VM Server for SPARC MIB Software
Installing and Configuring the Oracle VM Server for SPARC MIB Software
How to Install the Oracle VM Server for SPARC MIB Software Package
How to Load the Oracle VM Server for SPARC MIB Module Into the Oracle Solaris SNMP Agent
How to Remove the Oracle VM Server for SPARC MIB Software Package
How to Create the Initial snmpv3 User
Querying the Oracle VM Server for SPARC MIB
Retrieving Oracle VM Server for SPARC MIB Information
Environment Variables Table (ldomEnvVarsTable)
Domain Policy Table (ldomPolicyTable)
Service Processor Configuration Table (ldomSPConfigTable)
Domain Resource Pool and Scalar Variables
Virtual CPU Table (ldomVcpuTable)
Virtual Memory Table (ldomVmemTable)
Virtual Memory Physical Binding Table (ldomVmemPhysBindTable)
Virtual Disk Service Table (ldomVdsTable)
Virtual Disk Service Device Table (ldomVdsdevTable)
Virtual Disk Table (ldomVdiskTable)
Virtual Switch Service Table (ldomVswTable)
Virtual Network Device Table (ldomVnetTable)
Virtual Console Concentrator Table (ldomVccTable)
Virtual Console Group Table (ldomVconsTable)
Virtual Console Relationship Table (ldomVconsVccRelTable)
Cryptographic Units Table (ldomCryptoTable)
I/O Bus Table (ldomIOBusTable)
Scalar Variables for Domain Version Information
Using Oracle VM Server for SPARC MIB Module Traps
Oracle VM Server for SPARC MIB Trap Descriptions
Domain State Change (ldomStateChange)
Virtual CPU Change (ldomVCpuChange)
Virtual Memory Change (ldomVMemChange)
Virtual Disk Service Change (ldomVdsChange)
Virtual Disk Change (ldomVdiskChange)
Virtual Switch Change (ldomVswChange)
Virtual Network Change (ldomVnetChange)
Virtual Console Concentrator Change (ldomVccChange)
Virtual Console Group Change (ldomVconsChange)
Chapter 18 Logical Domains Manager Discovery
Discovering Systems Running the Logical Domains Manager
How to Discover Logical Domains Managers Running on Your Subnet
Chapter 19 Using the XML Interface With the Logical Domains Manager
Registration and Unregistration
Logical Domains Manager Actions
Logical Domains Manager Resources and Properties
Domain Information (ldom_info) Resource
Virtual Disk Server (vds) Resource
Virtual Disk Server Volume (vds_volume) Resource
Virtual Console Concentrator (vcc) Resource
Physical I/O Device (physio_device) Resource
SP Configuration (spconfig) Resource
DRM Policy Configuration (policy) Resource
Virtual Data Plane Channel Service (vdpcs) Resource
The XML interface into Oracle VM Server for SPARC has two different formats:
A format for sending commands into the Logical Domains Manager
A format for Logical Domains Manager to respond on the status of the incoming message and the actions requested within that message.
The two formats share many common XML structures, but they are separated in this discussion for a better understanding of the differences between them.
An incoming XML request to the Logical Domains Manager at its most basic level includes a description of a single command operating on a single object. More complicated requests can handle multiple commands and multiple objects per command. The following example shows the structure of a basic XML command.
Example 19-1 Format of a Single Command Operating on a Single Object<LDM_interface version="1.3"> <cmd> <action>Place command here</action> <options>Place options for certain commands here</options> <arguments>Place arguments for certain commands here</arguments> <data version="3.0"> <Envelope> <References/> <!-- Note a <Section> section can be here instead of <Content> --> <Content xsi:type="ovf:VirtualSystem_Type" id="Domain name"> <Section xsi:type="ovf:ResourceAllocationSection_type"> <Item> <rasd:OtherResourceType>LDom Resource Type</rasd:OtherResourceType> <gprop:GenericProperty key="Property name">Property Value</gprop:GenericProperty> </Item> </Section> <!-- Note: More Sections sections can be placed here --> </Content> </Envelope> </data> <!-- Note: More Data sections can be placed here --> </cmd> <!-- Note: More Commands sections can be placed here --> </LDM_interface>
All commands sent to the Logical Domains Manager must start with the <LDM_interface> tag. Any document sent into the Logical Domains Manager must have only one <LDM_interface> tag contained within it. The <LDM_interface> tag must include a version attribute as shown in Example 19–1.
Within the <LDM_interface> tag, the document must include at least one <cmd> tag. Each <cmd> section must have only one <action> tag. Use the <action> tag to describe the command to run. Each <cmd> tag must include at least one <data> tag to describe the objects on which the command is to operate.
The <cmd> tag can also have an <options> tag, which is used for options and flags that are associated with some commands. The following commands use options:
The ldm remove-domain command can use the –a option.
The ldm bind-domain command can use the –f option.
The ldm add-vdsdev command can use the –f option.
The ldm cancel-operation command can use the migration or reconf option.
The ldm add-spconfig command can use the –r autosave-name option.
The ldm remove-spconfig command can use the –r option.
The ldm list-spconfig command can use the –r [autosave-name] option.
The ldm stop-domain command can use the following tags to set the command arguments:
<force> represents the –f option.
<halt> represents the –h option.
<message> represents the –m option.
<quick> represents the –q option.
<reboot> represents the –r option.
<timeout> represents the –t option.
Note that the tags must not have any content value. However, the –t and –m options must have a non-null value, for example, <timeout>10</timeout> or <message>Shutting down now</message>.
The following XML example fragment shows how to pass a reboot request with a reboot message to the ldm stop-domain command:
<action>stop-domain</action> <arguments> <reboot/> <message>my reboot message</message> </arguments>
Each <data> section contains a description of an object pertinent to the command specified. The format of the <data> section is based on the XML schema portion of the Open Virtualization Format (OVF) draft specification. That schema defines an <Envelope> section which contains a <References> tag (unused by Oracle VM Server for SPARC) and <Content> and <Section> sections.
For Oracle VM Server for SPARC, the <Content> section is used to identify and describe a particular domain. The domain name in the id= attribute of the <Content> node identifies the domain. Within the <Content> section are one or more <Section> sections describing resources of the domain as needed by the particular command.
If you need to identify only a domain name, then you do not need to use any <Section> tags. Conversely, if no domain identifier is needed for the command, then you need to provide a <Section> section describing the resources needed for the command, placed outside a <Content> section but still within the <Envelope> section.
A <data> section does not need to contain an <Envelope> tag in cases where the object information can be inferred. This situation mainly applies to requests for monitoring all objects applicable to an action, and event registration and unregistration requests.
Two additional OVF types enable the use of the OVF specification's schema to properly define all types of objects:
<gprop:GenericProperty> tag
<Binding> tag
The <gprop:GenericProperty> tag handles any object's property for which the OVF specification does not have a definition. The property name is defined in the key= attribute of the node and the value of the property is the contents of the node. The <binding> tag is used in the ldm list-bindings command output to define resources that are bound to other resources.
An outgoing XML response closely matches the structure of the incoming request in terms of the commands and objects included, with the addition of a <Response> section for each object and command specified, as well as an overall <Response> section for the request. The <Response> sections provide status and message information. The following example shows the structure of a response to a basic XML request.
Example 19-2 Format of a Response to a Single Command Operating on a Single Object<LDM_interface version="1.3"> <cmd> <action>Place command here</action> <data version="3.0"> <Envelope> <References/> <!-- Note a <Section> section can be here instead of <Content> --> <Content xsi:type="ovf:VirtualSystem_Type" id="Domain name"> <Section xsi:type="ovf:ResourceAllocationSection_type"> <Item> <rasd:OtherResourceType> LDom Resource Type </rasd:OtherResourceType> <gprop:GenericProperty key="Property name"> Property Value </gprop:GenericProperty> </Item> </Section> <!-- Note: More <Section> sections can be placed here --> </Content> </Envelope> <response> <status>success or failure</status> <resp_msg>Reason for failure</resp_msg> </response> </data> <!-- Note: More Data sections can be placed here --> <response> <status>success or failure</status> <resp_msg>Reason for failure</resp_msg> </response> </cmd> <!-- Note: More Command sections can be placed here --> <response> <status>success or failure</status> <resp_msg>Reason for failure</resp_msg> </response> </LDM_interface>
This <response> section, which is the direct child of the <LDM_interface> section, indicates overall success or failure of the entire request. Unless the incoming XML document is malformed, the <response> section includes only a <status> tag. If this response status indicates success, all commands on all objects have succeeded. If this response status is a failure and there is no <resp_msg> tag, then one of the commands included in the original request failed. The <resp_msg> tag is used only to describe some problem with the XML document itself.
The <response> section under the <cmd> section alerts the user to success or failure of that particular command. The <status> tag shows whether that command succeeds or fails. As with the overall response, if the command fails, the <response> section includes only a <resp_msg> tag if the contents of the <cmd> section of the request is malformed. Otherwise, the failed status means one of the objects that the command ran against caused a failure.
Finally, each <data> section in a <cmd> section also has a <response> section. This section shows whether the command being run on this particular object passes or fails. If the status of the response is SUCCESS, there is no <resp_msg> tag in the <response> section. If the status is FAILURE, there are one or more <resp_msg> tags in the <response> field depending on the errors encountered when running the command against that object. Object errors can result from problems found when running the command, or a malformed or unknown object.
In addition to the <response> section, the <data> section can contain other information. This information is in the same format as an incoming <data> field, describing the object that caused a failure. See The <data> Tag. This additional information is especially useful in the following cases:
When a command fails against a particular <data> section but passes for any additional <data> sections
When an empty <data> section is passed into a command and fails for some domains but passes for others