Chapter 4 Setting Up Services and Logical Domains

This chapter describes the procedures necessary to set up default services, your control domain, and guest domains.

You can also use the Logical Domains Configuration Assistant to configure logical domains and services. See Appendix D, Logical Domains Configuration Assistant.

This chapter covers the following topics:

• Output Messages

• Creating Default Services

• Initial Configuration of the Control Domain

• Rebooting to Use Logical Domains

• Enabling Networking Between the Control/Service Domain and Other Domains

• Enabling the Virtual Network Terminal Server Daemon

• Creating and Starting a Guest Domain

• Installing Solaris OS on a Guest Domain

• Saving Logical Domain Configurations for Future Rebuilding

• Rebuilding the Control Domain

• Configuring Domain Dependencies

Output Messages

You receive different output messages from the commands you use to create default services and to set up the control (primary) domain depending on your platform:

• Sun UltraSPARC T1 processors

• Sun UltraSPARC T2 and T2 Plus processors

Sun UltraSPARC T1 Processors

You receive the following notice after the setup commands for the primary domain if you are using a server with a Sun UltraSPARC T1 processor:

Notice: the LDom Manager is running in configuration mode. Any 
configuration changes made will only take effect after the machine
configuration is downloaded to the system controller and the host
is reset.

Sun UltraSPARC T2 and T2 Plus Processors

You receive the following message after the first operation that cannot be performed dynamically on any device or for any service on the primary domain if you are using a server with a Sun UltraSPARC T2 or T2 Plus processor:

Initiating delayed reconfigure operation on LDom primary. All
configuration changes for other LDoms are disabled until the
LDom reboots, at which time the new configuration for LDom
primary will also take effect.

You receive the following notice after every subsequent operation on the primary domain until reboot if you are using a server with a Sun UltraSPARC T2 or T2 Plus processor:

Notice: LDom primary is in the process of a delayed
reconfiguration. Any changes made to this LDom will only take
effect after it reboots.

Creating Default Services

You must create the following virtual default services initially to be able to use them later:

• vdiskserver – virtual disk server

• vswitch – virtual switch service

• vconscon – virtual console concentrator service

Create Default Services

1. Create a virtual disk server (vds) to allow importing virtual disks into a logical domain.

   For example, the following command adds a virtual disk server (primary-vds0) to the control domain (primary).

   primary# ldm add-vds primary-vds0 primary

2. Create a virtual console concentrator (vcc) service for use by the virtual network terminal server daemon (vntsd) and as a concentrator for all logical domain consoles.

   For example, the following command would add a virtual console concentrator service (primary-vcc0) with a port range from 5000 to 5100 to the control domain (primary).

   primary# ldm add-vcc port-range=5000-5100 primary-vcc0 primary

3. Create a virtual switch service (vsw) to enable networking between virtual network (vnet) devices in logical domains.

   Assign a GLDv3-compliant network adapter to the virtual switch if each of the logical domains needs to communicate outside the box through the virtual switch.

   For example, the following command would add a virtual switch service (primary-vsw0) on network adapter driver e1000g0 to the control domain (primary).

   primary# ldm add-vsw net-dev=e1000g0 primary-vsw0 primary

   This command automatically allocates a MAC address to the virtual switch. You can specify your own MAC address as an option to the ldm add-vsw command. However, in that case, it is your responsibility to ensure that the MAC address specified does not conflict with an already existing MAC address.

   If the virtual switch being added replaces the underlying physical adapter as the primary network interface, it must be assigned the MAC address of the physical adapter, so that the Dynamic Host Configuration Protocol (DHCP) server assigns the domain the same IP address. See Enabling Networking Between the Control/Service Domain and Other Domains.

   primary# ldm add-vsw mac-addr=2:04:4f:fb:9f:0d net-dev=e1000g0 primary-vsw0 primary

4. Verify the services have been created by using the list-services subcommand.

   Your output should look similar to the following.

   primary# ldm list-services primary VDS     NAME VOLUME OPTIONS DEVICE     primary-vds0   VCC     NAME PORT-RANGE     primary-vcc0 5000-5100   VSW     NAME MAC NET-DEV DEVICE MODE     primary-vsw0 02:04:4f:fb:9f:0d e1000g0 switch@0 prog,promisc

Initial Configuration of the Control Domain

Initially, all system resources are allocated to the control domain. To allow the creation of other logical domains, you must release some of these resources.

Set Up the Control Domain

This procedure contains examples of resources to set for your control domain. These numbers are examples only, and the values used might not be appropriate for your control domain.

1. Determine whether you have cryptographic devices in the control domain.

   primary# ldm list -o crypto primary

2. Assign cryptographic resources to the control domain.

   ---

   Note –

   If you have any cryptographic devices in the control domain, you cannot dynamically reconfigure CPUs. So if you are not using cryptographic devices, set-mau to 0.

   ---

   The following example would assign one cryptographic resource to the control domain, primary. This leaves the remainder of the cryptographic resources available to a guest domain.

   primary# ldm set-mau 1 primary

