Overview of the Control Program (CP)

A virtual machine can have up to 64 virtual CPUs. If capable of running in multiprocessor mode, your virtual machine operating system dispatches work on its virtual CPUs as if it were running on real hardware. CP handles the dispatching of work on your virtual CPUs to real CPUs.

Usually virtual machines share all CPUs, but a real CPU can be dedicated to a virtual machine, which means that the CPU is reserved for that virtual machine's exclusive use. Unless you have sufficient CPUs available and do good planning, dedicating CPUs can have an impact on the performance of other virtual machines in the system.

Related information: For more information about Linux and CPU usage, see: Linux Performance when running under VM.

Mainframe storage is analogous to memory in a personal computer. CP commands refer to memory as storage, so do not confuse the term storage with disk or tape storage.

Each virtual machine has its own virtual storage. CP manages the residency of virtual machine's pages in real storage through paging. Pages that have not been referenced can be moved out of real storage onto a paging device. When a virtual machine requires a page no longer in real storage, a page fault occurs and CP brings the missing page back into real storage.

CP has facilities that allow portions of real storage to be shared by many virtual machines. Such portions are called shared segments. This sharing economizes on real storage and requires less paging, thereby improving performance. For example, the CMS nucleus is shared in real storage by all virtual machines that loaded CMS by name; that is, every CMS virtual machine maps a 1 MB segment of virtual storage to the same 1 MB of real storage.

DASD, the mainframe term for disk drives, stands for direct access storage device and is analogous to a hard disk drive on a personal computer. A single real DASD is called a volume or real volume. Each volume has a label or volume serial number (volser) that identifies the volume to z/VM®.

Of special importance is the way z/VM shares DASD. CP can logically partition real DASD volumes into minidisks, which is analogous to dividing a personal computer hard disk into multiple partitions. A minidisk has its own label, which is distinct from the real DASD label. Each virtual machine can have one or more minidisks and those minidisks are under control of the guest operating system. To the guest, a minidisk appears as an entire DASD volume (though smaller) and the guest runs channel programs as normal to do I/O. Behind the scenes, CP reorients the channel programs: the guest perceives all minidisks as starting at cylinder 0, but the real DASD volume has only one cylinder 0, so CP must modify the cylinder offsets in the channel program to address DASD cylinders owned by the guest.

You can create a temporary minidisk from a special pool of real disks. The disk lasts as long as the virtual machine is logged on. At logoff, the temporary minidisk is deleted and the space returned to the available temporary disk pool.

Virtual disks in storage are similar to temporary minidisks, except the disks are mapped to storage rather than the cylinders of real disks. Using virtual disks in storage avoids the need for disk I/O. CP manages the virtual disk pages as part of its real memory management.

These devices are not associated with real devices, but are implemented through the spool file system. For more information, see Overview of the CP spool file system.

The virtual machine console or virtual console is the primary interface to the virtual machine. When you log on to a virtual machine from a local terminal or a remote workstation, the virtual console is associated with the terminal session. From the console, you can enter CP commands, such as loading (IPL) an operating system. The virtual console is the device an operating system views as its system or hardware console.

Related information: For more information about virtual consoles, see Using a Virtual Machine Operator's Console in z/VM: Virtual Machine Operation.

In the early days of computing, input to the computer came from punched cards loaded into a card reader. You used a key punch to record your program on punched cards, then loaded the cards into a card reader, which interpreted your cards and loaded your program into the computer. Output from the program was written to a printer. z/VM preserves this bit of computing history through virtual reader, punch, and printer devices, also called unit record devices. Unit record devices provide a handy way to send files from one virtual device to another, to other virtual machines, or to real devices (such as real printers). For instance, you can think of a file being sent from one virtual machine to another as the virtual equivalent of taking a card stack from one computer and loading the stack onto another computer's card reader.

