3.1 zVM basics
|
| < Day Day Up > |
|
3.1 z/VM basics
In this project, we used z/VM to provide multiple Linux environments on the same zSeries system.
Figure 3-1 shows a highly simplified and stylized view of a zSeries processor and its physical components or resources-processor units, memory (real and expanded storage), channels, control units, and devices. All of these are managed by an operating system; typically this is z/OS, z/VM, or Linux.
Figure 3-1: zSeries system resources
The original Virtual Machine (VM) operating system was developed in the late 1960s as a tool to aid in development and testing of new operating systems and software without the need to tie up an entire physical computer and associated hardware. It did this by allowing the creation of multiple virtual computers along with all hardware resources under the VM operating system. z/VM still works this way today. The resources that make up these virtual machines are defined by the directory entries of the user ID under which the virtual machine will log on. These virtual machines appear to the operating systems that run under them as real computers with real hardware.
z/VM has special abilities, however. Its two most important components are the control program (CP) and the Conversational Monitor System (CMS). CP is able to virtualize hardware resources. It does this either by partitioning or sharing real hardware resources, or by emulating their behavior programatically.
CP implements z/Architecture or S/390 architecture virtual machines. On a single piece of hardware, you can run several copies of the same or different operating systems under the control of CP. Any operating system that can run on S/390 or zSeries hardware can run under z/VM as a guest operating system in the z/VM-created virtual machine.
From the point of view of the operating system running inside the virtual machine, the hardware appears to be real hardware. These running operating systems are sometimes called guests. They can be added or deleted at will by changing the CP directory. We discuss this later.
We refer to z/VM as a hypervisor. The users of each virtual zSeries machine are unaware that a hypervisor is providing the zSeries environment in which their application is running. Each virtual machine has its own virtual memory, virtual devices, virtual processors, and other virtual resources.
Within each virtual machine, a zSeries operating system is IPLed. You can even IPL z/VM within a virtual machine. Each operating system running in its own virtual zSeries environment communicates with virtual devices. The mapping of virtual to real devices and resources is handled transparently by CP. The result is that by running z/VM on the processor shown in Figure 3-1 on page 28, we can replicate the zSeries environment many times over. This is illustrated in Figure 3-2.
Figure 3-2: Virtual machines running under the control of a hypervisor
The CP or user directory
The definition of a virtual machine is stored in a master directory called the CP directory and also often called the user directory. For example, the source listing of a user directory entry for one of our Linux guests is as follows:
Listing 3-1: Directory entry for Linux guest
 |
