Architectural Considerations when Mixing Virtual Partition and Operating System Versions Customer Viewable

A white paper from HP written by Alan Hymes

1 2 3 4

Audience..................................................................................................................................... 2 HP-UX Virtual Partitions Overview................................................................................................... 2 Virtual Partition Monitor and Database Relationship ......................................................................... 2 Operating System to vPar relationship ............................................................................................ 3 4.1 vPars A.01.xx, A.02.xx, and A.03.xx on HP-UX 11iV1 ............................................................. 3 4.2 vPars A.04.xx on HP-UX 11iV2............................................................................................... 3 Virtual Partition Architecture and Firmware ...................................................................................... 3 Upgrading vPars and/or the HP-UX OS .......................................................................................... 4 6.1 Initial Virtual Partition Deployment ........................................................................................... 4 6.2 Upgrading Operating System and/or Virtual Partition Versions .................................................. 5 6.2.1 Upgrading vPars Only ..................................................................................................... 5 6.2.2 Upgrading the OS only .................................................................................................... 5 6.2.3 Upgrading both vPars and OS .......................................................................................... 5 Customer Impact .......................................................................................................................... 5 7.1 Solution Design (potential) Issues............................................................................................. 5 7.1.1 Summary ........................................................................................................................ 6 7.2 Proposed Solution Design....................................................................................................... 7 7.2.1 Summary ........................................................................................................................ 7 For More Information .................................................................................................................... 9

5 6

Figure 1 Monitor to Database Relationship ..................................................................................3 Figure 2 vPar PA Architecture ....................................................................................................4 Figure 3 vPar IA Architecture .....................................................................................................4 Figure 4 Typical Customer Design ..............................................................................................6 Figure 5 Proposed Customer Design ...........................................................................................7

1 Audience
This white paper is intended for individuals who are interested in using HP-UX virtual partitions (vPars) to consolidate multiple systems onto a single system or hard partition. This document explains the issues around the mixing of different vPar versions and HP-UX Operating System versions in a vPars environment. This paper assumes that the reader has a good knowledge of the HP-UX operating system and is familiar with the concepts of vPars.

2 HP-UX Virtual Partitions Overview

Virtual Partitions allows the system administrator to create independent HP-UX operating environments from hardware resources in a system or hard partition. Each of the HP-UX operating environments can be tuned specifically for the applications that will be hosted. A vPar is composed of one or more CPUs, memory, and I/O devices for mass storage and networking. The minimum amount of memory necessary to boot a vPar is based on the minimum required by the operating system version (HP-UX 11i v1 requires 128 MB minimum but 256 MB is recommended and HP-UX 11i v2 requires a minimum of 1 GB). All the resources of each vPar are specified in a partition plan (vPars database) that resides on the boot disk of each vPar. The vPar commands vparcreate and vparmodify are used to create, add, delete, and modify resources in the partition plan. Each vPar should be configured with enough memory and I/O to sustain the peak workload that will be placed on it. The vPar Monitor manages the assignment of hardware resources to virtual partitions based on the vPar database, boots virtual partitions and their kernels, and emulates certain firmware calls. By emulating these specific calls, vPars creates the illusion to each HP-UX instance that it is running on a standalone server, consisting of the hardware that has been assigned to it. Once a virtual partition is launched, the Monitor transfers ownership of the hardware to the virtual partition. At that point the Monitor is not involved in accessing IO hardware, physical memory, or process to processor cycles: the individual HP-UX instances have complete ownership of their respective hardware resources. This allows each partition to run at full speed.

Virtual Partition Monitor and Database Relationship

For each system in the case of supported legacy non-cell based systems and each hard partition in the case of supported cell based systems, there is only one copy of the vPar monitor running and one copy of the vPar database loaded into memory. Further, each vPar boot disk contains a copy of the monitor and database such that at initial load time, the monitor may be loaded from any of the vPar boot disks (usually the primary partition boot disk). The database which also resides on every vPar boot disk is then read by the monitor and loaded into memory. Once one or more vPars are running, the vpard daemon synchronizes every live disk copy of the database with the one residing in memory. Figure 1 shows the relationship of the Monitor and Database.

2 of 9

Figure 1 Monitor to Database Relationship

4 Operating System to vPar relationship

As already explained, each system (on supported non-cell based) and each nPar (on supported cell based) has only one vPar Monitor running which manages all of the vPars in that partition. And as explained, each vPar has its own isolated Operating System. Due to the architecture of vPars and specific operating system functionality, there is a supported vPar version to OS version relationship that must be followed. This is primarily identified by the vPar Monitor since it is what is managing the whole vPar environment in a given hard partition.

