Migrating Bound or Inactive Domains

Only a few domain migration restrictions apply to a bound or inactive domain because such domains are not executing at the time of the migration. Therefore, you can migrate between different platform types, such as SPARC T4 to SPARC T7 platforms, Fujitsu SPARC M12 platforms or Fujitsu M10 platforms, because no runtime state is being copied across.

The migration of a bound domain requires that the target machine is able to satisfy the CPU, memory, and I/O constraints of the domain to be migrated. If these constraints cannot be met, the migration will fail.

Caution:

When you migrate a bound domain, the virtual disk back-end options and mpgroup values are not checked because no runtime state information is exchanged with the target machine. This check does occur when you migrate an active domain.

The migration of an inactive domain does not have such requirements. However, the target machine must satisfy the migrated domain's constraints when a bind is later attempted or the domain binding will fail.

Note:

After a domain migration completes, save a new SP configuration to the SP of both the source and target systems. As a result, the state of the migrated domain is correct if either the source or target system undergoes a power cycle.

Starting with Oracle VM Server for SPARC 3.5, an SP configuration can be saved automatically following a successful migration. For more information, see Saving Post-Migration SP Configurations Automatically.

Caution:

When cold migrating a bound domain that has a large number of virtual devices, the operation might fail with the following message in the SMF log:

warning: Timer expired: Failed to read feasibility response type (9) from target LDoms Manager

This failure indicates that the Logical Domains Manager running on the source machine timed out while waiting for the domain to be bound on the target machine. The chances of encountering this problem increases as the number of virtual devices in the migrating domain increases. The timing of this failure results in a bound copy of the domain on both the source machine and the target machine. Do not start both copies of this domain. This action can cause data corruption because both domains reference the same virtual disk backends. After verifying that the copy of the migrated domain is correct on the target machine, manually unbind the copy of the domain on the source machine and destroy it.