z/vm System Setup IBM Workload Deployer DIRM and SMAPI Socket Support

Transcription

1 z/vm System Setup IBM Workload Deployer DIRM and SMAPI Socket Support Copyright IBM Corp All Rights Reserved. Page 1 of 34

2 Table of Contents Introduction...4 Planning...4 Required Resources...4 Required Software...4 z/vm System Configuration...5 Accessing the SYSTEM CONFIG File...5 System DASD Page and Spool Disks...5 System DASD USER Volumes...6 z/vm Networking Options...7 Modifying Features...8 Custom User Classes...9 Restore z/vm Parm Disk...9 Completing the Setup...9 Removing RPC Support (optional)...10 Updating z/vm TCP/IP Configuration...11 Add the MAPLAN NIC to the TCP/IP Stack...11 Configuring Networking for the MAPLAN NIC...11 Completing the Setup...12 Customizing the z/vm Environment for Sockets...13 Updating Directory Entries for Worker and Requestor IDs...13 Update the Profile EXECs...14 Customizing the SMAPI Socket Environment...15 Update VSMWORK1 and Add Sample RACF Exit...16 Customizing the z/vm Environment...17 Customizing DIRM...17 Allocation Groups...18 Default Directory Entries...19 Prototype Directory Entries...19 Create MAPAUTH Guest...19 Assigning Authorizations...20 Disk Space for DIRMAINT...20 Customizing DATAMOVE...20 Creating the Linux Master System...22 Creating the Linux Master System Directory Entry (MAPSRV)...22 Installing the OS for the Linux Master System...23 Configuring the Guest LAN Connection to TCPIP...23 The z/vm Hypervisor...24 Creating a z/vm Cloud Group...24 Installing the z/vm Agent...24 Running Discovery on the z/vm Hypervisor...25 Disk Copying Features...28 Important z/vm Numbers and Set Up Configuration...29 Number of minidisk pools used by WCA...29 z/vm Websphere HV image size...30 Disk requirement for a VM guest...30 Size for minidisk_pool_for_cache...30 Size for minidisk_pool_for_vms...30 Physical Memory size required for a z/vm system...30 Number of CPUs (IFLs) required for a z/vm system...31 Number of z/vm systems managed by a WCA...31 Amount of time it takes to deploy a VM...31 Additional Information...32 Related documentation...32 Copyright IBM Corp All Rights Reserved. Page 2 of 34

3 Notices...32 Trademarks...34 Copyright IBM Corp All Rights Reserved. Page 3 of 34

4 Introduction Part 1 describes the required z/vm setup for IBM Workload Deployer provisioning on Linux on System z. Here is an outline of the steps: Update the System Configuration Update the TCP/IP Configuration Update the z/vm system including VM:Secure Create the Linux master system Install and run the zensemble RPM Systems that have RACF enabled require additional setup by the security administrator. Planning Required resources The following resources are required for setting up the z/vm system for IBM Workload Deployer. Minidisk pool for provisioning Linux guests and optionally for caching images for deployments Recommend two pools with the caching option enabled OSA Read/Write/Data addresses for TCP/IP connectivity IP Address for TCP/IP stack Dedicated OSA for Layer 2 or Layer 3 VSWITCH Guest LAN for communication between the Linux master system and z/vm socket IP Subnet for provisioned guests and DNS for name resolution DASD for additional SPOOL and PAGE datasets (as needed) Required software z/vm 5.4 with DIRM enabled Service Level 1003 for z/vm 5.4 or greater APAR VM64899 z/vm 6.1 with DIRM enabled Service Level 1003 for z/vm 6.1 or greater APAR VM64822 Linux on System z s390-tools RACF for z/vm (optional) z/vm TCP/IP VSMPROXY, VSMWORK1-3, VSMREQIN and and VSMREQIU SLES 10 Linux on System z (or higher) for the Linux master system There is a known problem with the Image Extension feature using SLES11. If you are plan to use the Image Extension feature of IWD, you are required to use SLES10. Copyright IBM Corp All Rights Reserved. Page 4 of 34

5 z/vm system configuration The z/vm system will need to be customized as part of the initial setup. There are a number of configuration steps which need to be completed. The following section describes the requirements. Note: Directions for updating the SYSTEM CONFIG file can be found in z/vm CP Planning and Administration Guide. Refer to this publication if there is any question in your mind about what you are changing. Mistakes made in this file can have serious repercussions on the usability of the system. The SYSTEM CONFIG file contains the primary system definitions used when CP is started (IPLed). All of the information needed to configure CP statically comes from this file. The SYSTEM CONFIG file resides in the same location as the bootable CP kernel. Update SYSTEM CONFIG from the MAINT guest which requires system administrator privileges. Accessing the SYSTEM CONFIG File Perform the following steps to release the primary parm disk: 1. Release the PARM disk from CP cprelease a 2. Access the primary parm disk (MAINT s CF1 disk) link maint cf1 cf1 mr access cf1 z 3. Edit the SYSTEM CONFIG file xedit system config a System DASD Page and Spool Disks In order to improve system performance for z/vm, we recommend additional PAGE and SPOOL datasets. The amount of additional space will vary customer to customer and should be monitored. MOD3-3390s are the recommended type of DASD to use for both SPOOL and PAGE datasets. Use the command CPFMTXA to format the disks as type PAGE or SPOOL and make sure to provide a unique label for each disk you format (540PG1-540PG5 for example). Below is an example of the CP_Owned section of the SYSTEM CONFIG. /**********************************************************************/ /* CP_Owned Volume Statements */ /**********************************************************************/ CP_Owned Slot 1 540RES CP_Owned Slot 2 540SPL CP_Owned Slot 3 540SP1 CP_Owned Slot 4 540PG1 CP_Owned Slot 5 540PG2 CP_Owned Slot 6 540PG3 CP_Owned Slot 7 540W01 CP_Owned Slot 8 540W02 CP_Owned Slot 10 RESERVED Copyright IBM Corp All Rights Reserved. Page 5 of 34

