1. Overview of the Oracle VM Server for SPARC Software
2. Installing and Enabling Software
4. Setting Up Services and the Control Domain
Introduction to Domain Migration
Overview of a Migration Operation
Authentication for Migration Operations
Performing Non-Interactive Migrations
Migrating CPUs in an Active Domain
Migrating Memory in an Active Domain
Migrating Physical I/O Devices in an Active Domain
Migrating Virtual I/O Devices in an Active Domain
Migrating NIU Hybrid Input/Output in an Active Domain
Migrating Cryptographic Units in an Active Domain
Delayed Reconfiguration in an Active Domain
Migrating Bound or Inactive Domains
Migrating CPUs in a Bound or Inactive Domain
Migrating Virtual Input/Output in a Bound or Inactive Domain
Migrating PCIe Endpoint Devices in a Bound or Inactive Domain
Monitoring a Migration in Progress
Canceling a Migration in Progress
Recovering From a Failed Migration
12. Performing Other Administration Tasks
A. Oracle VM Server for SPARC Physical-to-Virtual Conversion Tool
B. Oracle VM Server for SPARC Configuration Assistant
C. Logical Domains Manager Discovery
D. Using the XML Interface With the Logical Domains Manager
For the migration of an active domain to occur with Oracle VM Server for SPARC 2.0 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.
Note - 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.
Following are the requirements and restrictions on CPUs when you are 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.
Additional requirements and restrictions apply under any of the following conditions:
The target system is not running at least version 2.0 of the Logical Domains Manager. In this case, you might see the following message during the migration:
The target machine is running an older version of the domain manager that does not support the latest migration functionality.
The source system is not running at least version 2.0 of the Logical Domains Manager. Because the legacy Logical Domains Manager in the source domain is unable to detect the software mismatch, the migration proceeds without issuing a message.
The source domain is running an Oracle Solaris OS version older than the Oracle Solaris 10 9/10 OS. In this case, you might see the following message during the migration:
Domain ldom is not running an operating system that is compatible with the latest migration functionality.
If any of these conditions apply, the following requirements and restrictions on CPUs apply:
Full cores must be allocated for the migrated domain. If the number of strands in the source domain is 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. After a reboot has occurred, CPU DR becomes available for that domain.
The target system must have enough full cores that are entirely free to provide the number of strands required for the migrated domain. After the migration, if a full core is only partially used by the migrated domain, any extra strands are unavailable to any domain until after the migrated domain is rebooted.
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
Note - After a migration, memory dynamic reconfiguration (DR) is disabled for the target domain until it has been rebooted. After the reboot completes, memory DR is re-enabled for the 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.
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.
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.
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 Oracle Solaris OS versions support cryptographic unit DR:
At least the Solaris 10 10/09 OS
At least the Oracle 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.
Note - 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.
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.
Domain migrations are not supported for a source or target machine in elastic mode. If a migration is underway while the domain is in performance mode and the power management (PM) policy is set to elastic mode, the policy switch is deferred until the migration completes. The migration command returns an error if either the source or target machine is in elastic mode and a domain migration is attempted.
While a migration is in progress on a machine, any operation that could 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.