Chapter 10 Managing Configurations

This chapter contains information about managing configurations.

This chapter covers the following topics:

• Saving Logical Domain Configurations for Future Rebuilding

• Rebuilding the Control Domain

• Managing Logical Domains Configurations

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 10–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">nxge0</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 10–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 10–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 10–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 10–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 10–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 10–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">nxge0</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=nxge.

• 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=nxge 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

Managing Logical Domains Configurations

A Logical Domains configuration is a complete description of all the domains and their resource allocations within a single system. You can save and store configurations on the service processor (SP) for later use.

When you power up a system, the SP boots the selected configuration. By booting a configuration, the system runs the same set of domains, and uses the same virtualization and partitioning resource allocations that are specified in the configuration. The default configuration is the one that is most recently saved.

Starting with the Logical Domains 1.2 release, a copy of the current configuration is automatically saved on the control domain whenever the Logical Domains configuration is changed.

The autosave operation occurs immediately, even in the following situations:

• When the new configuration is not explicitly saved on the SP

• When the actual configuration change is not made until after the affected domain reboots

This autosave operation enables you to recover a configuration when the configurations that are saved on the SP are lost. This operation also enables you to recover a configuration when the current configuration was not explicitly saved to the SP when the system powercycled. In these circumstances, the Logical Domains Manager can restore that configuration on restart if it is newer than the configuration marked for the next boot.

Power management, FMA, ASR, and PRI update events do not cause an update to the autosave files.

You can automatically or manually restore autosave files to new or existing configurations. By default, when an autosave configuration is newer than the corresponding running configuration, a message is written to the LDoms log. Thus, you must use the ldm add-spconfig -r command to manually update an existing configuration or create a new one based on the autosave data.

When a delayed reconfiguration is pending, the configuration changes are immediately autosaved. As a result, if you run the ldm list-config -r command, the autosave configuration is shown as being newer than the current configuration.

For information about how to use the ldm *-spconfig commands to manage configurations and to manually recover autosave files, see the ldm(1M) man page.

For information about how to select a configuration to boot, see Using LDoms With the Service Processor.

Modify the Autorecovery Policy

The autorecovery policy specifies how to handle the recovery of a configuration when one configuration that is automatically saved on the control domain is newer than the corresponding running configuration. The autorecovery policy is specified by setting the autorecovery_policy property of the ldmd SMF service. The autorecovery_policy property can have the following values:

• autorecovery_policy=1 – Logs warning messages when an autosave configuration is newer than the corresponding running configuration. These messages are logged in the ldmd SMF log file. The user must manually perform any configuration recovery. This is the default policy.

• autorecovery_policy=2 – Displays a notification message if an autosave configuration is newer than the corresponding running configuration. This notification message is printed in the output of any ldm command the first time an ldm command is issued after each restart of the Logical Domains Manager. The user must manually perform any configuration recovery.

• autorecovery_policy=3 – Automatically updates the configuration if an autosave configuration is newer than the corresponding running configuration. This action overwrites the SP configuration that will be used during the next powercycle. This configuration is updated with the newer configuration that is saved on the control domain. This action does not impact the currently running configuration. It only impacts the configuration that will be used during the next powercycle. A message is also logged, which states that a newer configuration has been saved on the SP and that it will be booted the next time the system is powercycled. These messages are logged in the ldmd SMF log file.

1. Log in to the control domain.

2. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

3. View the autorecovery_policy property value.

   # svccfg -s ldmd listprop ldmd/autorecovery_policy

4. Stop the ldmd service.

   # svcadm disable ldmd

5. Change the autorecovery_policy property value.

   # svccfg -s ldmd setprop ldmd/autorecovery_policy=value

   For example, to set the policy to perform autorecovery, set the property value to 3:

   # svccfg -s ldmd setprop ldmd/autorecovery_policy=3

6. Refresh and restart the ldmd service.

   # svcadm refresh ldmd # svcadm enable ldmd

Example 10–7 Modifying the Autorecovery Policy From Log to Autorecovery

The following example shows how to view the current value of the autorecovery_policy property and change it to a new value. The original value of this property is 1, which means that autosave changes are logged. The svcadm command is used to stop and restart the ldmd service, and the svccfg command is used to view and set the property value.

# svccfg -s ldmd listprop ldmd/autorecovery_policy
ldmd/autorecovery_policy integer 1
# svcadm disable ldmd
# svccfg -s ldmd setprop ldmd/autorecovery_policy=3
# svcadm refresh ldmd
# svcadm enable ldmd