Are there issues with dormant but actively maintained/patched vPar software on active nPars?

[Alzhy]

One strategy for DR I am thinking about is to use vPars to consolidate our smaller (1-2cpu/2-4GB N-Class) servers on to a more current "bigger/faster" box (i.e. rp4440 or rp7420). To realize this I am thinking of having my servers be installed with vPar software and keep it's patches up to date. The software wil just be dormant/unused so when DR happens, the disks (clones that are periodically offsited) over at the recovery site can just be booted off and the environments recovered as vPars.

Will a dormant/unused vPar software pose any issues on the servers that are brought up as nPars?

[Luk Vandenbussche]

Hi Nelson,

A dormant vPAR is no problem on an npar server.

You just need enough free resources to bring it up on your npar system. If you have fe not enough memory you need to restart a partition to free up some memory.

But beware that the vpar daemon must be running before you can start a an extra vpar. So your npar system must consist of a running vpar software parition. You need mimimum one running vpar

[Alzhy]

Luk. Thanks.

The strategy (based on some carefully thought of plan and resource allocation of course) on the DR site,

1. Bring up the clone disk of the first server to be consolidated, "fix/acclimate it". Bring the nPar all up and define the vPars.

2. Reboot the nPar on the same disk and bringup vPmon, bring up vPar1 (same disk)

3. For each of the remaining clone disk of the other servers, vparboot to ISL, booting to LVM maintenance mode and "fix/acclimate" the OS - finally bringing each vPar to full run level ready for non-Os recovery stuff.

"fix/acclimate" - means.. fixing VG00, fix IOCONFIG and networking -- the details of which I will no longer discuss.

The idea is to consolidate 5 to 6 N-Class/rp7400 servers on to one rp74XX machine - for cost advantages and possibly for a straight migration off these older individual machines.

[Alzhy]

My issues really are:

With vPar software installed but the OS is not booted up in vPar mode - will there be vPar components that will actually be running? Will there be vPar patches/kernel hooks that will not be active and hence possibly introduce some instability tih it non-usage? And finally, licensing issues - will I still need to pay license for its being installed even if "dorman"? In a DR, we plan to use our DR licenses on our test and staging environments.

[Luk Vandenbussche]

Hi Nelson,

With active VPARs you have to boot another kernel /stand/vpmon

Without active VPARs you boot a kernel
/stand/vmunix.

of course there are vpar patches yet.

Concerning the license, it is CPU based....
But have you ever seen a tool to check this?

[Alzhy]

Luk, I know...

Problem is, our systems are closely monitored by HP - ISEE and periodic software audits, etc.

I've requested my boss to ask HP if the mere fact of having vPars software in an inactive state on our individual servers/nPars constitute license usage.

On the issue of stability of the OS with an inactive but regularly patched vPar software - I guess thorough long term testing is the only way to go. In the 4 years I have had to work on HP-UX environments, I've encountered some surprises that I never thought of. That is why testing.. testing and more testing.. is my motto on HP-UX environs.