Behind the manipulation of these files is a CP file system called the spool file system. CP manages spool files on one or more DASD volumes that act as temporary storage areas. A spool file is a collection of data along with device control instructions for processing on a unit record device. Spooling is the processing of files created by or intended for virtual readers, punches, and printers. Through CP and CMS commands, you can send spool files from one virtual device to another, from your virtual machine to another, and to real devices.

By convention, each virtual machine has a virtual reader at virtual device number 00C, a virtual punch at virtual device number 00D, and a virtual printer at virtual device number 00E. Your virtual reader is like the in-box of an e-mail system, except more than just e-mail can be placed there. Through your virtual punch, you can place a copy of an entire operating system into the system spool, then use the CP IPL command to load and run that operating system in your virtual machine. Installing Linux in a virtual machine shows you how to use this z/VM facility.

In an SSI cluster, spool volumes (disks) are shared through a function called cross-system spool. Each member of the cluster creates spool files only on spool volumes that it owns, but each member has access to the spool volumes owned by the other members. Users defined as single-configuration virtual machines¹ have a single logical view of all their spool files. Users logged on to one of the members of the SSI cluster can access all of their spool files regardless of which member they have logged on to for that session. (For a spool file to be accessible, the member on which it was created must be joined to the cluster.) Users can transfer their spool files to other users or to service virtual machines² anywhere in the cluster. They can select printers and other spool output devices for processing spool files created on any member of the cluster. Thus, the end-user view of spooling is nearly transparent. Although the CP commands that manipulate spool files operate differently internally for an SSI cluster, additional user options or parameters are not required.

User IDs defined as multiconfiguration virtual machines do not participate in cross-system spool. Each instance of a multiconfiguration virtual machine can view only the spool files owned by the instance on that member. A spool file owned by another instance of the virtual machine (that is, logged on to another member) is not visible. Spool file transfer services, such as RSCS³, can be used to move spool files to the member where the intended instance of the multiconfiguration virtual machine resides.

For information about managing spool files for your virtual machine, see Using Spooled Devices to Print, Punch, and Read Information in z/VM: Virtual Machine Operation.

For command help, see z/VM: CP Commands and Utilities Reference, and z/VM: CMS Commands and Utilities Reference.

For online help, type help on the CMS command line, then press the Enter key.

The z/VM user directory (or user registry) describes the configuration and operating characteristics of each virtual machine that can be created by CP. A z/VM user directory exists in two forms: a source form that consists of one or more CMS files, and an object form, created from the source, on a CP-formatted disk.

The following is a sample single-configuration virtual machine definition. The callouts next to each statement correspond to explanations that follow the sample.

 1   USER LINUXC MYPASS 256M 1G G
 2   INCLUDE LINDFLT
 3   IPL CMS
 4   MACHINE ESA 4
 5   CONSOLE 0009 3215
 6   NICDEF 4204 TYPE QDIO LAN SYSTEM VSWITCH1
 7   SPOOL 000C 3505 A
     SPOOL 000D 3525 A
     SPOOL 000E 1403 A
 8   LINK MAINT 0190 0190 RR
     …
 9   MDISK 0191 3390 1595 50 VMLU1A MR
     MDISK 0200 3390 0001 3338 LX1519 MR
     MDISK 0201 3390 0001 3338 LX1559 MR
     MDISK 0202 3390 0001 3338 LX1599 MR

