Add image guide for image requirements
Partial-implement-blueprint nova_doc Change-Id: I34bce105c9dfbcb165b2b1561bb431db89e01818
This commit is contained in:
parent
66a40cef68
commit
94b47c40f9
|
@ -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.
|
|
@ -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
|
|
@ -63,7 +63,7 @@ Creating zVM Images
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
images
|
||||
imageguide
|
||||
|
||||
|
||||
Contributing to the project
|
||||
|
|
Loading…
Reference in New Issue