Specifications

164 IBM System z Personal Development Tool: Volume 3 Additional Topics
Also, control point functions are needed to temporarily attach real DVD drives or USB sockets
to a virtual machine.
Access to vClient is controlled by a password. Very little training is required to use vClient for
basic operations; once introduced, the graphic controls are easy to use. The exposure is that
a user can control multiple virtual machines.
Access to an HMC is more complex and substantial training may be needed to use it. HMC
interfaces may be subsetted and given separate userids and passwords, but this requires
some skill to set up and maintain. General HMC access is usually very limited in a major
System z installation.
15.4 Performance
We found z/OS guests under VMWare to have performance ranging from excellent to
unacceptable, depending on the nature of the workload and whether the server was
overcommitted in some way. A virtualized environment, whether VMWare or zBX, cannot
create more machine capacity than what exists in the underlying hardware.
The key consideration is the nature of the workloads. The focus in these documents is z/OS,
but this does not imply any particular workload under z/OS. A z/OS system with many TSO
users (mostly editing source code or doing occasional compilations) might be considered
lightly loaded, whereas another z/OS system with only a few users running large DB2 jobs
might be quite heavily loaded. You cannot draw any conclusions about performance unless
you can realistically define your workloads.
Our notable points included:
򐂰 If the z/OS workloads tended to drive z/OS to 100% CP usage, then overcommitment of
server cores resulted in poor performance. This was easier to identify on a small server
with only four cores. If we created two virtual guests, each with three virtual cores (making
six virtual cores, where there were only four real cores) our z/OS workloads ran several
times slower than if we used only four virtual cores for the same workload.
򐂰 Performance degradation was not linear. Once the processors were overcommitted (with
near 100% utilization by z/OS workloads) performance dropped dramatically.
򐂰 z/OS jobs with heavy I/O ran considerably slower than in a non-virtual environment, even
with no overcommitment of cores. Some MIH
9
messages were seen, but z/OS recovered
from these.
򐂰 Light z/OS loads, such as TSO usage with occasional compilations, ran very well across
multiple virtual machines.
򐂰 We did not overcommit memory. This is possible with VMWare, but we avoided it. Such
overcommitting of memory could result in paging at the VMWare level and we assumed
this would degrade overall performance. It is not possible to overcommit memory with zBX
systems.
򐂰 Except for very light workloads, most z/OS jobs (in virtual machines) ran a little slower
than in non-virtual environments. This was expected and accepted. What was unexpected
(although reasonable) was the apparent processor time (TCB + SRB times) for z/OS jobs
was longer than in a non-virtual environment. That is, the apparent System z instructions
ran slower, and thus needed more System z processor time. This might be significant in a
situation where processor time (as reported by SMF) is important for some reason.
9
MIH is Missing Interrupt Handler. This is a z/OS function that can be triggered by very slow (or backlogged) I/O
operations.