See also, z/VM Storage Management page.
Return to Introduction to PAV page.
Introduction to PAV
VM provides support for
the Parallel Access Volumes (PAV) feature of the
IBM Enterprise Storage Server (ESS). ESS DASD
need to be defined to VM as 3390 model 2, 3, or
9 DASD on a 3990 model 3 or 6 control unit. 3380
track-compatibility mode for the 3390 model 2 or 3
DASD is also supported. The PAV feature of the
ESS is supported on VM for guest use via dedicated
(otherwise known as attached) DASD.
Figure 1. illustrates the PAV Base to Alias
volume relationship. The Base volume can be
thought of as the real physical DASD space. It
has its own unique subchannel ID. Alias volumes
X and Y in the figure can be thought of as volumes
that map the physical space occupied by the Base.
The Alias volumes don't have their own
space; they are 'shadows' of the Base. However,
they also each have unique subchannel Ids so
that I/O can be done concurrently to all three
volumes (Base, Alias X, and Alias Y).
For VM, the Base volumes are defined in IOCP
as UNIT=3990 on the CNTLUNIT statement and UNIT=3390B
(or 3380B) on the IODEVICE statement. Alias volumes
are defined as UNIT=3990 on the CNTLUNIT statement
and UNIT=3390A (or 3380A) on the IODEVICE statement.
UNIT=2105 on the CNTLUNIT statement is also acceptable.
Each volume can be assigned any available VM real
device number. The designation of which
real volumes are Base volumes, which are Alias
volumes, and which Alias volumes are associated
with each Base must be initially defined using the
ESS configuration console. The CP QUERY PAV
command can be used to view the current real Base
and Alias volume allocation under VM.
Workload Balancing via PAVs
The main purpose of the ESS PAV feature is
to increase system throughput and reduce I/O
bottlenecks by allowing multiple concurrent I/O
operations to the
same physical DASD space. This use of the
PAV feature will be referred to as 'workload
balancing' in the description below.
Figure 2 illustrates a guest running on VM
that uses PAV volumes for workload balancing.
For this application, the Base volume and all its
associated Alias volumes (Alias X and Alias Y)
will be dedicated via the CP ATTACH command
to the guest (VM Guest). The virtual device numbers
and subchannel IDs assigned to the PAV volumes
The guest will schedule I/O on whichever of the Base
and Alias volumes seems most appropriate in order to
maximize workload performance. I/O may be scheduled
concurrently on some or all of the associated PAV
It should be noted that the VM Guest in
Figure 2 must contain support code to
manage and serialize the workload data across
the PAV volumes. VM only acts as the 'pipe'
between the guest and the hardware. Once
the necessary Base and associated Alias volumes
are attached to the guest, it is the guest
that must manage their use.
An example of a guest operating system
that contains the
necessary support for PAV workload balancing is z/OS.
In addition to the workload support just described,
a z/OS guest also has the ability to dynamically
move an Alias volume from its current Base volume to
a different Base volume if the workload demands it. The
CP QUERY PAV command can be used to keep track
of the dynamic movement of Alias volumes performed by
a z/OS guest.
DASD Sharing via PAVs
Another use of the ESS PAV feature is for
sharing data across multiple host operating
systems. This use is primarily applicable to
the VM platform because of its ability to
run multiple operating system guests. The
main advantage of sharing data in this way
is that the PAV volumes are eligible for
I/O Assist when attached to Preferred VM guests.
Figure 3 illustrates the use of PAV volumes
for sharing data among multiple VM guests. In
the example, Alias X has been attached via the
CP ATTACH command to Guest A. Alias Y has
been attached, again via ATTACH, to Guest
B. Both Alias X and Y are associated with the
same Base volume (not shown, but can also be used
for sharing) which is attached
to neither guest. The VDISK (Virtual Disk
In Storage) in the example is linked to both
Guest A and B via the VM User Directory.
The linked VDISK is important because it
demonstrates a method for serializing the data
that is shared among the two guests. The VDISK
could contain, for example, the VSE lock file.
The VDISK would not be necessary in a read-only
environment. In that case, the Alias volumes
could just be attached to the guests using the
R/O option of the ATTACH command.
A method to serialize access to the Alias
volumes must be devised, because Reserve/Release
is not supported on PAV Alias volumes (the
CCWs will be rejected). By using a linked
VDISK, Reserve/Release can be used against the
VDISK to control access to the Alias volumes.
Also, it must be insured that free (not attached)
Base and Alias volumes associated with the PAV
volumes being shared are clear of all write
In summary, it is the sole responsibility
of the VM guests to manage and serialize any data
that is shared via Alias volumes. VM only
provides the 'pipe' for data exchange between the
hardware and the guests. Also, the above
described method of DASD sharing will not work
with z/OS guests since each z/OS guest must
have access to the Base volume.
VM Restrictions to PAV Usage
- An Alias volume can not be IPLed.
- An Alias volume can not be attached to the userid
- An Alias volume can not be attached to a guest if its
associated Base is currently attached to SYSTEM.
Alternatively, a Base volume can not be attached to
SYSTEM if any of its associated Alias volumes are
attached to one or more guests.
- An Alias volume will not come on-line to VM without an
associated Base volume. Also, a Base volume must have at least
one associated Alias volume for VM (e.g., QUERY PAV command)
to recognize the device as a Parallel Access Volume.
- A Base volume can not be changed or deleted with the SET
RDEVICE, DELETE RDEVICE, DELETE DEVICE, or MODIFY DEVICE
command unless all associated Alias volumes have been deleted
via the DELETE RDEVICE command.
Return to Introduction to PAV page.