2.7 VM planning considerations

< Day Day Up >

Refer to Chapter 3, "z/VM basics, planning, and tasks" on page 27 for more information about z/VM. In this section, we list some basics to keep in mind while planning your environment to exploit z/VM.

2.7.1 VM user IDs

You will need one VM user ID for each Linux guest. Example 2-1 on page 22 is a sample definition with minimal DASD defined for initial installation.

Example 2-1: Sample VM user definition

    USER LINUXB AAABBB5G 256M 512M G    IPL CMS PAMR AUTOCR    MACHINE ESA    DEDICATE 2C08 2C08    DEDICATE 2C09 2C09    DEDICATE 2C0A 2C0A    MDISK 0191 3390 1545 50 VMLU1A MR    MDISK 0200 3390 0001 3338 LX1518 MR    MDISK 0201 3390 0001 3338 LX1558 MR    MDISK 0202 3390 0001 3338 LX1598 MR    MDISK 0203 3390 0001 3338 LX15D8 MR

Depending on the size of the Domino server you are implementing, you will need to adjust the DASD and memory.

2.7.2 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 an entire real disk volume if you desire.

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.

Virtual minidisks

Virtual minidisks have similarities to temporary minidisks. 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.

The amount of DASD you configure in your VM system depends mainly on the requirements of your VM guests and your Domino infrastructure.

2.7.3 Memory

Each virtual machine has its own defined virtual storage or memory. CP manages the residency of virtual machine 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.

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. A rule of thumb is to use a 3:1 ratio of expanded to central storage. Refer to Chapter 11, "Capacity planning for Linux on z/VM" on page 269 for help in determining how much memory you need in your installation.

2.7.4 CPUs

The number of processors that z/VM has is also important. Processors on z/VM can be physical or logical. It is possible to define more logical CPUs than there are physical CPUs; however, this will generally not improve performance.

CPUs can either be dedicated to an LPAR, or shared across different LPARs. A minimum of two physical CPUs is recommended, as Domino performs better in a multiprocessor environment. Dedicated CPUs are recommended if you have only two, though shared CPUs are an option for smaller loads.

< Day Day Up >