HP-UX Virtual Partitions 6.0 Release Notes

Table 5 Known behaviors in vPars v6.0 (continued)
Description / actionProblem
The vPars v6 product supports dynamic CPU addition and deletion. The selection
criteria for CPU addition are performed from within the VSP based on LORA
CPU OLD policy
policies. The selection criteria for CPU deletion is performed from within the
HP-UX instance that is target of the CPU deletion. The following criteria are
used to select the CPU cores to be deleted:
• Only cores in the default pset (see psrset(1M)) can be dynamically removed.
• The monarch core can never be deleted.
• If the default pset does not contain enough cores to satisfy a full request to
reduce the number of cores, the processor assignments will remain
unchanged.
• Processors can be moved to the default pset and then deleted.
What to do
There is no workaround.
When Serviceguard detects a hang of the operating system, it uses a system
interface to TOC the operating system. If Serviceguard initiates a TOC in a
TC/RS/stop behavior during
ServiceGuard TOC
v6.0 vPar, any subsequent vparreset operation causes initiated from the
VSP to that specific vPar causes a message to be logged to syslog. The
command completes but no action is taken until the Serviceguard TOC operation
completes.
What to do
There is no workaround.
When the VSP boots it has visibility to all the memory in the system. During the
boot of HP-UX most of the VSP free memory is allocated and set aside to satisfy
Memory reservation is not guaranteed
across a host reboot
the configuration requirements of the vPars. The amount of free memory may
vary between boots of the VSP and this may lead to a memory over-subscription
issue if the sum of vPars memory is greater than the free memory available in
the VSP.
This is a rare condition and can arise if the configuration of the VSP changes
or if startup applications running on the VSP consume too much memory at the
time when memory for the vPar pool is allocated.
What to do
If this condition occurs, you can delete memory from a vPar that has enough
memory to cover the amount of the memory over-subscription. If the amount of
memory specified by the vparmodify is not enough to cover the
over-subscription then an error is raised and the memory remains the same.
Only one vPar can be modified to cover the over-subscription condition. After
the over-subscription is resolved, the memory amongst vPars can be modified
to suit the memory requirement of the vPars.
A vPar can be configured with a combination of 63 HBAs and NICs as long
as the number of NICs does not exceed 16. If the number of NICs exceeds 16,
MAX supported number of vNICs in
a vPar
a panic might occur during the boot of the vPar, displaying the following
message: VIRT: intr_disp_get_vector() failed.
What to do
Reduce the number of NICs assigned to the vPar to 16 or less.
SMH places a heavy load on the system when it starts up and may timeout
when it does not get the required amount of CPU cycles. On a VSP that is under
SMH is unresponsive when running
stress tests on a host
heavy load (greater than 80% utilized), executing SMH may timeout and need
refreshing to display system information.
What to do
If SMH repeatedly times out consider adding an additional core to the VSP to
allow SMH access to additional CPU cycles. Use the vparhwmgmt command
to move a core from the vPar pool to the VSP pool. If there are no free cores
in the vPar pool, a core must be removed from one of the vPars. When SMH
19