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

11.4.9 Time taken for CRA on a VSP
The default timeout value set for each guest OS to complete CRA requests issued to it, as part of
the host PCI OLR operations initiated using the olrad(1M). The value is two minutes. For guests
with large, active, and I/O configurations this may be insufficient. Administrators can configure
the timeout value by defining the parameter OLR_GUEST_RESP_TIMEOUT in /etc/
rc.config.d/hpvmconf the timeout value must be specified in milliseconds.
11.4.10 Impact of PCI OLR on HPVM
PCI OLR operations require the temporary suspension of affected I/O traffic within guests. During
this time, administrative operations that change the configuration or active status of running guests
are not allowed. Operations such as hpvmstart(1M) or vparboot(1M), Dynamic I/O addition
using hpvmmodify(1M) or vparmodify(1M), hpvmstop(1M), hpvmsuspend(1M),
hpvmmigrate(1M), and so on, are not allowed to run while a host PCI OLR operation is in
progress. These operations are serialized using a software lock. If any one of these commands is
running, attempts to run the same or any other commands that modify guest configuration or state
are failed with a message stating unable to get file lock. In such cases, the operation
may be retried after the first is completed.
11.5 Limitations of PCI OLR on SD2 VSPs
The following are the limitations of PCI OLR on SD2 VSPs:
• Online VM migration or resume of a guest that is using a resource backed by a suspended
VSP I/O resource fails.
• Starting a guest that has a resource backed by a suspended VSP resource succeeds as long
as the guest boot is not impacted.
• If a guest with a resource backed by a suspended VSP resource is booted, and the resource
is resumed on the VSP at a later point, a guest reboot is be required before the guest resource
is usable or online.
• If the OLR of a VSP resource impacts more than 32 I/O devices (vHBAs or vNICs) on any
guest, the OLR VSP operation fails.
• CRA on the guest will not take non-NPIV devices into account, that are configured as primary
boot (when the primary boot device is not the one on which the current boot occurred),
secondary boot, and dump devices. But, a caution is displayed in the VSP CRA log.
• For non-NPIV resources, no resource usage will be logged within the guest CRA log.
• While a PCI OLR is in progress on the VSP, no other HPVM command that results in a guest
state change can be executed (guest start, stop, migrate, suspend, resume, modify). Similarly,
while an HPVM command that can change the state of a guest is in progress, a PCI OLRAD
command cannot be executed on the VSP.
• PCI OLR is currently not supported on guests using vlan backed vswitches. When a CRA
request is issued to olrad capable slot containing a physical NIC and the NIC has virtual
LAN Interface (VLAN interfaces) backed to a vswitch always returns CRA_SUCCESS.
• A PCI OLR operation or a CRA on the VSP is not supported if any of the active vPars or VM
guests have more than 32 impacted IO devices of a particular type (NPIV or AVIO LAN) on
the I/O card.
• When a PCI OLR operation on the VSP reports a legacy AVIO resource as data critical for
any of the active vPars or VM guests, the olrad command must not be retried with the force
option without manually verifying if the primary or secondary boot device, swap, or dump
device or cluster lock disk configured within the vPar or VM will be impacted.
11.5 Limitations of PCI OLR on SD2 VSPs 193