C H A P T E R 10 |
This chapter explains the Extensible Markup Language (XML) communication mechanism through which external user programs can interface with Logical Domains software. These basic topics are covered:
Transport – How communications are initiated between an external program and the Logical Domains (LDoms) Manager.
Protocol – Format of XML messages sent to and received from the Logical Domains Manager.
For various schemas to use with the Logical Domains Manager, see Appendix A.
External programs use the Extensible Messaging and Presence Protocol (XMPP) – RFC 3920 to communicate with the Logical Domains Manager. XMPP is supported for both local and remote connections and is on by default. To shut off a remote connection, set the ldmd/xmpp_enable SMF property to false and restart the Logical Domains Manager.
# svcadm disable ldmd # svccfg -s ldom/ldmd setprop ldmd/xmpp_enabled=false # svcadm refresh ldmd # svcadm enable ldmd |
The Logical Domains Manager implements an XMPP server which can communicate with numerous available XMPP client applications and libraries. The LDoms Manager uses the following security mechanisms:
Transport Layer Security (TLS) to secure the communication channel between the client and itself.
Simple Authentication and Security Layer (SASL) for authentication. PLAIN is the only SASL mechanism supported. You must send in a user name and password to the server, so it can authorize you before allowing monitoring or management operations.
The LDoms Manager detects whether user clients are running on the same domain as itself and, if so, does a minimal XMPP handshake with that client. Specifically, the SASL authentication step after the setup of a secure channel through TLS is skipped. Authentication and authorization are done based on the credentials of the process implementing the client interface.
Clients can choose to implement a full XMPP client or to simply run a streaming XML parser, such as the libxml2 Simple API for XML (SAX) parser. Either way the client has to handle an XMPP handshake to the point of TLS negotiation. Refer to the XMPP specification for the sequence needed.
After communication initialization is complete, LDoms-defined XML messages are sent next. There are two general types of XML messages:
Request and response messages use the <LDM_interface> tag. This type of XML message is used for communicating commands and getting results back from the LDoms Manager, analogous to executing commands using the command-line interface (CLI). This tag is also used for event registration and unregistration.
Event messages use the <LDM_event> tag. This type of XML message is used to asynchronously report events posted by the LDoms Manager.
The XML interface into LDoms has two different formats:
Another format for LDoms 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 are separated in this discussion for a better understanding of the differences between them. This document also contains an XML Schema which details the combined incoming and outgoing XML (See LDM_Event XML Schema).
An incoming XML request to the LDoms 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. Following is the structure of a basic XML command.
All commands sent to the LDoms Manager must start with the <LDM_interface> tag. Any document sent into the LDoms Manager must have only one <LDM_interface> tag contained within it. The <LDM_interface> tag must include a version attribute as shown in EXAMPLE 10-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.
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 LDoms) and <Content> and <Section> sections.
For LDoms, 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 only need to identify 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 do need to provide a <Section> section, describing the resources needed for the command, outside of 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.
To allow use of the OVF specification’s schema to properly define all types of objects, two additional OVF types have been defined:
<gprop:GenericProperty> tag (See The GenericProperty XML Schema.)
<Binding> tag (See Binding_Type XML Schema.)
The <gprop:GenericProperty> tag was defined to handle 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 list-bindings subcommand 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 as described in EXAMPLE 10-2. Following is the structure of a response to a basic XML request.
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 if 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 the command ran against caused a failure.
Finally, each <data> section in a <cmd> section also has a <response> section. This shows if 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:
In lieu of polling, you can subscribe to receive event notifications of certain state changes that occur. There are three types of events to which you can subscribe, individually or collectively. See Event Types for complete details.
Use an <LDM_interface> message to register for events. See The <LDM_interface> Tag. The action tag details the type of event for which to register or unregister and the <data> section is left empty.
<LDM_interface version="1.0"> <cmd> <action>reg-domain-events</action> <data version="3.0"/> </cmd> </LDM_interface> |
The Logical Domains Manager responds with an <LDM_interface> response message stating whether the registration or unregistration was successful.
The action string for each type of event is listed in the events subsection.
Event messages have the same format as an incoming <LDM_interface> message with the exception that the start tag for the message is <LDM_event>. The action tag of the message is the action that was performed to trigger the event. The data section of the message describes the object associated with the event; the details depend on the type of event that occurred.
The three types of events to which you can subscribe are:
All the events correspond to Logical Domains Manager (ldm) subcommands.
Domain events describe what actions can be performed directly to a domain. The following table shows the domain events which can be listed in the <action> tag in the <LDM_event> message.
Domain Events | Domain Events |
---|---|
add-domain | remove-domain |
bind-domain | unbind-domain |
start-domain | stop-domain |
domain-reset | panic-domain |
These events always contain only a <Content> tag in the OVF data section that describes to which domain the event happened. To register for the domain events, send an <LDM_interface> message with the <action> tag set to reg-domain-events. Unregistering for these events requires an <LDM_interface> message with the action tag set to unreg-domain-events.
Resource events occur when resources are added, removed, or changed in any domain. The data section for some of these events contains the <Content> tag with a <Section> tag giving a service name in the OVF data section. The following table shows events which can be listed in the <action> tag in the <LDM_event> message.
Resource Events | Resource Events |
---|---|
add-vdiskserverdevice | remove-vdiskserverdevice |
set-vdiskserverdevice | remove-vdiskserver |
set-vconscon | remove-vconscon |
set-vswitch | remove-vswitch |
remove-vdpcs |
The remaining resource events always contain only the <Content> tag in the OVF data section that describes to which domain the event happened.
Resource Events | Resource Events | Resource Events |
---|---|---|
add-vcpu | add-crypto | add-memory |
add-io | add-variable | add-vconscon |
add-vdisk | add-vdiskserver | add-vnet |
add-vswitch | add-vdpcs | add-vdpcc |
set-vcpu | set-crypto | set-memory |
set-variable | set-vnet | set-vconsole |
set-vdisk | remove-vcpu | remove-crypto |
remove-memory | remove-io | remove-variable |
remove-vdisk | remove-vnet | remove-vdpcc |
To register for the resource events, send an <LDM_interface> message with the <action> tag set to reg-resource-events. Unregistering for these events requires an <LDM_interface> message with the <action> tag set to unreg-resource-events.
Hardware events pertain to changing the physical system hardware. In the case of LDoms software, the only hardware changes that can be made are those to the service processor (SP) when a user adds, removes, or sets an SP configuration. Currently, the only three events of this type are:
The hardware events always contain only a <Section> tag in the OVF data section which describes which SP configuration to which the event is happening. To register for these events, send an <LDM_interface> message with the <action> tag set to reg-hardware-events. Unregistering for these events requires an <LDM_interface> message with the <action> tag set to unreg-hardware-events.
You can also register to listen for all three type of events without having to register for each one individually. To register for all three types of events simultaneously, send an <LDM_interface> message with the <action> tag set to reg-all-events. Unregistering for these events require an <LDM_interface> message with the <action> tag set to unreg-all-events.
The commands specified in the <action> tag, with the exception of *-*-events commands, correspond to those of the LDoms command-line interface. For details about Logical Domains Manager (ldm) subcommands, refer to the Logical Domains (LDoms) Manager 1.1 Man Page Guide or the ldm man page.
Note - The XML interface does not support the verb or command aliases supported by the Logical Domains Manager CLI. |
The supported strings in the <action> tag are as follows:
LDoms Actions | LDoms Actions | LDoms Actions |
---|---|---|
list-bindings | list-services | list-constraints |
list-devices | add-domain | remove-domain |
list-domain | start-domain | stop-domain |
bind-domain | unbind-domain | add-io |
remove-io | add-mau | set-mau |
remove-mau | add-memory | set-memory |
remove-memory | remove-reconf | add-spconfig |
set-spconfig | remove-spconfig | list-spconfig |
add-variable | set-variable | remove-variable |
list-variable | add-vconscon | set-vconscon |
remove-vconscon | set-vconsole | add-vcpu |
set-vcpu | remove-vcpu | add-vdisk |
remove-vdisk | add-vdiskserver | remove-vdiskserver |
add-vdpcc | remove-vdpcc | add-vdpcs |
remove-vdpcs | add-vdiskserverdevice | remove-vdiskserverdevice |
add-vnet | set-vnet | remove-vnet |
add-vswitch | set-vswitch | remove-vswitch |
reg-domain-events | unreg-domain-events | reg-resource-events |
unreg-resource-events | reg-hardware-events | unreg-hardware-events |
reg-all-events | unreg-all-events | migrate-domain |
Following are the Logical Domains Manager resources and the properties that can be defined for each of those resources. The resources and properties are shown in bold type in the XML examples. These examples show resources, not binding output. The constraint output can be used to create input for the Logical Domains Manager actions. The exception to this is domain migration output. See Domain Migration. Each resource is defined in a <Section> OVF section and is specified by a <rasd:OtherResourceType> tag.
The ldom_info resource is always contained within a <Content> section. The two properties within the ldom_info resource are optional properties:
A cpu resource is always contained within a <Content> section. The only property is the <rasd:AllocationUnits> tag, which specifies the number of virtual CPUs.
A mau resource is always contained within a <Content> section. The only property is the <rasd:AllocationUnits> tag, which signifies the number of MAUs or other cryptographic units.
A memory resource is always contained within a <Content> section. The only property is the <rasd:AllocationUnits> tag, which signifies the amount of memory.
A virtual disk server (vds) resource can be in a <Content> section as part of a domain description, or it can appear on its own in an <Envelope> section. The only property is the <gprop:GenericProperty> tag with a key of "service_name" and which contains the name of the vds resource being described.
A vds_volume resource can be in a <Content> section as part of a domain description, or it can appear on its own in an <Envelope> section. It must have <gprop:GenericProperty> tags with the following keys:
service_name - Name of the virtual disk server to which this volume is to be bound
block_dev - File or device name to be associated with this volume
Optionally, a vds_volume resource can also have the following properties:
A disk resource is always contained within a <Content> section. It must have <gprop:GenericProperty> tags with the following keys:
service_name - Name of the virtual disk server to which this virtual disk is to be bound
vol_name - Virtual disk service device with which this virtual disk is to be associated
Optionally, the disk resource can also have the following property:
timeout - Timeout value in seconds for establishing a connection between a virtual disk client (vdc) and a virtual disk server (vds). If there are multiple virtual disk (vdisk) paths, then the vdc can try to connect to a different vds, and the timeout ensures that a connection to any vds is established within the specified amount of time.
A vsw resource can be either in a <Content> section as part of a domain description, or it can appear on its own in an <Envelope> section. It must have <gprop:GenericProperty> tags with the following keys:
Optionally, the vsw resource can also have the following properties:
<rasd:Address> - Assigns a MAC address to the virtual switch
pvid - Port virtual local area network (VLAN) identifier (ID) indicates the VLAN of which the virtual network needs to be a member, in untagged mode.
vid - Virtual local area network (VLAN) identifier (ID) indicates the VLAN of which a virtual network and virtual switch need to be a member, in tagged mode.
A network resource is always contained within a <Content> section. It must have <gprop:GenericProperty> tags with the following keys:
Optionally, the network resource can also have the following properties:
<rasd:Address> - Assigns a MAC address to the virtual switch
pvid - Port virtual local area network (VLAN) identifier (ID) indicates the VLAN of which the virtual network needs to be a member, in untagged mode.
vid - Virtual local area network (VLAN) identifier (ID) indicates the VLAN of which a virtual network and virtual switch need to be a member, in tagged mode.
mode - hybrid to enable hybrid I/O for that virtual network.
A vcc resource can be either in a <Content> section as part of a domain description, or it can appear on its own in an <Envelope> section. It can have <gprop:GenericProperty> tags with the following keys:
A var resource is always contained within a <Content> section. It can have <gprop:GenericProperty> tags with the following keys:
A physio_device resource is always contained within a <Content> section. The only property is the <gprop:GenericProperty> tag with the following key property value:
A service processor (SP) configuration (spconfig) resource always appears on its own in an <Envelope> section. It can have <gprop:GenericProperty> tags with the following keys
This resource is only of interest in a Netra DPS environment. A vdpcs resource can be either in a <Content> section as part of a domain description, or it can appear on its own in an <Envelope> section. The only property is the <gprop:GenericProperty> tag with the following key property value:
This resource is only of interest in a Netra DPS environment. A virtual data plane channel client resource is always contained within a <Content> section. It can have <gprop:GenericProperty> tags with the following keys:
A console resource is always contained within a <Content> section. It can have <gprop:GenericProperty> tags with the following keys:
This example shows what is contained in the <data> section for a migrate-domain subcommand.
First <Content> node (without an <ldom_info> section) is the source domain to migrate.
Second <Content> node (with an <ldom_info> section) is the target domain to which to migrate. The source and target domain names can be the same.
The <ldom_info> section for the target domain describes the machine to which to migrate and the details needed to migrate to that machine:
Note - The Logical Domains Manager uses sasl_decode64() to decode the target user name and password and uses sasl_encode64() to encode these values. SASL 64 encoding is equivalent to base64 encoding. |
Copyright © 2008, Sun Microsystems, Inc. All rights reserved.