Securing a cloud in an IBM z/VM environment
Today’s security requires consistent protection against threats and malware. Enterprises must be flexible while having a secure infrastructure to protect effectively the most valued asset of a company (the data), and their access through the cloud.
Running many distributed servers involves much effort to install, manage, maintain, and provide security for them. To contain this effort, many enterprises are consolidating these servers on IBM LinuxONE by using z/VM as the hypervisor, which takes advantage of the virtualization technologies to use the hardware effectively and to simplify administration tasks.
Implementing the enterprise security policy and following the least privilege principle increases the strength of security in your enterprise cloud.
This chapter describes the security of a Cloud on z/VM environment with its building blocks: z/VM Directory Manager (DirMaint), SMAPI, Extreme Cloud Administration Toolkit (xCAT), and Cloud Manager Appliance.
This chapter includes the following topics:
6.1 Cloud on z/VM components
An enterprise cloud might be composed of various components, depending on its main purpose. Implementing an Infrastructure as a Service (IaaS) cloud in z/VM demands the integration of some important components. The following components play a role in the integration of a cloud in z/VM:
•The z/VM Directory Manager (DirMaint) or a supported equivalent software provides a command-driven interface to manage z/VM directory entries.
•The z/VM Systems Management Application Programming Interface (SMAPI) provides programmatic access for managing many virtual images that are running on a single z/VM image by using a standard, platform-independent client interface, which reduces the number of z/VM-specific programming skills that are required.
•An External Security Manager (ESM) (such as IBM Resource Access Control Facility [RACF]) provides more resource protection beyond DIRMAINT and SMAPI authorizations. An ESM is optional, but implementing it might ensure that the company security policy is met. For more information about how to implement RACF, see Chapter 4, “IBM Resource Access Control Facility Security Server for IBM z/VM” on page 55.
•A Virtual Switch (VSWITCH) provides network connectivity between the management components to allow command-driven requests to come from the z/VM platform or other network -connected locations. They also provide the networks on to which newly provisioned instances are connected.
•The z/VM Cloud Manager Appliance (CMA) that is available is version 6.4 and is based on Newton. It provides an easy method to deploy z/VM OpenStack enablement. OpenStack products and solutions can be constructed to use as many or as few of the services as needed, whether that means that the CMA runs cloud controller services, compute node services, or only services that are needed by OpenStack z/VM drivers running in other virtual machines (VMs) or on other platforms.
 
Note: The CMA description in this publication that refers to CMA 6.4 (Newton) and the support for the Cloud Manager Appliance (CMA) on z/VM v7.1 is a transitional offer until a strategic long-term solution to replace the CMA is available. For more information, see IBM Cloud Private documentation at this web page.
The Cloud Manager Appliance 6.4 is available for z/VM v7.1 for the specific use case with IBM Cloud Private only. For more information, contact your IBM representative.
 
The xCAT MN and the ZHCP server now both run within the OPNCLOUD virtual machine.
z/VM supports the following system roles, which control the set of services that are running inside the OPNCLOUD virtual machine:
•CMA controller
Runs cloud controller services (such as glance image services) and all services that are listed under the compute_mn role. z/VM also runs the xCAT MN and ZHCP services to allow the controller to manage OpenStack z/VM hosts.
•CMA compute
Runs compute services (nova-compute service), networking services (neutron-zvm-agent service), and telemetry services (ceilometer-polling) for the z/VM hypervisor. z/VM also runs the ZHCP service to allow a remote xCAT MN service to manage hosts.
•Compute_MN
Runs compute, networking, and telemetry services (listed under the CMA compute role) for the z/VM hypervisor. It also runs xCAT and ZHCP services.
This type of node is used in an environment where OpenStack controller services are run on a non-CMA node. The xCAT MN and ZHCP services allow a controller to manage the z/VM host without requiring cloud controller services to be running on the host.
•mn
Runs the xCAT and ZHCP services. This role is useful when all OpenStack services are running in non-CMA nodes or when you want to use xCAT and not OpenStack.
•zhcp
Runs only the ZHCP service. This role is useful when all OpenStack services are running in non-CMA nodes or when you want xCAT and not OpenStack. In this case, another z/VM host must run xCAT MN service to manage the host through the ZHCP service.
 
