Flylib.com

Books Software

 
 
 

3.11 Resetting a Virtual Partition

     

3.11 Resetting a Virtual Partition

It is not inconceivable that an instance of HP-UX will hang, possibly due to a software or hardware fault. On a non-vPar server/n-Par, we can deal with this in two ways: We can issue a hard reset (the RS command from the GSP/console) or a soft reset (the TC command from the GSP/console, invoking a system crashdump ). If we perform either of these tasks on a vPar-enabled server/n-Par, we will reset all vPars and vpmon not a good idea. If we want to issue a hard or soft reset on an individual vPar, we use the vparreset command. The “h option is a hard reset (the RS command). The “t option is a soft reset (the TC command).



root @uksd3 #

vparreset -p vPar1 -t

Reset virtual partition vPar1? [n]

y

******** TOC -- Processor 2: HPA 0xfffffffffc27c000  Entity ID: 10 *********

General Registers 0 - 31

00-03  0000000000000000  000000000401521c  00000000043d3950  0000000000000000

04-07  0000000001540790  000000000153a000  000000000153a9b0  0000000004c48fd0

08-11  0000000004c74430  0000000004a87080  0000000004b7a080  0000000004b7c080

12-15  0000000004b7a080  0000000004b7c080  0000000004b7c080  0000000004ada1a0

16-19  0000000000000064  000000004008fd00  0000000000000000  0000000000000002

20-23  0000000000000000  0000000007ae04e0  0000000700000000  00000000049dcb80

24-27  fffffff000000000  0000000000000040  fffffff0ffffffff  0000000004b84080

28-31  fffffff0ffffffff  0000000007ae0350  0000000007ae0310  0000000004156c08



Control Registers 0 - 31

00-03  000000007d3c35f0  0000000000000000  0000000000000000  0000000000000000

04-07  0000000000000000  0000000000000000  0000000000000000  0000000000000000

08-11  000000000000ba0f  000000000000945c  00000000000000c0  0000000000000038

12-15  0000000000000000  0000000000000000  000000000400a000  fffffff0ffffffff

16-19  00000140924adab5  0000000000000000  00000000043d3950  00000000e81f1d05

20-23  000000001034001e  00000000b82e1300  000000000804021f  0000000000000000

24-27  000000000153a000  000000000465d1d6  000000004008fd00  000000004006cd80

28-31  000000000153a000  00000140921e233e  0000000000007c37  0000000007ae0310



Space Registers 0 - 7

00-03  000000000b049000  00000000024f8000  000000000a30a400  0000000000000000

04-07  0000000000000000  00000000ffffffff  0000000009886000  0000000000000000



IIA Space                    = 0000000000000000

IIA Offset                   = 00000000043d3954

CPU State                    = 0x9e000001



root @uksd3 #

The hex data is gathered from the Processor Information Module (PIM). This will be displayed whenever we perform a hard or soft reset of a vPar. After a TOC, we will find the crashdump under the directory configured to store crashdumps, /var/adm/crash by default. It should be noted that any root user logged into a vPar within a server/n-Par is able to reset any other vPar within the same server/n-Par.

     

3.12 Removing a Virtual Partition

NOTE : For this example, I have returned the configuration where both vPars have two CPUs: one bound and one unbound .




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/  5    1   1     9    0/  0         2048

vPar1                             1/  2    1   1     5    0/  0         2048

root @uksd3 #

In order to remove a virtual partition, it must be in a down state. After shutdown, we can remove the partition quite simply with vparremove :




root @uksd3 #

vparremove -p vPar1

Remove virtual partition vPar1? [n]

y

vparremove: Error: Specified virtual partition vPar1 not in Down state. Cannot remove the
graphics/ccc.gif
virtual partition.

root @uksd3 #

...

root @uksd5 #

shutdown -h now

SHUTDOWN PROGRAM

11/07/03 05:11:46 GMT



Broadcast Message from root (console) Fri Nov  7 05:11:46...

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   1     9    0/  0         2048

vPar1                             1/  2    1   1     5    0/  0         2048

root @uksd3 #

root @uksd3 #

vparremove -p vPar1

Remove virtual partition vPar1? [n]

y

root @uksd3 #

root @uksd3 #

vparstatus

[Virtual Partition]

                                                                          Boot

Virtual Partition Name       State Attributes Kernel Path               Opts

============================ ===== ========== ========================= =====

vPar0                          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     9    0/  0         2048

root @uksd3 #

The resources that were used by vPar1 are now available to be used by other partitions, or that's what you thought.



root @uksd3 #

vparstatus -A

[Unbound CPUs (path)]:  2.12

                        2.13

[Available CPUs]:  2



[Available I/O devices (path)]:  2.0.4

                                 2.0.6

                                 2.0.8

                                 2.0.9

                                 2.0.14



[Unbound memory (Base  /Range)]:  0x0/128

                (bytes) (MB)      0xc000000/1920

[Available memory (MB)]:  2048

root @uksd3 #

As we can see, there are now two processors available, as a result of removing vPar1. If I were to attempt to use these two processors in an existing partition, the task would fail:



root @uksd3 #

vparmodify -p vPar0 -m cpu::4

vparmodify Error: "-m cpu::4": One or more unbound CPUs was not available when

virtual partition vPar0 was booted. You must shut down the partition to add them.

root @uksd3 #

You might be able to deduce the reason for the error from the error message itself. What's this, a UNIX error message that actually means something? The reason for this is that when a Virtual Partition is booted, it creates an in- core table of all unbound CPUs. When vPar0 was booted, this constituted the two unbound CPUs: one in vPar0 and one in vPar1. Even though I have removed vPar1, the in-core table of unbound CPUs in vPar0 still only lists the two original unbound CPUs.

IMPORTANT

Only the UNBOUND CPUs visible to a partition at boot time can be reassigned. Any BOUND CPUs will not be visible even if the partition they belong to is removed.


{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

While I can allocate one of the available CPUs to vPar0, to be able to allocate the originally bound CPU from vPar1, I would have to reboot vPar0. Worth knowing I think.



root @uksd3 #

vparmodify -p vPar0 -m cpu::3

root @uksd3 #

vparstatus

[Virtual Partition]

                                                                          Boot

Virtual Partition Name         State Attributes Kernel Path               Opts

============================== ===== ========== ========================= =====

vPar0                          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


9    0/  0         2048

root @uksd3 #

vparstatus -A

[Unbound CPUs (path)]:  2.12

[Available CPUs]:  1



[Available I/O devices (path)]:  2.0.4

                                 2.0.6

                                 2.0.8

                                 2.0.9

                                 2.0.14



[Unbound memory (Base  /Range)]:  0x0/128

                (bytes) (MB)      0xc000000/1920

[Available memory (MB)]:  2048

root @uksd3 #