3. Assign virtual CPUs to the control domain.

   For example, the following command would assign 4 virtual CPUs to the control domain, primary. This leaves the remainder of the virtual CPUs available to a guest domain.

   primary# ldm set-vcpu 4 primary

4. Assign memory to the control domain.

   For example, the following command would assign 4 gigabytes of memory to the control domain, primary. This leaves the remainder of the memory available to a guest domain.

   primary# ldm set-memory 4G primary

5. Add a logical domain machine configuration to the service processor (SP).

   For example, the following command would add a configuration called initial.

   primary# ldm add-config initial

6. Verify that the configuration is ready to be used at the next reboot.

   primary# ldm list-config factory-default initial [next poweron]

   This list subcommand shows the initial configuration set will be used once you powercycle.

Rebooting to Use Logical Domains

You must reboot the control domain for the configuration changes to take effect and for the resources to be released for other logical domains to use.

Reboot

1. Shut down and reboot the control domain.

   primary# shutdown -y -g0 -i6

   ---

   Note –

   Either a reboot or powercycle instantiates the new configuration. Only a powercycle actually boots the configuration saved to the service processor (SP), which is then reflected in the list-config output.

   ---

Enabling Networking Between the Control/Service Domain and Other Domains

By default, networking between the control domain and other domains in the system is disabled. To enable this, the virtual switch device should be configured as a network device. The virtual switch can either replace the underlying physical device (e1000g0 in this example) as the primary interface or be configured as an additional network interface in the domain.

Perform the following procedure from the control domain's console, as the procedure could temporarily disrupt network connectivity to the domain.

Configure the Virtual Switch as the Primary Interface

1. Print out the addressing information for all interfaces.

   primary# ifconfig -a

2. Plumb the virtual switch. In this example, vsw0 is the virtual switch being configured.

   primary# ifconfig vsw0 plumb

3. (Optional) To obtain the list of all virtual switch instances in a domain, you can list them.

   primary# /usr/sbin/dladm show-link | grep vsw vsw0            type: non-vlan  mtu: 1500       device: vsw0

4. Unplumb the physical network device assigned to the virtual switch (net-dev), which is e1000g0 in this example.

   primary# ifconfig e1000g0 down unplumb

5. To migrate properties of the physical network device (e1000g0) to the virtual switch (vsw0) device, do one of the following:

   • If networking is configured using a static IP address, reuse the IP address and netmask of e1000g0 for vsw0.

     primary# ifconfig vsw0 IP_of_e1000g0 netmask netmask_of_e1000g0 broadcast + up

   • If networking is configured using DHCP, enable DHCP for vsw0.

     primary# ifconfig vsw0 dhcp start

6. Make the required configuration file modifications to make this change permanent.

   primary# mv /etc/hostname.e1000g0 /etc/hostname.vsw0 primary# mv /etc/dhcp.e1000g0 /etc/dhcp.vsw0

   ---

   Note –

   If necessary, you can also configure the virtual switch as well as the physical network device. In this case, plumb the virtual switch as in Step 2, and do not unplumb the physical device (skip Step 4). You must then configure the virtual switch with either a static IP address or a dynamic IP address. You can obtain a dynamic IP address from a DHCP server. For additional information and an example of this case, see Configuring Virtual Switch and Service Domain for NAT and Routing.

   ---

Enabling the Virtual Network Terminal Server Daemon

You must enable the virtual network terminal server daemon (vntsd) to provide access to the virtual console of each logical domain. Refer to the vntsd(1M) man page for information about how to use this daemon.

Enable the Virtual Network Terminal Server Daemon

Be sure that you have created the default service vconscon (vcc) on the control domain before you enable vntsd. See Creating Default Services for more information.

1. Use the svcadm(1M) command to enable the virtual network terminal server daemon, vntsd(1M).

   primary# svcadm enable vntsd

2. Use the svcs(1) command to verify that the vntsd is enabled.

   primary# svcs -l vntsd fmri         svc:/ldoms/vntsd:default enabled      true state        online next_state   none state_time   Sat Jan 27 03:14:17 2007 logfile      /var/svc/log/ldoms-vntsd:default.log restarter    svc:/system/svc/restarter:default contract_id  93 dependency   optional_all/error svc:/milestone/network (online) dependency   optional_all/none svc:/system/system-log (online)

Creating and Starting a Guest Domain

The guest domain must run an operating system that understands both the sun4v platform and the virtual devices presented by the hypervisor. Currently, this means that you must run at least the Solaris 10 11/06 OS. Running the Solaris 10 5/09 OS provides you with all the Logical Domains 1.2 features. See the Logical Domains 1.2 Release Notes for any specific patches that might be necessary. Once you have created default services and reallocated resources from the control domain, you can create and start a guest domain.

Create and Start a Guest Domain

1. Create a logical domain.

   For example, the following command would create a guest domain named ldg1.

   primary# ldm add-domain ldg1

