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.
Oracle Solaris OS version. You can perform a live migration of a guest domain that runs at least the Oracle Solaris 10 9/10 OS. You cannot perform a live migration of a guest domain that runs the Oracle Solaris 10 10/09 OS or earlier Oracle Solaris OS versions. You can still boot these older Oracle Solaris OS versions and perform cold migrations of such domains.
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. See System Firmware Versions in Oracle VM Server for SPARC 3.6 Installation Guide.
You cannot perform live migration operations between a server that runs system firmware version 7.x and a server that runs system firmware version 8.x.
Therefore, the following live migration operations are not supported:
From a server that runs version 7.x of the system firmware to a server that runs version 8.x of the system firmware
From a server that runs version 8.x of the system firmware to a server that runs version 7.x of the system firmware
Take care when performing migrations of domains that have the perf-counters property value set.
Before you perform the migration of a domain that has the perf-counters property value set to global, ensure that no other domain on the target machine has the perf-counters property set to global.
During a migration operation, the perf-counters property is treated differently based on whether the performance access capability is available on the source machine, the target machine, or both.
The perf-counters property value is treated as follows:
Source machine only. The perf-counters property value is not propagated to the target machine.
Target machine only. The perf-counters property value on the machine to be migrated is updated to be equivalent to perf-counters=.
Source and target machines. The perf-counters property value is propogated from the domain to be migrated to the migrated domain on the target machine.
In certain cross-CPU migration scenarios, a migration can fail with the following errors when you force the migration by using the –f option:
API group 0x20b v1.0 is not supported in the version of the firmware running on the target machine. API group 0x214 v1.0 is not supported in the version of the firmware running on the target machine.
All of the following conditions must be present to encounter this problem:
The domain has the cpu-arch property set to generic or migration-class1
The domain has a perf-counter property setting that includes the global value
The domain was booted on at least a SPARC M7 series server or a SPARC T7 series server
The target machine is a platform released prior to the SPARC M7 series server or SPARC T7 series server
This problem occurs because a domain booted on at least a SPARC M7 series server or a SPARC T7 series server with a perf-counter property setting that includes the global value will register platform-specific performance counter Hypervisor interfaces that do not exist on older platforms. As part of the migration, a check is performed to ensure that all the interfaces used by the domain are present on the target machine. When these SPARC M7 series server or SPARC T7 series server specific interfaces are detected, the migration is aborted.
Do not set perf-counter=global if cpu-arch is note native and at least SPARC M7 series servers and SPARC T7 series servers are part of the migration pool.
You can migrate a virtual network device that has a physical NIC backing device and has linkprop=phys-state to a target domain that does not have a physical NIC as a backing device (net-dev=). Because the linkprop=phys-state constraint is not a hard requirement, if such a domain is migrated to a machine that does not have an available net-dev value, the constraint is preserved but not fulfilled. The linkprop property is still preserved as phys-state and the network device link state shows as link up.
Sometimes, migrating a domain that has a large number of virtual devices causes the control domain on the target machine to be less responsive than usual. During this time, ldm commands appear to hang and standard Oracle Solaris OS commands take longer to complete than usual.
This interruption is caused by virtual servers processing the large number of incoming virtual devices associated with the migrated domain. After this processing completes, the control domain returns to normal and any stalled ldm commands complete.
You can minimize this sort of interruption by limiting the number of virtual devices used by a domain to no more than 1000.
SPARC servers starting with the SPARC M7, SPARC T7, and SPARC S7 series server support a hardware capability called Silicon Secured Memory (SSM). When enabled through the Application Data Integrity (ADI) API, this feature enables software to assign versions to regions of memory. These versions are used to detect invalid or unauthorized memory accesses. These version tags are part of the guest virtual machine state and are migrated with the guest domain.
For more information about SSM and the ADI API, see Software in Silicon: Enabling Secure Clouds for the Real-Time Enterprise (http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/sparc-t7-m7-server-architecture-2702877.pdf) and Using Application Data Integrity (ADI) in Oracle Solaris 11.4 Programming Interfaces Guide.
You can perform only a migration that preserves ADI tags between servers of the same CPU family. For example, you can perform a migration that preserves ADI tags from a SPARC M7 series server to another SPARC M7 series server or to a SPARC T7 series server. Or, you can perform a migration that preserves ADI tags from a SPARC T8 series server to another SPARC T8 series server or to a SPARC M8 series server.
Caution - If you intend to perform a domain migration on your servers that support SSM, ensure that they run at least the Oracle VM Server for SPARC 3.5 software. When running previous versions of the Oracle VM Server for SPARC software on servers that support SSM, ADI version information is not migrated to the target machine. This situation can result in undefined application behavior if ADI is in use in the domain being migrated.
While it is best to run the latest version of the Oracle VM Server for SPARC software on all SSM-capable machines used in a migration, if an upgrade is not possible on either the source machine or the target machine, you can still perform a migration if you are certain that the domain to be migrated does not use ADI versioning.
To perform this sort of migration, set the ldmd/migration_adi_legacy_compat SMF property value to true on the machine that runs Oracle VM Server for SPARC 3.5. By setting this property, the migration overrides the support checks and permits the migration to proceed. The migrated domain does not retain the ADI version tags.
If the cputrack command is run on a guest domain while that domain is migrated to a SPARC T4 server, the guest domain might panic on the target machine after it has been migrated. So, do not run the cputrack command during the migration of a guest domain to a SPARC T4 server.