1. The USER statement begins the directory entry. The user ID for this virtual machine is LINUXC. MYPASS is the user's logon password. The virtual machine has a default storage of 256 megabytes (256M), but you can redefine storage up to a maximum of 1 gigabyte (1G). The second G means the virtual machine user is a general class user and can control functions for this virtual machine only.
2. The INCLUDE statement specifies the name of a profile entry to be invoked as part of the user entry. In the example, there is a profile entry elsewhere in the user directory that starts with the statement PROFILE LINDFLT.
3. The IPL statement indicates which operating system to load when you log on to the virtual machine. The example shows that CMS will be loaded. Loading CMS is handy because it allows you to make changes to the normal environment as well as run some REXX EXECs (script-like executable files) to set up Linux.
4. The MACHINE statement describes the processor architecture of the virtual machine. The maximum number of virtual CPUs that can be defined for this virtual machine is four. The default is one.
5. The CONSOLE statement defines the operating console (virtual console) for the virtual machine. CMS requires console type 3215. If supported by the operating system, you can specify 3270 or issue the CP command TERMINAL CONSOLE 3270 to change the console from 3215 to 3270.
6. The NICDEF statement defines this virtual machine's attachment to a z/VM virtual switch.
7. SPOOL statements define the unit record devices. By convention, device number 000C is for the virtual reader (type 3505), device number 000D is for the virtual punch (type 3525), and device number 000E is for the virtual printer (type 1403).
8. LINK statements provide access to another virtual machine's minidisks.
9. MDISK statements define minidisks owned by the virtual machine. The format of the statement is:

   MDISK devno type start_cyl extent vol_label access_mode

   where

   devno

   Is the virtual device number of the minidisk.

   type

   Is the disk type of the real disk; typically 3390.

   start_cyl

   Is the real disk starting location of the first cylinder of the minidisk.

   extent

   Is the minidisk size in cylinders.

   vol_label

   Is the volume label of the real disk.

   access_mode

   Is the access mode. MR means the virtual machine has read/write access.

 1   IDENTITY OPERATOR pw 32M 32M ABCDEFG 
     INCLUDE IBMDFLT 
 2   BUILD ON MEMBER1 USING SUBCONFIG OPERTR-1 
     BUILD ON MEMBER2 USING SUBCONFIG OPERTR-2 
     BUILD ON MEMBER3 USING SUBCONFIG OPERTR-3 
     BUILD ON MEMBER4 USING SUBCONFIG OPERTR-4 
     AUTOLOG AUTOLOG1 OP1 MAINT 
     ACCOUNT 2 OPERATOR 
     MACHINE ESA 
     OPTION MAINTCCW 

 3   SUBCONFIG OPERTR-1 
     LINK OP1 191 192 RR 
     MDISK 191 3390 2924 005 FLA293 MR READ WRITE MULTIPLE 

     SUBCONFIG OPERTR-2 
     MDISK 191 3390 2924 005 FLA2A3 MR READ WRITE MULTIPLE 

     SUBCONFIG OPERTR-3 
     LINK OP1 191 192 RR 
     MDISK 191 3390 2924 005 FLA2B3 MR READ WRITE MULTIPLE

     SUBCONFIG OPERTR-4 
     LINK OP1 191 192 RR 
     MDISK 191 3390 2924 005 FLA2C3 MR READ WRITE MULTIPLE 

1. The IDENTITY statement begins the directory entry. Like the USER statement, the IDENTITY statement defines the user ID, password, default storage, maximum storage, and authorization class (or classes) for this virtual machine. You can add statements that are common to all instances of a multiconfiguration virtual machine within the IDENTITY entry (AUTOLOG, ACCOUNT, MACHINE, OPTION, and so forth).
2. The BUILD statement specifies a system name of an SSI cluster member and the SUBCONFIG ID of the subconfiguration entry that contains the system-specific directory statements for a multiconfiguration virtual machine instance. In the example, the first BUILD statement specifies MEMBER1 as the cluster member with system-specific directory statements defined in the OPERTR-1 subconfiguration entry.

   If specified, BUILD statements must immediately follow an IDENTITY statement, an INCLUDE statement, or another BUILD statement.

3. The SUBCONFIG statement starts a subconfiguration entry. This entry contains a set of directory statements in a multiconfiguration virtual machine definition that are specific to one of its virtual machine instances within the SSI cluster. In the example, the OPERTR-1 subcofiguration entry contains a system-specific LINK and MDISK statement.

   The SUBCONFIG statement must be unique among all users.

Related information: For more information about the user directory, see:

Creating and Updating a User Directory in z/VM: CP Planning and Administration