HP Integrity Virtual Machines 4.3: Installation, Configuration, Administration

For example, if a guest stops I/O to storage for too long, it could experience I/O errors and
applications could fail or the operating system could crash. If a guest is frozen for too long,
external network connections to the guest can time out and network connections can be dropped.
Network time-outs are especially troublesome for certain UDP applications that are not resilient
enough to tolerate packets being delayed and dropped. If you run UDP applications that assume
fast network packet turnaround, you might need to reduce the frozen phase time-out value,
which might cause online migrations to abort more often. However, it will preserve the integrity
of the network connections to the guest. The trade-off is that your migration might abort if
conditions are not right for fast and efficient migrations.
If necessary, you can carefully adjust the following migration time outs with the hpvmmodify
-x command:
• migrate_init_phase_timeout — Specifies the maximum number of seconds the online
migration spends during the initialize phase of the migration. The default is 90 seconds.
• migrate_copy_phase_timeout — Specifies the maximum number of seconds the online
migration spends during the full-copy phase. The default is infinite.
• migrate_io_quiesce_phase_timeout — Specifies the maximum number of seconds the
migration spends during the quiesce phase. The default is 15 seconds.
• migrate_frozen_phase_timeout — Specifies the maximum number of seconds the migration
spends during the freezing phase. The default is 60 seconds.
9.3.4.2 Migrations Might Time Out and Need to be Restarted
To protect a guest's workload, the Online VM Migration feature has limits for the amount of
time that a migrating guest can remain in various phases of a migration. There are several capacity
and resource-related reasons an attempted online migration might time out and abort, leaving
the guest running on the source host. Potential causes include:
• Insufficient resources on the target host
• Excessively busy VM Hosts
• A slow network connection
• An extremely busy guest
If conditions like these exist, the attempted migration is aborted , so the guest's workload can
continue running on the source VM Host. This is not a serious problem, because the guest
continues to run on the source, and the migration can be re-attempted when conditions improve.
9.3.4.3 Guest Storage Device Shareable Attribute not Propagated During Online Migration
The guest storage device shareable attribute is not propagated to the target VM Host during an
online migration. After the first guest that is configured to use the shared storage is online
migrated to the target, enable the shared attribute for the device to avoid online migration failures
for other guests that share the device. Use the hpvmstatus command to determine the device
special filename of the shared device on the target and the hpvmdevmgmt command to mark the
device shareable. For example:
hpvmstatus -P vm_name -d
hpvmdevmgmt -m gdev:/dev/rdisk/disknnn:attr:SHARE=YES
For online and offline migration, device special files (DSFs) assigned to virtual machines do not
need to match on source and target VM Hosts. Do not physically rearrange controllers on the
host systems to make the paths the same. This can lead to stale DSFs and stale entries in the
Integrity VM device management database. The hpvmmigrate command converts from DSF
on the source VM Host to WWID and then DSF on the target VM Host. Use ioscan -C disk
-P wwid to see if the virtual machine's disks are presented to both VM Hosts If you find stale
DSFs and stale entries in your Integrity VM device management database, use the insf -e
command and the hpvmdevmgmt command to repair the HP-UX VM Host system.
192 Migrating Virtual Machines