2. Add CPUs to the guest domain.

   For example, the following command would add four virtual CPUs to guest domain ldg1.

   primary# ldm add-vcpu 4 ldg1

3. Add memory to the guest domain.

   For example, the following command would add 2 gigabytes of memory to guest domain ldg1.

   primary# ldm add-memory 2G ldg1

4. Add a virtual network device to the guest domain.

   For example, the following command would add a virtual network device with these specifics to the guest domain ldg1.

   primary# ldm add-vnet vnet1 primary-vsw0 ldg1

   Where:

   • vnet1 is a unique interface name to the logical domain, assigned to this virtual network device instance for reference on subsequent set-vnet or remove-vnet subcommands.

   • primary-vsw0 is the name of an existing network service (virtual switch) to which to connect.

   ---

   Note –

   Steps 5 and 6 are simplified instructions for adding a virtual disk server device (vdsdev) to the primary domain and a virtual disk (vdisk) to the guest domain. To learn how ZFS^TM volumes and file systems can be used as virtual disks, see Export a ZFS Volume as a Single Slice Disk and Using ZFS With Virtual Disks.

   ---

5. Specify the device to be exported by the virtual disk server as a virtual disk to the guest domain.

   You can export a physical disk, disk slice, volumes, or file as a block device. The following examples show a physical disk and a file.

   • Physical Disk Example. The first example adds a physical disk with these specifics.

     primary# ldm add-vdsdev /dev/dsk/c2t1d0s2 vol1@primary-vds0

     Where:

     • /dev/dsk/c2t1d0s2 is the path name of the actual physical device. When adding a device, the path name must be paired with the device name.

     • vol1 is a unique name you must specify for the device being added to the virtual disk server. The volume name must be unique to this virtual disk server instance, because this name is exported by this virtual disk server to the clients for adding. When adding a device, the volume name must be paired with the path name of the actual device.

     • primary-vds0 is the name of the virtual disk server to which to add this device.

   • File Example. This second example is exporting a file as a block device.

     primary# ldm add-vdsdev backend vol1@primary-vds0

     Where:

     • backend is the path name of the actual file exported as a block device. When adding a device, the backend must be paired with the device name.

     • vol1 is a unique name you must specify for the device being added to the virtual disk server. The volume name must be unique to this virtual disk server instance, because this name is exported by this virtual disk server to the clients for adding. When adding a device, the volume name must be paired with the path name of the actual device.

     • primary-vds0 is the name of the virtual disk server to which to add this device.

6. Add a virtual disk to the guest domain.

   The following example adds a virtual disk to the guest domain ldg1.

   primary# ldm add-vdisk vdisk1 vol1@primary-vds0 ldg1

   Where:

   • vdisk1 is the name of the virtual disk.

   • vol1 is the name of the existing volume to which to connect.

   • primary-vds0 is the name of the existing virtual disk server to which to connect.

   ---

   Note –

   The virtual disks are generic block devices that are backed by different types of physical devices, volumes, or files. A virtual disk is not synonymous with a SCSI disk and, therefore, excludes the target ID in the disk label. Virtual disks in a logical domain have the following format: cNdNsN, where cN is the virtual controller, dN is the virtual disk number, and sN is the slice.

   ---

7. Set auto-boot and boot-device variables for the guest domain.

   The first example command sets auto-boot\? to true for guest domain ldg1.

   primary# ldm set-var auto-boot\?=true ldg1

   The second example command sets boot-device to vdisk for the guest domain ldg1.

   primary# ldm set-var boot-device=vdisk ldg1

8. Bind resources to the guest domain ldg1 and then list the domain to verify that it is bound.

   primary# ldm bind-domain ldg1 primary# ldm list-domain ldg1 NAME          STATE    FLAGS  CONS   VCPU MEMORY UTIL UPTIME ldg1          bound    -----  5000   4    2G

9. To find the console port of the guest domain, you can look at the output of the preceding list-domain subcommand.

   You can see under the heading Cons that logical domain guest 1 (ldg1) has its console output bound to port 5000.

10. Connect to the console of a guest domain from another terminal by logging into the control domain and connecting directly to the console port on the local host.

    $ ssh admin@controldom.domain $ telnet localhost 5000

11. Start the guest domain ldg1.

    primary# ldm start-domain ldg1

Installing Solaris OS on a Guest Domain

This section provides instructions for several different ways you can install the Solaris OS on a guest domain.

Install Solaris OS on a Guest Domain From a DVD

1. Insert the Solaris 10 OS DVD into the DVD drive.

2. Stop the volume management daemon, vold(1M) on the primary domain.

   primary# svcadm disable volfs

3. Stop and unbind the guest domain (ldg1). Then add the DVD with DVDROM media as a secondary volume (dvd_vol@primary-vds0) and virtual disk (vdisk_cd_media), for example.

   c0t0d0s2 is where the Solaris OS media resides

   primary# ldm stop ldg1 primary# ldm unbind ldg1 primary# ldm add-vdsdev /dev/dsk/c0t0d0s2 dvd_vol@primary-vds0 primary# ldm add-vdisk vdisk_cd_media dvd_vol@primary-vds0 ldg1

