Migrating an Active Domain

Certain requirements and restrictions are imposed on the domain to be migrated, the source machine, and the target machine when you attempt to migrate an active domain. For more information, see Domain Migration Restrictions in Oracle VM Server for SPARC 2.2 Release Notes.

A domain “loses time” during the migration process. To mitigate this time-loss issue, synchronize the domain to be migrated with an external time source, such as a Network Time Protocol (NTP) server. When you configure a domain as an NTP client, the domain's date and time are corrected shortly after the migration completes.

To configure a domain as an Oracle Solaris 10 NTP client, see Managing Network Time Protocol (Tasks) in System Administration Guide: Network Services. To configure a domain as an Oracle Solaris 11 NTP client, see Managing Network Time Protocol (Tasks) in Oracle Solaris Administration: Network Services.

Domain Migration Requirements for CPUs

Following are the requirements and restrictions on CPUs when you perform a migration:

• The target machine must have sufficient free virtual CPUs to accommodate the number of virtual CPUs in use by the domain to be migrated.

• For systems that run the Oracle Solaris 10 OS, the source and target machines must have the same processor types.

• For the Oracle Solaris 11 OS, setting the cpu-arch property enables you to migrate between systems that have different processor types. The following are the supported cpu-arch property values:

  • native uses CPU-specific hardware features to enable a guest domain to migrate only between platforms that have the same CPU type. native is the default value.

  • generic uses common CPU hardware features to enable a guest domain to perform a CPU-type-independent migration.

  Using the generic value might result in reduced performance compared to the native value. The possible performance degradation occurs because the guest domain uses only generic CPU features that are available on all supported CPU types instead of using the native hardware features of a particular CPU. By not using these features, the generic value enables the flexibility of migrating the domain between systems that use CPUs that support different features.

  Use the psrinfo -pv command to determine the processor type, as follows:

  # psrinfo -pv
  The physical processor has 8 virtual processors (0-7)
    SPARC-T4 (chipid 0, clock 2548 MHz)

• When the domain to be migrated runs the Oracle Solaris 11 OS, you can migrate the domain between a source system and a target system that have different processor frequencies and STICK frequency values. This type of migration is possible even if the cpu-arch property value is not set. However, when the domain to be migrated runs the Oracle Solaris 10 OS, the processor frequencies and STICK frequency values must match.

  Use the prtconf -pv command to determine the STICK frequency, as follows:

  # prtconf -pv | grep stick-frequency
      stick-frequency:  05f4bc08

  ---

  Note - The frequency at which the STICK register increments is derived from the full-speed CPU frequency. However, even though the CPU frequency on both machines might be identical, the exact STICK register frequency might differ slightly and thus block a migration.

  ---

Migration Requirements for Memory

There must be sufficient free memory on the target machine to accommodate the migration of a 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.

In addition, the layout of the available memory on the target machine must be compatible with the memory layout of the domain to be migrated or the migration will fail. In particular, if the memory on the target machine is fragmented into multiple small address ranges, but the domain to be migrated requires a single large address range, the migration will fail. The following example illustrates this scenario. The target machine has 2 Gbytes of free memory in two memory blocks:

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

The domain to be migrated, ldg-src, also has 2 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 t5440-sys-2
Target Password:
Unable to bind 2G memory region at real address 0x8000000
Domain Migration of LDom ldg-src failed

Migration Requirements for Physical I/O Devices

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

Migration Requirements for Virtual I/O Devices

All virtual I/O services that are used by the domain to be migrated must be available on the target machine. In other words, the following conditions must exist:

• Each virtual disk back end that is used in the domain to be migrated must be defined on the target machine. The virtual disk back end you define must have the same volume and service names as on the source machine. Paths to the back end might be different on the source and target machines, but they must refer to the same back end.

  ---

  Caution - A migration will succeed even if the paths to a virtual disk back end on the source and target machines do not refer to the same storage. However, the behavior of the domain on the target machine will be unpredictable, and the domain is likely to be unusable. To remedy the situation, stop the domain, correct the configuration issue, and then restart the domain. If you do not perform these steps, the domain might be left in an inconsistent state.

  ---

• Each virtual network device in the domain to be migrated must have a corresponding virtual network switch on the target machine. Each virtual network switch must have the same name as the virtual network switch to which the device is attached on the source machine.

  For example, if vnet0 in the domain to be migrated is attached to a virtual switch service named switch-y, a domain on the target machine must provide a virtual switch service named switch-y.

  ---

  Note - The physical network on the target machine must be correctly configured so that the migrated domain can access the network resources it requires. Otherwise, some network services might become unavailable on the domain after the migration completes.

  For example, you might want to ensure that the domain can access the correct network subnet. Also, you might want to ensure that gateways, routers, or firewalls are properly configured so that the domain can reach the required remote systems from the target machine.

  ---

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

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

Migration Requirements for NIU Hybrid I/O

You can migrate a domain that uses NIU Hybrid I/O resources. A constraint that specifies NIU Hybrid I/O resources is not a hard requirement of a domain. If such a domain is migrated to a machine that does not have available NIU resources, the constraint is preserved, but not fulfilled.

Migration Requirements for Cryptographic Units

On platforms that have cryptographic units, 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 Oracle Solaris OS versions support cryptographic unit DR:

• At least the Solaris 10 10/09 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 domain to be migrated 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.

Delayed Reconfiguration in an Active Domain

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

Migrating While an Active Domain Has the Power Management Elastic Policy in Effect

Domain migrations are not supported for a source or target machine that has the power management (PM) elastic policy in effect. If the PM policy on the source or target machine is switched from performance to elastic while a migration is in progress, the policy switch is deferred until the migration completes. The migration command returns an error if a domain migration is attempted while either the source or target machine has the elastic policy in effect.

Operations on Other Domains

While a migration is in progress on a machine, any operation that might result in the modification of the state or configuration of the domain being migrated, is blocked. All operations on the domain itself, as well as operations such as bind and stop on other domains on the machine, are blocked.

Migrating a Domain From the OpenBoot PROM or a Domain That Is Running in the Kernel Debugger

Performing a domain migration requires coordination between the Logical Domains Manager and the OS that is running in the domain to be migrated. When a domain to be migrated is running in OpenBoot or in the kernel debugger (kmdb), this coordination is not possible. As a result, the migration attempt fails, unless the domain to be migrated has only a single CPU. When the domain to be migrated has a single CPU, the migration proceeds when certain requirements and restrictions are met. See Domain Migration Restrictions in Oracle VM Server for SPARC 2.2 Release Notes.