Domain Migration Restrictions
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.
Version Restrictions for Migration
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 Minimum System Firmware Versions in Oracle VM Server for SPARC 3.5 Installation Guide.
This section describes version restrictions for performing live migrations.
Cross-CPU Restrictions for Migration
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.
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
Therefore, the following live migration operations are not supported:
Migration Restrictions for Setting perf-counters
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.
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.
The perf-counters property value is treated as follows:
For more information about the perf-counters property, see Using Perf-Counter Properties and the ldm(1M) man page.
Migration Restrictions for Setting linkprop=phys-state
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.
Migration Restrictions for Domains That Have a Large Number of Virtual Devices
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.
Migration Restrictions for Silicon Secured Memory Servers
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.3 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.