Delayed Reconfiguration

In contrast to dynamic reconfiguration 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 the logical domain

The Logical Domains Manager 1.2 software restricts delayed reconfiguration operations to the control domain. For all other domains, you must stop the domain to modify the configuration unless the resource can be dynamically reconfigured.

If you are using a Sun UltraSPARC T1 processor, when the Logical Domains Manager is first installed and enabled (or when the configuration is restored to factory-default), ldmd runs in configuration mode. In this mode, reconfiguration requests are accepted and queued up, but are not acted upon. This allows a new configuration to be generated and stored on the SP without affecting the state of the running machine. Thus, configuration mode is not encumbered by any restrictions such as delayed reconfiguration and reboot of I/O domains.

When a delayed reconfiguration is in progress on the control domain, other reconfiguration requests for the control domain are deferred until it is rebooted, or stopped and started. Also, when a delayed reconfiguration is outstanding for the control domain, reconfiguration requests for other logical domains are severely restricted and will fail with an appropriate error message.

The Logical Domains Manager ldm cancel-operation reconf command cancels delayed reconfiguration operations on the control domain. You can list delayed reconfiguration operations by using the ldm list-domain command. For more information about how to use the delayed reconfiguration feature, see the ldm(1M) man page.

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