4. Check to see that the DVD is added as a secondary volume and virtual disk.

   primary# ldm list-bindings NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME primary active -n-cv SP 4 4G 0.2% 22h 45m ... VDS   NAME VOLUME OPTIONS DEVICE   primary-vds0     vol1                            /dev/dsk/c2t1d0s2   dvd_vol                                          /dev/dsk/c0t0d0s2 .... ------------------------------------------------------------------------------ NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME ldg1 inactive ----- 60 6G ... DISK   NAME VOLUME TOUT DEVICE SERVER   vdisk1 vol1@primary-vds0   vdisk_cd_media dvd_vol@primary-vds0 ....

5. Bind and start the guest domain (ldg1).

   primary# ldm bind ldg1 primary# ldm start ldg1 LDom ldg1 started primary# telnet localhost 5000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.   Connecting to console "ldg1" in group "ldg1" .... Press ~? for control options ..

6. Show the device aliases in the client OpenBoot^TM PROM.

   In this example, see the device aliases for vdisk_cd_media, which is the Solaris DVD, and vdisk1, which is a virtual disk on which you can install the Solaris OS.

   ok devalias vdisk_cd_media  /virtual-devices@100/channel-devices@200/disk@1 vdisk1          /virtual-devices@100/channel-devices@200/disk@0 vnet1           /virtual-devices@100/channel-devices@200/network@0 virtual-console /virtual-devices/console@1 name            aliases

7. On the guest domain's console, boot from vdisk_cd_media (disk@1) on slice f.

   ok boot vdisk_cd_media:f -v Boot device: /virtual-devices@100/channel-devices@200/disk@1:f File and args: -s SunOS Release 5.10 Version Generic_139555-08 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.

8. Continue with the Solaris OS installation menu.

Install Solaris OS on a Guest Domain From a Solaris ISO File

1. Unbind the guest domain.

   The following shows ldg1 as the guest domain:

   primary# ldm unbind ldg1

2. Add the Solaris ISO file as a secondary volume and virtual disk.

   The following uses solarisdvd.iso as the Solaris ISO file, iso_vol@primary-vds0 as a secondary volume, and vdisk_iso as a virtual disk:

   primary# ldm add-vdsdev /export/solarisdvd.iso iso_vol@primary-vds0 primary# ldm-vdisk vdisk vdisk_iso iso_vol@primary-vds0 ldg1

3. Check to see that the Solaris ISO file is added as a secondary volume and virtual disk.

   primary# ldm list-bindings NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME primary active -n-cv SP 4 4G 0.2% 22h 45m ... VDS   NAME VOLUME OPTIONS DEVICE   primary-vds0     vol1                            /dev/dsk/c2t1d0s2   iso_vol                                          /export/solarisdvd.iso .... ------------------------------------------------------------------------------ NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME ldg1 inactive ----- 60 6G ... DISK   NAME VOLUME TOUT DEVICE SERVER   vdisk1 vol1@primary-vds0   vdisk_iso iso_vol@primary-vds0 ....

4. Bind and start the guest domain (ldg1).

   primary# ldm bind ldg1 primary# ldm start ldg1 LDom ldg1 started primary# telnet localhost 5000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.   Connecting to console "ldg1" in group "ldg1" .... Press ~? for control options ..

5. Show the device aliases in the client OpenBoot PROM.

   In this example, see the device aliases for vdisk_iso, which is the Solaris ISO image, and vdisk_install, which is the disk space.

   ok devalias vdisk_iso       /virtual-devices@100/channel-devices@200/disk@1 vdisk1          /virtual-devices@100/channel-devices@200/disk@0 vnet1           /virtual-devices@100/channel-devices@200/network@0 virtual-console /virtual-devices/console@1 name            aliases

6. On the guest domain's console, boot from vdisk_iso (disk@1) on slice f.

   ok boot vdisk_iso:f -v Boot device: /virtual-devices@100/channel-devices@200/disk@1:f File and args: -s SunOS Release 5.10 Version Generic_139555-08 64-bit Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.

7. Continue with the Solaris OS installation menu.

Jump-Start a Guest Domain

1. To jump-start a guest domain, use a normal JumpStart procedure with the following profile syntax changes from a regular Solaris OS JumpStart procedure to a JumpStart procedure specific to Logical Domains as shown in the following two examples.

   Normal JumpStart Profile

   filesys c1t1d0s0 free / filesys c1t1d0s1 2048 swap filesys c1t1d0s5 120 /spare1 filesys c1t1d0s6 120 /spare2

   Virtual disk device names in a logical domain differ from physical disk device names in that they do not contain a target ID (tN) in the device name. Instead of the normal cNtNdNsN format, virtual disk device names are of the format cNdNsN, where cN is the virtual controller, dN is the virtual disk number, and sN is the slice. Modify your JumpStart profile to reflect this change as in the following profile example.

   Actual Profile Used for a Logical Domain

   filesys c0d0s0 free / filesys c0d0s1 2048 swap filesys c0d0s5 120 /spare1 filesys c0d0s6 120 /spare2

   ---

   Note –

   You must use the MAC address of the virtual network (vnet) device as reported by the ldm(1M) command for your jumpstart configuration and not the one reported in the banner for the guest.

   ---

