HP vPars and Integrity Virtual Machines V6.1 Administrator Guide

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.
12.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 VSPs
• 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 VSP. 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.
12.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 VSP 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 VSPs. 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
VSP to WWID and then DSF on the target VSP. Use ioscan -C disk -P wwid to see if the
virtual machine's disks are presented to both VSPs. 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 VSP system.
212 Migrating virtual machines and vPars