Virtual Partition Example Scenario
| The remainder of this chapter focuses on an example scenario. The purpose of this scenario is to demonstrate the power and flexibility provided by Virtual Partitions. The scenario begins with an overview that outlines the steps that are generally required when deploying vPars. It then describes the environment in which Virtual Partitions will be deployed. Proper planning of the virtual partition configuration greatly eases the implementation; therefore, a few tips and suggestions are provided to facilitate the planning process. Next, the sequence of creating and booting the initial virtual partition is described. After the first virtual partition is running, the second vPar is created and booted from an Ignite-UX server. With two vPars running HP-UX, a shell script is written to illustrate the dynamic capabilities of vPars. Finally, the shell script is added as a scheduled task using the cron tool, which results in the dynamic reconfiguration of the system based on the timing of workload utilization peaks. It should be noted that portions of command output shown throughout this example have been modified for formatting purposes and to provide additional clarity. Example Scenario OverviewThis example scenario consists of the following steps. These steps are covered in detail throughout the example scenario. There are many possible ways to deploy vPars, and the intent of this example is to illustrate just one of them.
The Virtual Partition EnvironmentThe environment for this scenario is an HP nPartition server. An nPartition with one cell, four CPUs, and 2GB of memory will host two vPars. See Table 5-1 for the details of the nPartition.
Within the zoo6 nPartition, two vPars will be created. Each of the vPars will be assigned one bound CPU. Each vPar will also be assigned 1GB of memory, a networking interface, and interfaces for two boot devices. This configuration leaves two unbound CPUs for the purpose of migrating between the vPars as the workloads demand. Figure 5-3 shows the hardware diagram of the zoo6 nPartition. HP nPartition servers have exactly one I/O PCI slot per LBA. When an LBA is assigned to a vPar, the associated PCI slot, card, and all devices under the LBA are assigned to the vPar. Figure 5-3. Superdome nPartition I/O Hardware Diagram
The I/O device hardware paths in HP-UX within HP nPartition servers have the following format: <cell id>/<SBA>/<LBA>/<PCI card specific> The hardware paths for this nPartition start with 6 because the zoo6 nPartition contains a single cell with an ID of 6. There is a single system bus adapter (SBA), SBA 0, which yields a zero (0) in the second field of the hardware paths. Finally, there are 12 LBAs below each SBA. The LBAs are numbered starting at zero, but they are not numbered sequentially because of the double-bandwidth (2X) PCI slots. Therefore, ioscan output should be relied upon to find the hardware paths associated with each LBA for input to the Virtual Partitions commands. The core I/O card in slot 6/0/0 contains the console device for the nPartition and a LAN card. This is the LAN interface that will be used as the primary LAN card for the zoo24 vPar. The SCSI card in slot 6/0/6 will also be assigned to zoo24. The zoo25 vPar will be assigned the slots 6/0/8, 6/0/9, and 6/0/10, with the result that the vPar will own a LAN card and two SCSI cards. In this scenario, there are extra LBAs and I/O cards that not being used and are not assigned to any virtual partition. These LBAs and I/O cards can be utilized in the future by assigning the LBA to the vPar requiring the capabilities. Planning for Virtual PartitionsProper planning for vPars greatly simplifies the implementation process. Before performing any vPar tasks, the state of the server should be captured for future reference. At a minimum, output of the parstatus and ioscan commands should be saved or printed. The output of parstatus, shown in Listing 5-1, provides the details of the nPartition where the vPars will be created. The nPartition's boot paths, CPU count, and memory information have been highlighted. Listing 5-1. Status of nPartition# parstatus -V -p 6 [Partition] Partition Number : 6 Partition Name : zoo6 Status : active IP address : 0.0.0.0 Primary Boot Path : 6/0/6/0/0.2.0 Alternate Boot Path : 0/0/0/0/0.0.0 HA Alternate Boot Path : 0/0/0/0/0.0.0 PDC Revision : 35.3 IODCH Version : 5C70 CPU Speed : 552 MHz Core Cell : cab0,cell6 [Cell] CPU Memory OK/ (GB) Hardware Actual Deconf/ OK/ Location Usage Max Deconf Connected To ========== ============ ======= ========= =================== cab0,cell6 active core 4/0/4 2.0/ 0.0 cab0,bay1,chassis1 [Chassis] Core Connected Par Hardware Location Usage IO To Num =================== ============ ==== ========== === cab0,bay1,chassis1 active yes cab0,cell6 6 Capturing the I/O configuration of the server with ioscan is crucial because booting the vPar monitor results in limited I/O visibility. Only the I/O information for the resources that have been assigned to the local vPar is visible through tools such as ioscan after the vPar monitor is booted. Creating or modifying vPars can be difficult without a snapshot of the server's configuration before booting the vPar monitor. I/O visibility is limited because the vPar monitor applies a filter to restrict the hardware components visible to each vPar to only those which have been assigned. Even though the I/O data being sought is for resources that are not assigned to any vPar, the only detailed I/O information available is for resources assigned to the local Virtual Partition. The vparstatus command has an option to show the available resources, but this option does not provide any I/O details beyond the LBA level. Therefore, ioscan output such as the one shown in Listing 5-2 should be captured for future reference. The most relevant items are highlighted, as they will be referenced in upcoming vPar commands. tip Always capture the output of ioscan before booting the virtual partition monitor. After the vPar monitor is booted, only resources assigned to the local vPar are visible. Listing 5-2. Ioscan of nPartition before Virtual Partition Creation# ioscan -k H/W Path Class Description ======================================================= root 6 cell 6/0 ioa System Bus Adapter (804) 6/0/0 ba Local PCI Bus Adapter (782) 6/0/0/0/0 tty PCI Serial (103c1048) 6/0/0/1/0 lan HP PCI 10/100Base-TX Core 6/0/1 ba Local PCI Bus Adapter (782) 6/0/1/0/0 ext_bus SCSI C87x Ultra Wide Differential 6/0/1/0/0.7 target 6/0/1/0/0.7.0 ctl Initiator 6/0/2 ba Local PCI Bus Adapter (782) 6/0/3 ba Local PCI Bus Adapter (782) 6/0/4 ba Local PCI Bus Adapter (782) 6/0/4/0/0 ext_bus SCSI C87x Ultra Wide Differential 6/0/4/0/0.7 target 6/0/4/0/0.7.0 ctl Initiator 6/0/4/0/1 ext_bus SCSI C87x Ultra Wide Differential 6/0/4/0/1.7 target 6/0/4/0/1.7.0 ctl Initiator 6/0/6 ba Local PCI Bus Adapter (782) 6/0/6/0/0 ext_bus SCSI C896 Ultra2 Wide LVD 6/0/6/0/0.2 target 6/0/6/0/0.2.0 disk HP 18.2GST318404LC 6/0/6/0/0.4 target 6/0/6/0/0.4.0 disk HP 18.2GST318404LC 6/0/6/0/0.6 target 6/0/6/0/0.6.0 disk HP 18.2GST318404LC 6/0/6/0/0.7 target 6/0/6/0/0.7.0 ctl Initiator 6/0/6/0/1 ext_bus SCSI C896 Ultra2 Wide LVD 6/0/6/0/1.7 target 6/0/6/0/1.7.0 ctl Initiator 6/0/8 ba Local PCI Bus Adapter (782) 6/0/8/0/0 ext_bus SCSI C895 Ultra2 Wide LVD 6/0/8/0/0.7 target 6/0/8/0/0.7.0 ctl Initiator 6/0/8/0/0.8 target 6/0/8/0/0.8.0 disk HP 18.2GST318406LC 6/0/9 ba Local PCI Bus Adapter (782) 6/0/9/0/0 ext_bus SCSI C895 Ultra2 Wide LVD 6/0/9/0/0.7 target H/W Path Class Description ======================================================= 6/0/9/0/0.7.0 ctl Initiator 6/0/9/0/0.8 target 6/0/9/0/0.8.0 disk HP 18.2GST318406LC 6/0/10 ba Local PCI Bus Adapter (782) 6/0/10/0/0 lan HP A5230A/B5509BA PCI 10/100Base-TX 6/0/11 ba Local PCI Bus Adapter (782) 6/0/11/0/0 lan HP A5230A/B5509BA PCI 10/100Base-TX 6/0/12 ba Local PCI Bus Adapter (782) 6/0/14 ba Local PCI Bus Adapter (782) 6/5 memory Memory 6/10 processor Processor 6/11 processor Processor 6/12 processor Processor 6/13 processor Processor Installation of Virtual PartitionsInstalling Virtual Partitions is straightforward. The two most common methods used for installing the vPar software are (a) using an Ignite-UX server to install HP-UX and vPars together, and (b) installing and booting HP-UX and then installing the vPar software as a separate step afterward. It is generally recommended that you set up an Ignite-UX server and install HP-UX and the vPar software in a single step because it expedites the process of deploying vPars. See the Ignite-UX & vPars Cookbook referenced in Appendix A for details on setting up an Ignite-UX server for vPar deployment. For this example, the process of installing vPars will not be covered in detail. It is assumed the vPars software has been installed on the zoo6 nPartition. Running the swlist command shows the vPars software is in fact installed on the zoo6 nPartition. # swlist | grep Virtual T1335AC A.03.01.03 HP-UX Virtual Partitions Even though the vPars product is installed, it has not been configured for use. The vPar monitor is not running and no vPars have been created. This is evident by running the vparstatus command. # vparstatus vparstatus: Error: Virtual partition monitor not running. Create the First Virtual PartitionCreating the first vPar is similar to the creation of subsequent vPars with one important difference. Because the vPar Monitor is not yet running, the resources assigned to the vPar are not validated by the vPar commands. It is possible to create the first vPar in such a way that it will not be bootable. For example, too much memory could be assigned to the vPar, or I/O devices that don't exist in the nPartition could be assigned. As a result, it is important to ensure that the paths and resources assigned to the first vPar are manually validated against the resources available in the system as captured during the planning process. The command shown in Listing 5-3 creates the first vPar. note The LBA with the hardware console must be assigned to the first vPar created. Listing 5-3. Create Virtual Partition Command# /usr/sbin/vparcreate -p zoo24 \ > -a cpu::1 \ > -a cpu:::1:3 \ > -a mem::1024 \ > -a io:6/0/0 \ > -a io:6/0/6/0/0.2.0:boot \ > -a io:6/0/6/0/0.4.0:altboot The following list describes each argument and its purpose in the command:
The final two options are of particular importance because beyond specifying the primary and alternate boot devices, the options also implicitly assign the LBA 6/0/6 to the vPar. Just as assigning 6/0/0 adds everything under that path, the implicit assignment of 6/0/6 results in no other vPar having access to devices under the 6/0/6 LBA. The addition of the option a io:6/0/6 would have explicitly assigned the LBA to the vPar, but it would not have changed the behavior of the vPars; the only effect would have been the output shown by vparstatus. LBAs implicitly assigned to vPars are not shown by vparstatus; only explicitly assigned LBAs are shown. The command shown in Listing 5-3 creates the first vPar using the default vPar database file located at /stand/vpdb. If the default vPar database doesn't exist it will be automatically created. In this example, zoo24 was the first vPar to be created and the file didn't exist, so the vparcreate command created the file and defined the zoo24 partition. The zoo24 vPar has now been created, but it is not yet active. Listing 5-4 shows the output of the vparstatus command after creating the first vPar. The initial warning makes it clear the vPar monitor is still not running. The zoo24 vPar exists in the database and has a minimum of one CPU and a maximum of three. Additionally, the LBA 6/0/0 is assigned to the vPar and the two boot devices are also specified. Notice the 6/0/6 LBA is not explicitly mentioned in the vparstatus output, but in fact it is assigned to the vPar. Listing 5-4. Detailed Virtual Partition Status # vparstatus -v -p zoo24 vparstatus: Warning: Virtual partition monitor not running, Requested resources shown. [Virtual Partition Details] Name: zoo24 State: N/A Attributes: Dynamic,Autoboot Kernel Path: /stand/vmunix Boot Opts: [CPU Details] Min/Max: 1/3 Bound by User [Path]: Bound by Monitor [Path]: <no path> Unbound [Path]: [IO Details] 6.0.0 6.0.6.0.0.2.0.0.0.0.0 BOOT 6.0.6.0.0.4.0.0.0.0.0, ALTBOOT [Memory Details] Specified [Base /Range]: (bytes) (MB) Total Memory (MB): 1024 Virtual Partition StatesBefore diving into the process of booting the vPar monitor and the first vPar, a discussion of the vPar states is in order. The states of a vPar are shown in Figure 5-4. These states are helpful in interpreting the output of the vparstatus command and managing vPars. Listing 5-4 shows the zoo24 vPar is in the N/A state. In this case, the vPar monitor has not been booted, so the vPar can't be in any other state. The following list describes all of the vPar states and an explanation of when a vPar can be in each state.
Figure 5-4. Virtual Partition States
Booting the First Virtual PartitionIn order to boot a vPar to the up state, the next step is booting the vPar monitor. This is accomplished by booting the vPar monitor by interacting with the firmware interfaces to specify the path of the vPar monitor. Listing 5-5 shows an example of interacting with the Initial System Loader (ISL) to boot the vPar monitor at /stand/vpmon instead of the default HP-UX kernel. Listing 5-5. Virtual Partition Monitor Boot Process---- Main Menu ------------------------------------------------- Command Description ------- ----------- BOot [PRI|HAA|ALT|<path>] Boot from specified path PAth [PRI|HAA|ALT] [<path>] Display or modify a path SEArch [ALL|<cell>|<path>] Search for boot devices ScRoll [ON|OFF] Display or change scroll capability COnfiguration menu Displays or sets boot INformation menu Displays hardware info SERvice menu Displays service commands DIsplay Redisplay the current menu HElp [<menu>|<command>] Display help for menu REBOOT Restart Partition RECONFIGRESET Reset to allow Reconfig ---- Main Menu: Enter command or menu > bo Primary Boot Path: 6/0/6/0/0.2 Do you wish to stop at the ISL prompt? (y/n) >> y Initializing boot Device. Boot IO Dependent Code (IODC) Revision 0 Boot Path Initialized. HARD Booted. ISL Revision A.00.43 Apr 12, 2000 ISL> hpux /stand/vpmon Boot : disk(6/0/6/0/0.2.0.0.0.0.0;0)/stand/vpmon 679936 + 190216 + 17306888 start 0x23000 Welcome to VPMON (type '?' for a list of commands) MON> When the vPar monitor is loaded without arguments as shown in Listing 5-5, it will not automatically boot any of the vPars. Instead the monitor stops at the vPar monitor prompt, MON>. From this prompt, several vPar specific commands are available. The most commonly used commands are vparload and reboot. The vparload command can be used in several ways. To boot all of the vPars that have their auto attribute set (the default setting) simply specify the vparload auto command. All vPars can be booted, regardless of their auto attribute by using the vparload all option. Finally, specific vPars can be booted using the vparload p <partition> option. This is the option used in Listing 5-6 to boot the zoo24 vPar. The output from the HP-UX boot process has been suppressed from the listing. Listing 5-6. Loading First Virtual PartitionMON> vparload Usage: vparload -auto | -all vparload -p <partition> [-o <boot opts>] [-b <kern path>] [-B <boot device>] MON> vparload -p zoo24 [MON] Booting zoo24... [MON] Console client set to zoo24 [MON] Console server set to zoo24 [zoo24] [MON] zoo24 loaded <normal HP-UX boot follows> With the HP-UX boot process completes, the first vPar has been successfully booted and in the up state. The output of the vparstatus command executed from the HP-UX within the first vPar is shown in Listing 5-7. The vPar zoo24 is assigned one bound CPU, the minimum number of CPUs is one, and the maximum number of CPUs is three. The vPar has 1024MB of memory. Listing 5-7. Virtual Partition Status # vparstatus -v -p zoo24 [Virtual Partition Details] Name: zoo24 State: Up Attributes: Dynamic,Autoboot Kernel Path: /stand/vmunix Boot Opts: [CPU Details] Min/Max: 1/3 Bound by User [Path]: Bound by Monitor [Path]: 6.10 Unbound [Path]: [IO Details] 6.0.0 6.0.6.0.0.2.0.0.0.0.0 BOOT 6.0.6.0.0.4.0.0.0.0.0, ALTBOOT [Memory Details] Specified [Base /Range]: (bytes) (MB) Total Memory (MB): 1024 Before creating the second vPar, closely examine Listing 5-8. Notice that the ioscan output shows only the I/O devices under LBAs 6/0/0 and 6/0/6. There are 12 LBAs in the zoo6 nPartition, so the remaining 10 LBAs are hidden from view by the vPar monitor. This illustrates the importance of capturing the ioscan output during the planning phase so it can be referred to during the creation of subsequent vPars. Listing 5-8. Ioscan after Booting Virtual Partition # ioscan -k H/W Path Class Description ======================================================= root 6 cell 6/0 ioa System Bus Adapter (804) 6/0/0 ba Local PCI Bus Adapter (782) 6/0/0/0/0 tty PCI Serial (103c1048) 6/0/0/1/0 lan HP PCI 10/100Base-TX Core 6/0/6 ba Local PCI Bus Adapter (782) 6/0/6/0/0 ext_bus SCSI C896 Ultra2 Wide LVD 6/0/6/0/0.2 target 6/0/6/0/0.2.0 disk HP 18.2GST318404LC 6/0/6/0/0.4 target 6/0/6/0/0.4.0 disk HP 18.2GST318404LC H/W Path Class Description ======================================================= 6/0/6/0/0.6 target 6/0/6/0/0.6.0 disk HP 18.2GST318404LC 6/0/6/0/0.7 target 6/0/6/0/0.7.0 ctl Initiator 6/0/6/0/1 ext_bus SCSI C896 Ultra2 Wide LVD 6/0/6/0/1.7 target 6/0/6/0/1.7.0 ctl Initiator 6/5 memory Memory 6/10 processor Processor 6/11 processor Processor 6/12 processor Processor 6/13 processor Processor 64 tty Virtual Console Client 65 tty Virtual Console Server Creating the Second Virtual PartitionAfter booting the first virtual partition, the second will be created. Most of the options for creating the vPar are similar to those specified when creating the first vPar. Of particular interest, though, is the fact that the boot and alternate boot devices are no longer under the same LBA. This provides an additional level of availability, as the failure of the PCI device under LBA 6/0/8 will not make the vPar unbootable. Instead, the PCI device under the LBA 6/0/9 can be used as an alternate boot device. This configuration assigns 6/0/8, 6/0/9, and 6/0/10 to the zoo25 vPar. The first two LBAs are implicitly assigned and the last one is explicitly assigned. Listing 5-9. Create Second Virtual Partition Command# vparcreate -p zoo25 \ > -a cpu::1 \ > -a cpu:::1:3 \ > -a mem::1024 \ > -a io:6/0/8/0/0.8.0:boot \ > -a io:6/0/9/0/0.8.0:altboot \ > -a io:6/0/10 At this point, both vPars have been created. The vparstatus output shown in Listing 5-10 shows both vPars exist but the zoo25 vPar has not been booted; it is in the down state. If the boot disk specified in the vparcreate command for zoo25 already contains the HP-UX operating system and the vPar software, then the vPar may be booted from its primary boot disk using the vparboot command. In this case, the boot disk does not contain an operating system so it must be installed using Ignite-UX. Listing 5-10. Status of Virtual Partitions # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================== ===== ========== ============= zoo24 Up Dyn,Auto /stand/vmunix zoo25 Down Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num CPU Bound/ IO Virtual Partition Name Min/Max Unbound devs Total MB ============================== ================ ==== ======== zoo24 1/ 3 1 0 4 1024 zoo25 1/ 3 1 0 5 1024 Booting the Second Virtual PartitionThe zoo25 vPar can now be booted from an Ignite-UX server with the hostname of seminole. In this example, there is only one remaining vPar to be installed with Ignite-UX. In situations where multiple vPars have been created and require an operating system to be installed, the process of installing operating systems can be streamlined by using the approach shown in Listing 5-11. Each vPar that requires installation of an operating system can be booted in parallel from an Ignite-UX server. tip Multiple operating systems may be installed in parallel after booting the first vPar. The vparboot command with the I option can be used for each vPar requiring an operating system to be installed. This results in provisioning the operating systems for each vPar in parallel. The output shown in Listing 5-11 illustrates the process of booting the newly created zoo25 vPar from an Ignite-UX server. Notice the <ctrl-a> in the listing after the vPar is loaded. The <ctrl-a> command was manually issued at the console to toggle between the vPar consoles. In this case, the vparboot command was issued from the zoo24 operating system on the physical console assigned to zoo24. The consoles for all the vPars in a server are accessible from the physical console. From the physical console, each of the individual vPar consoles can be accessed using the <ctrl-a> keys. This command cycles through the consoles for all of the vPars in the server. The output shown at the end of the listing is that of the standard Ignite-UX interface. The operating system for zoo25 is configured and installed just as any operating system would be in a non-vPar environment, assuming the Ignite-UX depot contains the vPar software. warning Booting vPars from an Ignite-UX server provides a streamlined installation process. However, the Ignite-UX depots must be properly configured with the vPar software and its dependencies in order for the operating system to boot in a vPar environment. Listing 5-11. Booting of Second Virtual Partition# vparboot -p zoo25 -I seminole,WINSTALL vparboot: Booting zoo25. Please wait... # [MON] zoo25 loaded <ctrl-a> [zoo25] . . . Welcome to Ignite-UX! Use the <tab> key to navigate between fields, and the arrow Keys within fields. Use the <return/enter> key to select an item. Use the <return> or <space-bar> to pop-up a choices list. If the menus are not clear, select the "Help" item for more information. Hardware Summary: System Model: 9000/800/SD64000 +---------------------+----------------+-------------------+ | Disks: 2 ( 33.9GB) | Floppies: 0 | LAN cards: 1 | | CD/DVDs: 0 | Tapes: 0 | Memory: 942Mb | | Graphics Ports: 0 | IO Buses: 2 | CPUs: 3 | +---------------------+----------------+-------------------+ [ Install HP-UX ] [ Run a Recovery Shell ] [ Advanced Options ] [ Reboot ] [ Help ] Listing 5-12 shows the status of the vPars after the installation of the HP-UX operating system is complete and the vPar has been booted. Notice both zoo24 and zoo25 are in the up state. Listing 5-12. Status of Final Virtual Partition Configuration # vparstatus [Virtual Partition] Boot Virtual Partition Name State Attributes Kernel Path Opts ============================== ===== ========== ============= zoo24 Up Dyn,Auto /stand/vmunix zoo25 Up Dyn,Auto /stand/vmunix [Virtual Partition Resource Summary] CPU Num CPU Bound/ IO Virtual Partition Name Min/Max Unbound devs Total MB ============================== ================ ==== ======== zoo24 1/ 3 1 0 4 1024 zoo25 1/ 3 1 0 5 1024 # Configuring an nPartition and Virtual Partitions for Auto-BootingThe two vPars are now configured and running properly. However, the boot sequence for the vPar monitor and the two vPars requires manual interaction. This may not be obvious because the vparstatus output shown in Listing 5-12 indicates that both of the vPars have the auto attribute set. However, additional configuration steps are necessary for two reasons. First, each vPar's auto attribute is used by the vPar monitor, not the firmware of the server where vPars are running. Therefore, firmware must be set to automatically boot independent of the vPars' attributes. Secondly, the vPar monitor must be invoked in such a manner as to automatically boot all vPars whose auto attribute set. If you don't configure these settings, the vPars will require manual interaction during booting. The vPar architecture allows the monitor to be booted from the boot disk of any of the vPars. No one vPar is the "master" vPar. Even if the disk that is used as the primary boot device for the monitor experiences a hardware failure, the worst-case scenario is the loss of a single vPar. The vPar monitor can be booted from another vPar's boot disk and the configuration will be the same as if it was booted from the original. The following steps are required for an nPartition and the contained vPars to be booted automatically.
note In a vPar environment, the setboot command does not affect the boot paths used by firmware to boot the vPar monitor. Instead, the setboot command only affects the boot paths for the local vPar. Listing 5-13 shows the nPartition status for zoo6. Notice that the primary, alternate, and HA alternate boot paths are set to the same boot devices configured for the zoo24 and zoo25 vPars. The parmodify command can be used to set the boot paths when they have not already been set using the nPartition commands or the firmware interfaces for the nPartition. Listing 5-13. nPartition Status with Boot Paths# parstatus -V -p 6 [Partition] Partition Number : 6 Partition Name : zoo6 Status : active IP address : 0.0.0.0 Primary Boot Path : 6/0/6/0/0.2.0 Alternate Boot Path : 6/0/8/0/0.8.0 HA Alternate Boot Path : 6/0/9/0/0.8.0 PDC Revision : 35.3 IODCH Version : 5C70 CPU Speed : 552 MHz Core Cell : cab0,cell6 [Cell] CPU Memory OK/ (GB) Hardware Actual Deconf/ OK/ Location Usage Max Deconf Connected To ========== ============ ======= ========= =================== cab0,cell6 active core 4/0/4 2.0/ 0.0 cab0,bay1,chassis1 [Chassis] Core Connected Par Hardware Location Usage IO To Num =================== ============ ==== ========== === cab0,bay1,chassis1 active yes cab0,cell6 6 After setting the boot paths used by firmware, each of the boot disks must be configured to load the vPar monitor. Notice that in Listing 5-14, the primary boot device for zoo24 is shown in the ioscan output. The raw disk device is used as an argument to the mkboot command. The mkboot command shown at the end of the listing modifies the AUTO file on the specified disk. The AUTO file is used when booting and in this case boot the vPar monitor. Also note that the a argument is passed to the vPar monitor. This argument causes the vPar monitor to boot all of the vPars whose auto attribute is set. The mkboot command must be executed on the vPar that owns the respective boot devices. In this example, only the nPartition's primary boot device for the zoo6 nPartition is owned by the vPar zoo24. Listing 5-14. Set Primary Boot Disk to Auto Boot vPar Monitor (from zoo24)# ioscan -funC disk Class I H/W Path Driver S/W State H/W Type ============================================================= disk 0 6/0/6/0/0.2.0 sdisk CLAIMED DEVICE /dev/dsk/c3t2d0 /dev/rdsk/c3t2d0 disk 1 6/0/6/0/0.4.0 sdisk CLAIMED DEVICE /dev/dsk/c3t4d0 /dev/rdsk/c3t4d0 disk 2 6/0/6/0/0.6.0 sdisk CLAIMED DEVICE /dev/dsk/c3t6d0 /dev/rdsk/c3t6d0 # mkboot -a "hpux /stand/vpmon -a" /dev/rdsk/c3t2d0 To achieve the highest level of availability, the nPartition's alternate and HA alternate devices must also have their AUTO file set to automatically boot the vPar monitor. Since the zoo25 vPar owns both of the zoo6 nPartition's alternate and HA alternate boot devices, the mkboot command is executed for both of those devices from the same vPar. The mkboot commands are identical except for the path of the target device, and the firmware boots the monitor in the same fashion regardless of the physical boot device. Listing 5-15. Set Alternate Boot Disks to Auto Boot vPar Monitor (from zoo25)# ioscan -funC disk Class I H/W Path Driver S/W State H/W Type ============================================================= disk 3 6/0/8/0/0.8.0 sdisk CLAIMED DEVICE /dev/dsk/c5t8d0 /dev/rdsk/c5t8d0 disk 4 6/0/9/0/0.8.0 sdisk CLAIMED DEVICE /dev/dsk/c6t8d0 /dev/rdsk/c6t8d0 # mkboot -a "hpux /stand/vpmon -a" /dev/rdsk/c5t8d0 # mkboot -a "hpux /stand/vpmon -a" /dev/rdsk/c6t8d0 The nPartition's primary, alternate, and HA alternate boot devices have been properly configured to boot the vPar monitor and all of the vPars. The final step is configuring firmware to automatically boot from these boot paths. Listing 5-16 shows the boot console handler (BCH) firmware commands for setting the boot order and actions. This sequence of commands tells the firmware to attempt to boot from the nPartition's primary, HA alternate, and alternate boot paths, in that order. The value at the end of each of the commands specifies the action to take if booting from a given path is unsuccessful. The value 2 specifies that the firmware should continue on to the next path when booting fails. The value 1 specifies that firmware should return to BCH upon failure to boot. In this case, firmware is configured to attempt booting from all three booth paths and return to BCH only if all three are unsuccessful. Listing 5-16. Set Firmware Path Flags to Automatically BootConfiguration Menu: Enter command > pf PRI 2 Primary Boot Path Action Boot Actions: Boot from this path. If unsuccessful, go to next path. Configuration Menu: Enter command > pf HAA 2 HA Alternate Boot Path Action Boot Actions: Boot from this path. If unsuccessful, go to next path. Configuration Menu: Enter command > pf ALT 1 Alternate Boot Path Action Boot Actions: Boot from this path. If unsuccessful, go to BCH. Configuration Menu: Enter command > All of the steps necessary for automatically booting the nPartition and the contained vPars have been completed. The nPartition zoo6 will automatically boot the vPar monitor and pass the vPar monitor the appropriate flag to indicate that it should automatically boot all vPars. Listing 5-17 shows the fully automatic boot process. Listing 5-17. Example Automatic Booting of Virtual Partition Monitor and Virtual PartitionsFirmware Version 35.3 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 ---- ---- ------------ --- -------- ----------- ------ ------ 6 0/6 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 Primary Boot Path: 6/0/6/0/0.2 Boot Actions: Boot from this path. If unsuccessful, go to next path. HA Alternate Boot Path: 6/0/9/0/0.8 Boot Actions: Boot from this path. If unsuccessful, go to next path. Alternate Boot Path: 6/0/8/0/0.8 Boot Actions: Boot from this path. If unsuccessful, go to BCH. Console Path: 6/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 SL booting hpux /stand/vpmon -a Boot : disk(6/0/6/0/0.2.0.0.0.0.0;0)/stand/vpmon 679936 + 190216 + 17306888 start 0x23000 [MON] Booting zoo25... [MON] Booting zoo24... [MON] Console client set to zoo25 [MON] zoo25 loaded [MON] Console server set to zoo24 [zoo25] [MON] zoo24 loaded Using a Script to Migrate CPUsHaving booted the vPars and with them up and running, the example could stop here. Each of the vPars is running as an independent operating system with full operating system isolation. However, there are two unused CPUs in the nPartition. Furthermore, the nature of the workloads in zoo24 and zoo25 allows the CPUs to be migrated between the two vPars, which would mean better performance for each of the workloads during their peak utilization times. The CPUs could be migrated manually on demand, but a preferred method would be an automated process for moving CPUs when they are needed. The script shown in Listing 5-18 automates the process of migrating a specified number of CPUs from one vPar to another. The script starts by parsing the command-line arguments and ensuring that all required arguments are given. The final steps remove the specified number of CPUs from the source vPar and add the CPUs to the destination vPar. While this script illustrates the flexibility of vPars and the power provided by having the ability to dynamically move CPUs based on workload demand, it isn't suited for production use. Most important, it does no error-checking to ensure that the commands will succeed. Instead, it just tries to perform the operation and if it doesn't work, it returns the error. In addition, before this script is initially executed, the two unassigned CPUs must be assigned to one of the vPars. Listing 5-18. Script for Migrating CPUs#!/usr/bin/sh # *************************************************************** # Migrate CPUs # --------------------------------------------------------------- # # Usage: # migrate_cpus -s <source vpar> -d <dest vpar> -c <count> # # Description: # # This script will move <count> CPUs from <source vpar> to # <dest vpar>. # # This script is for illustration purposes only. # # *************************************************************** # # Initialize variables # SOURCE="" DEST="" COUNT="" USAGE="migrate_cpus -s <source vpar> -d <dest vpar> -c <count>" # # Parse the command line arguments, see getopt(1) for usage details. # set -- $(getopt c:d:s: $*) if [ $? -ne 0 ]; then print -u2 "$USAGE" exit 1 fi while [ $# -gt 0 ]; do case "$1" in '-c') COUNT=$2 shift 2 ;; '-d') DEST=$2 shift 2 ;; '-s') SOURCE=$2 shift 2 ;; --) break # this is the end of parameters ;; esac done # # Ensure all of the required parameters were specified # if [ -z "$SOURCE" -o -z "$DEST" -o -z "$COUNT" ]; then print -u2 "ERROR: Missing required argument(s)" print -u2 "$USAGE" exit 1 fi vparmodify -p $SOURCE -d cpu::$COUNT || exit $? sleep 10 vparmodify -p $DEST -a cpu::$COUNT exit $? The sleep command between the two vparmodify commands is required because the removal of CPUs from a vPar is asynchronous. The vparmodify command that removes the CPUs will return immediately. However, the CPUs will be delayed for an indeterminate amount of time before they are actually removed from the vPar and become available for assignment to another vPar. This is a result of pending threads and processes being serviced by the CPUs. A 10-second sleep is sufficient for most cases, but in fact a busy system could delay the removal of CPUs even longer. This script could be enhanced to poll the vparstatus command to check for the availability of the removed CPU. Using Cron to Automatically Migrate CPUsThe migrate_cpus script doesn't provide much value alone. For manual CPU migration, simply invoking the two vparmodify commands in succession isn't difficult. The value of a script such as migrate_cpus is realized when it is integrated with a task scheduler such as cron. In this case, two cron entries results in a simple but dynamic computing environment. The migrate_cpus command could be added as a set of cron entries such as: # crontab -l 00 22 * * * /usr/local/bin/migrate_cpus -s zoo24 -d zoo25 -c 2 00 06 * * * /usr/local/bin/migrate_cpus -s zoo25 -d zoo24 -c 2 The combination of the migrate_cpus script and the cron entries illustrates the power and flexibility provided by vPars. However, there are several technical issues with this solution. The migrate_cpus script has no concept of what the initial and final states should be. As a result, it is unable to ensure that the configuration is correct at the end of the script. For example, assume that the 10-second delay is not adequate for the removed CPUs to become available. In this situation, assigning the CPUs to the destination vPar would fail. Assuming no user intervention, the next time the script was executed, the first vparmodify command that removes the CPUs from the source vPar would fail. This effectively would result in no CPUs being migrated until an administrator manually intervened and corrected the situation. The HP Virtual Server Environment has a robust solution for this problem. Both Chapter 15, "Workload Manager," and Chapter 19, "Global Workload Manager," describe how to provide tight integration with vPars to enable much more powerful and flexible vPar workload management than shown with the migrate_cpus script and cron jobs. Shutting Down Virtual PartitionsVirtual partitions are shut down and rebooted independent of one another using the traditional HP-UX reboot and shutdown commands. The only recommended modification to the shutdown process is to run the vparstatus command immediately before shutting down the operating system. This forces the vPar monitor's in-memory copy of the database to be synchronized with the file on the vPar's file system. This ensures that the copy of the database on the vPar's file system reflects the most recent configuration changes that may have been made. In a dynamic environment where CPUs are being migrated from one vPar to another on a regular basis, this is especially important. When vPars are running within nPartitions, there is a special situation that should be understood. If a change is made to an active nPartition containing vPars that results in a pending SCCD such as removing a cell from an nPartition, then all of the vPars must be shut down before the change can take effect. When a pending SCCD is present and a vPar is rebooted, the vPar will not be restarted until all of the vPars are shutdown and the nPartition becomes inactive. This is true regardless of the auto attribute for the vPar. Therefore, it is recommended that changes to an nPartition containing vPars that require the nPar to be shut down for reconfiguration be performed when all of the vPars are in the down state and the cells are inactive. |
EAN: 2147483647
Pages: 197