Saving Logical Domain Configurations for Future Rebuilding

The basic process is to save the constraints information for each domain into an XML file, which can then be re-issued to the Logical Domains Manager, for example, after a hardware failure to rebuild a desired configuration.

Rebuild Guest Domain Configurations works for guest domains, not the control domain. You can save the control (primary) domain's constraints to an XML file, but you cannot feed it back into the ldm add-domain -i command. However, you can use the resource constraints from the XML file to create the CLI commands to reconfigure your primary domain. See Rebuilding the Control Domain for instructions on how to translate typical XML output from an ldm list-constraints -x primary command into the CLI commands needed to reconfigure a primary domain.

The method that follows does not preserve actual bindings, only the constraints used to create those bindings. This means that, after this procedure, the domains will have the same virtual resources, but will not necessarily be bound to the same physical resources.

Save All Logical Domain Configurations

1. For each logical domain, create an XML file containing the domain's constraints.

   # ldm list-constraints -x ldom > ldom.xml

   The following example shows how to create an XML file, primary.xml, that contains the primary domain's constraints:

   # ldm list-constraints -x primary > primary.xml

Rebuild Guest Domain Configurations

1. Run the following commands for each guest domain's XML file you created.

   # ldm add-domain -i ldom.xml # ldm bind-domain ldom # ldm start-domain ldom

Rebuilding the Control Domain

This section provides instructions for how to translate typical XML output from an ldm list-constraints -x primary command into the CLI commands needed to reconfigure a primary domain. The resources and properties that you use to translate XML into CLI commands are shown in bold type in the sample XML output. Refer to the ldm(1M) man page for complete information about the CLI commands.

A sample output from a ldm list-constraints -x primary command follows.

Example 4–1 Sample XML Output From list-constraints Subcommand

<?xml version="1.0"?>
<LDM_interface version="1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="./schemas/combined-v3.xsd"
        xmlns:ovf="./schemas/envelope"
        xmlns:rasd="./schemas/CIM_ResourceAllocationSettingData"
        xmlns:vssd="./schemas/CIM_VirtualSystemSettingData"
        xmlns:gprop="./schemas/GenericProperty" xmlns:bind="./schemas/Binding">
  <data version="3.0">
    <Envelope>
      <References/>
      <Content xsi:type="ovf:VirtualSystem_Type" ovf:id="primary">
        <Section xsi:type="ovf:ResourceAllocationSection_Type">
          <Item>
            <rasd:OtherResourceType>ldom_info</rasd:OtherResourceType>
            <rasd:Address>00:03:ba:d8:ba:f6</rasd:Address>
            <gprop:GenericProperty key="hostid">0x83d8baf6</gprop:GenericProperty>
          </Item>
        </Section>
        <Section xsi:type="ovf:VirtualHardwareSection_Type">
          <Item>
            <rasd:OtherResourceType>cpu</rasd:OtherResourceType>
            <rasd:AllocationUnits>4</rasd:AllocationUnits>
          </Item>
        </Section>
        <Section xsi:type="ovf:VirtualHardwareSection_Type">
          <Item>
            <rasd:OtherResourceType>mau</rasd:OtherResourceType>
            <rasd:AllocationUnits>1</rasd:AllocationUnits>
          </Item>
        </Section>
        <Section xsi:type="ovf:VirtualHardwareSection_Type">
          <Item>
            <rasd:OtherResourceType>memory</rasd:OtherResourceType>
            <rasd:AllocationUnits>4G</rasd:AllocationUnits>
          </Item>
        </Section>
        <Section xsi:type="ovf:VirtualHardwareSection_Type">
          <Item>
            <rasd:OtherResourceType>physio_device</rasd:OtherResourceType>
            <gprop:GenericProperty key="name">pci@7c0</gprop:GenericProperty>
          </Item>
        </Section>
        <Section xsi:type="ovf:VirtualHardwareSection_Type">
          <Item>
            <rasd:OtherResourceType>vsw</rasd:OtherResourceType>
            <rasd:Address>auto-allocated</rasd:Address>
            <gprop:GenericProperty key="service_name">primary-vsw0</gprop:GenericProperty>
            <gprop:GenericProperty key="dev_path">e1000g0</gprop:GenericProperty>
            <gprop:GenericProperty key="default-vlan-id">1</gprop:GenericProperty>
            <gprop:GenericProperty key="pvid">1</gprop:GenericProperty>
          </Item>
        </Section>
        <Section xsi:type="ovf:VirtualHardwareSection_Type">
          <Item>
            <rasd:OtherResourceType>vcc</rasd:OtherResourceType>
            <gprop:GenericProperty key="service_name">primary-vcc0</gprop:GenericProperty>
            <gprop:GenericProperty key="min_port">5000</gprop:GenericProperty>
            <gprop:GenericProperty key="max_port">6000</gprop:GenericProperty>
          </Item>
        </Section>
        <Section xsi:type="ovf:VirtualHardwareSection_Type">
          <Item>
            <rasd:OtherResourceType>vds</rasd:OtherResourceType>
            <gprop:GenericProperty key="service_name">primary-vds0</gprop:GenericProperty>
          </Item>
        </Section>
        <Section xsi:type="ovf:VirtualHardwareSection_Type">
          <Item>
            <rasd:OtherResourceType>vds_volume</rasd:OtherResourceType>
            <gprop:GenericProperty key="vol_name">primary-vds0-vol0</gprop:GenericProperty>
            <gprop:GenericProperty
              key"block_dev">/opt/SUNWldm/domain_disks/testdisk.nv.53.1</gprop:GenericProperty>
            <gprop:GenericProperty key="service_name">primary-vds0</gprop:GenericProperty>
          </Item>
        </Section>
      </Content>
    </Envelope>
  </data>
