| We now have two vPars up and running:
root @uksd5 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================ ===== ========== ========================= ===== vPar0 Up Dyn,Auto /stand/vmunix vPar1 Up Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num Memory (MB) CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== vPar0 1/ 2 1 1 10 0/ 0 2048 vPar1 1/ 2 1 1 5 0/ 0 2048 root @uksd5 #
At present, the only hardware we can manage without forcing a reboot of a vPar or the underlying server/nPar are unbound CPUs. A bound CPU handles interrupts and as such cannot be moved from a running vPar. The process of moving an unbound CPU is not as difficult as it might at first seem. Here's a quick recap on where we are currently: -
In our initial configuration, we stipulated a total number of CPUs for each vPar to = 2. -
We specified a minimum and maximum number of CPUs we wanted to maintain for our vPar (this is optional, but allows us to maintain a minimum and a maximum configuration). -
We specified the specific CPU(s) by hardware address that were bound CPUs. Currently we have no control over which unbound CPUs will be selected for inclusion in our vPar. To remove an unbound CPU from a vPar, we can simply delete a specified number of CPUs.
root @uksd3 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================ ===== ========== ========================= ===== vPar0 Up Dyn,Auto /stand/vmunix vPar1 Up Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num Memory (MB) CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== vPar0 1/ 2 1 1 10 0/ 0 2048 vPar1 1/ 2 1 1 5 0/ 0 2048 root @uksd3 # vparstatus -w The current virtual partition is vPar0. root @uksd3 # vparmodify p vPar1 d cpu::1 root @uksd3 # root @uksd3 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================ ===== ========== ========================= ===== vPar0 Up Dyn,Auto /stand/vmunix vPar1 Up Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num Memory (MB) CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== vPar0 1/ 2 1 1 10 0/ 0 2048 vPar1 1/ 2 1 0 5 0/ 0 2048 root @uksd3 #
The first thing to note is that we can manage any partition from any other partition. We could have deleted a CPU by modifying the total number of CPUs assigned to the vPar (e.g., vparmodify “p vPar “m cpu::1 ). This would have effectively deleted 1 CPU. In our configuration, both commands are effectively equivalent. Deleting a CPU by hardware address implies removing a bound CPU, which requires the vPar to be down . We can now view available resources that are not assigned to any vPar:
root @uksd3 # vparstatus -A [Unbound CPUs (path)]: 2.13 [Available CPUs]: 1 [Available I/O devices (path)]: <none> [Unbound memory (Base /Range)]: (bytes) (MB) [Available memory (MB)]: 0 root @uksd3 #
In a similar fashion, we can modify the total number of CPUs in vPar0 to allow us to include the available CPU:
root @uksd3 # vparmodify -p vPar0 -m cpu::3 vparmodify Error: "-m cpu::3": Total CPUs would exceed configured maximum. root @uksd3 #
This error message makes sense. As part of our configuration, we decided to specify a maximum and minimum number of processors per partition. That part of the configuration was optional . Here we can see the effect it has on future configuration changes. Now we need to modify the maximum number of processors before modifying the total number of processors for this partition. The problem with modifying the maximum number of processors is that it requires the partition to be down .
root @uksd3 # vparstatus -w The current virtual partition is vPar0. root @uksd3 # root @uksd3 # vparmodify -p vPar0 -m cpu:::1:5 vparmodify: Error: Virtual partition vPar0 must be in the Down state. root @uksd3 # root @uksd3 # shutdown -h now SHUTDOWN PROGRAM 11/07/03 02:13:32 GMT Broadcast Message from root (console) Fri Nov 7 02:13:32... SYSTEM BEING BROUGHT DOWN NOW ! ! ! ... root @uksd5 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================ ===== ========== ========================= ===== vPar0 Down Dyn,Auto /stand/vmunix vPar1 Up Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num Memory (MB) CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== vPar0 1/ 2 1 1 10 0/ 0 2048 vPar1 1/ 2 1 0 5 0/ 0 2048 root @uksd5 # vparmodify -p vPar0 -m cpu:::1:5 root @uksd5 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================== ===== ========== ========================= ===== vPar0 Down Dyn,Auto /stand/vmunix vPar1 Up Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num Memory (MB) CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== vPar0 1/ 5 1 1 10 0/ 0 2048 vPar1 1/ 2 1 0 5 0/ 0 2048 root @uksd5 # root @uksd5 # vparboot -p vPar0 vparboot: Booting vPar0. Please wait... root @uksd5 # [MON] Console server set to vPar0 [vPar1] [MON] vPar0 loaded root @uksd5 # root @uksd5 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================ ===== ========== ========================= ===== vPar0 Up Dyn,Auto /stand/vmunix vPar1 Up Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num Memory (MB) CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== vPar0 1/ 5 1 1 10 0/ 0 2048 vPar1 1/ 2 1 0 5 0/ 0 2048 root @uksd5 # root @uksd5 # root @uksd5 # vparmodify -p vPar0 -m cpu::3 root @uksd5 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================ ===== ========== ========================= ===== vPar0 Up Dyn,Auto /stand/vmunix vPar1 Up Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num Memory (MB) CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== vPar0 1/ 5 1 2 10 0/ 0 2048 vPar1 1/ 2 1 0 5 0/ 0 2048 root @uksd5 #
| NOTE : The point of this configuration is to show that specifying a minimum and maximum number of processors may cause you problems in the future, even when you come to manage unbound processors. |
root @uksd3 # vparstatus -w The current virtual partition is vPar0. root @uksd3 # vparstatus -vp vPar0 [Virtual Partition Details] Name: vPar0 State: Up Attributes: Dynamic,Autoboot Kernel Path: /stand/vmunix Boot Opts: [CPU Details] Min/Max: 1/5 Bound by User [Path]: 2.10 Bound by Monitor [Path]: Unbound [Path]: 2.11 2.13 [IO Details] 2.0.0 2.0.1 2.0.2 2.0.3 2.0.10 2.0.11 2.0.12 2.0.14 2.0.1.0.0.0.0 BOOT 2.0.11.0.0.3.0 ALTBOOT [Memory Details] Specified [Base /Range]: (bytes) (MB) Total Memory (MB): 2048 root @uksd3 #
The additional CPU allocated to vPar0 is now available to the scheduler to allocate to threads/processes. Similarly, vPar1 now has less processing power at its disposal. We need to understand the implications of such a change before we start, don't we? We can manage other hardware in a Virtual Partition in a similar fashion except that for any changes to IO and memory requirements, the vPar must be in a down state. In this example, I ran shutdown “h now on vPar0 to take it to a down state:
root @uksd5 # vparstatus -w The current virtual partition is vPar1. root @uksd5 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================ ===== ========== ========================= ===== vPar0 Down Dyn,Auto /stand/vmunix vPar1 Up Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num Memory (MB) CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== vPar0 1/ 5 1 2 10 0/ 0 2048 vPar1 1/ 2 1 0 5 0/ 0 2048 root @uksd5 # root @uksd5 # vparstatus -vp vPar0 [Virtual Partition Details] Name: vPar0 State: Down Attributes: Dynamic,Autoboot Kernel Path: /stand/vmunix Boot Opts: [CPU Details] Min/Max: 1/5 Bound by User [Path]: 2.10 Bound by Monitor [Path]: Unbound [Path]: <no path> <no path> [IO Details] 2.0.0 2.0.1 2.0.2 2.0.3 2.0.10 2.0.11 2.0.12 2.0.14 2.0.1.0.0.0.0 BOOT 2.0.11.0.0.3.0 ALTBOOT [Memory Details] Specified [Base /Range]: (bytes) (MB) Total Memory (MB): 2048 root @uksd5 #
I can now remove an IO device (an LBA) using vparmodify :
root @uksd5 # vparmodify -p vPar0 -d io:2/0/14 root @uksd5 # root @uksd5 # vparstatus -vp vPar0 [Virtual Partition Details] Name: vPar0 State: Down Attributes: Dynamic,Autoboot Kernel Path: /stand/vmunix Boot Opts: [CPU Details] Min/Max: 1/5 Bound by User [Path]: 2.10 Bound by Monitor [Path]: Unbound [Path]: <no path> <no path> [IO Details] 2.0.0 2.0.1 2.0.2 2.0.3 2.0.10 2.0.11 2.0.12 2.0.1.0.0.0.0 BOOT 2.0.11.0.0.3.0 ALTBOOT [Memory Details] Specified [Base /Range]: (bytes) (MB) Total Memory (MB): 2048 root @uksd5 # root @uksd5 # vparstatus -A [Unbound CPUs (path)]: 2.11 2.13 [Available CPUs]: 0 [Available I/O devices (path)]: 2.0.14 [Unbound memory (Base /Range)]: 0x8000000/64 (bytes) (MB) 0x84000000/1984 [Available memory (MB)]: 0 root @uksd5 #
We can now add this IO device to vPar1 if we want, although this would require that we restart vPar0 (use the vparboot “p vPar0 command) and then take vPar1 to a down state.
root @uksd5 # vparboot -p vPar0 vparboot: Booting vPar0. Please wait... root @uksd5 #[MON] Console server set to vPar0 [MON] vPar0 loaded root @uksd5 # root @uksd5 # vparstatus -w The current virtual partition is vPar1. root @uksd5 # shutdown -h now SHUTDOWN PROGRAM 11/07/03 02:41:59 GMT Broadcast Message from root (console) Fri Nov 7 02:41:59... SYSTEM BEING BROUGHT DOWN NOW ! ! ! ... root @uksd3 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================ ===== ========== ========================= ===== vPar0 Up Dyn,Auto /stand/vmunix vPar1 Down Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num Memory (MB) CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== vPar0 1/ 5 1 2 9 0/ 0 2048 vPar1 1/ 2 1 0 5 0/ 0 2048 root @uksd3 # root @uksd3 # vparmodify -p vPar1 -a io:2/0/14 root @uksd3 # root @uksd3 # vparstatus -vp vPar1 [Virtual Partition Details] Name: vPar1 State: Down Attributes: Dynamic,Autoboot Kernel Path: /stand/vmunix Boot Opts: [CPU Details] Min/Max: 1/2 Bound by User [Path]: 2.12 Bound by Monitor [Path]: Unbound [Path]: [IO Details] 2.0.4 2.0.6 2.0.9 2.0.8 2.0.4.0.0.8.0 BOOT 2.0.14 [Memory Details] Specified [Base /Range]: (bytes) (MB) Total Memory (MB): 2048 root @uksd3 # root @uksd3 # vparboot -p vPar1 vparboot: Booting vPar1. Please wait... root @uksd3 # [MON] vPar1 loaded root @uksd3 #
The only issue we haven't discussed here is deleting a vPar. I will cover that toward the end of this section. 3.7.1 Adding/removing cells to an nPar running vPars If we want to effect a change to an nPar that will change the underlying cell assignment, we can do so while vpmon is up and running. The tricky part of this configuration is being able to step back and realize that in fact we are running vPars from within an nPar:
root @uksd3 # parstatus -w The local partition number is 2. root @uksd3 # root @uksd3 # parstatus -P [Partition] Par # of # of I/O Num Status Cells Chassis Core cell Partition Name (first 30 chars) === ============ ===== ======== ========== =============================== 0 active 1 1 cab0,cell0 uksd1 1 active 1 1 cab0,cell4 uksd2 2 active 1 1 cab0,cell2 uksd3 root @uksd3 #
In our configuration, we are running two vPars within nPar = 2 (partition name = uksd3 ). From here we can effect changes to the nPar, i.e., adding and/or removing cells using standard nPar management techniques.
root @uksd3 # parstatus -AC [Cell] CPU Memory Use OK/ (GB) Core On Hardware Actual Deconf/ OK/ Cell Next Par Location Usage Max Deconf Connected To Capable Boot Num ========== ============ ======= ========= ================= ======= ==== === cab0,cell1 absent - - - - - - cab0,cell3 absent - - - - - - cab0,cell5 absent - - - - - - cab0,cell6 inactive 4/0/4 4.0/ 0.0 cab0,bay0,chassis3 yes - - cab0,cell7 absent - - - - - - root @uksd3 # root @uksd3 # parmodify -p 2 -a 6::: In order to activate any cell that has been newly added, reboot the partition with the -R option. Command succeeded. root @uksd3 #
As we can see, there is now a pending change in the SCCD and all the Virtual Partitions are up and running. If we were simply to reboot the current vPar, even with the “R option, the reboot-for-reconfig would not take effect until all other vPars had been halted . Only then will vpmon be rebooted allowing the nPar to be rebooted and the new SCCD pushed out by the GSP. As you can imagine, this needs to be planned well in advance. The process of rebooting all vPars can take some considerable time.
root @uksd3 # shutdown -R now SHUTDOWN PROGRAM 11/07/03 03:20:02 GMT Broadcast Message from root (console) Fri Nov 7 03:20:02... SYSTEM BEING BROUGHT DOWN NOW ! ! ! .. [vPar1] [MON] vPar0 has halted. root @uksd5 # root @uksd5 # shutdown -ry now SHUTDOWN PROGRAM 11/07/03 03:24:02 GMT Broadcast Message from root (console) Fri Nov 7 03:24:02... SYSTEM BEING BROUGHT DOWN NOW ! ! ! ... Note: If this is a partitionable system, the requested reconfiguration will not take place until all the virtual partitions on this hard partition are shut down and the virtual partition monitor is rebooted. ... Closing open logical volumes... Done Cells has been reset and are ready for reconfiguration (Boot Is Blocked (BIB) is set). Please check Virtual Front Panel (VFP) for reset status. Reboot for reconfiguration returned 2 Cells have been reset (Boot Is Blocked (BIB) is not set). [MON] [MON] vPar1 has halted. All partitions have halted. System will now reboot for reconfiguration.
Once the nPar has rebooted, we have a new pool of available resources with which to manage our vPars.
Firmware Version 35.4 Duplex Console IO Dependent Code (IODC) revision 1 -------------------------------------------------------------------------- (c) Copyright 1995-2002, Hewlett-Packard Company, All rights reserved -------------------------------------------------------------------------- Cab/ Cell ------- Processor -------- Cache Size Cell Slot State # Speed State Inst Data ---- ---- ------------ --- -------- ----------- ------ ------ 2 0/2 Active 0 552 MHz Active 512 KB 1 MB 1 552 MHz Idle 512 KB 1 MB 2 552 MHz Idle 512 KB 1 MB 3 552 MHz Idle 512 KB 1 MB 6 0/6 Idle 0 552 MHz Idle 512 KB 1 MB 1 552 MHz Idle 512 KB 1 MB 2 552 MHz Idle 512 KB 1 MB 3 552 MHz Idle 512 KB 1 MB Primary Boot Path: 2/0/1/0/0.0 Boot Actions: Boot from this path. If unsuccessful, go to next path. HA Alternate Boot Path: 2/0/4/0/0.8 Boot Actions: Boot from this path. If unsuccessful, go to BCH. Alternate Boot Path: 2/0/4/0/0.8 Boot Actions: Skip this path. Go to BCH. Console Path: 2/0/0/0/0.0 Attempting to boot using the primary path. ------------------------------------------------------------- To discontinue, press any key within 10 seconds. 10 seconds expired. Proceeding... Initializing boot Device. Boot IO Dependent Code (IODC) Revision 0 Boot Path Initialized. HARD Booted. ISL Revision A.00.43 Apr 12, 2000 ISL booting hpux /stand/vpmon -a Boot : disk(2/0/1/0/0.0.0.0.0.0.0;0)/stand/vpmon 614400 + 168736 + 16898800 start 0x23000 [MON] Booting vPar1... [MON] Booting vPar0... [MON] Console client set to vPar1 [MON] vPar1 loaded [MON] Console server set to vPar0 ... root @uksd3 # vparstatus -A [Unbound CPUs (path)]: 6.10 6.11 6.12 6.13 [Available CPUs]: 4 [Available I/O devices (path)]: 6.0 6.0.0 6.0.1 6.0.2 6.0.3 6.0.4 6.0.6 6.0.8 6.0.9 6.0.10 6.0.11 6.0.12 6.0.14 [Unbound memory (Base /Range)]: 0x0/64 (bytes) (MB) 0xc000000/4032 [Available memory (MB)]: 4096 root @uksd3 #
| 