HP vPars and Integrity Virtual Machines V6.1 Administrator Guide

configuration on a per vPar basis. The -x active_config=false option must be used with

either the vparcreate or the vparmodify command.

You can deactivate a vPar configuration only if the vPar is in the inactive state, that is, the run-state

must be DOWN.

To deactivate a single vPar configuration, the vparmodify command must be used with the -x

active_config=false option. Once this is done, the vPar instance no longer consumes or

reserves the resources allocated to it, and those resources may be distributed to other partitions or

the VSP, or those resources may be used to a create different vPar instance.

To reactivate the vPar configuration use vparmodify with the -x active_config=true.

However, note that a vPar configuration cannot be reactivated unless the resources it requires are

available and not reserved by other vPar instances. A vPar can still be managed while its

configuration is deactivated; however, it cannot be booted.

Example 15 Deactivating a vPar named Gold

vparmodify -p Gold -x active_config=false

6.11 vPar V6.1 local MCA support

On a system running vPars V6.0, any Machine Check Abort (MCA) encountered in an individual

vPar (or the VSP) will result in a system crash that brings down all of the vPars. With vPars V6.1,

a certain class of recoverable, local MCAs caused by a CPU in an individual vPar are isolated to

that vPar and do not impact other running vPars.

The vPar OS first tries to automatically recover from such MCAs without bringing down the vPar

(APR – automatic process recovery supported by HP-UX). If that is not possible, the individual vPar

goes through a crash dump and is rebooted to recover from the error. If the vPar is rebooted, a

tombstones file is generated in the individual vPar.

The type of MCAs recovered from typically includes user process register file errors, kernel process

individual vPars or any type of local MCA affecting VSP cores and any global MCAs, a server or

nPartition crash happens impacting VSP and all vPars. In most cases, a VSP core dump is also

generated. In all cases, MCA logfiles are generated in the standard locations depending on the

platform.

You should be aware of the following behavior:

• If a CPU core experiences an excessive number of MCAs from which the vPar recovered either

through APR or through rebooting the vPar, system firmware and or diagnostics might

deconfigure or deactivate the CPU. In this case, when the vPar reboots, it will not contain a

deactivated or deconfigured CPU core and the MCA error records belonging to the affected

CPU core might not be available in the /var/tombstones directory.

• If another MCA (of any type) happens on any other CPU core when recovery of an earlier

MCA has not yet completed, this might cause the server or partition to be reset.

• If you stop or reset a vPar before it completely boots up after processing a local MCA, this

action might lead to the server or partition being reset depending on the platform. On

Superdome 2, this might also result in the nPartition status being displayed as MCA, even

though the vPar has actually recovered from the MCA.

• When a local MCA affecting an individual vPar cannot be contained or isolated, it will trigger

a server or nPartiton reset. In most cases, this will manifest as an INIT received by the VSP

resulting in a VSP crash dump and reboot. Hence, if there is an unexpected crash of the VSP

indicating that it was TOC’d, check the system firmware logs to determine if there was an

MCA that caused this. The VSP crashdump itself might not have any information about the

MCA.

72 Creating virtual partitions