Virtual Partition Boot Process Overview
| Booting partitions is similar to booting without partitions. The primary difference is the Virtual Partition Monitor - what I'll call vpmon in this chapter. vpmon is loaded at the time of boot and is located in /stand/vpmon . The vpmon sits between the firmware and operating system on your HP system. Figure 1-10 depicts the position of the vpmon relative to other HP system components . Figure 1-10. Virtual Partitions Software Stack Notice in the figure that different versions and patch levels of HP-UX 11i may be running in vPars. On Itanium Processor Family (IPF) systems, operating systems other than HP-UX may be running in vPars. This functionality was not available at the time of this writing, so only HP-UX 11i-based vPars are covered in this book. In the process of creating vPars, a partition database is produced that tracks the resources associated with vPars. The vpmon manages these resources, loads kernels , and performs other functions that make it look as though each virtual partition is its own system. Rather than booting a kernel directly from the ISL (see the non-vPars-specific portion of this chapter for detailed information on all aspects of booting, including ISL), you boot the vpmon . The vpmon then loads the partition database /stand/vpdb and creates the vPars based on the resources allocated to the vPars in the database. vpdb is the default database, which contains partition- related information. A copy of vpdb is kept on the disk for every partition and is automatically kept synchronized. When a change is made to any partition, the master vpdb is updated and then the local copies on other vPars are automatically updated. This synchronization occurs every few seconds and ensures that vpdb on all running partitions remains synchronized. If a partition is not running its vpdb cannot be updated. Without vPars you would boot the HP-UX kernel directly from ISL, as shown below:
You can boot the vpmon from ISL with the command below: ISL> hpux /stand/vpmon The vpmon is invoked with this command and the vpmon prompt appears from which you can load vPars. From the vpmon prompt we could issue the vparload command to load one or more Virtual Partitions. There are many options to the vparload command. There is no man page for vparload in Appendix B because it is a vpmon command. vparboot is a shell command so there is a man page in Appendix B for it. The following are the three forms of vparboot at the time of this writing: form1: vparload -all form2: vparload -auto form3: vparload -p vp_name [-b kernelpath] [-o boot_options] [-B hardware_path] form1 boots all vPars. form2 boots all vPars that have the autoboot attribute set. form3 allows you to specify options such as: the kernelpath to boot; the boot_options, such as "is" for single user mode; or hardware_path, which specifies the boot device to be used for the vPar. Issuing the /stand/vpmon command at the ISL> prompt gives us the MON> prompt. To use vparload to boot all Virtual Partitions on a server we would issue the following command: MON> vparload -all To use vparload to boot the Virtual Partition symbol1, we would issue the following command: MON> vparload -p symbol1 You could perform the steps to load both the vpmon and virtual partition symbol1 from ISL with the command below at the ISL prompt:
This command boots both vpmon and then symbol1 . You may perform experimentation with the kernels of the vPars on your system and have to boot different kernels. The following example shows booting from a kernel called vmunix_test1 : MON> vparload -p symbol1 -b /stand/vmunix_test1 As a side note, the kernel path above is loaded with this vparload , but no permanent changes were made. To make a permanent change to the vPars database you would issue the following command: # vparmodify -p symbol1 -b "stand/vmunix_test1" The vPar database has now been modified to have a default kernel of /stand/vmunix_test1 . You can boot a vPar in single-user mode with the following command: MON> vparload -p symbol1 -o "is" There are a variety of other options that you can use for booting vPars. As you can see from this discussion, the options are similar to options you would use on a non-vPars system. There are a variety of other commands that you can issue from MON> . The following shows some of the more common commands:
Many of these commands at MON> are informative. Let's now move on to vPars states. Virtual Partition Boot StatesWhen we boot a Virtual Partition, it progresses through load , then boot , and finally, up . There are other states in which you may find a Virtual Partition as well. Table 1-5 summarizes the states of Virtual Partitions at the time of this writing: Table 1-5. Virtual Partitions States
These states are used later when we create and boot Virtual Partitions and watch them boot by issuing successive vparstatus commands. The following example shows the process of the Virtual Partition cable2 booting: # vparboot -p cable2 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================== ===== ========== ========================= ===== cable1 Up Dyn,Manl /stand/vmunix cable2 Load Dyn,Manl /stand/vmunix [Virtual Partition Resource CPU Num Memory (MB) Summary] CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== cable1 2/ 4 2 0 4 0/ 0 2048 cable2 2/ 2 2 0 4 0/ 0 1024 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================== ===== ========== ========================= ===== cable1 Up Dyn,Manl /stand/vmunix cable2 Boot Dyn,Manl /stand/vmunix [Virtual Partition Resource CPU Num Memory (MB) Summary] CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== cable1 2/ 4 2 0 4 0/ 0 2048 cable2 2/ 2 2 0 4 0/ 0 1024 # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================== ===== ========== ========================= ===== cable1 Up Dyn,Manl /stand/vmunix cable2 Up Dyn,Manl /stand/vmunix [Virtual Partition Resource CPU Num Memory (MB) Summary] CPU Bound/ IO # Ranges/ Virtual Partition Name Min/Max Unbound devs Total MB Total MB ============================== ================ ==== ==================== cable1 2/ 4 2 0 4 0/ 0 2048 cable2 2/ 2 2 0 4 0/ 0 1024 # This example shows cable2 progressing through the load , then boot , and finally, up . cable2 was booted from cable1 running on the same hardware. The system had already gone through the boot process when cable1 booted. The boot time for cable2 is very quick since most of the hardware is already running. The boot time for the first Virtual Partition is comparable to the boot time of a non-Virtual Partition system, but the subsequent vPars boot much more quickly. setboot Command and vParsThe setboot command on a non-vPars system reads from and writes to stable storage. On a vPars system the setboot command interacts with the Virtual Partition database. Running setboot on a vPars system has the effects shown in Table 1-6: Table 1-6. setboot and Virtual Partitions
The setboot command is one of the aspects of working with vPars that is different from a non-vPars system.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ISL> 
25 18:2 1:12 PDT 2001 $ INFO:CPU0:MON:Partition uhnjlvp1 monarch set to 37 INFO:CPU0:MON:Partition uhnjlvp2 monarch set to 45 
EAN: 2147483647
Pages: 301