The following sections describe restrictions for domain migration. The Logical Domains Manager software and the system firmware versions must be compatible to permit migrations. Also, you must meet certain CPU requirements to ensure a successful domain migration.
Live migration is not qualified and supported on all combinations of the source and target platforms and system firmware versions. For those combinations that cannot perform a live migration, you can perform a cold migration instead.
This section describes version restrictions for performing live migrations.
Logical Domains Manager version. You can perform a live migration in either direction when one system runs the latest version of the Logical Domains Manager and the other system runs at least the immediately preceding version of the Logical Domains Manager.
In addition, in the case of the Oracle VM Server for SPARC 3.1.x software, you can perform the live migration of a domain to or from a system that runs version 3.1.x of the Logical Domains Manager to or from a system that runs version 3.0.0.x of the Logical Domains Manager.
System firmware version. In general, you can perform a live migration between two systems when both the source and target machines support the appropriate minimum system firmware versions.
The following list shows the platforms that support live migration and the associated minimum system firmware version:
UltraSPARC T2 and UltraSPARC T2 Plus platforms – Version 7.4.5
SPARC T3 and SPARC T4 platforms – Version 8.2.2.c
SPARC T5, SPARC M5, and SPARC M6 platforms – All system firmware versions
Fujitsu M10 systems – All XCP versions
However, some specific platform and firmware combinations do not support live migration. Attempting to perform the live migration of a domain from a system that runs at least system firmware version 8.4 or XCP2210 to a system that runs an older system firmware version fails. The failure occurs because of a hypervisor API mismatch between the newer and older system firmware versions. In this instance, the following message is issued:
primary# ldm migrate ldg1 root@target-name Target Password: Domain ldg1 is using features of the system firmware that are not supported in the version of the firmware running on the target machine. Domain Migration of LDom ldg1 failed
Note that you can perform the live migration of a domain from a system that runs system firmware version 8.3 to a system that runs at least system firmware version 8.4 unless the target machine is a SPARC M5-32 system. For more information, see Domain Migrations From SPARC T4 Systems That Run System Firmware 8.3 to SPARC T5, SPARC M5, or SPARC M6 Systems Are Erroneously Permitted.
System firmware versions 8.4 and 9.1 introduced support for EFI GPT disk labels. By default, virtual disks that are installed when running at least the Oracle Solaris 11.1 OS on those systems have an EFI GPT disk label. You cannot read this disk label on older versions of firmware (such as 9.0.x, 8.3, or 7.x). This situation precludes you from performing a live migration or a cold migration to a system that runs a system firmware version without EFI GPT support. Note that a cold migration also fails in this situation, which is different than the previous limitations.
To determine whether your virtual disk has an EFI GPT disk label, run the devinfo -i command on the raw device. The following examples show whether the virtual disk has an SMI VTOC or an EFI GPT disk label:
SMI VTOC disk label. When your virtual disk has an SMI VTOC, you can perform a migration to firmware regardless of whether it supports EFI.
This example indicates that the device has a VTOC label because the devinfo -i command reports device-specific information:
# devinfo -i /dev/rdsk/c2d0s2 /dev/rdsk/c2d0s2 0 0 73728 512 2
EFI GPT disk label. When your virtual disk has an EFI GPT disk label, you can perform a migration only to firmware that has EFI support.
This example indicates that the device has an EFI GPT disk label because the devinfo -i command reports an error:
# devinfo -i /dev/rdsk/c1d0s0 devinfo: /dev/rdsk/c1d0s0: This operation is not supported on EFI labeled devices
If the domain to be migrated is running an Oracle Solaris OS version older than the Oracle Solaris 10 1/13 OS, you might see the following message during the migration:
Domain domain-name is not running an operating system that is compatible with the latest migration functionality.
The following CPU requirements and restrictions apply when you run an OS prior to the Oracle Solaris 10 1/13 OS:
Full cores must be allocated to the migrated domain. If the number of threads in the domain to be migrated is less than a full core, the extra threads are unavailable to any domain until after the migrated domain is rebooted.
After a migration, CPU dynamic reconfiguration (DR) is disabled for the migrated domain until it has been rebooted. At that time, you can use CPU DR on the migrated domain.
The target machine must have enough free full cores to provide the number of threads that are required for the migrated domain. After the migration, if a full core is only partially used by the migrated domain, any extra threads are unavailable to any domain until after the migrated domain is rebooted.
These restrictions also apply when you attempt to migrate a domain that is running in OpenBoot or in the kernel debugger. See Migrating a Domain From the OpenBoot PROM or a Domain That Is Running in the Kernel Debugger in Oracle VM Server for SPARC 3.1 Administration Guide .
You cannot perform live migrations between an UltraSPARC T2, UltraSPARC T2 Plus, or SPARC T3 system and a SPARC T5, SPARC M5, or SPARC M6 system.
You can only perform a live migration between a SPARC T4 system and a SPARC T5, SPARC M5, or SPARC M6 system only if the following requirements are met:
The SPARC T4 system must run system firmware version 8.4
The SPARC T5, SPARC M5, or SPARC M6 system must run system firmware version 9.1
Both the source and target machines must run the Oracle VM Server for SPARC 3.1 software
Bug ID 17285751: Migrating a domain that has only one virtual CPU assigned to it might cause a panic on the guest domain in the function pg_cmt_cpu_fini().
Workaround: Assign at least two virtual CPUs to the guest domain before you perform the live migration. For example, use the ldm add-vcpu number-of-virtual-CPUs domain command to increase the number of virtual CPUs assigned to the guest domain.