HP-UX vPars and Integrity VM V6.1.5 Administrator Guide (5900-2295, April 2013)

SHARE=YES can lead to more than one virtual machine using the device at the same time and can
lead to disk corruption.
12.3.4.4 Rules for selecting physical HBA ports during migration with NPIV HBAs
This section summarizes the rules that the hpvmmigrate command uses to decide upon the physical
HBA port (pFC) on the target host on which a particular guest NPIV HBA is created after a guest
migration. These rules are applicable for both offline as well as online migrations and for VM
guests as well as vPars.
The following rules apply:
• For a particular guest NPIV HBA, when selecting a physical HBA port (or pFC) on the target
host, the first preference is the pFCs that is connected to the same physical switch as the pFC
on the source host. Of all such pFCs, the one with the least number of active NPIV HBAs is
chosen, to ensure that no one pFC is overloaded with too many NPIV HBAs.
• If no such pFC is found on the target, then a pFC that is connected to the same fabric as the
pFC on the source host is selected. Of all such pFCs, the one with the least number of active
NPIV HBAs is chosen.
• Which pFCs are chosen on the target host depends on the following:
The number of pFCs on the target host◦
◦ The number of active NPIV HBAs that each of them already has
◦ The FC connectivity of the pFCs to the FC fabric (that is, to which physical switch and
fabric they are connected).
• During migration, the hpvmmigrate command might not take redundancy or multi-pathing
aspects into account under all scenarios. Two NPIV HBAs that were originally created on pFCs
on two distinct physical HBA cards on the source host could eventually end up on the same
pFC or two pFCs on the same HBA card on the target.
• If the FC connectivity on the source and the target are exactly identical, and all the pFCs on
the target have no NPIV HBAs, then during migration, the NPIV HBA distribution across the
pFCs on the target will be largely similar to what it was on the source host.
12.3.4.5 Using NTP on the VM guests
Using NTP is strongly recommended for Online VM Migration environments. Each guest should
include all potential VSPs as servers in its ntp.conf file so the current local VSP can be used
as a time source. Whether migrating or not, guests should not be used as time servers. To maintain
reliable time synchronization on a guest, it might be necessary to reduce the NTP polling interval,
so the guest checks the time more frequently with the NTP server.
12.3.4.6 Marking a guest not runnable
On all VSPs that have a virtual machine configured, the virtual machine should be marked
Runnable on only one VSP at a time. While migrating online guests, unexpected errors or guest
resets or aborts should not cause your guest to be marked Runnable or Not Runnable incorrectly.
To verify the Runnable state of a virtual machine, use the hpvmstatus command to see that the
guest is Runnable on only one VSP and Not Runnable on all other VSPs. If the Runnable
state of a virtual machine is not correct on a VSP, use the hpvmmodify command to correct it.
For information about the hpvmmodifycommand and how to mark a guest Runnable or Not
Runnable, see Section 12.2.4 (page 208).
To mark a guest Not Runnable, use the following command:
# hpvmmodify -P guestname -x runnable_status=disabled
To mark a guest Runnable, use the following command:
12.3 VSP and virtual machine configuration considerations 217