HP vPars and Integrity Virtual Machines V6.1 Release Notes

# ioscan -P ms_scan_time -C fc
Class I H/W Path ms_scan_time
============================================
fc 0 44/0/0/0/0/0/0 0 min 7 sec 7 ms
fc 1 44/0/0/2/0/0/0 0 min 6 sec 213 ms
fc 2 44/0/0/2/0/0/1 0 min 4 sec 1 ms
3. If an individual FC HBA takes more than 10 seconds to probe, check your FC switch and zone
settings to see why the probe time is so high.
4. Increase the online migration timeout value using the hpvmmodify command. For example,
if the syslog reports a warning that the NPIV probe time is 79 seconds, increase the timeout
value several seconds beyond that, to around 90 seconds (90000 msec):
# hpvmmodify -P guest1 -x "tunables=ogmo=90000"
# hpvmmodify -P guest1 -x migrate_frozen_phase_timeout=90
The default timeout value for ogmo is 30000 msec (30 seconds). The default timeout value for
migrate_frozen_phase_timeout is 60 seconds.
Alternatively, you can also reduce the NPIV probe time by reducing the number of NPIV HBAs
assigned to the guest.
3.1.22 vPar might hang during boot
A vPar might hang during boot, just prior to running the system run level startup rc scripts. This
is expected to be a rare occurrence. Pressing the Enter key or any other key on the vPar (guest)
console should resume boot up of the vPar. The problem does not occur with virtual machines.
3.1.23 Memory allocation might not be as expected
vPar and VM memory is allocated in granules of 64 MB. If a vPar's or VM's memory size is not
an even multiple of 64 MB, the API/CLI code rounds up, but hpvmapp rounds down. Consequently,
there will be 64 MB of memory reserved for the vPar/VM, but not used by it, and the vPar/VM
might have up to 64MB to 1KB of memory less than was allocated.
To work around this problem, set the vPar or VM memory size to a multiple of 64 MB.
3.1.24 I/Os take long to complete under heavy I/O conditions on vPars/VMs with
large NPIV LUN configuration
In a large LUN configuration, spread NPIV HBAs across multiple physical HBA ports at the VSP
level.
3.1.25 vPar/VM hangs on boot just prior to RC scripts being launched
The vPar/VM might hang on boot just prior to RC scripts being launched, The boot hang is caused
by a vPar/VM console output buffer overflow condition.
In the event of a vPar or VM hangs during boot, press the Enter key or any other key to resume
the vPar/VM boot process.
3.1.26 CPU deconfigured by firmware can be assigned to vPar/VM
If a CPU experiences local MCA’s too many times, the system firmware de-configures the CPU
without HP-UX knowledge. This might cause the VSP to give the CPU to one of the vPars or VMs
(which originally owned the CPU). The result of this is a vPar/VM hang in the bootloader.
The likelihood of this situation occurring is low, but if it does, stop and restart the vPar/VM to cause
different CPUs to be assigned to the vPar or VM.
20 Issues in this release