From 94b47c40f915a442ec3a8d5a6007ab7100e03c91 Mon Sep 17 00:00:00 2001 From: jichenjc Date: Sat, 29 Apr 2017 18:43:48 +0800 Subject: [PATCH] Add image guide for image requirements Partial-implement-blueprint nova_doc Change-Id: I34bce105c9dfbcb165b2b1561bb431db89e01818 --- doc/source/imageguide.rst | 85 +++++++++++++++++++++++++++++++++++++++ doc/source/images.rst | 7 ---- doc/source/index.rst | 2 +- 3 files changed, 86 insertions(+), 8 deletions(-) create mode 100644 doc/source/imageguide.rst delete mode 100644 doc/source/images.rst diff --git a/doc/source/imageguide.rst b/doc/source/imageguide.rst new file mode 100644 index 0000000..bedadfa --- /dev/null +++ b/doc/source/imageguide.rst @@ -0,0 +1,85 @@ +.. _imageguide: + +=========== +Image guide +=========== + +This guideline will describe the requirements, steps to make images, configurations +about the image that can be used in z/VM solution. + +Image Requirements +------------------ + +* supported Linux distribution (for deploy). The following are supported: + RHEL 6.2, 6.3, 6.4, 6.5, 6.6, and 6.7 + RHEL 7.0, 7.1 and 7.2 + SLES 11.2, 11.3, and 11.4 + SLES 12 and SLES 12.1 + Ubuntu 16.04 + +* A supported root disk type for snapshot/spawn. The following are supported: + FBA + ECKD + +* Images created with the previous version of the OpenStack support should be recaptured with an + updated xcatconf4z installed, version 2.0 or later. see below chapter for more detail on + xcatconf4z. + +* An image deployed on a compute node must match the disk type supported by that compute node, as + configured by the zvm_diskpool_type property in the nova.conf configuration file. A compute node + supports deployment on either an ECKD or FBA image, but not both at the same time. If you wish to + switch image types, you need to change the zvm_diskpool_type and zvm_diskpool properties in the + nova.conf file, accordingly. Then restart the nova-compute service to make the changes take effect. + +* If you deploy an instance with an ephemeral disk, both the root disk and the ephemeral disk will be + created with the disk type that was specified by zvm_diskpool_type property in the nova.conf file. That + property can specify either ECKD or FBA. + +* When resizing, remember that you can only resize an instance to the same type of disk. For example, if + an instance is built on an FBA type disk, you can resize it to a larger FBA disk, but not to an ECKD + disk. + +* For glance image-create, it is strongly suggested that you capture an instance with a root disk size no + greater than 5GB. If you really want to capture a larger root device, you will need to logon xCAT MN + and modify the timeout value in for httpd service to make image-create work as expected. + +* For nova boot, it is recommended that you deploy an instance with a root disk size no greater than + 5GB. If you really want to deploy a larger root device, you will need to logon xCAT MN and modify + the timeout value in for httpd service to make boot work as expected. + +* For nova resize operation, we suggest that you resize an instance with a root disk size no greater than + 5GB. + +* The network interfaces must be IPv4 interfaces. + +* Image names should be restricted to the UTF-8 subset, which corresponds to the ASCII character set. In + addition, special characters such as /, \, $, %, @ should not be used. For the FBA disk type "vm", + capture and deploy is supported only for an FBA disk with a single partition. Capture and deploy is + not supported for the FBA disk type "vm" on a CMS formatted FBA disk. + +* The virtual server/Linux instance used as the source of the new image should meet the following criteria: + 1. The root filesystem must not be on a logical volume. + 2. The minidisk on which the root filesystem resides should be a minidisk of the same type as + desired for a subsequent deploy (for example, an ECKD disk image should be captured + for a subsequent deploy to an ECKD disk), + 3. not be a full-pack minidisk, since cylinder 0 on full-pack minidisks is reserved, and be + defined with virtual address 0100. + 4. The root disk should have a single partition. + 5. The image being captured should support SSH access using keys instead of specifying a password. The + subsequent steps to capture the image will perform a key exchange to allow xCAT to access the server. + 6. The image being captured should not have any network interface cards (NICs) defined below virtual + address 1100. + +In addition to the specified criteria, the following recommendations allow for efficient use of the image: + +* The minidisk on which the root filesystem resides should be defined as a multiple of full gigabytes in +size (for example, 1GB or 2GB). OpenStack specifies disk sizes in full gigabyte values, whereas z/VM +handles disk sizes in other ways (cylinders for ECKD disks, blocks for FBA disks, and so on). See the +appropriate online information if you need to convert cylinders or blocks to gigabytes; for example: +http://www.mvsforums.com/helpboards/viewtopic.php?t=8316. + +* During subsequent deploys of the image, the OpenStack code will ensure that a disk image is not +copied to a disk smaller than the source disk, as this would result in loss of data. The disk specified in +the flavor should therefore be equal to or slightly larger than the source virtual machine's root disk. +IBM recommends specifying the disk size as 0 in the flavor, which will cause the virtual machine to be +created with the same disk size as the source disk. diff --git a/doc/source/images.rst b/doc/source/images.rst deleted file mode 100644 index e482ee8..0000000 --- a/doc/source/images.rst +++ /dev/null @@ -1,7 +0,0 @@ -============= -Create images -============= - -zvm driver can deploy pre-made images with special action introduced in the -document, for detailed info, please refer to zvm document: -http://www.vm.ibm.com/sysman/osmntlvl.html diff --git a/doc/source/index.rst b/doc/source/index.rst index fdd3797..be6adbc 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -63,7 +63,7 @@ Creating zVM Images .. toctree:: :maxdepth: 2 - images + imageguide Contributing to the project