</LDM_interface>

The <Content> tag and the <Section>s inside the <Content> tag describe the primary domain and all the resources contained in the primary domain. The <rasd:...> and <gprop:GenericProperty...> tags within <Item>s describe the properties needed for each resource. You can go through each resource in each <Section> and construct CLI commands based on the resource's constraints. The following sections identify some of the more common resources in the domain XML description and the equivalent CLI command for that resource.

Logical Domain Information (ldom_info) Section

This section describes the primary domain's MAC address and host ID information. Because this is the primary domain, you cannot set this information; it is automatically set.

Example 4–2 Logical Domains Information (ldom_info) Section

<Section> xsi:type="ovf:ResourceAllocationSection_Type">
  <Item>
    <rasd:OtherResourceType>ldom_info</rasd:OtherResourceType>
    <rasd:Address>00:03:ba:d8:ba:f6</rasd:Address>
    <gprop:GenericProperty key="hostid">0x83d8baf6</gprop:GenericProperty>
  </Item>
</Section>

In this example, the logical domain information (ldom_info) is as follows:

• (MAC) Address - 00:03:ba:d8:ba:f6

• hostid - 0x83d8baf6

Cryptographic (mau) Section

This section describes the number of cryptographic units (maus) allocated to the primary domain.

Even though the mau section comes after the cpu section in the XML listing, you must run the set-mau subcommand before the set-cpu subcommand, because you cannot remove CPUs from a domain without also removing their corresponding cryptographic units.

Example 4–3 Cryptographic (mau) Section

<Section> xsi:type="ovf:VirtualHardwareSection_Type"
  <Item>
    <rasd:OtherResourceType>mau</rasd:OtherResourceType>
    <rasd:AllocationUnits>1</rasd:AllocationUnits>
  </Item>
</Section>

This section is equivalent to the following CLI command:

# ldm set-mau 1 primary

CPU (cpu) Section

This section describes the number of virtual cpus allocated to the primary domain.

Example 4–4 CPU (cpu) Section

<Section> xsi:type="ovf:VirtualHardwareSection_Type"
  <Item>
    <rasd:OtherResourceType>cpu</rasd:OtherResourceType>
    <rasd:AllocationUnits>4</rasd:AllocationUnits>
  </Item>
</Section>

This section is equivalent to the following CLI command:

# ldm set-vcpu 4 primary

Memory (memory) Section

This section describes the amount of memory allocated to the primary domain.

Example 4–5 Memory (memory) Section

<Section> xsi:type="ovf:VirtualHardwareSection_Type"
  <Item>
    <rasd:OtherResourceType>memory</rasd:OtherResourceType>
    <rasd:AllocationUnits>4G</rasd:AllocationUnits>
  </Item>
</Section>

This section is equivalent to the following CLI command:

# ldm set-memory 4G primary

Physical Input/Output (physio_device) Section

This section describes the physical I/O buses that you want to remain in the primary domain.

Example 4–6 Physical I/O (physio_device) Section

<Section> xsi:type="ovf:VirtualHardwareSection_Type"
  <Item>
    <rasd:OtherResourceType>physio_device</rasd:OtherResourceType>
    <gprop:GenericProperty key="name">pci@7c0</gprop:GenericProperty>
  </Item>
</Section>

To set your primary domain with the same I/O devices as previously configured, you first need to list the I/O devices that are configured on startup.

# ldm list -l primary
....
IO
    DEVICE           PSEUDONYM        OPTIONS
    pci@7c0          bus_b
    pci@780          bus_a
....

In Example 4–6, the bus previously configured to remain in the primary domain was pci@7c0. If there are no other physio-device sections in the XML, the pci@780 bus must be removed.

This section is equivalent to the following CLI command:

# ldm remove-io pci@780 primary

Virtual Switch (vsw) Section

