|< Day Day Up >|| |
This section describes some of the z/VM characteristics that you should be aware of.
Processors or CPUs
Paging and spool space
Managing the user directory
Disk space for Linux
Networking for z/VM and Linux-addressed in 5.2, "z/VM networking" on page 72
Details on installing z/VM are beyond the scope of this redbook. For information on this topic, see z/VM Guide for Automated Installation and Service, Version 4, Release 4.0, GC24-6064. z/VM publications are on the Web at:
Also, the z/VM product comes with a convenient one-page installation summary entitled z/VM Installation and Service Summary.
Normally z/VM 4.3 is installed on two 3390-3 DASDs, while z/VM 4.4 is installed on three.
Traditionally, the term for memory used by zSeries personnel has been storage. Today, with the advent of Storage Area Networks, the term "storage" is used for disk space. z/VM commands still use the term "storage". However, in this book, we will use the term "memory".
The amount of memory that z/VM has is very important to the performance of almost any application. zSeries memory can be allocated as either central or expanded. Central memory is addressed at the byte level, while expanded memory is addressed a page at a time.
Expanded memory acts as a fast paging area. Central memory on non-zArchitecture machines (G5, G6, MP3000, and others) is limited to 2 GB due to 31-bit addressing.
To query central memory and expanded memory, the following commands are used.
q stor STORAGE = 2097148K q xstor XSTORE= 2048M online= 2048M XSTORE= 2048M userid= SYSTEM usage= 4% retained= 768M pending= 0M XSTORE MDC min=0M, max=2048M, usage=4% XSTORE= 1280M userid= (none) max. attach= 1280M
This shows that the system has approximately 2 GB of central storage and another 2 GB of expanded storage. A rule of thumb that has been suggested is to have a 3:1 ratio of central memory to expanded memory; however, this is not the case on our system.
Traditionally the term for CPUs used by zSeries personnel has been processors. Also, the term engines is sometimes used.
Each zSeries box has multiple physical processors which come in a number of different flavors. The two flavors important to z/VM and Linux are central processor (sometimes called standard engine) and Integrated Facility for Linux (IFL). As they pertain to z/VM and Linux, IFLs perform identically to central processors on the same machine-the major difference is in price and licensing terms.
The LPAR either has CPUs dedicated to it, or shares CPUs with other LPARs. When the CPU is dedicated, the unused cycles are lost and cannot be used by the LPARs. When you share CPUs, the LPAR is assigns a weight that determines what share of those CPUs can be used by the LPAR.
Virtual processors are assigned to virtual machines in a similar way. Adding virtual processors to a virtual machine allows the virtual machine to get more CPU resources. This is only useful when the operating system can take advantage of it.
It is not recommended to add more virtual CPUs than you have real CPUs in your z/VM system. A minimum of two CPUs is recommended, dedicated or shared.
The number of CPUs can be queried from a privileged user ID with the following command:
q processors PROCESSOR 00 MASTER PROCESSOR 01 ALTERNATE
The maximum number of virtual CPUs that can be defined is specified in the user directory entry for each z/VM user ID. For example, the following line in the user directory entry specifies that a maximum of four CPUs can be defined to the z/VM user ID:
MACHINE ESA 4
The number of virtual CPUs can be set in one of two ways, either in the user directory, or interactively with the DEFINE CPU command. We show both ways here:
In the user directory:
CPU 00 BASE CPU 01
Interactively, with the DEFINE CPU command. Here is an example of setting up a second virtual CPU:
q cpus CPU 00 ID FF02082370600000 (BASE) def cpu 01 CPU 01 defined q cpus CPU 00 ID FF02082370600000 (BASE) CPU 01 ID FF02082370600000 STOPPED
If you then IPL Linux, the new CPU will be used. For example, this is shown from z/VM using the QUERY CPUS command:
CP Q CPUS CPU 00 ID FF02082370600000 (BASE) CPU 01 ID FF02082370600000
From Linux, the same processors can be queried through the /proc filesystem:
# cat /proc/cpuinfo vendor_id : IBM/S390 # processors : 2 bogomips per cpu: 211.35 processor 0: version = FF, identification = 020823, machine = 7060 processor 1: version = FF, identification = 020823, machine = 7060
z/VM requires adequate page space to perform well when more virtual memory is defined than physical memory. A rule of thumb, described in Linux for S/390 and zSeries: ISP/ASP Solutions, SG24-6299, is to have twice as much page space on DASD as the sum of your total virtual storage (which includes z/VM and all Linux guests) and virtual disk.
For example, if your z/VM has 2 GB of central storage and you plan to have 12 Linux guests each with 512 MB, then you should have 16 GB of paging space (2*(2+12*0.5)). That would equate to 7 3390-3 paging volumes (or packs).
Another rule of thumb says that z/VM should only use an average of 30% or less of its page space. If z/VM runs out of page space, it will abend with a code of PGT004.
The amount of page space currently allocated and being used can be queried with the QUERY ALLOC PAGE command:
q alloc page EXTENT EXTENT TOTAL PAGES HIGH % VOLID RDEV START END PAGES IN USE PAGE USED ------ ---- ------ ------ ------ ------ ------ ---- VMPAG1 0202 1 3338 600840 526 556 1% VMPAG2 0203 1 3338 600840 0 0 0% ------ ------ ---- SUMMARY 1202K 526 1% USABLE 1202K 526 1%
This shows that this z/VM system is using almost no page space. To add additional page, spool and temporary disk space, see 3.3.8, "Add page, spool and temporary disk space" on page 43
Traditionally, the term for disk space used by zSeries personnel has been DASD. A popular format is that of 3390-3s, which are about 2.3 GB when formatted for Linux. Often these are referred to as "mod-3s" or simply "packs". z/VM is installed on 2 or 3 3390-3s plus what is needed for page and spool space. Each Linux image with $DOMINO code is often installed on two 3390-3s plus whatever space is needed for the Notesdata directory. For details, see Chapter 4, "Disk configuration" on page 49.
For example, we needed at least 66 packs (3390-3 DASD) for this project: six for z/VM and 60 for Linux. z/VM 4.3 requires two install packs and we dedicated two packs for page space and one for spool/tdisk. Also, part of one pack was used for the Linux user ID 191 disks for some CMS read/write space. Each of the three Linux user IDs was given 20 packs: two to install Linux, and 18 for a large volume group for Notesdata and translogs.
zSeries also has the ability to utilize Storage Area Networks (SAN) with the new FCP support. This is a relatively new technology, not widely utilized in production. There is an introductory Redpaper dealing with this topic entitled Getting Started with zSeries Fibre Channel Protocol, REDP-0205. It is available on the Web at:
The CP or user directory is commonly maintained in one of two ways:
A separately-priced product, such as IBM DirMaint or CA VM:Direct
Manually editing the user directory file
When CMS under VM was a popular end-user operating system, hundreds or thousands of users and minidisks often had to be maintained. Directory maintenance products such as DirMaint or VM:Direct were popular due to the complexity of managing this number of directory entries.
However, with Linux on zSeries, the number of directory entries is often in the tens or even less than ten. When this is the case, manually editing the USER DIRECT file and applying the changes by the DIRECTXA command is simple and the complexity is not significant. Thus we recommend manually editing the USER DIRECT file unless a directory maintenance product is already in place and the necessary skills are available.
|< Day Day Up >|| |