6 To add new CP owned volumes to the system, add additional slots with the correct volume labels. Add additional reserved slots so that page volumes can be dynamically added to the system. Make sure to increment the slot number. Below is the example of the updated CP_Owned volumes. We have added page volume 540PG4-540PG5 and added three RESERVED slots. /**********************************************************************/ /* CP_Owned Volume Statements */ /**********************************************************************/ CP_Owned Slot 1 540RES CP_Owned Slot 2 540SPL CP_Owned Slot 3 540SP1 CP_Owned Slot 4 540PG1 CP_Owned Slot 5 540PG2 CP_Owned Slot 6 540PG3 CP_Owned Slot 7 540W01 CP_Owned Slot 8 540W02 CP_Owned Slot PG4 CP_Owned Slot PG5 CP_Owned Slot 12 RESERVED CP_Owned Slot 13 RESERVED CP_Owned Slot 14 RESERVED *** Important Note: do not re-arrange the volumes in the CP_Owned list. Moving SPOOL volumes will result in the z/vm segments to be deleted and other catastrophic errors. Always append new volumes to the end of the list. System DASD USER Volumes User volumes are required to define minidisks to the z/vm system. This is required for IBM Workload Deployer since all target disks for provisioning VMs will be obtained from dasd pools defined in the EXTENT CONTROL file. DASDPOOL is a group of minidisks managed by DIRM and the z/vm system. All image disks provided by IBM Workload Deployer HV Edition are defined as MOD9-3390s. This will work fine for most functions except disk extensions. For this feature, we would recommend using MOD27s or greater when defining the minidisks. Use the CPFMTXA command to format the minidisks for the dasd pool. As a shortcut, you can format all the minidisks with the same first two characters (CBxxxx where xxxx is the DASD address). This will allow you to use a wildcard when defining the User_Volume_List statement in the SYSTEM CONFIG. /**********************************************************************/ /* User_Volume_List */ /**********************************************************************/ USER_VOLUME_LIST CB* /* All IBM Workload Deployer Minidisks */ Also verify DASD addresses are marked ONLINE at IPL. Copyright IBM Corp All Rights Reserved. Page 6 of 34

7 z/vm Networking Options There are a minimum of two network definitions required in the SYSTEM CONFIG MAPLAN and VSWITCH. The types of networking options used are limited to these examples. MAPLAN The MAPLAN is used to allow communication between the Linux master system and the VSMSERVE application in the TCP/IP stack. This is a guest lan and has no external adapters. This becomes a secure connection by limiting the number of connections to two and allowing access to only TCP/IP and the Linux Master System. MAPLAN QDIO Example DEFINE LAN MAPLAN OWNERID SYSTEM MAXCONN 2 RESTRICTED TYPE QDIO IP MODIFY LAN MAPLAN OWNERID SYSTEM GRANT TCPIP MODIFY LAN MAPLAN OWNERID SYSTEM GRANT <Linux_Master_System> MAPLAN Hipersocket Example DEFINE LAN MAPLAN OWNERID SYSTEM MAXCONN 2 RESTRICTED TYPE HIPER IP MODIFY LAN MAPLAN OWNERID SYSTEM GRANT TCPIP MODIFY LAN MAPLAN OWNERID SYSTEM GRANT <Linux_Master_System> VSWITCH The VSWITCH is used for external communications. The VSWITCH can be Layer 2 or Layer 3 and VLAN support is optional. VSWITCH virtualizes a single OSA adapter or multiple OSAs can be aggregated using LACP to provide redundancy, failover and additional bandwidth if desired. Network definitions for the Linux master system must be in the main SYSTEM CONFIG file. The z/vm guests provisioned using the IBM Workload Deployer will have required definitions added as part of the z/vm directory entry. By not coding CON CONTROLLER, we accept the fact that the default owners DTCVSW1 and DTCVSW2 will be used. These guests should be added to the AUTOLOG or AUTOLOG1 PROFILE EXEC so the VSWITCH definitions are active after IPLs. Layer 2 VLAN No VLAN Support DEFINE VSWITCH <name> RDEV <OSA_Addr> ETH MODIFY VSWITCH <name> GRANT <Linux_Master_System> Layer 2 VLAN With VLAN Support DEFINE VSWITCH <name> RDEV <OSA_Addr> ETH VLAN <def_vlan> NAT <native_vlan> MODIFY VSWITCH <name> GRANT <Linux_Master_System> VLAN <number> Layer 3 VLAN No VLAN Support DEFINE VSWITCH <name> RDEV <OSA_Addr> MODIFY VSWITCH <name> GRANT <Linux_Master_System> Copyright IBM Corp All Rights Reserved. Page 7 of 34

8 Layer 3 VLAN With VLAN Support DEFINE VSWITCH <name> RDEV <OSA_Addr> VLAN <def_vlan> NAT <native_vlan> MODIFY VSWITCH <name> GRANT <Linux_Master_System> Adding the OSA link aggregation feature to any of the networking options will provide fail-over support and increased bandwidth. Layer 3 using Link Aggregation DEFINE VSWITCH <name> RDEV <OSA_Addr1> <OSA_Addr2> <OSA_Addr3> Modifying Features The FEATURES statement in SYSTEM CONFIG allows you to modify attributes associated with the running system at IPL time. Allow Password on Commands The PASSWORDS_on_CMDS feature tells CP which commands allow passwords. Passwords_on_Cmds, Autolog yes, Link yes, Logon yes, Enable System Shutdown The Disconnect_Timeout feature controls whether and when a virtual machine is logged off after it has been forced to disconnect. You will turn this feature off, so that any virtual machine that has been forced to disconnect will not be logged off. Add the following option to the Features Statement: Disconnect_Timeout off The ShutdownTime and Signal ShutdownTime features enable a virtual machine to register with CP to receive a shutdown signal when z/vm is shutting down. CP waits to shut itself down until the time interval (in seconds) is exceeded, or all of the virtual machines enabled for the signal shutdown have reported a successful shutdown. Linux distributions support this function, which allows Linux to shut down cleanly before z/vm shuts down. Add the following line after the Features statement. Set, ShutdownTime 30, Signal ShutdownTime 500 Copyright IBM Corp All Rights Reserved. Page 8 of 34