This section describes any virtual switches (vsws) allocated to the primary domain.

<Section xsi:type="ovf:VirtualHardwareSection_Type">
  <Item>
    <rasd:OtherResourceType>vsw</rasd:OtherResourceType>
    <rasd:Address>auto-allocated</rasd:Address>
    <gprop:GenericProperty key="service_name">primary-vsw0</gprop:GenericProperty>
    <gprop:GenericProperty key="dev_path">e1000g0</gprop:GenericProperty>
    <gprop:GenericProperty key="mode">sc</gprop:GenericProperty>
    <gprop:GenericProperty key="default-vlan-id">1</gprop:GenericProperty>
    <gprop:GenericProperty key="pvid">1</gprop:GenericProperty>
  </Item>
</Section>

Where:

• The <rasd:Address> tag describes the MAC address to be used for the virtual switch. If the value of this tag is auto-allocated, you do not need to supply a MAC address.

• The XML key property service_name is the name of the virtual switch; in this case, primary-vsw0.

• The XML key property dev_path is the path name for the actual network device; in this case net-dev=e1000g.

• The XML key property mode indicates sc for SunCluster heartbeat support.

Some of the values in this section are default values, such as the default-vlan-id (1) and pvid (1), so the section is equivalent to the following CLI command:

# ldm add-vswitch net-dev=e1000g primary-vsw0 primary

Virtual Console Concentrator (vcc) Section

This section describes any virtual console concentrator (vcc) allocated to the primary domain.

<Section xsi:type="ovf:VirtualHardwareSection_Type">
  <Item>
    <rasd:OtherResourceType>vcc</rasd:OtherResourceType>
    <gprop:GenericProperty key="service_name">primary-vcc0</gprop:GenericProperty>
    <gprop:GenericProperty key="min_port">5000</gprop:GenericProperty>
    <gprop:GenericProperty key="max_port">6000</gprop:GenericProperty>
  </Item>
</Section>

Where the XML key property service_name is the name of the vcc service; in this case, primary-vcc0.

This section is the equivalent of the following CLI command:

# ldm add-vcc port-range=5000-6000 primary-vcc0 primary

Virtual Disk Server (vds) Section

This section describes any virtual disk server (vds) allocated to the primary domain.

<Section xsi:type="ovf:VirtualHardwareSection_Type">
  <Item>
    <rasd:OtherResourceType>vds</rasd:OtherResourceType>
    <gprop:GenericProperty key="service_name">primary-vds0</gprop:GenericProperty>
  </Item>
</Section>

Where the XML key property service_name is the service name for this instance of the virtual disk server; in this case, primary-vds0. The service_name must be unique among all virtual disk server instances on the server.

This section is the equivalent of the following CLI command:

# ldm add-vds primary-vds0 primary

Virtual Disk Server Device (vdsdev) Section

This section describes any device (vdsdev) exported by the virtual disk server that is allocated to the primary domain.

<Section xsi:type="ovf:VirtualHardwareSection_Type">
  <Item>
    <rasd:OtherResourceType>vds_volume</rasd:OtherResourceType>
    <gprop:GenericProperty key="vol_name">vdsdev0</gprop:GenericProperty>
    <gprop:GenericProperty key="service_name">primary-vds0</gprop:GenericProperty>
    <gprop:GenericProperty
      key="block_dev">/opt/SUNWldm/domain_disks/testdisk1</gprop:GenericProperty>
    <gprop:GenericProperty key="vol_opts">ro</gprop:GenericProperty>
    <gprop:GenericProperty key="mpgroup">mpgroup-name</gprop:GenericProperty>
  </Item>
</Section>

Where:

• The XML key properties volume name (vol_name) and service name (service_name) are paired in the CLI command; in this case, vdsdev0@primary-vds0.

• The XML key property block_dev is the backend argument in the equivalent CLI command, which is the location where data of a virtual disk are stored; in this case, /opt/SUNWldm/domain_disks/testdisk1.

• The optional XML key property vol_opts is one or more of the following, comma-separated, within one string: {ro,slice,excl}.

• The optional XML key property mpgroup is the name of the multipath (failover) group.

This section is equivalent to the following CLI command:

# ldm add-vdsdev options=ro mpgroup=mpgroup-name
/opt/SUNWldm/domain_disks/testdisk1 vdsdev0@primary-vds0

Configuring Domain Dependencies

You can use the Logical Domains Manager to establish dependency relationships between domains. A domain that has one or more domains that depend on it is called a master domain. A domain that depends on another domain is called a slave domain.

Each slave domain can specify up to four master domains by setting the master property. For example, the pine slave domain specifies its four master domains in the following comma-separated list:

# ldm add-domain master=apple,lemon,orange,peach pine

Each master domain can specify what happens to its slave domains in the event that the master domain fails. For instance, if a master domain fails, it might require its slave domains to panic. If a slave domain has more than one master domain, the first master domain to fail triggers its defined failure policy on all of its slave domains.

