HP-UX vPars and Integrity VM V6.3 Administrator Guide

If a target VSP contains multiple DIO-capable functions with the same label, it might be possible
that offline migration picks the DIO-capable function which is used by another vPar or VM. In such
cases, the vPar or VM that is migrated offline will not be able to power on if another vPar or VM
assigned with the same DIO-capable function is already running. You must either manually change
the DIO-capable function with an unused DIO-capable function or assign the DIO-capable functions
with unique labels such that it maintains an exact one-to-one mapping between each labeled
function on the source vPar or VM and available DIO-capable functions on the target VSP.
Label-matching is independent of whether the labels are assigned to DLA or FLA functions. However,
offline migration first attempts a match of like-for-like function types. For more information about
DLA and FLA distinction, see Section 8.5.1 (page 128).
12.2 Command line interface for migration
To migrate a VM to another VSP:
1. Set up SSH keys on both the source and target hosts, as described in Section 12.3.3 (page 210).
2. Present all SAN storage assigned to the VM to the target VSP (if it is not already there).
3. If using offline migration and the guest is booted, stop the guest on the source host, using the
hpvmstop or hpvmconsole command. You can also use the hpvmmigrate -d command
to stop the guest during the migration. This has an advantage in that, the resource checks are
made on the target before the guest is stopped on the source. However, it is best to log into
the guest and shut it down before starting an offline migration. This ensures that all guest data
is properly flushed to the disks.
For information about starting and stopping guests, see Chapter 13 (page 217).
4. On the source host, enter the hpvmmigrate command, as described in Section 12.2.1
(page 199). When migrating an online guest, there are several reasons why the migration
might abort, leaving the guest running on the source host. The success or failure of migrations
is reported by the hpvmmigrate command. Causes for the abortion include insufficient
resources on the target host, excessively busy VSPs, a slow network connection, or busy guest.
If such conditions exist, the migration attempt is aborted so the workload of the guest can
continue running on the source host. This is not a serious problem because the migration can
be re-attempted when conditions improve.
5. If migrating the guest offline, restart the guest on the target host using the hpvmstart or
hpvmconsole command. You can also use the hpvmmigrate -b option with an offline
migration to automatically restart the guest on the target.
If you do not use the hpvmmigrate -D option to remove the VM configuration on the source
VSP, it is marked Not Runnable, and it is configured with all its devices. This protects the storage
from unintended use by Integrity VM commands.
If you never intend to migrate the guest back to the source VSP, you can remove the VM
configuration with the hpvmremove command. After the guest is removed from the VSP, you must
unpresent the SAN storage of the guest and remove the associated device special files (using the
rmsf command). If you cannot unpresent the storage, you must use the hpvmdevmgmt -a
rdev:/device command for each device to mark them restricted.
The hpvmmigrate command verifies that the target host has sufficient resources (such as memory,
network switches, and storage devices) for the guest to run. If the resources are insufficient or do
not exist, or if other errors occur, the guest is not migrated to the target host.
After successfully migrating the guest, the hpvmmigrate command automatically disables the
guest on the source host.
12.2.1 Using the hpvmmigrate command
You can migrate an online guest or an offline VM or vPar from a source VSP to a specified target
VSP using the hpvmmigrate command. vPars and VMs can be migrated while OFF, and online
12.2 Command line interface for migration 199