x
/
nova-zvm-virt-driver
Code Issues Proposed changes

Merge "Add image guide for image requirements"

This commit is contained in:
Jenkins 2017-05-08 07:24:52 +00:00 committed by Gerrit Code Review
parent e7689e2062 94b47c40f9
commit 79e6b97a7d
3 changed files with 86 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

85
doc/source/imageguide.rst Normal file
View File

@ -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.

7
doc/source/images.rst
View File

@ -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

2
doc/source/index.rst
View File

@ -63,7 +63,7 @@ Creating zVM Images
.. toctree::
:maxdepth: 2
images
imageguide
Contributing to the project