HP-UX vPars and Integrity VM V6.3 Administrator Guide

The way the virtual media I/O gets to the physical storage backing is also an important
consideration. As shown in Figure 6 (page 67), all virtual I/O goes through a general VSP I/O
services layer that routes the virtual I/O to the correct VSP interface driver. The interface driver
then controls the physical I/O adapter to issue virtual I/O to the physical storage device. By load
balancing across these physical adapters, virtual I/O bottlenecks can be eliminated at the physical
hardware layers, thereby increasing performance. Load balancing can be done by using a
multi-pathing solution on the VSP. For help with selecting a multipath solution for a virtual media
type, see Section 6.4.1.3 (page 69).
The performance of attached devices is largely determined by the type of physical device attached
to the VM. Tapes, media changers, and CD or DVD burners are inherently slow devices, not
significantly impacted by the software overhead of vPar and Integrity VM.
6.4.1.3 Storage multipath solutions
vPars and Integrity VM virtual devices support the built-in multi-pathing of the HP-UX 11i v3 VSP,
which is enabled by default to provide improved performance, load-balancing, and higher
availability for vPars and VM guests. Starting with V6.3, vPars and Integrity VM virtual devices
also support Veritas DMP devices. Currently, there are no multipath solutions supported for the
attachable device types of tapes, media changers, and CD or DVD burners.
For non-NPIV devices, there are no multiple paths to virtual devices inside a VM. The following
are the reasons for the support of multi-pathing only on the VSP for non-NPIV based AVIO backing
stores:
• The VSP is the only place where all virtual I/O can be properly load balanced for the best
overall performance. A single VM cannot account for all the other vPar or VM I/O with which
it is competing on the VSP (see Figure 6 (page 67)).
• Running a multipath solution in a vPar or VM guest does not provide any high availability for
a virtual device. Virtual connections between virtual adapters and their devices are never lost
until an hpvmmodify command is used to disconnect them. The only connection ever lost is
the ability of a virtual device to access its own virtual media through the VSP. Errors in
communication to the virtual media are properly emulated as media errors sent to the guest
OS, not as path failures.
• The VSP does not return specific errors to Integrity VM for hardware path failures. vPars and
Integrity VM does not detect such events and does not pass them to the vPar and VM guest.
For NPIV devices, multi-pathing products run on the vPar or VM guest and not on the VSP. For
more information about multi-pathing for NPIV devices, see Section 7.4.3.8 (page 108).
6.4.1.4 Storage management
Before you decide how to divide VSP storage, consider the impact on the management of the
storage subsystem.
A VSP administrator manages vPar or VM storage to make sure virtual media is allocated safely.
This begins with understanding the VSP I/O stack and knowing from where the virtual media is
being allocated. When you share a physical backing storage device among VMs, potential conflicts
are not always obvious. For example, if you use a file in a file system on a whole disk as a backing
store, the raw whole disk device itself cannot also be used as a backing store.
Figure 8 (page 70) shows an example of a VSP I/O stack as it applies to a single LUN.
6.4 Configuring vPar and VM guest storage 69