Migrating an Active Domain

For the migration of an active domain to occur with Logical Domains 1.3 software, there is a certain set of requirements and restrictions imposed on the source logical domain, the source machine, and the target machine. The sections following describe these requirements and restrictions for each of the resource types.

The migration operation speeds up when the primary domain on the source and target systems have cryptographic units assigned. Starting with Logical Domains 1.3, you can speed up migration by adding more virtual CPUs to the primary domains of both the source and target systems.

Migrating CPUs in an Active Domain

Following are the requirements and restrictions on CPUs when performing a migration.

• The source and target machines must have the same processor type running at the same frequency.

• The target machine must have sufficient free strands to accommodate the number of strands in use by the domain. In addition, full cores must be allocated for the migrated domain. If the number of strands in the source are less than a full core, the extra strands are unavailable to any domain until after the migrated domain is rebooted.

• After a migration, CPU dynamic reconfiguration (DR) is disabled for the target domain until it has been rebooted. Once a reboot has occurred, CPU DR becomes available for that domain.

• Either the source domain must have only a single strand, or the guest OS must support CPU DR, so that the domain can be shrunk to a single strand before migration. Conditions in the guest domain that would cause a CPU DR removal to fail would also cause the migration attempt to fail. For example, processes bound to CPUs within the guest domain, or processor sets configured in the source logical domain, can cause a migration operation to fail.

Migrating Memory in an Active Domain

There must be sufficient free memory on the target machine to accommodate the migration of the source domain. In addition, following are a few properties that must be maintained across the migration:

• It must be possible to create the same number of identically-sized memory blocks.

• The physical addresses of the memory blocks do not need to match, but the same real addresses must be maintained across the migration.

The target machine must have sufficient free memory to accommodate the migration of the source domain. In addition, the layout of the available memory on the target machine must be compatible with the memory layout of the source domain or the migration will fail.

In particular, if the memory on the target machine is fragmented into multiple small address ranges, but the source domain requires a single large address range, the migration will fail. The following example illustrates this scenario. The target domain has two Gbytes of free memory in two memory blocks:

# ldm list-devices memory
MEMORY
    PA                   SIZE
    0x108000000          1G
    0x188000000          1G

The source domain, ldg-src, also has two Gbytes of free memory, but it is laid out in a single memory block:

# ldm list -o memory ldg-src
NAME
ldg-src

MEMORY
    RA               PA               SIZE
    0x8000000        0x208000000      2G

Given this memory layout situation, the migration fails:

# ldm migrate-domain ldg-src dt212-239
Target Password:
Unable to bind 2G memory region at real address 0x8000000
Domain Migration of LDom ldg-src failed

Migrating Physical I/O Devices in an Active Domain

Virtual devices that are associated with physical devices can be migrated. However, domains that have direct access to physical devices cannot be migrated. For instance, you cannot migrate I/O domains.

Migrating Virtual I/O Devices in an Active Domain

All virtual I/O (VIO) services used by the source domain must be available on the target machine. In other words, the following conditions must exist:

• Each logical volume used in the source logical domain must also be available on the target host and must refer to the same storage.

  ---

  Caution –

  If the logical volume used by the source as a boot device exists on the target but does not refer to the same storage, the migration appears to succeed, but the machine is not usable as it is unable to access its boot device. The domain has to be stopped, the configuration issue corrected, and then the domain restarted. Otherwise, the domain could be left in an inconsistent state.

  ---

• For each virtual network device in the source domain, a virtual network switch must exist on the target host, with the same name as the virtual network switch the device is attached to on the source host.

  For example, if vnet0 in the source domain is attached to a virtual switch service name switch-y, then there must be a logical domain on the target host providing a virtual switch service named switch-y.

  ---

  Note –

  The switches do not have to be connected to the same network for the migration to occur, though the migrated domain can experience networking problems if the switches are not connected to the same network.

  ---

  MAC addresses used by the source domain that are in the automatically allocated range must be available for use on the target host.

• A virtual console concentrator (vcc) service must exist on the target host and have at least one free port. Explicit console constraints are ignored during the migration. The console for the target domain is created using the target domain name as the console group and using any available port on the first vcc device in the control domain. If there is a conflict with the default group name, the migration fails.

Migrating NIU Hybrid Input/Output in an Active Domain

A domain using NIU Hybrid I/O resources can be migrated. A constraint specifying NIU Hybrid I/O resources is not a hard requirement of a logical domain. If such a domain is migrated to a machine that does not have available NIU resources, the constraint is preserved, but not fulfilled.

Migrating Cryptographic Units in an Active Domain

Starting with Logical Domains 1.3, you can migrate a guest domain that has bound cryptographic units if it runs an operating system that supports cryptographic unit dynamic reconfiguration (DR).

The following Solaris OS versions support cryptographic unit DR:

• At least the Solaris 10 10/09 OS

• At least the OpenSolaris 2009.06 OS

• At least the Solaris 10 5/08 OS plus patch ID 142245-01

At the start of the migration, the Logical Domains Manager determines whether the source domain supports cryptographic unit DR. If supported, the Logical Domains Manager attempts to remove any cryptographic units from the domain. After the migration completes, the cryptographic units are re-added to the migrated domain.

If the constraints for cryptographic units cannot be met on the target machine, a migration operation might still complete successfully. In such a case, the domain might end up with fewer cryptographic units than it had prior to the migration operation.

Delayed Reconfiguration in an Active Domain

Any active delayed reconfiguration operations on the source or target hosts prevent a migration from starting. Delayed reconfiguration operations are blocked while a migration is in progress.

Operations on Other Domains

While a migration is in progress on a machine, any operation which could result in the modification of the Machine Description (MD) of the domain being migrated is blocked. This includes all operations on the domain itself as well as operations such as bind and stop on other domains on the machine.