Note: Running the xCAT MN and the ZHCP server in separate virtual machines is not supported in z/VM 6.4 and later releases.
6.2 DirMaint
DirMaint provides well-organized and secure interactive facilities for maintaining the z/VM system directory. Directory management is simplified by the DirMaint command interface and automated facilities. DirMaint supports all the z/VM directory statements. Most DirMaint directory commands include the same names and format as the z/VM directory.
6.2.1 DirMaint controls
Important control files of DIRMAINT are available that can be tailored to work correctly according to your environment settings. These DIRMAINT files are described next.
When performing a new implementation of the product, you must modify or create the following files:
•CONFIG DATADVH (included with the product)
•CONFIGnn DATADVH (must be created)
•AUTHFOR CONTROL (must be updated
•RPWLIST DATA (copied from MAINT’s 2CC disk)
•EXTENT CONTROL (must be updated)
CONFIG DATADVH
The CONFIG DATADVH file is the most important file for the DirMaint configuration. It contains all of the tailorable parameters for the product. You should never modify this IBM supplied file because it might be updated through the service process and overwrite your changes.
To change parameters on this file, create an override file instead where your installation-specific parameters are defined. The override file is named CONFIGnn DATADVH, where the nn can be any two digits you want to assign and is loaded in alphabetical order or numerical order.
 
For example, you can create CONFIGAA as your specifics settings and then DIRMAINT loads it after load CONFIG DATADVH. The CONFIG DATADVH file is self-documented. For more information, see Directory Maintenance Facility Tailoring and Administration Guide, SC24-6283. Example 6-5 on page 166
CONFIGSM DATADVH
 
Note: The CONFIGSM DATADVH file must be on the 11F disk when it is created. It is updated by using the dirm send and dirm file commands to get and replace this file. After changes are made, the DirMaint administrator must run the dirm rldata command. This command is used to instruct the DIRMAINT VM to reload all DATADVH files into memory.
The statements that are shown in Example 6-1 are considered as a good starting point for your CONFIGSM DATADVH file. DirMaint accepts nn as AA, BB, and so on. This example uses SM to refer to SMAPI configuration.
Example 6-1 CONFIGSM DATADVH
ALLOW_ASUSER_NOPASS_FROM= VSMGUARD *
ALLOW_ASUSER_NOPASS_FROM= VSMWORK1 *
ALLOW_ASUSER_NOPASS_FROM= VSMWORK2 *
ALLOW_ASUSER_NOPASS_FROM= VSMWORK3 *
ALLOW_ASUSER_NOPASS_FROM= WAVEWRKS *
ALLOW_ASUSER_NOPASS_FROM= WAVEWRKC *
ALLOW_ASUSER_NOPASS_FROM= WAVEWRKL *
ALLOW_ASUSER_NOPASS_FROM= EDI *
ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT.TCP= DVHXNE EXEC
ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT.UDP= DVHXNE EXEC
This file must be on the same disk as the CONFIG DATADVH file.
 
Note: Consider the following points:
•The ALLOW_ASUSER_NOPASS_FROM lines allow SMAPI users to issue commands to the Directory Manager by using the ASUSER modifier and the password of that user.
•The ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT lines activate an exit that notifies SMAPI of changes that are made to the user directory.
•If privacy of residual data is a concern on your system, use DISK_CLEANUP=YES.
•The ONLINE= IMMED line sets your changes to be made immediately.
•The RUNMODE= OPERATIONAL line sets directory changes to be committed. This line can be set to TESTING and the changes are not performed.
AUTHFOR control file
This file defines authorized administrators for your system in DirMaint. Several administrators can be defined in the AUTHFOR CONTROL file. The file is not included with the product and must be created manually. The file must be on the DIRMAINT 1DF disk. This file is also case-sensitive and must be in uppercase.
As shown in Figure 6-1 on page 161, a set of service VMs are granted full DirMaint authority through DirMaint specific privilege classes (ADGHOPS). These privilege classes represent distinct types of DirMaint roles and correspond to particular DirMaint commands and operations. When updating the AUTHFOR file, carefully consider the requirements of the VMs that are added and the scope of their authority.
ALL LNXADMIN * 140A ADGHOPS
ALL LNXADMIN * 150A ADGHOPS
ALL MAINT710 * 140A ADGHOPS
ALL MAINT710 * 150A ADGHOPS
ALL MAINT * 140A ADGHOPS
ALL MAINT * 150A ADGHOPS
ALL VSMGUARD * 140A ADGHOPS
ALL VSMGUARD * 150A ADGHOPS
ALL VSMWORK1 * 140A ADGHOPS
ALL VSMWORK1 * 150A ADGHOPS
ALL VSMWORK2 * 140A ADGHOPS
ALL VSMWORK2 * 150A ADGHOPS
ALL VSMWORK3 * 140A ADGHOPS
ALL VSMWORK3 * 150A ADGHOPS
ALL EDI * 140A ADGHOPS
ALL EDI * 150A ADGHOPS
Figure 6-1 Administrators who are authorized in DirMaint
The AUTHFOR CONTROL file specifies which VMs include the authority to modify the characteristics of other VMs on the system. This authority can be limited to specific target VMs or to specific attributes of a target VM. This authority is implemented by using DirMaint command sets. The format of this file is column-specific.
RPWLIST DATA
The RPWLIST DATA file is on the MAINT 2CC minidisk. When installing DIRMAINT, link and access this disk and copy this file to the 11F disk that is owned by DIRMAINT. It can be used to disable passwords that you deem to be trivial.
EXTENT CONTROL
The EXTENT CONTROL file defines disks (volumes) to DirMaint for minidisk allocation. It also contains system and device default values that are used during allocation operations. The following sections must be populated:
•Regions define the actual disks and their sizes to DirMaint. The AUTOR keyword can be used in user directory entries to take space from the regions. As a preferred practice, the region name and volume label always should be identical.
•Groups define pools of disks so that the AUTOG keyword can be used to take space from the pools, not from specific disks.
 
Note: For more information about DIRMAINT, see Directory Maintenance Facility Tailoring and Administration Guide, SC24-6283.
DirMaint-RACF Connector
RACF can coexist with the DirMaint product installed. However, to avoid dual maintenance of password processing (and other RACF functions), complete the following steps:
1. Use the DirMaint supplied sample file CONFIGRC SAMPDVH. You must copy this file to the 7VMDIR10 11F disk as CONFIGRC DATADVH.
Note: For more information about this file, see Chapter 3, “Tailoring the DIRMAINT Service Machine”, in Directory Maintenance Facility Tailoring and Administration Guide, SC24-6283. For this file to take effect, perform an IPL of DirMaint or run the DIRM RLDDATA command.
2. If RACF administration is centralized, you must give the DIRMAINT user ID RACF administrator SPECIAL authority. If RACF administration is decentralized, you must give the DIRMAINT user ID RACF group-SPECIAL authority.
3. If you want to record DirMaint activity in RACF SMF records, enable ESM_LOG_RECORDING_EXIT.
To do this, remove the comment from the item ESM_LOG_RECORDING_EXIT in the CONFIGRC DATADVH file. For this change to take effect, perform an IPL of DirMaint or run the DIRM RLDDATA command.
4. Authorize the DirMaint service machines DIRMAINT, DATAMOVE, and DIRMSAT to use the RACROUTE interface.
 
Note: For more information, see Directory Maintenance Facility Tailoring and Administration Guide, SC24-6283, and z/VM: Security Server RACROUTE Macro Reference, SC24-6324.
6.2.2 Delegating DirMaint authority
DirMaint access management include the following components:
•Command privilege classes
•AUTHFOR CONTROL and AUTHBY CONTROL files
•Exit routines
These mechanisms provide the management of administrators that are authorized to use DirMaint and the level of authority they have over their own user ID and the IDs of others.
In addition, DirMaint allows for commands to be issued under the authority of another user by using the ASuser prefix. Although this method is used when issuing commands to another system, it can also be used as a method for delegation of authority.
Command privilege classes
DirMaint uses a privilege class structure that is similar to that used by CP. Commands are grouped into classes based on the administrative function they perform, and users are then assigned to a class. A command can exist in one or more classes, and a user can also be assigned privileges over more than one class. The 140CMDS DATADVH and 150CMDS DATADVH files contain the mapping of commands into classes.
Custom classes can be created in the 1*0CMDS DATADVH files, which allows for a DirMaint administrator to create groupings of commands that suit the requirements of the installation. This process is described in “Defining a Custom Command Set” in the Directory Maintenance Facility Tailoring and Administration Guide, SC24-6283.
AUTHFOR CONTROL and AUTHBY CONTROL
The AUTHFOR CONTROL file on the DIRMAINT 1DF disk maps DirMaint administration users to the users they are allowed to administer and the command privileges they have over those users. An example of the AUTHFOR CONTROL file is shown in Example 6-2 on page 163.
Example 6-2 Example of the AUTHFOR CONTROL file
ALL LNXADMIN * 140A ADGHOPS
ALL LNXADMIN * 150A ADGHOPS
ALL LNXMAINT * 140A ADGHOPS
ALL LNXMAINT * 150A ADGHOPS
ALL MAINT * 140A ADGHOPS
ALL MAINT * 150A ADGHOPS
ALL MAINT710 * 140A ADGHOPS
ALL MAINT710 * 150A ADGHOPS
In this example, the users LNXADMIN, LNXMAINT, MAINT, and MAINT710 can run commands from both of the DirMaint command levels (140A and 150A) in the classes A, D, G, H, O, P, and S against all users on the system (the ALL keyword at the start of the records).
The AUTHFOR CONTROL file can be updated by running the DirMaint AUTHFOR command, or by running DIRM SEND to send a copy of the file, editing it directly, and running DIRM FILE to store it back to DirMaint. If the file is edited directly, the DIRM RLDCode command must be run to refresh DirMaint with the update.
 
Note: For more information about AUTHFOR CONTROL, see Directory Maintenance Facility Tailoring and Administration Guide, SC24-6283.
Running commands by using ASuser
On the example system, Linux system administrators maintain Linux VM definitions by using DirMaint. Currently, the AUTHFOR CONTROL file grants access to these administrators over all the VMs on the system (by using the ALL keyword).
Suppose that you want to give these administrators access to operate only on the Linux VM users. By using AUTHFOR CONTROL, the only way this process can be done is to specifically list each Linux VM and the command privilege that applies for each administrator. This process introduces the following considerations:
•Each time a Linux is added, AUTHFOR CONTROL must be updated to add authority to the new guest for all Linux administrators.
•If an administrator joins or leaves the team, AUTHFOR CONTROL must be modified to add or remove entries for all the Linux guests.
•If the command privilege level that the Linux administrators should be assigned over Linux guests changes, every corresponding line in AUTHFOR CONTROL must be updated.
A method that can be used to implement a group membership approach is to define an administrator ID for each set of Linux guests. Individual administrators then use the ASuser prefix keyword on the DIRM command to issue their administrative commands to DirMaint under the authority of the group ID, as shown in the following example:
DIRM AS LNX1GRP FOR LNXS0030 REVIEW
This process works as a way to reduce the configuration effort because the only ID that appears in the AUTHFOR CONTROL file is the group administrator ID. However, consider the following drawbacks:
•The group administrator ID must be defined to RACF. It does not have to be defined to the CP directory.
•The ASuser prefix keyword forces a prompt for the administrator password whenever it
is used.
•The password that must be provided when ASuser is used as the password of the group administrator ID.
Using BYuser
The ASuser prefix can be combined with BYuser to avoid having to know the password of the administrator ID. The use of BY with AS allows an administrator to override the password prompt that comes from using AS with a prompt for their own password, but the administrator must use their own ID as the option on the BY prefix. The DirMaint command then appear as shown in the following example:
DIRM AS LNX1GRP BY EDI FOR LNXICP1 REVIEW
A DirMaint administrator must be authorized to run commands by using BYuser because the password of the administrator who is running the command is used. Therefore, administrators on the system must be protected from other admins that are running commands on their behalf.
The authority is managed in a configuration file within DirMaint in a similar fashion to FOR by using the file AUTHBY CONTROL. The AUTHBY CONTROL file is maintained in a similar way to AUTHFOR CONTROL; that is, by using the DirMaint AUTHBY command or by directly editing the AUTHBY CONTROL file.
 
Note: Like AUTHFOR CONTROL, no supplied AUTHBY CONTROL file is available in a DirMaint installation. Use the AUTHBY command to create the first AUTHBY entry so that DirMaint creates the file on the correct disk. You can then use the SEND/FILE process to edit the file directly if you want.
To enable the AUTHBY command, the LNX1GRP user runs the following command:
DIRM AUTHBY EDI
If another administrator can access run commands on behalf of LNX1GRP, they also can run the following command:
DIRM FOR LNX1GRP AUTHBY EDI
Either of these commands result in a line being added to the AUTHBY CONTROL file, as shown in Example 6-3.
Example 6-3 Line added to AUTHBY CONTROL
LNX1GRP  EDI
Suppressing the password prompt
DirMaint includes a configuration option ALLOW_ASUSER_NOPASS_FROM, which allows authorized administrators to run commands by using the ASuser prefix without being prompted for a password. This option is used only for the SMAPI worker servers; other DirMaint administrators should not be entered in this option. Therefore, it is not possible to suppress the password prompt for a DirMaint administrator by using the ASuser prefix.
Exit routines
In Chapter 9 “Exit routines” of Directory Maintenance Facility Tailoring and Administration Guide, SC24-6283, the exits are described that are available to modify the way DirMaint operates. Many of the exits that are available have an influence over command processing, which is useful because it allows more granular access control than what is provided by command privilege or administrator configuration.
Example exit usage: FOR authorization
The following sections describe an example of how a DirMaint exit can be used. The example implements group-based administration by using ASuser and BYuser by using a DirMaint exit instead of AUTHFOR and AUTHBY.
An easier way to achieve the requirement might be to use the DirMaint exit routine for the FOR command. Because the Linux administrators are using the DIRM FOR command to perform operations on the guests they manage, the use of the exit routine that is called when FOR commands are run is a good way to determine programmatically whether the command should be granted.
An example exit routine to achieve the effect is shown in Example 6-4.
Example 6-4 Sample DVHXFA EXEC for authority delegation
/* REXX */
/* DVHXFA EXEC */
/* DirMaint FOR Authorization Checking exit */
Address 'COMMAND'
Parse Upper Arg Asuser NodeID TgtID TgtNode CmdLvl CmdSet Cmd
/* Read in the user file to find the group(s) */
'PIPE < USR2GRP DIRMFILE | ',
'LOCATE /'TgtID'/ | ',
'STEM Groups.'
/* Does the user belong to a group? Exit if not */
If Groups.0=0 Then Exit 30
/* For each group the user is a member of, see if the issuer is a member */
Do counter=1 to Groups.0
Group=Word(Groups.counter,2)
'PIPE < GRP2ADM DIRMFILE | ',
'LOCATE /'Group'/ | ',
'LOCATE /'Asuser'/ | ',
'STEM Admin.'
/* If the stem is empty we try again; if not, we got one, we’re done */
If Admin.0=0 Then Iterate; Else Exit 0
End
Exit 30
The exec uses two files that are stored on a DirMaint disk, USR2GRP DIRMFILE and GRP2ADM DIRMFILE to provide group-based organization to DirMaint access control. The USR2GRP DIRMFILE file links z/VM user IDs to the group they belong to, and GRP2ADM DIRMFILE maps the administration groups to the DirMaint administrator users who are permitted to operate on them.
Records in USR2GRP DIRMFILE feature the following format:
Userid Group
One space character is sufficient between the user ID and the group.
Records in GRP2ADM DIRMFILE feature the following format:
Group Adminid [Adminid …]
You can specify the group multiple times if needed to support many administrator IDs.
Implementing the DVHXFA exit
In this example, you implement the DVHXFA EXEC exit to ensure it works as expected. Complete the following steps:
1. Install the files onto the DIRMAINT 11F disk by running DIRM FILE (specifying the destination file mode of D to make sure that they went to 11F instead of the 191):
DIRM FILE DVHXFA EXEC A = = D
DIRM FILE USR2GRP DIRMFILE A = = D
DIRM FILE GRP2ADM DIRMFILE A = = D
2. Add the correct entry to the CONFIG* DATADVH file set to activate the exit:
FOR_AUTHORIZATION_CHECKING_EXIT= DVHXFA EXEC
3. You have a CONFIGAA DATADVH file that contains all the local changes, so add the line there by running DIRM SEND, receive, edit, and the run DIRM FILE.
4. Activate the altered configuration by running DIRM RLDData to put the exit into service.
5. Remove the authorization for the Linux administrators from AUTHFOR CONTROL by using a bulk update by using the SEND-receive-edit-FILE-RLDD method.
6. Ensure that the administrators can do what they need. In this example, the administrator EDI was permitted to administer only the groups CMSGRP and LNX1GRP. LNX1GRP contained the user LNXS0030, but another user LNXS0038 was in a different group. The CMS user USERBOB was part of CMSGRP.
Example 6-5 shows the results when administrator EDI attempted to work on system user IDs.
Example 6-5 Run DirMaint commands when the DVHXFA exit is in place
dirm for userbob review
DVHXMT1191I Your REVIEW request has been sent for processing to DIRMAINT
DVHXMT1191I at ITSOZVM1.
Ready; T=0.01/0.01 17:18:40
DVHREQ2288I Your REVIEW request for USERBOB at * has been accepted.
RDR FILE 0237 SENT FROM DIRMAINT PUN WAS 6593 RECS 0028 CPY 001 A NOHOLD NOKEEP
DVHREQ2289I Your REVIEW request for USERBOB at * has completed; with
DVHREQ2289I RC = 0.
dirm for lnxs0030 review
DVHXMT1191I Your REVIEW request has been sent for processing to DIRMAINT
DVHXMT1191I at ITSOZVM1.
Ready; T=0.01/0.01 17:19:11
DVHREQ2288I Your REVIEW request for LNXS0030 at * has been accepted.
RDR FILE 0241 SENT FROM DIRMAINT PUN WAS 6597 RECS 0045 CPY 001 A NOHOLD NOKEEP
DVHREQ2289I Your REVIEW request for LNXS0030 at * has completed; with RC
DVHREQ2289I = 0.
dirm for lnxs0038 review
DVHXMT1191I Your REVIEW request has been sent for processing to DIRMAINT
DVHXMT1191I at ITSOZVM1.
DVHREQ2287E User EDI at ITSOZVM1 is not authorized to act for LNXS0038
DVHREQ2287E at *; your request is ignored.
dirm for maint710 review
DVHXMT1191I Your REVIEW request has been sent for processing to DIRMAINT
DVHXMT1191I at ITSOZVM1.
DVHREQ2287E User EDI at ITSOZVM1 is not authorized to act for MAINT710
DVHREQ2287E at *; your request is ignored.
6.3 Systems Management API
The z/VM SMAPI is the access point for any external tool to manage the z/VM running on IBM LinuxONE platform. It supports management of lifecycle and configuration of various platform resources, such as Guest, CPU, memory, virtual switches, storage, and more.
Some IBM products use the SMAPI to perform various tasks on the z/VM system (see Figure 6-2). Therefore, it is necessary to make sure that SMAPI is configured and running before you configure any cloud piece that interacts with z/VM. The exact configuration steps for SMAPI might differ from the following section based on the version and release level of z/VM.
Figure 6-2 SMAPI socket-based servers work together
 
Note: Because this IBM Redbooks publication references the current version of CMA Newton (6.4), we must use the SMAPI 6.4 to be compatible and it is included with CMA 6.4.
6.3.1 SFS
The SMAPI request servers and worker servers use Shared File System (SFS) directories to access configuration files and other data. SMAPI uses the standard file pool VMSYS and VMPSFS to keep their files. The VSMWORK1 user ID is the owner of some of the SFS directories that have control files, logs, and so on.
Security aspects with SFS directories
The SFS directories are defined on SFS file pools. The authorization and ownership for the SFS directories are done by using enroll SFS commands. You can set AUDIT parameter on DSMPARMS file for auditing purpose.
 
Note: For more information about managing and auditing the VMSYS or VMPSFS file pools, see z/VM: CMS File Pool Planning, Administration, and Operation, SC24-6261.
All commands that are shown in this chapter regarding SFS ENROLL and GRANT are performed automatically during z/VM installation. They are shown here for verification and testing purposes.
Also, if you are adding a worker or request server, you can use the appropriate commands from these lists as a guide for enrolling your new server in the correct file pool and then grant SFS authorizations (see Example 6-6 on page 168).
Example 6-6 SFS ENROLL command
ENROLL USER VSMWORK1 VMSYS: (BLOCKS 6000 STORGROUP 2
ENROLL USER VSMWORK2 VMSYS:
ENROLL USER VSMWORK3 VMSYS:
ENROLL USER VSMREQIN VMSYS:
ENROLL USER VSMREQIU VMSYS:
ENROLL USER VSMGUARD VMPSFS: (BLOCKS 1000 STORGROUP 2
ENROLL USER VSMGUARD VMSYS:
ENROLL USER VSMREQI6 VMSYS:
ENROLL USER VSMEVSRV VMSYS:
ENROLL USER DTCSMAPI VMSYS:
ENROLL USER OPERATNS VMSYS:
ENROLL USER PERSMAPI VMSYS: (BLOCKS 24000 STORGROUP 2
ENROLL USER OPNCLOUD VMSYS:
If you do not grant access to the specific directory, you cannot access it. Example 6-7 shows SFS GRANT commands that are automatically performed during z/VM installation.
Example 6-7 SFS GRANT command
GRANT AUTHORITY VMSYS:VSMWORK1. TO OPNCLOUD (WRITE NEWWRITE
GRANT AUTHORITY VMSYS:VSMWORK1.DATA TO OPNCLOUD (WRITE NEWWRITE
GRANT AUTHORITY VMSYS:VSMWORK1. TO MAINT (WRITE NEWWRITE
GRANT AUTHORITY VMSYS:VSMWORK1.DATA TO MAINT (WRITE NEWWRITE
GRANT AUTHORITY VMSYS:VSMWORK1. TO VSMGUARD (WRITE NEWWRITE
GRANT AUTHORITY VMSYS:VSMWORK1.DATA TO VSMGUARD (WRITE NEWWRITE
GRANT AUTHORITY VMSYS:VSMWORK1.STATUS TO VSMGUARD (WRITE NEWWRITE
GRANT AUTHORITY VMSYS:VSMWORK1.STATUS TO VSMWORK2 (WRITE NEWWRITE
GRANT AUTHORITY VMSYS:VSMWORK1.STATUS TO VSMWORK3 (WRITE NEWWRITE
GRANT AUTHORITY * * VMSYS:VSMWORK1. TO VSMGUARD (READ
GRANT AUTHORITY VMSYS:VSMWORK1. TO PERSMAPI (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO DIRMAINT (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO DIRMSAT (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO DIRMSAT2 (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO DIRMSAT3 (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO DIRMSAT4 (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO DATAMOVE (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO DATAMOV2 (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO DATAMOV3 (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO DATAMOV4 (READ NEWREAD
GRANT AUTHORITY VMPSFS:VSMGUARD. TO AUTOLOG1 (WRITE NEWWRITE
GRANT AUTHORITY VMPSFS:VSMGUARD. TO AUTOLOG2 (WRITE NEWWRITE
 
Note: For more information about SMAPI, see The Virtualization Cookbook for IBM z Systems®Volume 1: IBM z/VM 6.3, SG24-8147, Systems Management Application Programming (6.4), SC24-6327, and Enabling z/VM for OpenStack (Newton), SC24-6253.
6.3.2 Other SMAPI user IDs
The interaction with SMAPI occurs through a client/server architecture and SMAPI includes the following types of servers:
•Request
•Worker
Request servers
A listening request server receives a connection request from a client, establishes a connection, and then accepts requests from that client. The following request servers are available:
•VSMREQIN
•VSMREQI6
•VSMREQIU
•VSMEVSRV
Worker servers
The worker servers process API function requests. The following worker servers are defined in the default installation:
•VSMWORK1
•VSMWORK2
•VSMWORK3
A fourth worker server, VSMGUARD, is also defined. VSMGUARD is a “guard” server that helps provide better resiliency and error recovery. For more information, see 6.3.3, “VSMGUARD” on page 169.
Other servers
The following severs also are available:
•The LOHCOST server is used for caching the system directory contents that are required to satisfy the various query APIs. It is also used to store and retrieve data that is used by the metadata APIs.
•The DTCSMAPI server is used by several of the SMAPI servers for communication and workload balancing.
•The PERSMAPI server is used for performance monitoring.
•The VSMEVSRV server is used to listen for and then propagate VMEVENT and directory updates.
•The OPERATNS server is used to collect, format, and distribute ABEND memory dumps.
6.3.3 VSMGUARD
The VSMGUARD worker server grants authority to all the other SMAPI servers that are configured to access the SMAPI file space. Therefore, VSMGUARD must be made an administrator of the VMSYS: file pool. This process is done by adding VSMGUARD to the list of users that are authorized for ADMIN authority.
 
Note: In the default environment, this process is done by updating the VMSERVS DMSPARMS file on the VMSERVS 191 disk.
VSMGUARD has an important role in the SMAPI environment. When you must recycle all SMAPI user IDs, you do it by recycling VSMGUARD (force and xautolog) and it recycles all the other SMAPI user IDs, saves the SMAPI segment, and defines the vSwitches that are listed in the configuration file.
 
Note: For more information about SMAPI, see The Systems Management Application Programming for 6.4, SC24-6327.
6.3.4 SMAPI controls
Because xCAT uses SMAPI to interact with the system to enable xCAT on z/VM, you must configure the following SMAPI files:
•DMSSISVR NAMES
DMSSISVR NAMES is a CMS NAMES file that defines each specific request and worker servers in the z/VM environment. This file is on the MAINT the new 1193 MDisk that is included with the currently CMA 6.4 package.
Modify the DMSSISVR NAMES file and uncomment the directory manager and the memory dump handler definitions. You can modify it manually or run the VMSES/E LOCALMOD command to change this file.
 
Note: The use of VM/SES helps preserve your configuration changes if IBM makes service updates or future release update in this file.
•DMSSICNF COPY
The DMSSICNF COPY file contains several global attributes that can be modified to better fit your installation and networking configurations, such as IP addresses, gateway, netmask, domain name, and vSwitches. This file is the heart of SMAPI and xCAT because it is used to control the definition of the servers when it is initialized. This file is on MAINT new 1193 MDisk and is included with the current CMA 6.4 package.
To make the DMSSISVR and DMSSINCF files changes available to SMAPI and the OPNCLOUD server user IDs, run the following VM/SES commands after the files are updated:
SERVICE CMS BUILD
PUT2PROD
6.3.5 Security aspects of SMAPI
An ESM controls who can have access, and what kind of access they can have, to specific resources. If an ESM is implemented at your installation, SMAPI must be given the appropriate access to the disks, SFS directories, and resources you want it to manage. In this example installation, use RACF as the ESM.
In addition to the security aspects that you have by using SFS, you have other authority files on SMAPI that list who is authorized to run commands on SMAPI. Make sure your installation grants access to authorized people only.
VSMWORK1 AUTHLIST
Authenticated users must be authorized to issue API requests. A server authorization file is used for this purpose. The authorization file contains entries that authorize authenticated users to perform specific functions for specific virtual images (target users) or lists of virtual images. The authorization can be granted per requesting VM, per target, or per function. This file is in the VMSYS file pool, under the VSMWORK1 SFS directory and, during the installation, VSMGUARD is granted access to it, as shown in Example 6-8.
Example 6-8 VSMGUARD access to the VSMWORK1 directory
grant authority vmsys:vsmwork1. to vsmguard (write newwrite
grant authority vmsys:vsmwork1.data to vsmguard (write newwrite
grant authority * * vmsys:vsmwork1. to vsmguard (read
Using SMAPI with RACF
RACF for z/VM can be used to enhance the security and integrity of your system in the following ways:
•Helping you to implement the company’s security policy
•Identifying and authenticating each user
•Controlling each user’s access to sensitive data
•Logging and reporting events that are relevant to the system’s security
Enabling RACROUTE
Enable the SMAPI service machines VSMREQI6, VSMREQIN, VSMREQIU, VSMEVSRV, DTCSMAPI, VSMWORK1, VSMWORK2, and VSMWORK3 to use RACROUTE services, as shown in Example 6-9.
Example 6-9 RACF RACROUTE definitions for SMAPI user IDs
RAC SETROPTS CLASSACT(FACILITY)
RAC SETROPTS RACLIST(FACILITY)
RAC RDEFINE FACILITY ICHCONN UACC(NONE)
RAC PERMIT ICHCONN CLASS(FACILITY) ID(VSMREQI6) ACCESS(UPDATE)
RAC PERMIT ICHCONN CLASS(FACILITY) ID(VSMREQIN) ACCESS(UPDATE)
RAC PERMIT ICHCONN CLASS(FACILITY) ID(VSMREQIU) ACCESS(UPDATE)
RAC PERMIT ICHCONN CLASS(FACILITY) ID(VSMEVSRV) ACCESS(UPDATE)
RAC PERMIT ICHCONN CLASS(FACILITY) ID(DTCSMAPI) ACCESS(UPDATE)
RAC PERMIT ICHCONN CLASS(FACILITY) ID(VSMWORK1) ACCESS(UPDATE)
RAC PERMIT ICHCONN CLASS(FACILITY) ID(VSMWORK2) ACCESS(UPDATE)
RAC PERMIT ICHCONN CLASS(FACILITY) ID(VSMWORK3) ACCESS(UPDATE)
RAC SETROPTS RACLIST(FACILITY) REFRESH
The directory entry for the SMAPI service machines that use this capability must all contain the following statement:
IUCV ANY PRIORITY MSGLIMIT 255
An MSGLIMIT value of 255 is initially suggested. It can be adjusted as needed.
Making SMAPI user IDs exempt for some RACF checking
The SMAPI service machines (DTCSMAPI, VSMWORK1, VSMWORK2, and VSMWORK3) should be made exempt from access checking. Even if access checking is not active on your system, make the SMAPI service machines exempt from access checking for the FOR (privilege class C), and LINK commands, as shown in Example 6-10.
Example 6-10 Make SMAPI user IDs exempt for FOR and LINK commands
RAC SETROPTS CLASSACT(VMXEVENT)
RAC RDEFINE VMXEVENT USERSEL.DTCSMAPI
RAC RALTER VMXEVENT USERSEL.DTCSMAPI ADDMEM(FOR.C/NOCTL)
RAC RALTER VMXEVENT USERSEL.DTCSMAPI ADDMEM(LINK/NOCTL)
RAC SETEVENT REFRESH USERSEL.DTCSMAPI
RAC RDEFINE VMXEVENT USERSEL.VSMWORK1
RAC RALTER VMXEVENT USERSEL.VSMWORK1 ADDMEM(FOR.C/NOCTL)
RAC RALTER VMXEVENT USERSEL.VSMWORK1 ADDMEM(LINK/NOCTL)
RAC SETEVENT REFRESH USERSEL.VSMWORK1
RAC RDEFINE VMXEVENT USERSEL.VSMWORK2
RAC RALTER VMXEVENT USERSEL.VSMWORK2 ADDMEM(FOR.C/NOCTL)
RAC RALTER VMXEVENT USERSEL.VSMWORK2 ADDMEM(LINK/NOCTL)
RAC SETEVENT REFRESH USERSEL.VSMWORK2
RAC RDEFINE VMXEVENT USERSEL.VSMWORK3
RAC RALTER VMXEVENT USERSEL.VSMWORK3 ADDMEM(FOR.C/NOCTL)
RAC RALTER VMXEVENT USERSEL.VSMWORK3 ADDMEM(LINK/NOCTL)
RAC SETEVENT REFRESH USERSEL.VSMWORK3
Making the OPNCLOUD user ID exempt from transfer command access
validation
If your system is using xCAT integrated to CMA, the OPNCLOUD service machine must be made exempt from spool checking so that it can transfer files to various virtual machines. Do this by running the commands that are shown in Example 6-11.
Example 6-11 Exempt the ZHCP user ID for access command validation
RAC SETROPTS CLASSACT(VMXEVENT)
RAC RDEFINE VMXEVENT USERSEL.OPNCLOUD
RAC RALTER VMXEVENT USERSEL.OPNCLOUD ADDMEM(TRANSFER.G/NOCTL)
RAC SETEVENT REFRESH USERSEL.OPNCLOUD
Enabling SMAPI to access DIAGNOSE X'88'
You must enable the SMAPI service machines for DIAGNOSE X'88' access. If RACF is used to control DIAGNOSE X'88' access, enable DIAGNOSE X'88' access for SMAPI by completing the following steps:
1. Enable RACF/VM profile protection for DIAGNOSE X'88', as shown in Example 6-12.
Example 6-12 Create a profile DIAG88 in VMCMD class
RAC RDEFINE VMCMD DIAG088 UACC(NONE)
RAC SETROPTS CLASSACT(VMCMD)
 
Note: Each SMAPI server has the OPTION DIAG88 statement in its directory entry. If you do not enable RACF protection, the checking defaults to the CP directory OPTION DIAG88 entry, which tells CP that the server is authorized to use DIAGNOSE code X'88'.
2. Give the SMAPI server permission to perform password validation (which uses DIAGNOSE X'88' subcode 8), as shown in Example 6-13, Example 6-14, and Example 6-15 on page 173.
Example 6-13 Give authority to the requester servers
RAC PERMIT DIAG088 CLASS(VMCMD) ID(VSMREQIN) ACCESS(READ)
RAC PERMIT DIAG088 CLASS(VMCMD) ID(VSMREQI6) ACCESS(READ)
RAC PERMIT DIAG088 CLASS(VMCMD) ID(VSMREQIU) ACCESS(READ)
RAC PERMIT DIAG088 CLASS(VMCMD) ID(VSMEVSRV) ACCESS(READ)
Example 6-14 Give authority to the worker servers
RAC PERMIT DIAG088 CLASS(VMCMD) ID(VSMGUARD) ACCESS(READ)
RAC PERMIT DIAG088 CLASS(VMCMD) ID(VSMWORK1) ACCESS(READ)
RAC PERMIT DIAG088 CLASS(VMCMD) ID(VSMWORK2) ACCESS(READ)
RAC PERMIT DIAG088 CLASS(VMCMD) ID(VSMWORK3) ACCESS(READ)
Example 6-15 Give authority to these SMAPI user IDs
RAC PERMIT DIAG088 CLASS(VMCMD) ID(LOHCOST) ACCESS(READ)
RAC PERMIT DIAG088 CLASS(VMCMD) ID(DTCSMAPI) ACCESS(READ)
RAC PERMIT DIAG088 CLASS(VMCMD) ID(PERSMAPI) ACCESS(READ)
RAC PERMIT DIAG088 CLASS(VMCMD) ID(OPERATNS) ACCESS(READ)
 
Attention: After creating DIAG088, you must issue the permit command to DIRMAINT.
Enabling SMAPI to access needed resources
You must enable the SMAPI service machine for minidisk, reader, and VMBATCH access, as shown in Example 6-16, Example 6-17, Example 6-18, and Example 6-19.
Example 6-16 For minidisk access: RACF uses to control minidisk access
RAC PERMIT MAINT710.5E5 CLASS(VMMDISK) ID(VSMWORK1) ACCESS(READ)
RAC PERMIT MAINT710.51D CLASS(VMMDISK) ID(VSMWORK1) ACCESS(READ)
RAC PERMIT PMAINT.551 CLASS(VMMDISK) ID(VSMGUARD) ACCESS(READ)
Example 6-17 Allow VSMWORK1 minidisk authority
RAC PERMIT PMAINT.CF0 CLASS(VMMDISK) ACC(CONTROL) ID(VSMWORK1)
RAC PERMIT MAINT.CF1 CLASS(VMMDISK) ACC(CONTROL) ID(VSMWORK1)
Example 6-18 Allow SMAPI worker servers to read the TCPMAINT 198 disk
RAC PERMIT TCPMAINT.198 CLASS(VMMDISK) ACC(READ) ID(VSMGUARD)
RAC PERMIT TCPMAINT.198 CLASS(VMMDISK) ACC(READ) ID(VSMWORK1)
RAC PERMIT TCPMAINT.198 CLASS(VMMDISK) ACC(READ) ID(VSMWORK2)
RAC PERMIT TCPMAINT.198 CLASS(VMMDISK) ACC(READ) ID(VSMWORK3)
Example 6-19 Enable reader access to DTCSMAPI for MAINT and TCPMAINT user IDs
RAC PERMIT MAINT CLASS(VMRDR) ID(DTCSMAPI) ACCESS(UPDATE)
RAC PERMIT TCPMAINT CLASS(VMRDR) ID(DTCSMAPI) ACCESS(UPDATE)
VMBATCH access
Permit the SMAPI servers CONTROL access to a generic VMBATCH, or to an existing discrete VMBATCH profile to use the SMAPI services, as shown in Example 6-20, Example 6-21, and Example 6-22 on page 174.
Example 6-20 RACF commands to define VMBATCH
rac setropts generic(vmbatch) gencmd(vmbatch)
rac rdefine vmbatch ** uacc(none)
rac permit ** class(vmbatch) id(ftpserve vmnfs dirmsat dirmsat2) acc(control)
rac setropts classact(vmbatch vmmdisk vmcmd vmlan surrogat)
Example 6-21 Give CONTROL access if you have an existing generic VMBATCH profile
RAC PERMIT ** CLASS(VMBATCH) ID(VSMWORK1) ACCESS(CONTROL)
RAC PERMIT ** CLASS(VMBATCH) ID(VSMWORK2) ACCESS(CONTROL)
RAC PERMIT ** CLASS(VMBATCH) ID(VSMWORK3) ACCESS(CONTROL)
RAC PERMIT ** CLASS(VMBATCH) ID(DTCSMAPI) ACCESS(CONTROL)
Example 6-22 Give CONTROL access if you have an existing generic VMBATCH profile:
RAC PERMIT CLASS(VMBATCH) ID(VSMWORK1) ACCESS(CONTROL)
RAC PERMIT CLASS(VMBATCH) ID(VSMWORK2) ACCESS(CONTROL)
RAC PERMIT CLASS(VMBATCH) ID(VSMWORK3) ACCESS(CONTROL)
RAC PERMIT CLASS(VMBATCH) ID(DTCSMAPI) ACCESS(CONTROL)
Although all of the items that are described here are important, they are not enough without validating them. Auditing SMAPI requests ensures that the security policies that are applied are being followed and are correctly assigned.
SMAPI ESM authorization support
SMAPI provides the following Enterprise Security Manager (ESM) interaction:
•When an ESM is present, programs can use the ESM for all SMAPI authorization decisions at the same granularity that is used with the SMAPI existing authorization mechanism. The ESM logs (or does not log) the decision that is based on its active policy, without SMAPI knowledge or intervention.
•When an ESM defers its authorization decision to SMAPI, one of the following actions is taken based on a configuration option:
 – The SMAPI authorization decision uses the existing authorization process. SMAPI calls the ESM to log the decision in the ESM-managed security log. SMAPI has no knowledge if the ESM audit logging is enabled or disabled.
 – SMAPI treats the request as unauthorized
6.4 z/VM Cloud Manager Appliance
z/VM Cloud Manager Appliance (CMA) allows the use of OpenStack to deploy Linux guests on z/VM, and for the integration of z/VM into larger environments. The current CMA version is on OpenStack Newton and is supported as a z/VM component without extra license requirements.
CMA manages only z/VM platforms and it does not deploy guests onto non-z/VM platforms. The CMA changes provide several different options for using CMA: as stand-alone cloud or integrated with another OpenStack environment.
This section refers to the current version of z/VM CMA Newton.
 
Note: Consider the following points:
•The support for CMA Newton version on z/VM v7.1 is a transitional offer until a strategic long-term solution to replace the CMA becomes available.
•CMA Newton is available for z/VM v7.1 for the specific use case with IBM Cloud Private only.
•To get the CMA Newton package, you must contact your IBM representative or IBM account team.
Figure 6-3 shows an overall view of CMA Architecture for z/VM.
Figure 6-3 z/VM CMA architecture
6.4.1 Basic requirements and configuration options
Each z/VM logical partition (LPAR) requires a CMA. The extreme Cloud Administration Toolkit (xCAT) must always be active within the CMA. The OpenStack services are optional, and depend on the intended use.
CMA can be configured in different ways, based on the needed function or integration requirements. z/VM currently supports the following system roles, which control the set of services running inside the OPNCLOUD virtual machine:
•Controller node
Runs cloud controller services (such as the glance image services) in addition to all services that are listed under the compute role. z/VM also runs the xCAT MN and ZHCP services to allow the controller to manage OpenStack z/VM hosts.
•Compute node
Runs compute services (nova-compute service), networking services (neutron-zvm-agent service), and telemetry services (ceilometer-polling) for the z/VM hypervisor. z/VM also runs the ZHCP service to allow a remote xCAT MN service to manage the host.
•Compute MN
Runs compute, networking, and telemetry services (listed under the compute role) for the z/VM hypervisor. It also runs the xCAT MN and ZHCP services. This type of node is used in an environment where OpenStack controller services are run on a non-CMA node (for example, on other platforms). The xCAT MN and ZHCP services allow a controller to manage the z/VM host without requiring cloud controller services to be running on the host.
•Managed Node (MN)
Runs the xCAT MN and ZHCP services. This role is useful when all OpenStack services are running in non-CMA nodes or when you want to use xCAT and not OpenStack.
•ZHCP
Runs only the ZHCP service. This role is useful when all OpenStack services are running in non-CMA nodes or when you want to use xCAT and not OpenStack. Another z/VM host must run an xCAT MN service to manage the host through the ZHCP service.
 
Note: xCAT MN and ZHCP servers run within the same virtual machine, which is called the OPNCLOUD.
z/VM currently supports OpenStack Newton, which includes the following items:
•Support for the Newton release of OpenStack.
•Integration of the xCAT function into the z/VM CMA, which allows running a fully functional z/VM OpenStack solution in a single virtual server so that separate ZHCP servers are not required.
•Support for provisioning Red Hat RHEL 7 and SUSE SLES 12 servers.
For more information about z/VM CMA for OpenStack Newton, see Enabling z/VM for OpenStack (Support for OpenStack Newton Release), SC24-6251, and Systems Management Application Programming (6.4), SC24-6327.
 
Note: To get CMA Newton, contact your IBM representative or IBM account team.
6.4.2 OpenStack and xCAT Service Deployment Patterns
In this section, we provide an overview of the z/VM systems management architecture, OpenStack architecture, the CMA, which are environments that are available for using OpenStack with z/VM. We also include some examples for choosing the correct environment for your installation.
An OpenStack solution is free to run its components wherever it want; its options range from running all components on z/VM, to running some on z/VM and others elsewhere, to running all components on other platforms. The solution is also free to source its components wherever it wants, by using z/VM’s OpenStack enablement components or not using the components.
6.4.3 z/VM System Management Architecture
z/VM includes a set of servers that provide local system management APIs. These servers consist of request servers that accept local connections, receive the data, and then call one of a set of worker servers to process the request. These servers are known collectively as SMAPI. The worker servers can interact with the z/VM hypervisor (CP) or with a directory manager. A directory manager is required for this environment.
Since z/VM version 6.3, more functions are provided by integrated xCAT services. xCAT is an open source scalable distributed computing management and provisioning tool that provides a unified interface for hardware control, discovery, and deployment, including remote access to the SMAPI APIs. It can be used for the deployment and administration of Linux servers that OpenStack wants to manipulate. The z/VM drivers in the OpenStack services communicate with xCAT services by using REST APIs to manage the virtual servers.
xCAT is composed of two main services: the xCAT management node (xCAT MN) and ZHCP. The xCAT MN server and the ZHCP server run within the same virtual machine, which is called the OPNCLOUD virtual machine.
The xCAT MN coordinates creating, deleting, and updating virtual servers. The management node uses a z/VM hardware control point (ZHCP) to communicate with SMAPI to implement changes on a z/VM host. Only one instance of the xCAT MN is necessary to support multiple z/VM hosts. Each z/VM host runs one instance of ZHCP. xCAT MN supports both a GUI for human interaction and REST APIs for use by programs (for example, OpenStack).
Next, we describe two examples of how you can use this environment.
CMA with z/VM in controller node
You configure the CMA on one z/VM system in the cloud (for example, z/VM 1) to run in the “controller” role so it sets up the OPNCLOUD virtual server to run the OpenStack cloud controller, OpenStack compute (managing the system on which it is running; for example, z/VM 1), xCAT MN, and ZHCP services.
You configure the CMA on all other z/VM systems (for example, z/VM 2) in the cloud to run in the “compute” role so they each set up one OPNCLOUD virtual server to run the OpenStack compute and ZHCP services that manage the system on which those services are running.
Because the xCAT MN service running in z/VM 1 manages all z/VM systems in the cloud through the ZHCP service running on each z/VM system, you do not run the xCAT MN service on any other systems in the cloud (in this case, on z/VM 2).
Each CMA installs the OpenStack code and configures its z/VM drivers automatically because all CMAs here are configured to run OpenStack compute services. The virtualization manager calls OpenStack cloud controller APIs when it must interact with the virtual servers OpenStack deploys on z/VM; these APIs are served by the OPNCLOUD virtual server on z/VM 1.
Services and virtual machines that run when a virtualization manager uses z/VM’s CMA as a cloud controller are shown in Figure 6-4. It also shows variations with one and two z/VM systems.
Figure 6-4 z/VM CMA in controller node
CMA with z/VM in an entry level cloud
You configure the CMA on one z/VM system in the cloud (for example, z/VM 1) to run in the “controller” role, so it sets up the OPNCLOUD virtual server to run the OpenStack cloud controller, OpenStack compute, xCAT MN, and ZHCP services.
You configure the CMA on all other z/VM systems (for example, z/VM 2) in the cloud to run in the “compute” role, so they each set up one OPNCLOUD virtual server to run the OpenStack compute and ZHCP services that manage the system on which those services are running. Because the xCAT MN service running in z/VM 1 manages all z/VM systems in the cloud through the ZHCP service running on each z/VM system, you do not run the xCAT MN service on any other systems in the cloud (in this case, on z/VM 2).
Each CMA installs the OpenStack code and configures its z/VM drivers automatically because all CMAs here are configured to run OpenStack compute services.
Figure 6-5 shows services and virtual machines that run when you use z/VM’s CMA as an entry level cloud, which you might do in preparation for adopting an OpenStack solution, for evaluation purposes, or to run an entry level z/VM-only cloud. It shows variations with one and two z/VM systems.
Figure 6-5 z/VM entry level cloud with compute node.
For more information about z/VM CMA for OpenStack Newton and server development patterns, see Enabling z/VM for OpenStack (Support for OpenStack Newton Release), SC24-6251, and Systems Management Application Programming (6.4), SC24-6327.
6.5 CMA Controller node
When the CMA is in controller node mode, it can be used in the following ways:
•A stand-alone OpenStack environment
CMA acts as an xCAT MN and controller and as the compute node and ZHCP for the z/VM LPAR on which it is running.
•Multi-region OpenStack environment
Other z/VM LPAR CMAs are defined as compute nodes and run the xCAT ZHCP function, and are controlled by the controller CMA.
•Integrated with other z/VM LPARs
Other z/VM LPAR CMAs are defined as compute nodes and run the xCAT ZHCP function, and are controlled by the controller CMA.
Figure 6-6 shows the CMA for z/VM controller and compute nodes.
Figure 6-6 CMA for z/VM controller and compute nodes
The following files are used to configure the CMA Newton (6.4) as the Controller node:
•DMSSICNF COPY
•DMSSICMO COPY
6.5.1 DMSSICNF COPY for the controller node
The DMSSICNF COPY file contains several global attributes that can be modified to better fit your installation. In this case, it is defined on the RDBKZVM1 LPAR.
 
Note: When modifying this file, note that it is case-sensitive. When xediting it, always run the case mixed command.
Example 6-23 shows a DMSSICNF COPY.
Example 6-23 DMSSICNF COPY example of using CMA
/*********************************************************************/
/* XCAT server defaults */
/*********************************************************************/
XCAT_User = "OPNCLOUD" /* xCAT z/VM user ID */
XCAT_Addr = "10.10.10.10" /* XCAT IP Address */
XCAT_Host = "opncloud" /* xCAT hostname */
XCAT_Domain = ".cpolab.ibm.com" /* Main name */
XCAT_vswitch = "XCATVSW1" /* xCAT Vswitch name */
XCAT_OSAdev = "NONE" /* OSA address for xCAT */
XCAT_zvmsysid = "RDBKZVM1" /* xCAT z/VM system id */
XCAT_notify = "OPERATOR" /* Notify when xCAT started */
XCAT_gateway = "NONE" /* Network gateway IP addr. */
XCAT_netmask = "255.255.255.0" /* Default network mask */
XCAT_vlan = "NONE"
XCAT_MN_Addr = "9.76.61.215" /* xCAT mgmt node IP address */
XCAT_MN_vswitch = "XCATVSW2" /* xCAT MN Vswitch name */
XCAT_MN_OSAdev = "1B14" /* OSA address for xCAT MN */
XCAT_MN_gateway = "9.76.61.1" /* Network gateway IP addr. */
XCAT_MN_Mask = "255.255.255.0" /* Netmask for xCAT MN */
XCAT_MN_vlan = "2230"
XCAT_MN_admin = "mnadmin" /* MN administrator userid */
XCAT_MN_pw = "yourppw" /* MN admin password */
/* (if NOLOG, userid cannot */
/* ssh into XCAT MN) */
/*********************************************************************/
/* ZHCP server defaults */
/*********************************************************************/
ZHCP_User = "OPNCLOUD" /* zhcp z/VM user ID */
ZHCP_Addr = "NONE" /* zhcp IP ADDRESS */
ZHCP_Host = "zhcpzvm1" /* zhcp hostname */
ZHCP_Domain = ".cpolab.ibm.com" /* Domain name */
ZHCP_gateway = "NONE" /* Network gateway IP addr. */
ZHCP_netmask = "NONE" /* Default network mask */
ZHCP_vswitch = "NONE" /* zhcp Vswitch name */
ZHCP_OSAdev = "NONE" /* OSA address for zhcp */
ZHCP_vlan = "NONE"
/*********************************************************************/
The following configuration options are available:
XCAT_Domain OpenStack controller domain name
XCAT_OSAdev XCATVSW1 (for xCAT internal network) real OSA device address
XCAT_zvmsysid z/VM SYSID where OpenStack controller runs (lowercase)
XCAT_MN_Addr OpenStack controller (xCAT Management Node) IP address
XCAT_MN_OSAdev XCATVSW2 (for management network) real OSA device address
XCAT_MN_gateway OpenStack controller default gateway
XCAT_MN_netmask OpenStack controller default netmask
XCAT_MN_pw xCAT Management Node (mnadmin) default password, which should be changed during setup
ZHCP_Host ZHCP host name
ZHCP_Domain ZHCP domain name
ZHCP_OSAdev ZHCP (internal network) real OSA device address
 
Note: XCAT_MN_vswitch is the z/VM Virtual Switch for the management network. The default value is XCATVSW2. Do not change it.
6.5.2 DMSSICMO COPY file for the controller node
CMA configures its services based on the properties in the DMSSICMO configuration file that contains the CMA and OpenStack parameters. This includes whether this CMA is a controller node (user functions and a compute node) or a compute node only (managed by another controller node). A script reads the data in this file and updates various OpenStack configuration files when the server starts.
 
Note: When modifying this file, note that it is case-sensitive. When xediting it, always run the case mixed i command.
Example 6-24 shows a DMSSICMO COPY example of the use of CMA.
Example 6-24 DMSSICMO COPY example of using CMA
/*********************************************************************/
/* CMO User Configurable Settings */
/*********************************************************************/
cmo_admin_password = "cmopass"
cmo_data_disk = "LXBK01 LXBK02"
openstack_system_role = "controller"
openstack_controller_address = "ip address"
openstack_zvm_diskpool = "ECKD:yourname"
openstack_instance_name_template = "dfltlnx"
openstack_zvm_fcp_list = "NONE"
openstack_zvm_timeout = "300"
openstack_zvm_scsi_pool = "NONE"
openstack_zvm_zhcp_fcp_list = "NONE"
openstack_san_ip = "NONE"
openstack_san_private_key = "NONE"
openstack_storwize_svc_volpool_name = "NONE"
openstack_storwize_svc_vol_iogrp = "NONE"
openstack_zvm_image_default_password = "password"
openstack_xcat_mgt_ip = "10.10.10.10"
openstack_xcat_mgt_mask = "255.255.255.0"
openstack_zvm_xcat_master = "yourlparname"
openstack_zvm_vmrelocate_force = "NONE"
openstack_default_network = "9.76.61.1-9.16.8.29/2"
openstack_zvm_xcat_service_addr = "9.16.8.23"
openstack_volume_enable_multipath = "FALSE"
The following configuration options are available:
cmo_admin_password OpenStack controller default password, which is changed inside the guest operating system during initial configuration.
cmo_data_disk VOLIDs for OpenStack controller data disk.
openstack_system_role OpenStack controller role.
openstack_zvm_diskpool IBM ECKD™ or FBA:DIRMAINT definition for OpenStack disk pool.
openstack_instance_name_template z/VM user ID instance name template.
openstack_zvm_image_defaults_password Default root password for deployed instances, which should be changed inside the guest operating system during initial configuration. Consider making this option AUTOONLY or LBYONLY.
openstack_zvm_xcat_master xCAT Management Node name.
 
Note: For the SCSI environment, the value that is used for configuration option was openstack_zvm_diskpool = “FBA:xxxxx”.
6.6 CMA compute node
The compute node configuration allows the CMA to integrate into an OpenStack environment as a compute node. In this case, the z/VM drivers are not needed in the other OpenStack environment because that function is part of the OpenStack services on the compute node.
6.6.1 DMSSICNF COPY file for the compute node
The DMSSICNF COPY file contains several global attributes that can be modified to better fit your installation. In this case, you define it on the ITSOVM2 LPAR.
 
Note: When modifying this file, note that it is case-sensitive. When xediting it, always run the case mixed i command.
Example 6-25 shows a DMSSICNF COPY example of the use of CMA.
Example 6-25 DMSSICNF COPY example of using CMA
/*********************************************************************/
/* XCAT server defaults */
/*********************************************************************/
XCAT_User = "OPNCLOUD" /* xCAT z/VM user ID */
XCAT_Addr = "10.10.10.30" /* XCAT IP Address */
XCAT_Host = "xcat2" /* xCAT hostname */
XCAT_Domain = ".cpolab.ibm.com" /* Main name */
XCAT_vswitch = "XCATVSW1" /* xCAT Vswitch name */
XCAT_OSAdev = "2126" /* OSA address for xCAT */
XCAT_zvmsysid = "rdbkzvm2" /* xCAT z/VM system id */
XCAT_notify = "OPERATOR" /* Notify when xCAT started */
XCAT_gateway = "10.10.10.1" /* Network gateway IP addr. */
XCAT_netmask = "255.255.255.0" /* Default network mask */
XCAT_vlan = "NONE"
XCAT_iso = ""
XCAT_MN_Addr = "ip address" /* xCAT mgmt node IP address */
XCAT_MN_vswitch = "XCATVSW2" /* xCAT MN Vswitch name */
XCAT_MN_OSAdev = "2106" /* OSA address for xCAT MN */
XCAT_MN_gateway = "x.xx.x.1" /* Network gateway IP addr. */
XCAT_MN_Mask = "255.255.240.0" /* Netmask for xCAT MN */
XCAT_MN_vlan = "NONE"
XCAT_MN_admin = "mnadmin" /* MN administrator userid */
XCAT_MN_pw = "yourppsw" /* MN admin password */
/* (if NOLOG, userid cannot */
/* ssh into XCAT MN) */
/*********************************************************************/
/* ZHCP server defaults */
/*********************************************************************/
ZHCP_User = "ZHCP" /* zhcp z/VM user ID */
ZHCP_Addr = "10.10.10.40" /* zhcp IP ADDRESS */
ZHCP_Host = "zhcp2" /* zhcp hostname */
ZHCP_Domain = ".itso.ibm.com" /* zhcp domain name */
ZHCP_gateway = "10.10.10.1" /* Network gateway IP addr. */
ZHCP_netmask = "255.255.255.0" /* Default network mask */
ZHCP_vswitch = "XCATVSW1" /* zhcp Vswitch name */
ZHCP_OSAdev = "2126" /* OSA address for zhcp */
ZHCP_vlan = "NONE"
/*********************************************************************/
The following configuration options are available:
XCAT_Domain OpenStack compute domain name
XCAT_OSAdev XCATVSW1 (for xCAT internal network) real OSA device address
XCAT_zvmsysid z/VM SYSID where OpenStack controller run (lowercase)
XCAT_MN_Addr OpenStack controller (xCAT Management Node) IP address
XCAT_MN_OSAdev XCATVSW2 (for management network) real OSA device address
XCAT_MN_gateway OpenStack controller default gateway
XCAT_MN_netmask OpenStack controller default netmask
XCAT_MN_pw xCAT Management Node (mnadmin) default password
ZHCP_Host ZHCP host name
ZHCP_Domain ZHCP domain name
ZHCP_OSAdev ZHCP (internal network) real OSA device address
 
Note: XCAT_MN_vswitch is the z/VM Virtual Switch for the management network. The default value is XCATVSW2. Do not change it.
6.6.2 DMSSICMO COPY file for the compute node
CMA configures its services based on the properties in the DMSSICMO configuration file, which contains the CMA and OpenStack parameters. This configuration includes whether this CMA is a controller node (user functions and a compute node) or a compute node only (managed by another ICM controller node). A script reads the data in this file and updates various OpenStack configuration files when the server starts.
 
Note: When modifying this file, note that it is case-sensitive. When xediting it, always run the case mixed i command.
Example 6-26 shows a DMSSICMO COPY example of the use of CMA.
Example 6-26 DMSSICMO COPY example of using CMA
/*********************************************************************/
/* CMO User Configurable Settings */
/*********************************************************************/
cmo_admin_password = "yourppw"
cmo_data_disk = "volid1 volid2 volid3 volid4"
openstack_system_role = "compute"
openstack_controller_address = "ip address"
openstack_zvm_diskpool = "ECKD:xxxx"
openstack_instance_name_template = "osp%05x"
openstack_zvm_fcp_list = "NONE"
openstack_zvm_timeout = "300"
openstack_zvm_scsi_pool = "NONE"
openstack_zvm_zhcp_fcp_list = "NONE"
openstack_san_ip = "NONE"
openstack_san_private_key = "NONE"
openstack_storwize_svc_volpool_name = "NONE"
openstack_storwize_svc_vol_iogrp = "NONE"
openstack_zvm_image_default_password = "yourppw"
openstack_xcat_mgt_ip = "NONE"
openstack_xcat_mgt_mask = "NONE"
openstack_zvm_xcat_master = "xcat1"
openstack_zvm_vmrelocate_force = "NONE"
openstack_default_network = "NONE"
openstack_zvm_xcat_service_addr = "“
openstack_volume_enable_multipath = "FALSE"
The following configuration options are available:
cmo_admin_password OpenStack controller default password
cmo_data_disk VOLIDs for OpenStack controller data disk
openstack_system_role OpenStack controller role
openstack_zvm_diskpool ECKD or FBA:DIRMAINT region for OpenStack disk pool
openstack_instance_name_template z/VM user ID instance name template
openstack_zvm_image_defaults_password Default root password for deployed instances
openstack_zvm_xcat_master xCAT Management Node name
 
Note: For the SCSI environment, the value that is used for the configuration option was openstack_zvm_diskpool = “FBA:xxxxx”.
To add compute nodes for other LPARs on your environment, repeat the definitions that are described in this chapter by updating the specific information for the LPAR.
For more information about CMA for OpenStack Newton, see Enabling z/VM for OpenStack (Support for OpenStack Newton Release), SC24-6251, and Systems Management Application Programming (6.4), SC24-6327.
6.7 CMA installation
The instructions that are presented in this section are for installing the z/VM 6.4 CMA on an existing z/VM 7.1 system. The CMA running on 7.1 requires SMAPI running at the 6.4 version. You cannot run the 7.1 version of SMAPI at the same time as the CMA. The 7.1 version of SMAPI remains installed and available if you want to run the 7.1 version of SMAPI in the future.
The z/VM 6.4 CMA running on z/VM 7.1 requires that the z/VM 6.4 version of SMAPI is operational and the CMA-specific configuration values and files be available on z/VM 7.1. This process includes the following tasks:
•Install (restore) SMAPI 6.4 on your 7.1 system (leaving your 7.1 SMAPI code intact) and configure your SMAPI servers to use the 6.4 level of SMAPI.
•Create the CMA user ID (OPNCLOUD) and allocate the necessary resources. Install (restore) the CMA code.
•Authorize OPNCLOUD with your ESM, SMAPI, and Directory Manager.
•Configure SMAPI and OPNCLOUD as documented and appropriate for your specific needs.
To install and run CMA Newton, you need the MDisks that are listed in Table 6-1.
Table 6-1 Required MDisks
Owner
Virtual
address
Volume use
ECKD
cylinders
OPNCLOUD
191
OPNCLOUD 191 disk
1
OPNCLOUD
101
CMA Newton first System disk
3338
OPNCLOUD
102
CMA Newton second System disk
3338
MAINT710
102
Packed copy of CMA101 ECKPDPACK file
3338
MAINT710
103
Packed copy of CMA102 ECKPDPACK file
3338
MAINT710
104
Unpacked copy of CMA101 ECKD file
3338
MAINT710
105
Unpacked copy of CMA102 ECKD file
3338
MAINT710
106
Packed copy of MNT1193 ECKDDPACK file
500
MAINT710
107
Unpacked copy of MNT1193 ECKD file
500
MAINT
1193
Restored MAINT 1193 disk
500
If you use a CP directory management tool, such as DirMaint, use the appropriate directory management tool commands to add this MDisk. If you are not using a directory management tool, use XEDIT to change your CP user directory by using your local change management procedures.
 
Note: To get the CMA Newton package, contact your IBM representative or IBM account team because this option is restricted to ICP customers.
The following materials are available from your IBM account team:
•MNT1193 ECKDPACK file. This file is a DDR image to be restored on the new MAINT 1193 virtual disk you create.
•CMA101 ECKDPACK file. This file is a DDR image to be restored on the new OPNCLOUD 0101 virtual disk you create.
•CMA102 ECKDPACK file. This file is a DDR image to be restored on the new OPNCLOUD 0101 virtual disk you create.
 
Note: The files must be transferred to your z/VM system as binary, fixed-length record format files with a logical record length of 1024.
6.7.1 Initial set-up
Complete the following steps to create the OPNCLOUD user ID and disks that are required for the installation:
1. Use the definitions that are found Appendix H, “OPNCLOUD Directory Entry” of Systems Management Application Programming Version 6 Release 4, SC24-6234.
2. Using Table 6-1 on page 185, create the required MDisks for MAINT710 and MAINT. The OPNCLOUD 101, 102, and 191 MDisks were created as part of adding the OPNCLOUD user ID to your system. If these MDisks were not created, create them now.
6.7.2 Installing SMAPI 6.4 on your 7.1 system
This step installs a copy of z/VM 6.4 SMAPI on your z/VM 7.1 system. The 7.1 SMAPI code is not overwritten or removed from your system. The 6.4 version of SMAPI is on the MAINT 1193 disk. The 7.1 SMAPI code remains on the MAINT 193 disk.
Complete the following steps to restore the contents of the MAINT 1193 disk:
1. Run the CP LINK * 106 106 MR command from MAINT710.
2. Run the CP LINK * 107 170 MR command from MAINT710.
3. Run the CP LINK MAINT 1193 1193 MR command from MAINT710.
4. Run the FORMAT 106 T command from MAINT710:
 – Answer 1 when prompted to format.
 – Answer MNT106 when prompted to provide a label.
5. Run the FORMAT 107 U command from MAINT710:
 – Answer 1 when prompted to format.
 – Answer MNT107 when prompted to provide a label.
6. Run the FORMAT 1193 V command from MAINT710:
 – Answer 1 when prompted to format.
 – Answer MN1193 when prompted to provide a label.
7. Run the CP DETACH 106 command from MAINT710.
8. Use FTP to move the MNT1193 ECKDPACK file from your workstation to z/VM.
 
Note: All ECKDPACK files must be transferred as a binary, fixed-length record format with a logical record length of 1024 file.
9. From your workstation command prompt, enter the following information:
 – FTP ipaddr_VM_system
 – USER MAINT710
 – Password
10. Run the CP DETACH 106 command from MAINT710.
11. Use FTP to move the MNT1193.ECKDPACK file from your workstation to z/VM.
12. Use FTP to move the MNT1193 ECKDPACK file from your workstation to z/VM.
13. From your workstation command prompt, enter the following information:
 – FTP ipaddr_VM_system
 – USER MAINT710
 – Password
The DDRREST command displays out that is similar to the output that is shown in Example 6-27.
Example 6-27 DDRREST messages
z/VM DASD DUMP/RESTORE PROGRAM
HCPDDR698I DATA DUMPED FROM OCSYS1 TO BE RESTORED
HCPDDR697I NO VOL1 LABEL FOUND
RESTORING MT1193
DATA DUMPED mm/dd/yy AT hh.mm.ss GMT FROM MNT1193 RESTORED
INPUT CYLINDER EXTENTS OUTPUT CYLINDER EXTENTS
START STOP START STOP
0 499 0 499
END OF RESTORE
BYTES RESTORED xxxxxxxxx
 
END OF JOB
6.7.3 Installing the CMA files on your z/VM 7.1 system
Log on to the MAINT710 user ID. You use the MDisks that were defined to hold the restorable CMA images (virtual device addresses: 102-105). These four MDisks are owned by the MAINT710 user ID and are defined as the sizes listed in the Table 6-1 on page 185. They contain copies of the CMA images that are provided by your IBM representatives.
These copies must exist only on your z/VM 7.1.0 system until the CMA is restored and running. If you are in a multi-member SSI, these MDisks can be shared across the MAINT710 members in the SSI cluster.
 
Note: To get the CMA Newton package, contact your IBM representative or IBM account team because this option is restricted to ICP customers.
After defining these MDisks to the MAINT710 user ID, make them accessible to MAINT710. Complete the following steps:
1. Run the CP LINK * 102 102 MR command.
2. Run the CP LINK * 103 103 MR command.
3. Run the CP LINK * 104 104 MR command,
4. Run the CP LINK * 105 105 MR command.
5. Run the FORMAT 102 T command:
 – When prompted, respond 1.
 – When prompted again, respond MNT102.
6. Run the FORMAT 103 U command:
 – When prompted, respond 1.
 – When prompted again, respond MNT103.
7. Run the FORMAT 104 V command:
 – When prompted, respond 1.
 – When prompted again, respond MNT104.
8. Run the FORMAT 105 W command:
 – When prompted, respond 1.
 – When prompted again, respond MNT105.
9. Run the following commands:
 – CP DETACH 102
 – CP DETACH 103
10. Use FTP to move the CMA files from your workstation to z/VM. These files must be transferred as binary, fixed-length record format with a logical record length of 1024 files.
From your workstation command prompt, enter the following commands, one at a time:
1. FTP ipaddr_VM_system
2. USER MAINT710
3. password
4. BIN
5. QUOTE SITE FIXRECFM 1024
6. CD MAINT710.102
7. PUT CMA101.ECKDPACK CMA101.ECKDPACK
8. CD MAINT710.103
9. PUT CMA102.ECKDPACK CMA102.ECKDPACK
10. QUIT
Back on the z/VM MAINT710 user ID, copy the packed CMA image files to unpacked image files using the following commands:
1. CP LINK * 102 102 RR
2. ACCESS 102 T
3. CP LINK * 103 103 RR
4. ACCESS 103 U
5. COPYFILE CMA101 ECKDPACK T CMA101 ECKD V ( UNPACK OLDDATE
6. COPYFILE CMA102 ECKDPACK U CMA102 ECKD W ( UNPACK OLDDATE
6.7.4 Restoring the CMA files
Now that the CMA image files are on your z/VM 7.1.0 system, you must restore the image files to the OPNCLOUD 101 and 102 minidisks. While still logged on to MAINT710, enter the following commands:
1. DET 101-102
2. LINK OPNCLOUD 101 101 MR
3. LINK OPNCLOUD 102 102 MR
4. ACCESS 193 R
5. ACCESS 104 V
6. ACCESS 105 W
7. DDRREST 101 CMA101 ECKD V
8. DDRREST 102 CMA102 ECKD W
The use of the DDRREST command displays output that is similar to the output that is shown in Example 6-28.
Example 6-28 DDREREST messages
z/VM DASD DUMP/RESTORE PROGRAM
HCPDDR698I DATA DUMPED FROM OCSYS1 TO BE RESTORED
HCPDDR697I NO VOL1 LABEL FOUND
RESTORING OCSYS1
DATA DUMPED mm/dd/yy AT hh.mm.ss GMT FROM OCSYS1 RESTORED
INPUT CYLINDER EXTENTS OUTPUT CYLINDER EXTENTS
START STOP START STOP
0 3337 0 3337
END OF RESTORE
BYTES RESTORED 2467590380
 
Note: Be careful to verify the extents that are copied and bytes restored values.
After restoring the CMA to the OPNCLOUD 101 minidisk and 102 minidisk, run the DETACH 101-102 command to relinquish control of the MDisks.
6.7.5 Configuring to use CMA 6.4 (Newton)
The following configuration changes also must be made to your z/VM 7.1 system for the CMA:
•Make a copy of the 6.4 version of SSPSTART EXEC and OPNCLOUD SAMPPROF by running the following commands from MAINT710:
LINK OPNCLOUD 191 91 MR
LINK MAINT 1193 1193 RR
ACCESS 91 G
ACCESS 1193 H
COPYFILE SSPSTART EXEC H SSPSTART EXEC G (OLDDATE
COPYFILE OPNCLOUD SAMPPROF H PROFILE EXEC G (OLDDATE
RELEASE G (DETACH
RELEASE H
•Point the new MAINT 1193 MDisk.
The MAINT 193 disk is at the z/VM 7.1 level. However, the CMA requires the files on the 193 disk be at the z/VM 6.4 level. To do this, the following USERS must be updated to have their virtual 193 disk use the MAINT 1193 disk:
 – VSMGUARD
 – VSMWORK1
 – VSMWORK2
 – VSMWORK3
 – VSMWORKx (if you added SMAPI worker servers)
 – VSMREQIU
 – VSMREQIN
 – VSMREQI6
 – LOHCOST
 – OPNCLOUD
These user IDs are all IDENTITY users in an SSI-enabled directory. The appropriate SUBCONFIG entry should be updated for each IDENTITY.
Change from:
LINK MAINT 0193 0193 RR
To:
LINK MAINT 1193 0193 RR
•The startup of OPNCLOUD might generate several error messages that include the text “failed to get suitable CP”. These messages are informational only and can be safely ignored.
For more information about how to configure SMAPI and CMA, see Systems Management Application Programming version 6 release 4, Enabling z/VM for OpenStack (Support for OpenStack Newton Release) version 6 release 4, SC24-6253.
Stop using CMA 6.4 (Newton)
To stop using the 6.4 CMA on z/VM 7.1 and switch to the 7.1 version of SMAPI, the following servers should have their directory entries changed as described next:
•VSMGUARD
•VSMWORK1
•VSMWORK2
•VSMWORK3
•VSMWORKx (if you added SMAPI worker servers)
•VSMREQIU
•VSMREQIN
•VSMREQI6
•LOHCOST
•OPNCLOUD
These user IDs are all IDENTITY users. In an SSI-enabled directory, the appropriate SUBCONFIG entry should be updated for each IDENTITY.
Change from:
LINK MAINT 1193 0193 RR
To:
LINK MAINT 0193 0193 RR
No other changes are required. Restart SMAPI by FORCEing and XAUTOLOGging VSMGUARD.
 
6.8 Securing your cloud components
A Cloud on z/VM environment might use several components. It is important to protect each of the components.
The cloud components on z/VM can be protected with most of what is described in Chapter 3, “IBM z/VM hypervisor” on page 25, but that does not remove the need for an ESM. When using RACF to control your cloud resources, grant the VMs only the bare minimum privileges required to perform their intended tasks.
As described in 5.1.1, “Least privilege principle” on page 108, do not allow the VMs to exceed the scope of their responsibility.
It is important to have your company’s security policy job roles relate to the cloud, such as a cloud administrator and a cloud auditor. Make sure the job roles that are related to the cloud also have their accesses described in the security policy, and that those accesses are implemented across the cloud environment.
Integrating the identity management across the cloud environment makes it easy to manage. Since z/VM 6.3, OpenStack Keystone is supported for installation-wide authentication and authorization to OpenStack Services.
The use of the identity integration brings some important capabilities to the cloud environment and z/VM, including authenticating user and password requests against multiple back ends, such as SQL or LDAP, as described in 8.2, “Lightweight Directory Access Protocol” on page 246.
The following key service capabilities also are available:
•Token: Validates and manages tokens for user authentication
•Catalog: Allows for endpoint registry of available services.
•Policy: Authorizes API requests, and others, such as domain, project, and user models with role-based access control (RBAC) for access compute, storage, and networking.
Table 6-2 lists the security mechanisms that are available when a cloud environment is deployed on top of z/VM. Because the cloud can be composed of several components, careful attention should be given to each component to prevent eventual security breaches across your environment.
Table 6-2 Security mechanisms in a private cloud on z/VM environment
z/VM and CMA cloud layers
Security mechanism
Risks addressed
CMA (OpenStack Controller)
•Projects
•Roles and RBAC
•Identity management
•Account hijacking
•Malicious insiders
OpenStack (Compute Node)
•Tenancy
•HTTPS (encryption)
•Insecure APIs
•Denial of service
xCAT
•Identity management
•SSH (encryption)
•Insecure APIs
•Abuse and nefarious use
SMAPI
•RBAC by API
•TLS (encryption)
•Insecure APIs
•Malicious insiders
DirMaint for z/VM
•Resource access control
•Auditing
•Data loss
•Insufficient due diligence
z/VM (CP with RACFVM)
•Guest isolation
•Privilege classes
•RBAC
•Security zones
•Auditing (SMF)
•Data breaches
•Account hijacking
•Abuse and nefarious use
•Insufficient due diligence
•Shared technology issues
6.8.1 Security considerations inherent in a cloud environment
In this section, we describe guidelines for security and privacy in a cloud computing environment.
Governance
Extend organizational practices that pertain to the policies, procedures, and standards that are used for application development and service provisioning in the cloud, and the design, implementation, testing, use, and monitoring of deployed or engaged services.
Put in place audit mechanisms and tools to ensure that organizational practices are followed throughout the system lifecycle.
Compliance
Understand the various types of laws and regulations that impose security and privacy obligations on the organization and potentially affect cloud computing initiatives, particularly those involving data location, privacy and security controls, records management, and electronic discovery requirements.
Review and assess the cloud provider’s offerings regarding the organizational requirements to be met and ensure that the contract terms adequately meet the requirements. Ensure that the cloud provider’s electronic discovery capabilities and processes do not compromise the privacy or security of data and applications.
Trust
Ensure that service arrangements have sufficient means to allow visibility into the security and privacy controls and processes that are used by cloud computing and their performance over time. Establish clear, exclusive ownership rights over data.
Institute a risk management program that is flexible enough to adapt to the constantly evolving and shifting risk landscape for the lifecycle of the system. Continuously monitor the security state of the information system to support on-going risk management decisions.
Architecture
Understand the underlying technologies that the cloud computing uses to provision services, including the implications that the technical controls involved have on the security and privacy of the system, over the full system lifecycle, and across all system components.
IdEA Mgmt
Ensure that adequate safeguards are in place to secure authentication, authorization, and other identity and access management functions, and are suitable for the organization.
Software isolation
Understand virtualization and other logical isolation techniques that the cloud provider employs in its multi-tenant software architecture, and assess the risks involved for the organization.
Data protection
Evaluate the suitability of the cloud computing’s data management solutions for the organizational data concerned and the ability to control access to data to secure data while at rest, in transit, and in use, and to sanitize data.
Consider the risk of collating organizational data with that of other organizations whose threat profiles are high or whose data collectively represent significant concentrated value. Fully understand and weight the risks that are involved in cryptographic key management with the facilities that are available in the cloud environment and the processes that are established by the cloud provider.
Availability
Understand the contract provisions and procedures for availability, data backup and recovery, and disaster recovery, and ensure that they meet the organization’s continuity and contingency planning requirements. Ensure that during an intermediate or prolonged disruption or a serious disaster, critical operations can be immediately resumed, and that all operations can be eventually reinstituted in a timely and organized manner.
Incident response
Understand the contract provisions and procedures for incident response and ensure that they meet the requirements of the organization. Ensure that the cloud computing has a transparent response process in place and sufficient mechanisms to share information during and after an incident.
Also, ensure that the organization can respond to incidents in a coordinated fashion with the cloud environment in accordance with their respective roles and responsibilities for the computing environment.
6.8.2 Security tips for the cloud
In this section, we describe some security tips for the cloud.
Do not forget the basics
Consider the following points:
•Access controls and incidence response do not go away in the cloud.
•Be mindful of asset-tracking, data flow, and change management.
•Your data is of varying classifications; therefore, use multi-tenant features when pertinent.
Use cloud to enhance security
Consider the following points:
•Cloud offers rapid scale of environments and networking.
•Employ Security as a Service for varying definitions of security, such as threat and intrusion detection, and vulnerability scanning mechanisms.
•Standardizing means less variability, which can mean fewer surprises.
Understand your cloud’s capabilities
Consider the following points:
•Determine whether your provider is part of your company or a third party.
•Establish clear roles and communication paths for escalations and incident management.
•Understand where the data must be stored (for regulatory and geopolitical reasons) and who is the owner and can access it.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.117.231.15