Go to main content

Oracle® VM Server for SPARC 3.6 Administration Guide

Exit Print View

Updated: September 2019

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.

Migration Requirements for Virtual I/O Devices

For an inactive domain, no checks are performed of the virtual I/O (VIO) constraints. Therefore, the VIO servers do not need to exist for the migration to succeed. As with any inactive domain, the VIO servers must exist and be available at the time the domain is bound.

Migration Requirements for PCIe Endpoint Devices

You cannot perform a domain migration on an I/O domain that is configured with PCIe endpoint devices. This requirement applies to bound domains but not to inactive domains.

For information about the direct I/O (DIO) feature, see Creating an I/O Domain by Assigning PCIe Endpoint Devices.

Migration Requirements for PCIe SR-IOV Virtual Functions

Except for SR-IOV Ethernet virtual functions, you cannot perform a domain migration on an I/O domain that is configured with PCIe SR-IOV virtual functions. This requirement applies to bound domains but not to inactive domains.

For information about the SR-IOV feature, see Creating an I/O Domain by Using PCIe SR-IOV Virtual Functions.

For information about migrating a domain that has SR-IOV Ethernet virtual functions, see Migrating a Domain That Has an SR-IOV Ethernet Virtual Function Assigned.