USER LINUXC XXXXXXXX 256M 1G G [1] IPL CMS PARM AUTOCR [2] MACHINE ESA 4 [3] DEDICATE 2C0C 2C0C [4] DEDICATE 2C0D 2C0D [4] DEDICATE 2C0E 2C0E [4] DEDICATE 2C60 2C60 [5] DEDICATE 2C61 2C61 [5] DEDICATE 2C62 2C62 [5] CONSOLE 0009 3215 [6] SPECIAL 0600 HIPER 3 SYSTEM GUESTLAN [7] SPOOL 000C 3505 A [8] SPOOL 000D 3525 A [8] SPOOL 000E 1403 A [8] LINK MAINT 0190 0190 RR [9] LINK MAINT 019E 019E RR [9] LINK MAINT 019F 019F RR [9] LINK MAINT 019D 019D RR [9] MDISK 0191 3390 1595 50 VMLU1A MR [10] MDISK 0200 3390 0001 3338 LX1519 MR [10] MDISK 0201 3390 0001 3338 LX1559 MR [10] MDISK 0202 3390 0001 3338 LX1599 MR [10] MDISK 0203 3390 0001 3338 LX15D9 MR [10] MDISK 0204 3390 0001 3338 LX8026 MR [10] MDISK 0205 3390 0001 3338 LX8027 MR [10] MDISK 0206 3390 0001 3338 LX8125 MR [10] MDISK 0207 3390 0001 3338 LX8126 MR [10] MDISK 0208 3390 0001 3338 LX8127 MR [10] MDISK 0209 3390 0001 3338 LX8225 MR [10] MDISK 020A 3390 0001 3338 LX8226 MR [10] MDISK 020B 3390 0001 3338 LX8227 MR [10] MDISK 020C 3390 0001 3338 LX151E MR [10] MDISK 020D 3390 0001 3338 LX151F MR [10] MDISK 020E 3390 0001 3338 LX155E MR [10] MDISK 020F 3390 0001 3338 LX155F MR [10] MDISK 0210 3390 0001 3338 LX159E MR [10] MDISK 0211 3390 0001 3338 LX159F MR [10] MDISK 0212 3390 0001 3338 LX15DE MR [10] MDISK 0213 3390 0001 3338 LX15DF MR [10] MDISK 0301 FB-512 V-DISK 204800 MR [11] MDISK 0302 FB-512 V-DISK 204800 MR [11] MDISK 0303 FB-512 V-DISK 204800 MR [11] MDISK 0304 FB-512 V-DISK 204800 MR [11] MDISK 0305 FB-512 V-DISK 204800 MR [11] MDISK 0306 FB-512 V-DISK 204800 MR [11] MDISK 0307 FB-512 V-DISK 204800 MR [11] MDISK 0308 FB-512 V-DISK 204800 MR [11] MDISK 0309 FB-512 V-DISK 204800 MR [11] MDISK 0310 FB-512 V-DISK 204800 MR [11] SPECIAL 808 CTCA TCPIP[12] SPECIAL 809 CTCA TCPIP[12]
|
Most of the statements in this entry define virtual resources or devices.
Notes:
| [1] | The user ID that identifies this virtual machine is LINUXC. The password field shows XXXXXXXX, but this is DirMaint hiding the true password. In the USER DIRECT file without DirMaint, the real password will be in this field. The virtual machine is defined with a default storage of 256 megabytes, but this can be redefined up to a maximum of 1 gigabyte. This is probably a good starting point for a server that will run Domino. |
| [2] | This statement indicates what operating system will be IPLed when you log on to the virtual machine. In our example, an IPL of CMS will occur. We did this because we needed to set up some changes to the normal environment, as well as run some REXX EXECs to set up Linux to run Domino more effectively. This was done through the user ID's PROFILE EXEC. If no changes need to be made, you can IPL Linux from the minidisk at address 0200 at logon time by changing the directory statement to:
IPL 200 |
| [3] | This statement describes the processor architecture of the virtual machine. The maximum number of processors that can be defined for this virtual machine is four. The default is one. |
| [4] | Dedicate statements for the OSA Express address triplet. Three are required one for input control, one for output control, and one for data. These three addresses are associated with a single IP address. |
| [5] | When running a Domino server, you might need a second IP address. This may be used for clustering or a second partition in the server. If this is the case, a second set of dedicate statements for the address of the second OSA adapter will be needed. Three are required: one for input control, one for output control, and one for data. These three addresses are associated with a single IP address. This second OSA will need to be on a different physical adapter than the first and have a different MAC address |
| [6] | The CONSOLE statement defines the operating console for the virtual machine. |
| [7] | These statements define the HiperSocket address triplet for use with the Guest LAN named GUESTLAN. |
| [8] | These statements define a virtual reader, punch, and printer for the virtual machine. |
| [9] | These are read-only links to minidisks owned by other virtual machines. They typically provide services to the virtual machine. They are sometimes referred to as "system disks". |
| [10] | These statements define twenty-one minidisks owned by the LINUXC user ID The general format of the minidisk statement is:
MDISK aaaa tttt ffff ssss vvvv rr where:
For example, consider the following MDISK statement:
MDISK 0191 3390 1595 50 VMLU1A MR Device 191 is a minidisk (partition) of Volume VMLU1A that begins at cylinder 1595 with a size of 50 cylinders. It occupies the following cylinder ranges from 1595 to 1645 on the device. This is the Linux guest virtual machine's CMS A disk. Device numbers 201-213 are minidisks on 13 different volumes. Device number 200 occupies all cylinders 1-3338 on the real disk with VOLID LX1591. Cylinder 0 is typically used by the z/VM operating system and usually is not assigned to a minidisk. Device number 191 occupies cylinder range 1595-1645 on the real disk with VOLID VMLU1A. These are all read/write minidisks. |
| [11] | These statements define the virtual minidisks. We used these primarily for Linux swap space. The format is of the statement is:
MDISK 0310 FB-512 V-DISK 204800 MR This MDISK statement defines 204800 fixed 512-byte blocks (about 100 MB) in read/write mode and assigns it an address of 310. In all, 10 minidisks are assigned with addresses from 301-311. These addresses were used for /swap and for the Domino indexing. |
| [12] | These statements define the read/write pair of a virtual channel-to-channel adapter. |
Now we take a brief look at how CP implements certain device types. Because the S/390 virtual machine concept dates back to the late 1960s and early 1970s, some of the standard devices such as a card reader and card punch may seem antiquated, but they are still extremely useful when virtualized.
Processors
A virtual machine can have up to 64 virtual processors defined (on 64-bit hardware). If the operating system running in the virtual machine is multi-processor (MP)-capable, it will dispatch work on its virtual processors as if it were running without a hypervisor (on the real hardware). CP will handle the dispatching of virtual processors on the real processors available to that virtual machine. A real processor can be either dedicated to a virtual machine, or shared among virtual machines. Dedicated processors can only be used by one virtual machine.
Storage
Each virtual machine has its own defined virtual storage or memory. CP manages the residency of virtual machines' pages in real storage with a sophisticated paging mechanism. Pages that have not been referenced can be moved out of real storage, either into expanded storage, or onto a paging device. When a virtual machine touches a page that is no longer in real storage, a page fault occurs and CP will bring the missing virtual page back into real storage.
A portion of the real storage on a zSeries system can be dedicated to a virtual machine. In this case, the storage of the virtual machine is real and the operating system running in the virtual machine can perform its own memory management without intervention by CP. Expanded storage can also be dedicated to a virtual machine.
CP also has facilities that allow the sharing of virtual pages by a number of virtual machines. A shared virtual page requires just one page of real storage no matter how many virtual machines are sharing it, thereby economizing on real storage requirements.
Minidisks
VM minidisks are virtual disk devices. They are implemented by partitioning a real volume into cylinder ranges that appear as separate disk volumes to the virtual machine. A minidisk can span a whole real disk volume. A real disk can also be dedicated to a virtual machine.
Minidisks can be shared or non-shared. If authorized, one virtual machine can link to a minidisk belonging to another virtual machine to access the data on it. Links can either read-only or read-write. When a minidisk is write-shared, some software is needed to manage access to the data.
CP is able to cache the contents of minidisks in real or expanded storage to improve application response times.
Temporary minidisks
Temporary minidisks are allocated from a defined pool of real disk storage, either when the virtual machine is logged on or by explicit definition. They last for the life of the virtual machine. When the virtual machine is logged off or the minidisk is detached, the temporary minidisk is destroyed.
Virtual minidisks
Virtual minidisks (sometimes called vdisks) have similarities to temporary minidisks. But instead of being mapped to cylinders of real disk volumes, they are mapped into real storage by CP. This means that they avoid the need for disk I/O. The associated pages are managed by CP as part of its overall real memory management.
Reader, punch, printer
These devices are not associated with real devices, but are implemented through the CP spooling subsystem. The spool files created or read on these devices can be transferred between virtual machines very easily.
The console
The console is an important device for the virtual machine, as it is the primary user interface. When you log on to a virtual machine from a real 3270 terminal or 3270 emulator, the virtual console becomes associated with the real 3270. This allows you to enter CP commands and to IPL an operating system.
When an operating system is IPLed in a virtual machine, it will look for a device to be its system console. This device is often the one defined by the CONSOLE statement in the CP directory.
After the operating system is IPLed in a virtual machine, the console device is sometimes no longer required and it may be disconnected. The virtual machine can continue to function with a disconnected console.
Channel-to-channel device
A virtual channel-to-channel device is implemented by CP entirely through software. Virtual I/O instructions are intercepted by CP and the data moved between memory buffers. This enables very high-speed communications between virtual machines.
Virtual I/O
An operating system such as z/OS or VSE/ESA running in a virtual machine will issue normal S/390 I/O instructions to perform I/O. The operating system builds a string of Channel Command Words (CCWs) and issues a Start Subchannel (SSCH) instruction.
If the I/O is to a minidisk device, the virtual device number must be converted to a real device number and the virtual cylinder number must be converted to a real cylinder number. Also, the address of the data to be read or written must be converted to a real address. This process, called CCW Translation, is carried out transparently by CP.
By dedicating real storage and devices to a virtual machine, the processor-related overhead of CCW translation can be bypassed. A "preferred" guest can perform disk I/O without any intervention by CP.
CMS
The Conversational Monitor System (CMS) is a unique zSeries operating system. It is IPLed in a virtual machine in the normal way, but is often a single user environment. You can think of it as the original time-sharing PC! CMS provides a rich application development and execution environment. It has powerful commands and tools that are useful to both developers and end users.
The REXX interpreter makes it easy to write command scripts and even whole applications. The XEDIT editor is a sophisticated editor with a large subcommand set. CMS Pipelines allows the concept of UNIX pipes.
Besides acting as a single-user system, server applications can also be written that run on CMS. Many z/VM products and tools are implemented in this way (the TCP/IP service machine and related daemon virtual machines, for example).
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 162