Jump to: navigation, search

FastCloningForXenServer

Revision as of 23:29, 17 February 2013 by Ryan Lane (talk | contribs) (Text replace - "__NOTOC__" to "")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Table of contents:

Summary

This blueprint defines a set of solutions to ensure that an instance creation is as fast as possible within a given XenServer. Once an image has been streamed to a given XenServer host, we should reuse the local image for subsequent instances rather than re-streaming them.

On a XenServer host, nova-compute gets the image from glance for instance creation. There will be local copies of an image on a given XenServer if multiple instance (of one image) are created on it. We can avoid streaming the image and creating local copies by re-using the images that have already been streamed. This can be achieved by using the copy on write feature provided by XenServer. Copy on write allows an image to be cloned and re-used. Cloning of a disk is almost instantaneous and avoids the overhead of the time spend re-streaming the image.

Use cases

  1. When an instance create request is placed, nova-compute searches the local cache for the image. The search is done based on image-id. If the image is not present it is streamed from glance and the instance is created.
  2. When an instance create request is placed, nova-compute searches the local cache for the image. The search is done based on image-id. If the image is present the instance is created from it.

Requirements

  1. Openstack on Xenserver host will use copy on write by default.
    1. If it is the first time that an instance of an image is being created on a given Xenserver, stream the image from glance.
    2. If the image is already present on a given Xenserver host, clone that image and use the cloned image to create a new instance.
    3. "use_cow_images" flag must be used to identify whether an existing image should be cloned or a new one streamed from glance.
  2. If the copy on write option is turned off, we'll stream the image from glance.
  3. Functionality would be supported on Local SR of type Ext. Support for other SR's will be added later. LVM and LVHD based Local SRs will not support fast cloning.

Design notes

  1. There are two ways to set up the Local storage SR. One is called "LVHD" and involves putting VHD files inside LVM volumes on the local disk. The other is called "ext" and involves putting VHD files inside an ext3 filesystem on the local disk instead.
  2. Most of XenServer storage types support thin provisioning. When we want to stream from glance to start a VM, we need to know which disks are already present, and which need to be streamed. Having the VHD files easily visible inside Dom0 makes it very easy to check which disks have been streamed and which ones haven't. That is why we have choosen to use Ext. The advantage of Ext is that the VHD file is easily visible inside Dom0.
  3. To identify whether an image has already been streamed to a given Xenserver host, "image-id" will be stored in the other-config parameter field. If copy on write is to be used, existing disks will be listed and checked if there is one present with the given image id. If present a new vhd will be cloned and used for creating the new instance.
  4. If "use_cow_images" is given as false, but the image has already been streamed to the XenServer host and is available, we'll copy that image (not clone) and use it while spawning a new instance.
  5. For Local SR of type LVM (or LVHD), vhd file tracking will not be possible. Copy on write will not be supported on them. If the "use_cow_images" flag is set to 'true', it'll be ignored and an instance will be created by making a copy of the image.