Delayed Reconfiguration

In contrast to DR operations that take place immediately, delayed reconfiguration operations take effect in the following circumstances:

  • After the next reboot of the OS

  • After a stop and start of a logical domain if no OS is running

In general, delayed reconfiguration operations are restricted to the control domain. For all other domains, you must stop the domain to modify the configuration unless the resource can be dynamically reconfigured.

Delayed reconfiguration operations are restricted to the control domain. You can run a limited number of commands while a delayed reconfiguration on the root domain is in progress to support operations that cannot be completed dynamically. These subcommands are add-io, set-io, remove-io, create-vf, and destroy-vf. You can also run the ldm start-reconf command on the root domain. For all other domains, you must stop the domain to modify the configuration unless the resource can be dynamically reconfigured.

While a delayed reconfiguration is in progress, other reconfiguration requests for that domain are deferred until it is rebooted or stopped and started.

The ldm cancel-reconf command cancels delayed reconfiguration operations on the domain. For more information about how to use the delayed reconfiguration feature, see the ldm(8) man page.

Note:

You cannot use the ldm cancel-reconf command if any other ldm remove-* commands have already performed a delayed reconfiguration operation on virtual I/O devices. The ldm cancel-reconf command fails in this circumstance.

You can use delayed reconfiguration to decrease resources on the control domain. To remove a large number of CPUs from the control domain, see Removing a Large Number of CPUs From a Domain Might Fail. To remove large amounts of memory from the control domain, see Decrease the Control Domain's Memory.

Note:

When the primary domain is in a delayed reconfiguration state, resources that are managed by Oracle VM Server for SPARC are power-managed only after the primary domain reboots. Resources that are managed directly by the OS, such as CPUs that are managed by the Solaris Power Aware Dispatcher, are not affected by this state.