If more than one master domain fails simultaneously, only one of the specified failure policies will be enforced on all the affected slave domains. For example, if the failed master domains have failure policies of stop and panic, all slave domains will be either stopped or panicked.

The master domain's failure policy is controlled by setting one of the following values to the failure-policy property:

• ignore ignores any slave domains when the master domain fails.

• panic panics any slave domains when the master domain fails.

• reset resets any slave domains when the master domain fails.

• stop stops any slave domains when the master domain fails.

In this example, the master domains specify their failure policy as follows:

# ldm set-domain failure-policy=ignore apple
# ldm set-domain failure-policy=panic lemon
# ldm set-domain failure-policy=reset orange
# ldm set-domain failure-policy=stop peach

You can use this mechanism to create explicit dependencies between domains. For example, a guest domain implicitly depends on the service domain to provide its virtual devices. A guest domain's I/O is blocked when the service domain on which it depends is not up and running. By defining a guest domain as a slave of its service domain, you can specify the behavior of the guest domain when its service domain goes down. When no such dependency is established, a guest domain just waits for its service domain to return to service.

The Logical Domains Manager does not permit you to create domain relationships that create a dependency cycle. For more information, see Dependency Cycles.

For domain dependency XML examples, see Example 10–6.

Domain Dependency Examples

The following examples show how to configure domain dependencies.

• The first command creates a master domain called twizzle. This command uses failure-policy=reset to specify that slave domains reset if the twizzle domain fails. The second command modifies a master domain called primary. This command uses failure-policy=panic to specify that slave domains panic if the primary domain fails. The third command creates a slave domain called chocktaw that depends on two master domains, twizzle and primary. The slave domain uses master=twizzle,primary to specify its master domains. In the event either the twizzle or primary domain fails, the chocktaw domain will reset or panic. The first master domain to fail is the one responsible for determining the behavior of the slave domains.

  # ldm add-domain failure-policy=reset twizzle # ldm set-domain failure-policy=panic primary # ldm add-domain master=twizzle,primary chocktaw

• This example shows how to use the ldm set-domain command to modify the orange domain to assign primary as the master domain. The second command uses the ldm set-domain command to assign orange and primary as master domains for the tangerine domain. The third command lists information about all of these domains.

  # ldm set-domain master=primary orange # ldm set-domain master=orange,primary tangerine # ldm list -o domain NAME STATE FLAGS UTIL primary active -n-cv- 0.2% SOFTSTATE Solaris running HOSTID 0x83d8b31c CONTROL failure-policy=ignore DEPENDENCY master= ------------------------------------------------------------------------------ NAME STATE FLAGS UTIL orange bound ------ HOSTID 0x84fb28ef CONTROL failure-policy=stop DEPENDENCY master=primary VARIABLES test_var=Aloha ------------------------------------------------------------------------------ NAME STATE FLAGS UTIL tangerine bound ------ HOSTID 0x84f948e9 CONTROL failure-policy=ignore DEPENDENCY master=orange,primary VARIABLES test_var=A hui hou

• The following shows an example listing with parseable output:

  # ldm list -o domain -p VERSION 1.4 DOMAIN|name=primary|state=active|flags=normal,control,vio-service|util=0.3 softstate=Solaris running HOSTID|hostid=0x83d8b31c CONTROL|failure-policy=ignore DEPENDENCY|master= DOMAIN|name=orange|state=bound|flags=|util= HOSTID|hostid=0x84fb28ef CONTROL|failure-policy=stop DEPENDENCY|master=primary VARIABLES|test_var=Aloha DOMAIN|name=tangerine|state=bound|flags=|util= HOSTID|hostid=0x84f948e9 CONTROL|failure-policy=ignore DEPENDENCY|master=orange,primary VARIABLES|test_var=A hui hou

Dependency Cycles

The Logical Domains Manager does not permit you to create domain relationships that create a dependency cycle. A dependency cycle is a relationship between two or more domains that lead to a situation where a slave domain depends on itself, or a master domain depends on one of its slave domains.

The Logical Domains Manager determines whether a dependency cycle exists before adding a dependency. The Logical Domains Manager starts at the slave domain and searches along all paths that are specified by the master array until the end of the path is reached. Any dependency cycles found along the way are reported as errors.

The following example shows how a dependency cycle might be created. The first command creates a slave domain called mohawk that specifies its master domain as primary. So, mohawk depends on primary in the following dependency chain:

Figure 4–1 Single Domain Dependency

The second command creates a slave domain called primary that specifies its master domain as counter. So, mohawk depends on primary, which depends on counter in the following dependency chain:

Figure 4–2 Multiple Domain Dependency

The third command attempts to create a dependency between the counter and mohawk domains, which would produce the following dependency cycle:

Figure 4–3 Domain Dependency Cycle

The ldm set-domain command will fail with the following error message:

# ldm add-domain master=primary mohawk
# ldm set-domain master=counter primary
# ldm set-domain master=mohawk counter
Dependency cycle detected: LDom "counter" indicates "primary" as its master