HP-UX vPars and Integrity VM V6.1.5 Administrator Guide (5900-2295, April 2013)

and tuning operating systems for the virtual platform. At the same time, vPars and Integrity VM
V6.1.5 provides more virtualization choices to VSP administrators, so that they can find the best
balance between virtualization and performance to meet their needs.
9.1.1.4 Storage security
To avoid problems while supporting multiple vPars/VMs on one physical machine, vPars and
Integrity VM V6.1.5 isolates each virtual machine and virtual partition. Using Integrity VM
commands, the VSP administrator determines the physical storage resources that each virtual
machine and virtual partition can access. This storage isolation is maintained by the vPar/VM
storage subsystem through DMA boundary checks on each vPar/VM I/O operation, thereby
ensuring that one virtual machine or virtual partition does not access the memory of another.
9.1.1.5 Storage configurability
VSP administrators expect the vPars/VMs to be as easily configurable as HP Integrity servers. The
vPar/VM storage subsystem allows for easy changes of the storage devices through vPars and
Integrity VM commands. Using these commands, the VSP administrator dynamically adds, deletes,
and modifies storage devices on virtual machines and virtual partitions. Guest administrators can
change some storage, limited in scope by the VSP administrator, using the virtual console.
9.1.2 Storage architectures
To provide the flexibility required to meet a variety of data center needs, the vPar/VM storage
subsystem consists of two storage architectures, shared I/O and attached I/O.
9.1.2.1 Shared I/O
The shared I/O architecture is a means by which a vPar/VM accesses an entirely virtualized
storage subsystem provided by vPars and Integrity VM V6.1.5. The vPar/VM storage subsystem
emulates real hardware to the vPar/VM while interacting with the VSP to complete the vPar/VM
I/O operation to the VSP storage entity. This abstraction provides the ability of a VSP administrator
to share physical VSP storage hardware across multiple virtual machines and to allocate that
storage at sub-LUN levels.
The sharing of individual storage LUNs is accomplished by dividing a VSP LUN into smaller parts,
like logical volumes, or files. Each of these sub-LUN VSP entities can then be used as media for
separate virtual storage devices. The vPars/VMs access the virtual storage devices as real storage
devices, with no knowledge that the virtual storage media is actually a sub-LUN VSP entity.
The way the virtual storage media is accessed by the vPar/VM storage subsystem allows vPars/VMs
to share physical VSP storage adapters. All virtual storage media is accessed through user-defined
interfaces on the VSP. The VSP maintains complete control of the physical hardware and handles
the vPar/VM I/O operations just as it would be handled for any other user application. Thus, just
as hardware is shared among normal applications running on the VSP, vPar/VM I/O is shared
across the physical storage as well.
This architecture also provides for whole LUNs to be virtualized. While this does not increase
storage utilization, it does provide higher storage availability. Because the LUN is virtualized, the
guest OS does not have to support the physical VSP LUN. It only has to be able to support the
virtualized version of it. Thus by using shared I/O, a vPar/VM can run with any physical hardware
that is supported by the VSP.
Finally, all vPar/VM I/O requests in shared I/O are processed by virtual adapters. A virtual adapter
is either an emulation of a real adapter that a native guest OS driver accesses as real hardware,
or a special driver loaded into the guest OS. In either case, the virtual adapter uses internal
vPar/VM storage subsystem calls to handle communication of vPar/VM I/O to the virtual devices.
This connection between the virtual adapter and the virtual devices need not resemble anything in
an HP Integrity server system. It is emulated so that the vPar/VM does not know the difference.
110 Creating virtual storage devices