System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

N-Part & V-Par regarding query

masthan_1
Advisor

N-Part & V-Par regarding query

Please help me in understanding the following:

1)  Lets assume that I have 2 npars (npar1, npar2) & each npar having 2 vpars. For some reason, I wanted to shutdown the vpars presented in npar1. After shutting down the vpars, how can i confirm or where should i go to confirm that the vpars are shutdown...is it in the MP of that server complex..?
if through MP, which section i need to check whether it is under vfp, co or cm (may be i need to go to sub-sections?

 

2) Where the boot processes are differ for npar & vpar?

Pls explain briefly on how NPAR & VPARS are booting, when we power on the superdome server complex which has 2 cabinets?

 

3) Where do i need to install the OS? whether it is on the boot disk of npar or boot disk of vpar. how do i call this? (confused that, are both npar & vpar having separate boot disk?

 

4) Configuring the boot disks (is it from npar or from vpar)?

 

Thank you.

 

Masthan

2 REPLIES
Matti_Kurkela
Honored Contributor

Re: N-Part & V-Par regarding query

1.) You can confirm the vPars of the npar1 have shut down by entering the MP and selecting the COnsole of npar1. Normally you can switch between the consoles of the vPars of this nPar by pressing Ctrl-A; but if all the vPars are down, you'll only see the MON> prompt of the vPar monitor (vpmon) and find you cannot switch away from it with Ctrl-A. You can use the vparinfo command in the MON> prompt to confirm all the vPars have completely shut down. Then you can use "reboot" to shutdown/reboot the vPar monitor and then use the MP's power control commands to power down the nPar. (Apparently older versions of vpmon did not have a "halt" command in the MON> prompt.)

 

2.)

On a non-partitionable system, when power is switched on, the firmware runs self-tests and then starts the boot loader, which then loads & runs the OS kernel.

 

On a partitionable system, each cell starts firmware self-tests independently at power-on, then according to the "complex configuration" the cells join together into one or more nPars. In each nPar, the firmware starts a boot loader (1 bootloader per nPar only), which then loads either the OS kernel directly (if only nPar-level partitioning is used) or the vPar monitor (vpmon) if vPars are used.

 

If vPars are used, vpmon then takes control of all the hardware in the nPar, reads the vPar configuration and then prepares one or more vPars for booting. If the vPars have the autoboot flag set, then the vPar monitor will automatically load & run the OS kernels for them; if not, the monitor will display the MON> prompt and wait for commands.

 

3.) This might be easiest to understand by walking through the vPar set-up procedures.

 

If you plan to set up vPars to a brand new nPar, you'll first install a normal HP-UX OS in the nPar as normal. This OS is now running in "non-vPar mode". You use it to install the vPar software and prepare your vPar configuration. At this point, the OS will see all the hardware available to this nPar, so you can verify the hardware paths of each future vPar boot disk easily.

 

As the vPar software is installed, the vPar monitor (vpmon) and the vPar configuration database to the /stand of this OS installation. At this point, you can define multiple vPars, but cannot start them yet. The boot disk of the first vPar should be configured to be the same as the boot disk of the nPar. Thus, the first vPar will already have an OS installed; the other vPars will have no OS at this point.

 

To switch the system to vPar mode, you tell the nPar-level bootloader to load vpmon instead of the vmunix kernel and reboot.

 

Now, the sequence is: first, the nPar firmware uses the boot disk settings in the NVRAM (= nPar boot disk setting) to find the bootloader (PDC on PA-RISC; EFI on Itanium), which will load vpmon. The vpmon then reads the vPar configuration database, and starts the vPar(s) marked as auto-bootable in the vPar configuration database. The vPar config database tells vpmon that the boot disk of the first vPar is the same as the disk where vpmon was installed on, so the original OS that was installed to the nPar now becomes the OS of the first vPar. 

 

You can now start creating other vPars. If you already pre-configured them before switching to vPar mode, the next task is to install the OS on them, typically using Ignite network installation.

 

So, each vPar will have its own boot disk. But one of the vPar boot disks will be special: it will contain the active vpmon, and thus it will *also* be the nPar-level boot disk.

 

4.) When you're in vPar mode, the regular "setboot" command will manipulate the vPar boot configuration in the vPar configuration database instead of NVRAM. If you need to make configuration changes to a vPar that is currently down, you'll make them via vparmodify from the *other* vPars of the same nPar, or from the MON> prompt.

 

When running in vPar mode, you typically leave the boot disk configuration of the nPar level mostly alone, because it is only used to tell the system where to find vpmon. But if you need to change it (e.g. you're migrating the entire set of vPars to different disks), then you can modify the nPar-level boot disk setting from the MON> prompt, or by shutting down all the vPars and rebooting the entire nPar to firmware boot prompt and then using the firmware commands as usual.

 

Clear as mud?

MK
masthan_1
Advisor

Re: N-Part & V-Par regarding query

Hi,

 

Thank you so much for your reply and spending your valuable time in writing these many points. As I am learning vpars npars administration may need your help in future as well..can you please share any links which may have some description and some ideas further on this...Thanks agian..kudo's givn..