|
| 1 | +zVM |
| 2 | +=== |
| 3 | + |
| 4 | +z/VM System Requirements |
| 5 | +~~~~~~~~~~~~~~~~~~~~~~~~ |
| 6 | + |
| 7 | +* The appropriate APARs installed, the current list of which can be found: z/VM |
| 8 | + OpenStack Cloud Information (http://www.vm.ibm.com/sysman/osmntlvl.html). |
| 9 | + |
| 10 | +.. note:: |
| 11 | + |
| 12 | + IBM z Systems hardware requirements are based on both the applications and |
| 13 | + the load on the system. |
| 14 | + |
| 15 | +Active Engine Guide |
| 16 | +~~~~~~~~~~~~~~~~~~~ |
| 17 | + |
| 18 | +Active engine is used as an initial configuration and management tool during |
| 19 | +deployed machine startup. Currently the z/VM driver uses ``zvmguestconfigure`` |
| 20 | +and ``cloud-init`` as a two stage active engine. |
| 21 | + |
| 22 | +Installation and Configuration of zvmguestconfigure |
| 23 | +--------------------------------------------------- |
| 24 | + |
| 25 | +Cloudlib4zvm supports initiating changes to a Linux on z Systems virtual |
| 26 | +machine while Linux is shut down or the virtual machine is logged off. |
| 27 | +The changes to Linux are implemented using an activation engine (AE) |
| 28 | +that is run when Linux is booted the next time. The first active engine, |
| 29 | +``zvmguestconfigure``, must be installed in the Linux on z Systems virtual |
| 30 | +server so it can process change request files transmitted by the |
| 31 | +cloudlib4zvm service to the reader of the virtual machine as a class X file. |
| 32 | + |
| 33 | +.. note:: |
| 34 | + |
| 35 | + An additional activation engine, cloud-init, should be installed to handle |
| 36 | + OpenStack related tailoring of the system. |
| 37 | + The cloud-init AE relies on tailoring performed by ``zvmguestconfigure``. |
| 38 | + |
| 39 | +Installation and Configuration of cloud-init |
| 40 | +-------------------------------------------- |
| 41 | + |
| 42 | +OpenStack uses cloud-init as its activation engine. Some Linux distributions |
| 43 | +include cloud-init either already installed or available to be installed. |
| 44 | +If your distribution does not include cloud-init, you can download |
| 45 | +the code from https://launchpad.net/cloud-init/+download. |
| 46 | +After installation, if you issue the following |
| 47 | +shell command and no errors occur, cloud-init is installed correctly:: |
| 48 | + |
| 49 | + cloud-init init --local |
| 50 | + |
| 51 | +Installation and configuration of cloud-init differs among different Linux |
| 52 | +distributions, and cloud-init source code may change. This section provides |
| 53 | +general information, but you may have to tailor cloud-init |
| 54 | +to meet the needs of your Linux distribution. You can find a |
| 55 | +community-maintained list of dependencies at http://ibm.biz/cloudinitLoZ. |
| 56 | + |
| 57 | +As of the Rocky release, the z/VM OpenStack support has been tested with |
| 58 | +cloud-init 0.7.4 and 0.7.5 for RHEL6.x and SLES11.x, 0.7.6 for RHEL7.x and |
| 59 | +SLES12.x, and 0.7.8 for Ubuntu 16.04. |
| 60 | + |
| 61 | +During cloud-init installation, some dependency packages may be required. |
| 62 | +You can use zypper and python setuptools to easily resolve these dependencies. |
| 63 | +See https://pypi.python.org/pypi/setuptools for more information. |
| 64 | + |
| 65 | +Image guide |
| 66 | +~~~~~~~~~~~ |
| 67 | + |
| 68 | +This guideline will describe the requirements and steps to create and |
| 69 | +configure images for use with z/VM. |
| 70 | + |
| 71 | +Image Requirements |
| 72 | +------------------ |
| 73 | + |
| 74 | +* The following Linux distributions are supported for deploy: |
| 75 | + |
| 76 | + * RHEL 6.2, 6.3, 6.4, 6.5, 6.6, and 6.7 |
| 77 | + * RHEL 7.0, 7.1 and 7.2 |
| 78 | + * SLES 11.2, 11.3, and 11.4 |
| 79 | + * SLES 12 and SLES 12.1 |
| 80 | + * Ubuntu 16.04 |
| 81 | + |
| 82 | +* A supported root disk type for snapshot/spawn. The following are supported: |
| 83 | + |
| 84 | + * FBA |
| 85 | + * ECKD |
| 86 | + |
| 87 | +* An image deployed on a compute node must match the disk type supported by |
| 88 | + that compute node, as configured by the ``zvm_diskpool_type`` property in |
| 89 | + the `zvmsdk.conf`_ configuration file in `zvm cloud connector`_ |
| 90 | + A compute node supports deployment on either an ECKD or FBA image, |
| 91 | + but not both at the same time. If you wish to switch image types, |
| 92 | + you need to change the ``zvm_diskpool_type`` and |
| 93 | + ``zvm_diskpool`` properties in the `zvmsdk.conf`_ file, accordingly. |
| 94 | + Then restart the nova-compute service to make the changes take effect. |
| 95 | + |
| 96 | +* If you deploy an instance with an ephemeral disk, both the root disk and the |
| 97 | + ephemeral disk will be created with the disk type that was specified by |
| 98 | + ``zvm_diskpool_type`` property in the `zvmsdk.conf`_ file. That property can |
| 99 | + specify either ECKD or FBA. |
| 100 | + |
| 101 | +* The network interfaces must be IPv4 interfaces. |
| 102 | + |
| 103 | +* Image names should be restricted to the UTF-8 subset, which corresponds to |
| 104 | + the ASCII character set. In addition, special characters such as ``/``, ``\``, |
| 105 | + ``$``, ``%``, ``@`` should not be used. For the FBA disk type "vm", |
| 106 | + capture and deploy is supported only for an FBA disk with a single partition. |
| 107 | + Capture and deploy is not supported for the FBA disk type "vm" on a CMS |
| 108 | + formatted FBA disk. |
| 109 | + |
| 110 | +* The virtual server/Linux instance used as the source of the new image should |
| 111 | + meet the following criteria: |
| 112 | + |
| 113 | + 1. The root filesystem must not be on a logical volume. |
| 114 | + |
| 115 | + 2. The minidisk on which the root filesystem resides should be a minidisk of |
| 116 | + the same type as desired for a subsequent deploy (for example, an ECKD disk |
| 117 | + image should be captured for a subsequent deploy to an ECKD disk). |
| 118 | + |
| 119 | + 3. The minidisks should not be a full-pack minidisk, since cylinder 0 on |
| 120 | + full-pack minidisks is reserved, and should be defined with virtual |
| 121 | + address 0100. |
| 122 | + |
| 123 | + 4. The root disk should have a single partition. |
| 124 | + |
| 125 | + 5. The image being captured should not have any network interface cards (NICs) |
| 126 | + defined below virtual address 1100. |
| 127 | + |
| 128 | +In addition to the specified criteria, the following recommendations allow for |
| 129 | +efficient use of the image: |
| 130 | + |
| 131 | +* The minidisk on which the root filesystem resides should be defined as a |
| 132 | + multiple of full gigabytes in size (for example, 1GB or 2GB). |
| 133 | + OpenStack specifies disk sizes in full gigabyte values, whereas z/VM |
| 134 | + handles disk sizes in other ways (cylinders for ECKD disks, blocks for FBA |
| 135 | + disks, and so on). See the appropriate online information if you need to |
| 136 | + convert cylinders or blocks to gigabytes; for example: |
| 137 | + http://www.mvsforums.com/helpboards/viewtopic.php?t=8316. |
| 138 | + |
| 139 | +* During subsequent deploys of the image, the OpenStack code will ensure that |
| 140 | + a disk image is not copied to a disk smaller than the source disk, |
| 141 | + as this would result in loss of data. The disk specified in |
| 142 | + the flavor should therefore be equal to or slightly larger than the source |
| 143 | + virtual machine's root disk. |
| 144 | + |
| 145 | +.. _zvmsdk.conf: https://cloudlib4zvm.readthedocs.io/en/latest/configuration.html#configuration-options |
| 146 | +.. _zvm cloud connector: https://cloudlib4zvm.readthedocs.io/en/latest/ |
0 commit comments