4.1 vPars A.01.xx, A.02.xx, and A.03.xx on HP-UX 11iV1

Virtual partition release streams A.01, A.02, and A.03 have been architected to work with HP-UX 11iV1 (11.11). The supported release of vPars to HP-UX 11iV1 release is listed in the Virtual Partition Ordering and Configuration Guide but aside from particular minor OS releases, the above vPar releases are only supported on HP-UX 11iV1. Virtual partition release streams A.01, A.02, and A.03 will not run on 11iV2 (11.23).

4.2 vPars A.04.xx on HP-UX 11iV2

Virtual partition release stream A.04 has been architected to work with HP-UX 11iV2. The supported release of vPars to HP-UX 11iV2 release is listed in the Virtual Partition Ordering and Configuration Guide but aside from particular minor OS releases, the above vPar release is only supported on HPUX 11iV2. Virtual partition release stream A.04 will not run on HP-UX 11iV1.

5 Virtual Partition Architecture and Firmware

In addition to the vPar version and the OS version, the system firmware must be considered. Figure 2 and Figure 3 below are high level architectural views of both the PA-RISC (PA) and Itanium (IA) vPar environments. The key is that since the vPar monitor sits on top of the system firmware in both architectures, the system firmware revision must match the hardware, vPar version, and OS version.

3 of 9

Figure 2 vPar PA Architecture

Figure 3 vPar IA Architecture The supported firmware versions are listed in the vPar Ordering and Configuring guide.

6 Upgrading vPars and/or the HP-UX OS

6.1 Initial Virtual Partition Deployment
In order to successfully deploy vPars, the system/complex must be supported, the system firmware must be supported, and then the vPar version and OS versions must be compatible and supported. Again, all of this is listed in the vPar Ordering and Configuration Guide. Typically, the system,

4 of 9

firmware, and OS will be in a supported configuration and vPars is then installed. In this case, the version of vPars must be supported with the existing configuration.

6.2 Upgrading Operating System and/or Virtual Partition Versions

There are three scenarios that must be considered when upgrading. These are upgrading vPars and not the OS version, upgrading the OS version and not vPars, and upgrading both vPars and the OS version.

6.2.1 Upgrading vPars Only

The version of vPars may be upgraded by itself as long as the firmware version and OS version is supported with the new version of vPars. For example, upgrading from version A.03.01 to version A.03.02 may be done without an OS version change following the vPars Ordering and Configuration Guide requirements. In this case, only the vPar software needs to be updated on each of the vPar boot disks. This may be done with HP Software Distributor or HP Update-UX. Further, the upgrade may be done to each running vPar while the vPar monitor is running. However, as soon as each upgrade completes, the vPar monitor must be rebooted. HP does not support running while the monitor and vPar software have different versions at this release. The vPar and OS version rules in Section 4 above must be followed for a supported environment.

6.2.2 Upgrading the OS only

The minor release of the OS may be upgraded by itself as long as the firmware version and vPar version is supported with the new release of the OS. For example, upgrading from HP-UX 11iV2 OS release 0505 to 0512 (considered a minor release update) may be done without a vPar release update following the vPars Ordering and Configuration Guide requirements. In this case, only the OS software needs to be updated on the vPar boot disks that need or want the update. A key point here is that each vPar boot disk does not have to have the same HP-UX OS minor release version as long as it is supported per the Ordering and Configuration Guide. The vPar and OS version rules in Section 4 above must be followed for a supported environment.

6.2.3 Upgrading both vPars and OS

The third scenario is most likely the most difficult for customers to deal with. In this case, both the version of vPars and the version of the OS are updated. The most recent example of this is when moving from vPars A.03.xx to vPars A.04.xx or moving from HP-UX 11iV1 to HP-UX 11iV2. Again, following Section 4 above, it would be necessary to upgrade both the OS and vPars when moving from A.03 to A.04 or from HP-UX 11iV1 to 11.23 because A.03 is not supported on HP-UX 11iV2 and HP-UX 11iV1 does not support A.04. There is an entire section in the Managing and Installing HP-UX Virtual Partition document on how to accomplish this using update-ux.

7 Customer Impact
Now that we have established the rules for mixing vPar versions and OS versions, how this affects customer solutions will now be discussed.

7.1 Solution Design (potential) Issues

Figure 4 below shows how customers are typically deploying vPars. In this example, there are 3 hard partitions (nPar 1, 2, and 3) sitting on top of the System Firmware (SFW). Each hard partition is running vPars A.03. And running within each vPar are standard and business applications.

5 of 9

