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

and features when they are needed. This is especially true for workloads with well-understood
cyclic resource requirements (for example, month-end processing).
• Balancing VSP workloads — You might want to segregate VMs to balance the workload on
VSPs. For example, you might want to separate VMs whose workloads peak simultaneously.
Perhaps you want to group workloads together that have similar special resource requirements.
For example, you will run your multi-threaded applications on a VSP that has several CPUs in
order to maximize the effectiveness of multi-way VMs. OVMM enables a new level of
workload-to-resource alignment flexibility and agility where you can segregate or combine
your workloads, without any interruption in application availability.
• Optimizing physical resource utilization — The OVMM feature enables you to optimize the
physical resources in use by running VM. You can move (or park) idle VM, near-idle VM, or
VM with currently less-critical workloads on a smaller or less powerful machine. You can use
the dynamic memory feature to reduce the amount of memory in use by the VMs and shrink
CPU entitlements to more tightly packed VMs on a smaller VSP.
For more information about the online and offline migration support, see HP-UX vPars and Integrity
VM Release Notes, available at http://www.hp.com/go/hpux-hpvm-docs
To verify whether a guest can be migrated to the target VSP, use the hpvmmigrate -s option.
12.1.2 Considerations for migrating VMs or vPars offline
Following are the considerations to migrate a VM or vPar offline:
• The vPar or VM can be stopped; you must move the configuration information offline.
• Migrating the VM or vPar offline does not use the VSP resources (such as memory and CPUs)
on the source and target VSPs (You can migrate vPars offline only.).
• The vPar or VM might have local storage, logical volumes, or file-backed storage, which must
be copied to the target VSP.
• The source and target VSPs might have different processor types that prevent online migration.
• The source VSP might be running a version of Integrity VM earlier to Version 6.3, which does
not support OVMM.
• You can migrate vPars or VMs offline between different processor families.
For more information about the migration path for offline migration, see HP-UX vPars and Integrity
VM Release Notes, available at http://www.hp.com/go/hpux-hpvm-docs.
Offline migration of a vPar or VM guest with DIO functions assigned requires that each function
is assigned a label using the hpvmhwmgmt -L label switch (See hpvmhwmgmt(1M) for the
command syntax.). Additionally, for each DIO-capable function on the vPar or VM guest on the
source VSP, there must be at least one DIO capable function on the target VSP.
A label can contain up to 255 alphanumeric characters, including A-Z, a-z, 0-9, the dash (-), the
underscore (_), and the period (.), except that it might not be the string "." or "..". Labels apply
only to DIO functions, and are added to the DIO pool on the source and target VSPs using the
following command:
hpvmhwmgmt -p dio -a hwpath
If any DIO function in a vPar or VM does not have a label, offline migration fails. There might be
more functions with the same label available on the target VSP than are needed to do a one-to-one
matching of DIO functions on the target VSP, but there must be at least a one-to-one correspondence
between each labeled function on the source vPar or VM and available DIO-capable functions on
the target VSP.
HP recommends that you assign labels to correspond to IP names, so that the network mapping
on the source vPar or VM is preserved when the vPar or VM is migrated to the target VSP. It is not
a requirement for offline migration to succeed, but failure to maintain the one-to-one correspondence
with IP names might cause problems when the migrated vPar or VM is started.
198 Migrating VMs and vPars