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.

Saving a configuration on the SP makes it persist across domain reboots and system power cycles. You can save several configurations and specify which configuration to boot on the next power on attempt.

Starting with the Oracle VM Server for SPARC 3.0 release, a local copy of the SP configuration and the Logical Domains constraint database is saved on the control domain whenever you save a configuration to the SP. This local copy is called a bootset. The bootset is used to load the corresponding Logical Domains constraints database when the system undergoes a power cycle.

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.

A copy of the current configuration is automatically saved on the control domain whenever the Logical Domains configuration is changed. This autosave operation does not explicitly save the configuration to the SP.

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 after a system power cycle. 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.

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 Logical Domains 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.

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 Logical Domains With the Service Processor.

How to 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 power cycle. 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 power cycle. A message is also logged, which states that a newer configuration has been saved on the SP and that it will be booted at the next system power cycle. These messages are logged in the ldmd SMF log file.

1. Log in to the control domain.
2. Become an administrator.

   For Oracle Solaris 10, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. For Oracle Solaris 11.1, see Part III, Roles, Rights Profiles, and Privileges, in Oracle Solaris 11.1 Administration: 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 11-3 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