Figure 4 Typical Customer Design Looking back at Section 6 above, lets see how upgrading either vPars or the OS impacts this design. From Section 6.2.1 just the version of vPars in each nPar can be upgraded as long as the version stays at the A.03.xx release stream (i.e. A.03.01, A.03.02, A.03.03, etc). And each nPars vPar version can be upgraded independently of the other nPars. From Section 6.2.2 just the release of the OS in each vPar can be upgraded as long as the release stays at the 11iV1 release stream (i.e. Fusion Releases). Section 6.2.3 proves to be the difficult upgrade. In this example, all of the vPars are running production and/or critical applications. If either a major release upgrade of the OS version (i.e. from 11iV1 to 11iV2) or a major release upgrade of the vPar software (i.e. from A.03 to A.04) is required, then BOTH the OS and vPars must be upgraded at the same time. Remember, vPars A.03 cant run on 11iV2 and vPars A.04 cant run on 11iV1. The problem with the design in Figure 4 is that the customer has not left any Test and Development space to try out the new OS and vPars upgraded versions within the complex.

7.1.1 Summary
The customer has fully standardized on vPars A.03.xx and HP-UX 11iV1 and utilized the entire system for business applications. This leads to the following issues: The full capacity of the system is dedicated to Business needs and is virtualized The customer doesnt have the capacity now, or a parallel System for QA / Dev The customer incorrectly assumed vPars A.03.xx could support HP-UX 11iV1 and HP-UX 11iV2 or vPars A.04.xx could run HP-UX 11iV1 The customer didnt understand that only one major version of vPars can run in a nPar In this environment there is no place to test upgrades before Business implementation: Customers are now submitting escalations to HP to get vPars A.03.xx to support HP-UX 11iV2 or A.04.xx to support HP-UX 11iV1 Upgrades must be tested on a separate system

6 of 9

7.2 Proposed Solution Design

Figure 5 below shows how HP might suggest customers deploy vPars. In this example, there are 3 hard partitions (nPar 1, 2, and 3) sitting on top of the System Firmware (SFW). However, in this case, nPar1 is running vPars A.03, nPar2 is not running vPars, and nPar3 is running vPars A.04.

Figure 5 Proposed Customer Design Looking back at Section 6 above, lets see how upgrading either vPars or the OS impacts this design. From Section 6.2.1 just the version of vPars in nPar1 and nPar3 can be upgraded as long as the version stays at the A.03.xx release stream (i.e. A.03.01, A.03.02, A.03.03, etc) in nPar1 and the version stays at the A.04.xx release stream (i.e. A.04.01, A.04.02, etc) in nPar3. In addition, each nPars vPar version can be upgraded independently of the other nPars. From Section 6.2.2 just the release of the OS in each vPar can be upgraded as long as the release stays at the 11iV1 release stream (i.e. Fusion Releases) in nPar1 and the release stays at the 11iV2 release stream (i.e. Fusion Releases) in nPar3. In this example, all of the vPars are not running production and/or critical applications; specifically nPar3 is QA/DEV. Again, if either a major release upgrade of the OS version (i.e. from 11iV1 to 11iV2) or a major release upgrade of the vPar software (i.e. from A.03 to A.04) is required, then BOTH the OS and vPars must be upgraded at the same time. However, with the design in Figure 4 the customer has left a QA and Development space to try out the new OS and vPars upgraded versions. This allows the customer to try out the new versions on the same system without impacting the other hard partitions or having to utilize another system.

7.2.1 Summary
The customer has not fully standardized on vPars A.03.xx and HP-UX 11iV1 and has not utilized the entire system for business and/or critical applications. This leads to the following benefits: The customer deployment is based on Pre-Sales and vPars EAP data vPars is not present in all nPars Main Business Critical Application in one large nPar Customer is mixing vPars and non-vPars environments on large systems An nPar is reserved for Quality and Development of new OS, Patches and vPar versions

7 of 9

This configuration provides customers with QA/Dev nPar they can use to test vPar A.03.xx before upgrade to A.04.xx: Customers have the flexibility to switch to a newly created nPar/vPar when setup and testing are complete

8 of 9

8 For More Information

http://www.hp.com/go/virtualization (HP-UX Virtualization) http://docs.hp.com/en/T1335-90051/T1335-90051.pdf (Installing and Managing HP-UX Virtual Partitions) http://docs.hp.com/en/1705/oc.pdf (HP-UX Virtual Partitions Ordering and Configuration Guide)

2005 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Itanium is a trademark or registered trademark of Intel Corporation in the U.S. and other countries and is used under license. XXXX-XXXXEN, 10/2005

9 of 9