9 Custom User Classes The following commands need to be added to allow the Linux master system to manage and update the virtual network devices. /********************************************************************/ /* IBM PRIVCLASS SETUP */ /********************************************************************/ MODIFY CMD SET SUBC VSWITCH IBMCLASS B PRIVCLASS BT MODIFY CMD QUERY SUBC * IBMCLASS B PRIVCLASS BT MODIFY CMD IND IBMCLASS E PRIVCLASS ET MODIFY CMD QUERY SUBC * IBMCLASS G PRIVCLASS GT MODIFY CMD LINK IBMCLASS G PRIVCLASS GT Restore z/vm Parm Disk Perform the following steps to release the primary parm disk: 1. Release the PARM disk from CP release z (det 2. Access the primary parm disk (MAINT s CF1 disk) link * cf1 cf1 rr 3. Edit the SYSTEM CONFIG file access maint cf1 a sr Completing the Setup Once all the changes have been implemented, you will need to IPL the z/vm LPAR to pick up the changes. Copyright IBM Corp All Rights Reserved. Page 9 of 34

10 Removing RPC Support (optional) If you are migrating from WebSphere Cloudburst Appliance or earlier, you will need to convert the system from RPC support to SMAPI sockets. RPC support removal can be done by simply removing the PORTMAP and VSMSERVE statements from the TCP/IP profile definitions and ensuring that neither PORTMAP or VSMSERVE are started by the AUTOLOG guests. Remove RPC AUTOLOG statements Stop the PORTMAP and VSMSERVER from logging on during the TCP/IP startup. Remove or comment out the following statements: AUTOLOG ; PORTMAP 0 ; PORTMAP SERVER ; VSMSERVE 0 ; VM SMAPI SERVER ENDAUTOLOG Removing RPC PORT statements You will also need to remove or comment out the port statements for PORTMAP and VSMSERVE. PORTMAP Uses port 111 and listens on both TCP and UDP sockets. PORT 111 TCP PORTMAP ; Portmap Server 111 UDP PORTMAP ; Portmap Server TCP VSMSERVE ; VM SMAPI SERVER When completed, stop and restart the TCP/IP stack by logging off the ID and logging back on. From MAINT, issue the command q names to make sure that both PORTMAP and VSMSERVE are not in the output. Removing RPC PORT statements Check to make sure that VSMSERVE and PORTMAP are not included in the AUTOLOGx ID s profile execs. If these are present, remove these statements. Copyright IBM Corp All Rights Reserved. Page 10 of 34

11 Updating z/vm TCP/IP Configuration For the purpose of this document, we will assume the TCP/IP stack for z/vm has been setup and you have IP connectivity to the z/vm LPAR. This section will deal with the configuration and setup to allow the TCP/IP stack to communicate socket server thus allowing the Linux master system to issue commands to the z/vm system. It is standard practice to use the TCPMAINT guest to edit the TCP/IP configuration. The definitions for the TCP/IP stack reside on the TCPMAINT 198 disk. The TCPMAINT guest can be logged on directly or you can link to the TCPMAINT 198 disk from MAINT or other approved guest. Unlike RPC support, there is no requirement for PORTMAP or VSMSERVE to be defined on the TCP/IP stack. Add the MAPLAN NIC to the TCP/IP Stack The first step is to define the NIC for MAPLAN to the TCP/IP stack. This is the private network between the Linux master system and the TCP/IP stack. In this example, we will define NIC C300 to the system. 1. Logon to TCPMAINT or access TCPMAINT 198 disk from an authorized ID. You will need to determine how the TCPMAINT 198 disk is accessed on the TCPMAINT guest using the the q disk command. This file is usually on the D disk. 2. Xedit the SYSTEM DTCPARMS D and add the following statements: :NICK.TCPIP :TYPE.SERVER :CLASS.STACK :VNIC.C300 TO SYSTEM MAPLAN 3. Enter the command FILE to save and exit the file. Configuring Networking for the MAPLAN NIC Now that the MAPLAN NIC is defined to the TCPIP guest, we must add the device to the TCP/IP profile. In the preceding section, we defined device C300 as the NIC for accessing MAPLAN. We will use this address when defining the DEVICE statement. The PORTNAME value is arbitrary so we added the portname NICC300. QDIO Device DEVICE MAPLAN OSD C300 PORTNAME NICC300 NONROUTER LINK MAPLAND QDIOETHERNET MAPLAN MTU 1500 START MAPLAN Hipersocket Device DEVICE HIPR1 HIPERS C300 PORTNAME HIPER1 LINK QDIO1 QDIOIP HIPR1 MTU 8192 START MAPLAN Add the IP address for the MAPLAND link to the HOME statement MAPLAND Copyright IBM Corp All Rights Reserved. Page 11 of 34

12 Completing the Setup Now that the required changes have been made to the TCP/IP profile, save the changes and restart the TCP/IP stack. 1. Enter the command FILE to save and exit the file. 2. Logon to MAINT from the master console. This console would be the same console you use to IPL z/vm. It is important to use this console since you will be recycling TCP/IP in the next step. If you do not have this console, do not proceed until you do. 3. From MAINT, issue the following commands: FORCE TCPIP IMMED (This command will terminate the TCP/IP guest) XAUTOLOG TCPIP (This command will restart the TCP/IP guest ) Copyright IBM Corp All Rights Reserved. Page 12 of 34

13 Customizing the z/vm Environment for Sockets The following section will detail the steps required to customize the z/vm environment for socket support. Updating the worker and requestor IDs in DIRM Update DIRM to allow worker IDs to pass commands without password Update the profile exec on the requestor and worker IDs Update the VSMWORK1 environment Detailed information regarding the setup can be found in the zvm 5.4 or zvm 6.1 SMAPI Programming Guides (Chapter 3 & 4). Updating Directory Entries for Worker and Requestor IDs The following IDs are the required guests for SMAPI. As part of the default directory entry, the VSMWORK1-3, VSMPROXY, VSMREQIN and VSMREQIU entries should all reside in the DIRM database. Each set of IDs has unique customizations required as described below. Requestor IDs Requestor IDs are the VSMPROXY, VSMREQIN and VSMREQIU entries. Each of these IDs needs to be modified as follows: VSMPROXY MACHINE ESA IUCV ANY MSGLIMIT 255 IUCV *SCLP IUCV *VMEVENT VSMREQIN IUCV ANY MSGLIMIT 255 VSMREQIU IUCV ALLOW MSGLIMIT 255 Note that multiple CPs are not allowed for the requestor IDs. A sample profile exec exists on each 191 disk for the requestor IDs. The sample was taken from VSMREQIN SAMPPROF on MAINT s 193 disk. Copyright IBM Corp All Rights Reserved. Page 13 of 34

14 Work IDs Work IDs are the VSMWORK1 thru VSMWORK3. Each of the IDs is configured the same way. VSMWORK1-3 MACHINE ESA IUCV ANY MSGLIMIT 255 Note: Mulitple CPs are not allowed for the work IDs. A sample profile exec exists on each 191 disk for the requestor IDs. The sample was taken from VSMWORK1 SAMPPROF on MAINT s 193 disk. Update the Profile EXECs There are sample PROFILE EXECs provided for the requestor and worker IDs. These are located on MAINT 193s disk. Requestor IDs 1. Logon to each of the VSMREQIN, VSMREQIU and VSMPROXY. 2. Issue command #cp ipl cms and at the VM READ prompt, enter acc (noprof on each ID. 3. Issue command link maint rr and acc 193 L 4. Rename the profile exec on the a-disk to a new name 5. Copy the file VSMREQIN SAMPPROF L to PROFILE EXEC A 6. Logoff all the IDs. Worker IDs 1. Logon to each of the VSMWORK1-VSMWORKx IDs 2. Issue command #cp ipl cms and at the VM READ prompt, enter acc (noprof on each ID. 3. Issue command link maint rr and acc 193 L 4. Rename the profile exec on the a-disk to a new name 5. Copy the file VSMWORK1 SAMPPROF L to PROFILE EXEC A 6. Logoff VSMWORK2-VSMWORKx 7. On VSMWORK1-x, add the following statements to the PROFILE EXEC EXEC DIRMAINT EXECLOAD EXEC DIRMAINT DEFAULT MENUS DISABLED EXEC DIRMAINT DEFAULT PROMPTS DISABLED 8. Enter the command dirm needpass no on each of the VSMWORKx IDs. 9. Leaving VSMWORK1 in the current state, continue to the next section. Copyright IBM Corp All Rights Reserved. Page 14 of 34

15 Customizing the SMAPI Socket Environment From the VSMWORK1 ID, enter the following commands to setup the shared file pool: SET FILEPOOL VMSYS: ACCESS VMSYS:VSMWORK1.DATA A(FORCERW ACCESS VMSYS:VSMWORK1. B (FORCERW ACCESS 191 D VMSWORK1 AUTHLIST In order to protect MAINT password, IBM Workload Deployer will use MAPAUTH as the surrogate ID to pass the commands. Locate the disk where the VSMWORK1 AUTHLIST resides (typically B ). By default, VSMWORK1 and MAINT will already be authorized. Replicate the ID MAINT and change the name to MAPAUTH. Make sure to replicate the line because the LRECL is 195 and the statements in the file are positional. Once updated, save the file. DMSSISVR NAMES The DMSSISRV NAMES file, by default, resides on the proper disk. This file can be edited to customize the AF_INET port for the VSMREQIN server if the default is not desired. DMSSICNF COPY A default copy of the DMSSICNF COPY file resides on the MAINT 193 disk. Copy this file to the same disk where VSMWORK1 AUTHLIST resides (typically B ). Edit the DMSSICNF COPY file on the B disk. All values can be defaulted. If you have RACF enabled on the zvm system, you will want to review additional setup steps required in the RACF section of this document. If not, you are ready to issue #cp I cms, the VSMWORK1 ID should successfully IPL and start the other two worker IDs (VSMWORK2 and VSMWORK3) as well as the requestor IDs (VSMREQIN, VSMREQIU and VSMPROXY). The command #cp q names will show the following names as active: Ready; T=0.01/ :51:55 VSMPROXY - DSC, VSMREQIU - DSC, VSMREQIN - DSC, VSMWORK3 - DSC VSMWORK2 - DSC, VSMWORK1 - DSC, MAPSRV19 - DSC, FTPSERVE - DSC DATAMOVE - DSC, DIRMAINT - DSC, DTCVSW2 - DSC, DTCVSW1 - DSC VMSERVR - DSC, VMSERVU - DSC, VMSERVS - DSC, TCPIP - DSC AUTOLOG2 - DSC, RACFVM - DSC, OPERSYMP - DSC, AUTOLOG1 - DSC DISKACNT - DSC, EREP - DSC, OPERATOR - DSC, MAINT -L0008 VSM - TCPIP Ready; T=0.01/ :51:55 Copyright IBM Corp All Rights Reserved. Page 15 of 34

16 Update VSMWORK1 and Add Sample RACF Exit If your system has RACF definitions, then following additional steps need to be taken to authorize VSMWORKx guest to pass commands: 1. Copy /opt/ibm/zensemble/zvm-scripts/wcasecpc.exec to Maint's 193 disk 2. On VSMWORK1, edit DMSSIUSR NAMES and add the following statement to invoke the sample RACF exit. :nick.security_manager_permit :program.wcasecpc 3. On VSMWORK1, edit DMSSICNF COPY and change ulong to the following: ULONG = 'SECURITY_MANAGER_PERMIT' Copyright IBM Corp All Rights Reserved. Page 16 of 34

17 Customizing the z/vm Environment There are a number of other changes which need to be made to complete the customization of z/vm for Cloudburst. These are broken down into 6 groups: 1. Customization of DIRM 2. Allocation Groups or DASD pools 3. Creation of Linux default directory entry 4. Creation of Linux prototype directory entry 5. Creation of the MAPAUTH Guest 6. Authorization of MAPAUTH, VSMWORKx and VSMPROXY to DIRM The following sections will cover these topics. Customizing DIRM DIRM needs to be enabled as part of the z/vm setup. In addition to the base configuration of DIRM, the CONFIGxx DATADVH file must be customized to allow VSMSERVE to talk to DIRMAINT. The z/vm system can contain multiple CONFIGxx DATADVH files. The files are read by the system in reverse alphabetical order. It is recommended to name the file CONFIGZZ DATADVH to ensure your required changes are picked up first. The following steps will create a customized CONFIGZZ DATADVH file In order to authorize VSMSERVE to communicate to DIRMAINT, do the following: 1. Retrieve the CONFIGZZ DATADVH file from DIRM. If the file is not present, you will receive a RC=28 error message. If you receive this message skip to step #3. dirm send configzz datadvh 2. From the RDRLIST, receive the file. If necessary, use the (replace option 3. Create or edit the CONFIGZZ DATADVH member xedit configzz datadvh a 4. The following two statements need to be added to the CONFIGZZ DATADVH to allow VSMSERVE to communicate to DIRMAINT directly. ALLOW_ASUSER_NOPASS_FROM= VSMWORK1 * ALLOW_ASUSER_NOPASS_FROM= VSMWORK2 * ALLOW_ASUSER_NOPASS_FROM= VSMWORK3 * ALLOW_ASUSER_NOPASS_FROM= VSMPROXY * 5. Add or verify the following entries are present in the CONFIGZZ DATADVH Copyright IBM Corp All Rights Reserved. Page 17 of 34

18 RUNMODE= OPERATIONAL ONLINE= IMMED DASD_ALLOCATE= EXACT_FF DATAMOVE_MACHINE= DATAMOVE * * DVHDXD_FLASHCOPY_BEHAVIOR= 2 DVHDXD_FLASHCOPY_COMPLETION_WAIT= 0 0 DM_MAXIMUM_RETRIES= 60 MAXIMUM_UNASSIGNED_WORKUNITS= 100 RACF_RDEFINE_VMRDR_DEFAULTS= UACC(UPDATE) AUDIT(FAILURES(READ)) 6. Save and File the changes. 7. Issue the following commands in order to update DIRM with the changes dirm file configzz datadvh dirm rldc dirm rldd dirm rlde 8. Verify all DIRM commands complete successfully. Allocation Groups Allocation groups are used to define DASDPOOLs to the z/vm system. The dasd pool is defined in two sections regions and groups. Regions consist of the pre-defined minidisks to be used by the various dasd pools (Groups). The regions are defined using a region ID value. All DASD must be formatted as a minidisk and defined in the SYSTEM CONFIG as user_volumes. In our SYSTEM CONFIG example, all of the DASD for the allocation group had a volume label of CBxxxx. For this example, we will use CB2001-CB2005 as our minidisks and these are of type MOD Retrieve the EXTENT CONTROL file. Dirm send extent control Receive xxx = = a (replace 2. Xedit the EXTENT CONTROL file and add the five minidisks to the REGION section. Each disk is given a unique ID. :REGIONS. *RegionId VolSer RegStart RegEnd Dev-Type Comments CB CB CB CB CB :END. 3. Designate the disks to the appropriate pools. In this example, 4 disks will be used as targets for the provisioning and one will be used to cache the installation images. :GROUPS. *GroupName RegionList POOL0 POOL POOL1 POOL :END. 4. Since the MOD54 is an unknown disk type to DIRM, we need to create a custom definition. Copyright IBM Corp All Rights Reserved. Page 18 of 34

19 :DEFAULTS. *DASDType Max-Size :END. 5. Send the EXTENT CONTROL file back to DIRM and activate it DIRM FILE EXTENT CONTROL A DIRM RLDE ALL Default Directory Entries Default directory entries are used to define common definitions for all provisioned guests. This entry will be referenced by the Linux prototype directory entry. Create a file called LINUX DIRECT using Xedit. Below is a sample of a default directory entry for Linux. PROFILE LINUX CLASS G STORAGE 512M MAXSTORAGE 2047M IPL 201 IUCV ALLOW MACHINE ESA OPTION QUICKDSP CONSOLE T SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A LINK MAINT RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR LINK TCPMAINT RR Save and exit the file. Add the new profile using the DIRM ADD command dirm add linux Prototype Directory Entries A directory prototype will allow provisioned guests to all share common statements. Multiple directory prototypes can be created to support as many configurations as are needed. 1. Create a file called LINUX PROTODIR A: USER LINUX NOLOG 512M 2G G INCLUDE LINUX 2. Add the prototype entry to DirMAINT dirm file linux protodir Create MAPAUTH Guest MAPAUTH is the Class A user that issues restricted system commands thru the SMAPI. Copyright IBM Corp All Rights Reserved. Page 19 of 34

20 Use Xedit to create the MAPAUTH DIRECT file. The following is an example: USER MAPAUTH PASSW0RD 32M 32M G INCLUDE IBMDFLT Save the file and add the guest to the o the z/vm user directory. dirm add mapauth Assigning Authorizations The following statement need to be added to the AUTHFOR CONTROL file to assign the appropriate user classes to the VSMWORKx, VSMPROXY and MAPAUTH guests. 1. Get the AUTHFOR CONTROL file from DIRM 2. XEDIT the file and add the following statements. ALL MAPAUTH * ALL MAPAUTH * ALL MAPSRV12 * ALL MAPSRV12 * ALL VSMWORK1 * ALL VSMWORK1 * ALL VSMWORK2 * ALL VSMWORK2 * ALL VSMWORK3 * ALL VSMWORK3 * ALL VSMPROXY * ALL VSMPROXY * 140A ADGHMOPS 150A ADGHMOPS 140A ADGHMOPS 150A ADGHMOPS 140A ADGHMOPS 150A ADGHMOPS 140A ADGHMOPS 150A ADGHMOPS 140A ADGHMOPS 150A ADGHMOPS 140A ADGHMOPS 150A ADGHMOPS 3. Save the file 4. Activate the changes Dirm rldc Dirm rldd Disk Space for DIRMAINT If logging is required for DIRMAINT, you will want to increase the amount of disk space for the 1AA and 155 disks. Failure to do so will result in DIRMAINT shutting down. The size of the minidisk and the retention period of the logs is determined on a per customer basis so no recommended defaults are provided. The other option to restricting the logging on the 1AA disk is to disable logging by commenting out the following statements in the CONFIGxx DATADVH / MESSAGE_LOGGING_FILETYPE= TRANSLOG / MESSAGE_LOGGING_FILTER_EXIT= DVHXLF EXEC / MESSAGE_LOG_RETENTION_PERIOD= 1 (DAYS) This is a choice which needs to be made by the z/vm System Administrator. Copyright IBM Corp All Rights Reserved. Page 20 of 34

21 Customizing DATAMOVE The default DATAMOVE DATADVH also needs to be customized. The following message appears in the DATAMOVE DATADVH file: * The following entry will cause the DATAMOVE server to wake up every * 30 minutes and review the DVHDMCTL QUEUE file for any pending work * which can be processed. 30 minutes is a sample time only. The * interval should be adjusted to best meet the performance and * usability characteristics for your system. ==/==/== +00:30:0 00/00/00 DMVCTL WAKEUP This last line needs to be customized and should be tuned. For WebSphere Cloudburst Appliance, we have changed this value to 1 minute to allow DATAMOVE to be active and waiting for work. To customize this value, you will need to do the following steps: 1. Retrieve the datamove datadvh file dirm send datamove datadvh 2. Update the VMCTL WAKEUP line ==/==/== +00:01:0 00/00/00 DMVCTL WAKEUP 3. File the changed file dirm file datamove datadvh 4. Activate the changes Dirm rldc Dirm rldd 5. Stop and Restart DATAMOVE Force datamove immed Xautolog datamove Copyright IBM Corp All Rights Reserved. Page 21 of 34

22 Creating the Linux Master System The Linux master system is a SLES Linux guest (SLES10 SP2) which will be used as the entry point into the z/vm LPAR. The RPM for IBM Workload Deployer will be installed on this system and using the MAPAUTH ID will be allowed to issue SMAPI commands to DIRMAINT. There are a number of steps to creating the MAP ID. This section will take you thru: 1. Creating the MAP directory entry 2. Installing Linux and the required pre-requisites 3. Configuring the connection to VSMSERVE 4. Installing the IBM Workload Deployer RPM. Creating the Linux Master System Directory Entry (MAPSRV) The Linux master system is a SLES10 Linux which will be used as the entry point into the z/vm LPAR. The directory entry will have the following statements coded. An example is also provided. The LINUX DIRECT has been referenced by the INCLUDE statement to pick up the default statements The example below has a dedicated volume for the Linux OS. This can also be a mini-disk (commented out ). In either case, the volume is mounted as virtual DASD address 107 and will be IPL d at startup. There are two NICDEF statements one for the external network and one for the MAPLAN to talk to VSMSERVE. It is recommended that the size of the disk(s) used to create the Linux master system be a total of at least 30gb. This will provide the required disk space required to store the OVAs. In this example below, we are using a MOD The MAPSRV DIRECT A USER MAPSRV PASSW0RD 512M 1G GT INCLUDE LINUX IPL 107 MACHINE ESA OPTION LNKNOPAS LANG AMENG * DEDICATE 0107 <real_dasd_addr> * MDISK CBxxxx MR <password>< password>< password> * NICDEF <vswitch_vdev> TYPE QDIO LAN SYSTEM <vswitch_name> NICDEF <maplan_vdev> TYPE QDIO LAN SYSTEM MAPLAN Save the file and add the guest to the o the z/vm user directory. dirm add mapsrv Copyright IBM Corp All Rights Reserved. Page 22 of 34

23 Installing the OS for the Linux Master System Instructions for installing SuSE Linux Enterprise Server 10 for System z can be found at the following site: When installing the Linux operating system, please make sure to install the following pre-requisites perl-libwww-perl perl-html-parser perl-html-tagset perl-xml-dom perl-xml-generator perl-xml-regexp perl-xml-writer Once the installation is complete, we need to add an entry to the /etc/sysconfig/kernel. Edit this file and add the following statement: MODULES_LOADED_ON_BOOT="vmcp" Save the changes and reboot the system. Configuring the Guest LAN Connection to TCPIP When the Linux master system has rebooted, you will need to SSH to the server and configure the connection which provides access to the MAPLAN. This will allow the MAP ID to communicate with the VSMSERVE application in the TCP/IP stack. The following steps will configure this interface. 1. From an SSH console to the Linux master system, start Yast. 2. Go to Network Devices Network Card 3. Use Traditional Method using ifup and then Next 4. Tab to device 0.0.C300 and then tab to Edit 5. Tab to Static IP Address Setup and use the IP address and mask of Tab down to Advanced Hardware Details. 7. Tab to OK and you will receive a message about chanids 0.0.c c c302 accept this by hitting OK. 8. Select Next Finish Quit The resulting ifconfig will show ETH1 setup correctly to talk to VSMSERVE. Mapsrv:/opt/ibm/zensemble # ifconfig eth1 eth1 Link encap:ethernet HWaddr 02:00:27:00:00:04 inet addr: Bcast: Mask: inet6 addr: fe80::200:2700:200:4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 RX packets:66 errors:0 dropped:0 overruns:0 frame:0 TX packets:77 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:10628 (10.3 Kb) TX bytes:5560 (5.4 Kb) Copyright IBM Corp All Rights Reserved. Page 23 of 34

24 The z/vm Hypervisor Creating a z/vm Cloud Group To enable IBM Workload Deployer to provision/manage Linux VMs on a z/vm system, it is necessary to install zensemble RPM. This RPM can be downloaded from the appliance directly. Therefore, it is necessary to define the Cloud Group first. From the IBM Workload Deployer user interface, go to Cloud Cloud Groups. Define Cloud by clicking on the green + sign and providing a descriptive name. From the pull down menu, you will select the hypervisor type of z/vm. Once a Cloud Group has been defined, you will be able to download the agent. Click on the Download Agent link. You will be prompted to receive the RPM file. This file must then be transferred to the Linux master system to be installed. Installing the z/vm Agent To install the RPM, copy the file to the Linux master system and invoke the RPM using the rpm ivh command: Mapsrv:/common/Cloudburst-Beta/rpms # rpm -ivh zensemble-x.x.x.x-y.s390x.rpm Preparing... ########################################### [100%] 1:zensemble ########################################### [100%] Please run /opt/ibm/zensemble/setproperties before you add this hypervisor to Cloudburst If the zensemble RPM is already installed, you will receive a similar error: mapsrv:/ # rpm -ivh zensemble-x.x.x.x-y.s390x.rpm Preparing... ########################################### [100%] file /opt/ibm/zensemble/functions from install of zensemble-x.x.x.x-y conflicts with file from package zensemble- x.x.x.x-z Use the rpm e command to remove the existing RPM: Copyright IBM Corp All Rights Reserved. Page 24 of 34

25 mapsrv:/ # rpm -e zensemble- x.x.x.x-z You can then repeat the install procedure. Running Discovery on the z/vm Hypervisor Once the RPM has successfully installed, you are required to run the setproperties.sh script located in the /opt/ibm/zensemble directory. This script will prompt you for information necessary to allow IBM Workload Deployer to instantiate VMs on this hypervisor. The following is output from the script being run: mapsrv:/opt/ibm/zensemble #./setproperties Verifying vmcp...success Enter the IP Address of the SMAPI management server [ ]: Verifying ip address...success Enter the TCP port of the SMAPI management server [44444]: Enter the User id to logon to the SMAPI management server [mapauth]: Enter the password logon to the SMAPI management server: Verifying vsmserve information...success Enter the storage over-commit factor (1 : no over commit -- max 10) [1]: 3 Use vswitch NS40VSW1 (y/n) [y]: y The vswitch is vlan aware. Need configuration to identify vlan to use. Hit Enter to continue Networks discovered from vswitch NS40VSW Name:NS40VSW Vlan: Name:NS40VSW IP: Vlan:0400 (U)se a discovered network (D)efine a custom network Choice: u Select 1..2 from discovered networks. anything else to go back: 2 Networks currently defined for vswitch NS40VSW Name:NS40VSW IP: Vlan:0400 Networks discovered from vswitch NS40VSW Name:NS40VSW Vlan: Name:NS40VSW IP: Vlan:0400 (U)se a discovered network (D)efine a custom network (R)emove a network definition (F)inish network configuration for vswitch Choice: f Enter the default prototype to build guests on [Linux]: Verifying proto...success Enter the naming convention for new guests. Trailing Xs will be replaced with numbers [WCAXXXXX]: WCA40XXX Enter the poolname to use [POOL0]: Verifying pool...success Should mini disks be used to cache images (y/n) [y]: Enter the poolname to use for cache [POOL0]: POOL1 Verifying pool...success Enter password for minidisks owned by the master system: Read-Only password for minidisk: Write-Only password for minidisk: Multi-Read password for minidisk: Configuration Finished Hit Enter to continue Copyright IBM Corp All Rights Reserved. Page 25 of 34

26 The following table will explain the prompts and associated answers: Verify CP Prompt or Message Enter the IP Address of the SMAPI management server [ ]: Verifying ip address...success Enter the TCP port of the SMAPI management server [44444]: Enter the User id to logon to the SMAPI management server [mapauth]: Enter the password logon to the SMAPI management server: Verifying vsmserve information...success Enter the storage over-commit factor (1 : no over commit -- max 10) [1]: 5 Use vswitch NS40VSW1 (y/n) [y]: y Networks discovered from vswitch NS40VSW Name:NS40VSW Vlan: Name:NS40VSW IP: Vlan:0400 (U)se a discovered network (D)efine a custom network (R)emove a network definition (F)inish network configuration for vswitch Enter the default prototype to build guests on [Linux]: Enter the naming convention for new guests. Trailing Xs will be replaced with numbers [WCAXXXXX]: WCA40XXX Enter the poolname to use [POOL0]: Verifying pool...success Should mini disks be used to cache images (y/n) [y]: Enter the poolname to use for cache [POOL0]: POOL1 Verifying pool...success Enter password for minidisks owned by the master system: Read-Only password for minidisk: Write-Only password for minidisk: Multi-Read password for minidisk: Definition Ensure the VMCP module is defined in /etc/sysconfig/kernel IP address of MAPLAN defined in the TCP/IP stack. This is the address associated with the socket server. Checks to see if IP address is reachable Prompts for port. Default port is for sockets. Prompts for MAPAUTH z/vm Guest name. MAPAUTH is the default. This is the password of the MAPAUTH ID. Verifies the logon to MAPAUTH Used to calculate storage presented to WCA. Allows admin to over-commit storage on z/vm and use paging. Discovers and prompts for VSWITCHs present on the system. If VLAN is not supported, then you would move to the next prompt. If you have VLAN support, you will be prompted which VLAN interface(s) to use. You can select multiple VSWITCHs. Select the VSWITCH you want to use by (1) Hitting U and selecting the network you want to define (2) Use D to define your own VLAN network (3) Use R to remove a VLAN interface and (4)Use F to save the selection and move to the next prompt. Enter the name of the Linux prototype directory entry. Default name is Linux. This allows the z/vm administrator to create recognizable z/vm guest names. The XXX in this example will provide 1000 z/vm guest names. Enter the name of the DASD pool defined in the EXTENT CONTROL file for DIRM and CONFIG DASD for VM:Secure. Verifies pool resides in DIRM. If you have two DASD pools defined in the EXTENT CONTROL or CONFIG DASD, you will answer yes to this prompt. Once the files are transferred from the appliance to the Linux master system, these images are copied to minidisks and assigned to the directory entry of the Linux master system. If you have one pool, caching is still possible. Enter the name of the DASD pool defined in the EXTENT CONTROL file for DIRM and CONFIG DASD for VM:Secure. Verifies pool resides in DIRM. Informational message no prompt. Password for read access to the Linux master system minidisks. Password for write access to the Linux master system minidisks. Password for multi-read access to the Linux master system minidisks. The number of shared CPs for the System z CEC. This is required for LMT. For ILMT: Number of physical CPs shared in this LPAR Configuration Finished Hit Enter to continue Execution of the script is completed and properties.xml file has been created. Copyright IBM Corp All Rights Reserved. Page 26 of 34

27 Copyright IBM Corp All Rights Reserved. Page 27 of 34

28 Disk Copying Features The IBM Workload Deployer will transfer the images to the Linux master system. It is a requirement that the Linux master system be defined with at least 30gb of space or have access to a NFS server where the /opt/ibm/zensemble/images library can be soft linked to. If caching is not enabled, then workflows from the IBM Workload Deployer will attach disks to the Linux master system and use the Linux dd command to image the new disks. If caching is being used, the same process above is used to create a master set of disks, but instead of being mounted to the new VM guest, the disks are defined to the Linux master system directory entry. From there, future deployments will be able to skip the linux dd step and will either use flashcopy or ddrcopy to image the disks. Flashcopy is a feature provide with the IBM DS/8000 and isn t available to all customers. If this feature is not available to you, the DDRCOPY EXEC will need to be created on the DATAMOVE machine in order for the imaging process to work. DDRCOPY EXEC /* DDRCOPY */ /* COPIES ONE DISK TO ANOTHER USING DDR */ /* SYNTAX: DDRCOPY SOURCEDISK TARGETDISK <DISKTYPE> */ ADDRESS COMMAND TRACE OFF /* CHECK INPUT */ ARG INADDR OUTADDR TYPE. IF INADDR = '' THEN EXIT 8 IF OUTADDR = '' THEN EXIT 8 IF TYPE = '' THEN TYPE = '3390' 'ERASE DDRCOPY INPUT A' 'MAKEBUF' BUF1 = RC QUEUE ' PROMPTS OFF' QUEUE ' INPUT' INADDR TYPE 'SCRATCH' QUEUE ' OUTPUT' OUTADDR TYPE 'SCRATCH' QUEUE ' SYSPRINT CONS' QUEUE ' COPY ALL' 'EXECIO 5 DISKW DDRCOPY INPUT A' 'DROPBUF' BUF1 'FINIS DDRCOPY INPUT A' /* DO THE DDR COPY USING THE INPUT FILE JUST CREATED */ 'DDR DDRCOPY INPUT A' R = RC /* CLEAN UP */ DONE: 'DROPBUF' BUF1 'ERASE DDRCOPY INPUT A' EXIT R Copyright IBM Corp All Rights Reserved. Page 28 of 34

29 Important z/vm Numbers and Set Up Configuration The following figure shows high level structure of how WCA supports z/vm systems. Linux Master System VM VM SM-API Virtual switch (vswitch) z/vm Linux Master System VM VM SM-API Virtual switch (vswitch) z/vm Number of minidisk pools used by WCA As shown in the figure above, WCA manages a z/vm system (LPAR) by communicating to a Linux Master System (LMS - a special Linux guest). The z/vm system needs to set up following the set up document shipped (or referenced) in the WCA release that supports z/vm. There will be an RPM that needs to be installed in the LMS. Once this RPM installed (in /opt/ibm/zensemble directory), a system administrator can run the script called setproperties to configure resources to be used by WCA. Among these configurations are the names of the two minidisk pools to be used by WCA. One minidisk pool is to be used for allocation of VM disks (referred to as minidisk_pool_for_vms); another disk pool (referred to as minidisk_pool_for_cache) is used for caching disks to enable fast provisioning of VM guests using disk copy (flash copy is used and if not available, ddr disk copy is used). A single minidisk pool can optionally be used for both purposes. As far as caching images, WCA deploys different mechanisms to enable faster provisioning of VM guests. WCA will always cache image files transferred from WCA appliance to a z/vm system. These image files are cached in subdirectory /opt/ibm/zensemble/images. This subdirectory can be mounted on a local disk (i.e., minidisks) which allows faster i/o; or it can be mounted through a remote file system such as NFS (slower option but SCSI storage can be used). The next level of caching is to decompress image disk files and put them on minidisks to be used for flash copy (or ddr); this level of caching is optional and can be specified through setproperties script. Copyright IBM Corp All Rights Reserved. Page 29 of 34

30 z/vm Websphere HV image size Each z/vm Websphere HV image size, tarred and compressed, is about 4 GB. Disk requirement for a VM guest Each Websphere HV image contains 3 disks. One disk (107) is mounted R/W for VM operation. The other 2 disks (108 and 109; 108 contains OS, and 109 contains Websphere Application Server binaries) can be R/O (read only) disks which VMs can link to for sharing code binaries. R/O option enables minimizing usage of minidisks by deployed VM guests. (Note that when a VM is provisioned for creating a new image WCA extend/capture capability all disks must be R/W modes.) Each disk, once decompressed, will require a 3390-mod9 disk which is approximately 7 GB. So, each VM will require 21 GB of disk storage. With R/O option, each VM requires only 7 GB R/W storage (disk 107) while sharing the other 2 disks; therefore consumes 1/3 only of the storage requirements. It is important to keep in mind that with R/O, as the name implies, a VM instance can not change the shared binary disk and therefore can not apply fix patches to it. In order to keep the option to apply emergency fixes to a VM instance, R/W disks should be used in the deployment. Another option is to use WCA extend/capture capability to apply fixes to an image and generate a new image which can be deployed with R/O disks. Size for minidisk_pool_for_cache Depending on the number of images that are in the disk cache, as above, each image contains 3 disks and each disk requires approximately 7 GB (e.g., on a 3390-mod9), for a total of 21 GB ( mod9 s). Similarly, WCA also caches image files as mentioned above. Each file, once untarred and uncompressed (107.img, 108.img, and 109.img respectively), is approximately 7 GB. The image file cache is in subdirectory /opt/ibm/zensemble/images. Size for minidisk_pool_for_vms Depending on the number of VMs to be deployed into a z/vm system and whether shared disk (R/O) is exploited, the size of minidisk_pool_for_vms can vary. If shared disk is used, each VM guest requires 7 GB of R/W disk, versus 21 GB if shared disk is not used. Let s take an example: when 10 VMs are deployed with shared disk, total disk usage is approximately: 10 x 7 GB + 14 GB = 84 GB (14 GB is for 2 shared R/O disks); if shared disk is not used, total disk usage is approximately: 10 x 21 GB = 210 GB. Physical Memory size required for a z/vm system Before discussing the physical memory requirement, it is good to understand how z/vm paging works starting with physical memory, expanding memory, and then disk. When all VM virtual memories fit into physical memory, it is not necessary for z/vm to page. However, as memory is over-committed (total size of VMs virtual memories exceed physical memory), z/vm starts to page to expanding storage (expanded storage is also in the form of physical memory but used exclusively for paging). Once expanded storage is also full, z/vm starts paging to disks, VM performance starts to slow. When setproperties script is run on LMS, a system administrator can set the over-commit ratio for the corresponding z/vm system. The over-commit ratio is used to indicate to WCA placement the available memory that can be allocated to VMs. So if physical memory is 8 GB, and over-commit ratio is 2, WCA will assume 16 GB is available for VM deployment. WCA monitors VM Working Set size (i.e., WS pages) and estimate usage of memory Copyright IBM Corp All Rights Reserved. Page 30 of 34

31 for placement. Each deployed VM has a default memory requirement of 2 GB but can be changed at pattern deployment time. As noted, VM performance starts to slow as paging starts to increase, so it is good to understand VM workload and whether over-commit ratio greater than 1 is to be used. Number of CPUs (IFLs) required for a z/vm system. The number of physical CPUs (IFLs) required for each z/vm system also depends on the VM workload. For instance, if a z/vm system has 2 physical IFLs, and a VM has 2 virtual CPUs and yet the VM workload requires 100 % of CPUs consumption, then putting more than 1 VM on a system will degrade VM performance. However, if a VM workload only consumes 50 % of CPU, then approximately 2 VMs of such workload can be deployed. Therefore, over-committing CPU requires careful consideration of VM workloads. WCA does not dedicate (in z/vm terminology) CPUs to VMs deployed into a z/vm system, VMs have virtual CPUs (specifiable at pattern deployment time) and will share the IFLs that are assigned to z/vm system by System z hypervisor (i.e., PR/SM). Number of z/vm systems managed by a WCA The number of z/vm systems managed by one WCA appliance depends on the number of VMs deployed (all VMs from all patterns). Initial performance tests have shown a single WCA can manage up to 150 VMs deployed across multiple hypervisors (a z/vm system is the same as a hypervisor), additional tests are being conducted. Amount of time it takes to deploy a VM. This time depends on whether or not it is the first time the VM image is to be transferred to a z/vm system. If it is the first time, then additional time is required to: transfer image disks to image file cache; uncompressed image disks and loaded them onto disk cache. The total time to deploy a VM is approximately minutes, depending on network load and system I/O load. If it is not the first time and image is already cached on z/vm system, the time it takes to deploy a VM is much shorter, is approximately minutes. The amount of time to deploy a Virtual System therefore depends on the number of nodes/vms defined for that Virtual System. Copyright IBM Corp All Rights Reserved. Page 31 of 34