Latest revision as of 23:30, 17 February 2013

XenServer Snapshot Blueprint

Introduction

The "snapshot" feature of OpenStack allows a user to make a point-in-time backup of a running VM without pausing or shutting down.

There are two types of snapshots possible, an "instance snapshot" which backups the root volume and is therefore bootable (if raw-disk-images are used) and a "volume snapshot" which is not bootable but instead snapshots an attached block storage device.

The Rackspace API currently implements "instance snapshots" whereas the EC2/euca-tools tool-chain in Nova implements "volume snapshots".

While ultimately we envision "volume snapshots" and "instance snapshots" being treated similarly, for now, the focus of this blueprint will be on creating an "instance snapshot" mechanism in Nova. Narrowing the scope even more, we will be providing an implemenation of "instance snapshots" for the XenAPI virt driver and leave the Libvirt implementation as future work.

Dependencies

The goal of this blueprint is to recreate Rackspace style "instance-snapshots" in Nova. In order to accomplish this, we'll need several components in place, including:

Raw Disk Images (to support kernel within the instance volume)
Glance Image GET/PUT (to store the images in Swift)

Components Modified

Several components will need to be modified to implement XenAPI snapshots, including:

Rackspace API (we will not be modifying EC2 for this blueprint)
compute/manager.py to add snapshot call on the compute worker
virt/libvirt_conn.py to add snapshot with NotImplmentedError
virt/xenapi/vmops.py to add implementation of XenServer snapshots on compute worker
/etc/xapi.d/plugins/glance A plugin which exists on the XenServer which will bundle the VHDs and upload the bundle into Glance

Description of Changes

A snapshot call will come into the Rackspace API which will invoke via an RPC the snapshot method in the compute/manager.py. This will then call the snapshot method for the given instance's hypervisor.

In the case of XenAPI, this will call virt/xenapi/vmops.py snapshot() which will cause a number of things to occur:

Snapshots will be unlocked (remove allowvssprovider config)
Snapshot will be trigged via the XenAPI (either VM.snapshot or VM.snapshot_with_queisce depending on the option passed). This will return an opaque reference to the template VM, snapshot_opaque_ref
The XenAPI will then call the "put_vdi" method of the glance plugin as pass the snapshot_opque_ref as an argument.
The put_vdi method will lookup the VDIs associated with the template vm (using the VBD).
The glance plugin will then bundle (using tar and gzip) the VHDs in the storage repository
The glance plugin will then stream the bundle into Glance (which will in turn register the image in Parallax)
The glance plugin will then return to the snapshot method of xenapi driver where the template VM and VDIs will be destroyed.
Snapshots will be locked (add allowvssprovider=false config)

Open Questions

Will we need to support a size constraint? Will this be implemented as a gflag?
Will we need to add an snapshot_in_progress flag to instance to prevent multiple snapshots from taking place
Will we need to add a queue to rate limit the number of snapshots taking place on the server.
Will snapshots be directly tied to an instance; is there a way to specify that it's not tied to an instance?
Will VHD chainging and coalescing difference in XenServer5.6 affect us?

Related Blueprints

Scheduled Backups - Kicking-off and replacing daily and weekly backups

@@ Line 1: / Line 1: @@
-__NOTOC__
-[[XenServerSnapshots]]
-Introduction
+= [[XenServer]] Snapshot Blueprint =
-In order for [[OpenStack]] to provide comparable functionality to the current [[CloudServers]] implementation, we will need to implement live-snapshotting of the VM's disks. In particular, we will need to support two types of snapshotting:
+== Introduction ==
-* On demand snapshots (these are snapshots initiated by the user)
+The "snapshot" feature of [[OpenStack]] allows a user to make a point-in-time backup of a running VM without pausing or shutting down.
-* Scheduled snapshots (these are snapshots automatically created by the system at a particular time determined by the user)
-Components
+There are two types of snapshots possible, an "instance snapshot" which backups the root volume and is therefore bootable (if raw-disk-images are used) and a "volume snapshot" which is not bootable but instead snapshots an attached block storage device.
-These are the components that will need to be involved to implement this functionality.
+The Rackspace API currently implements "instance snapshots" whereas the EC2/euca-tools tool-chain in Nova implements "volume snapshots".
-[[XenServer]] Plugin glance: This is a [[XenServer]] Plugin (similar to the current objectstore plugin that knows how to talk take an image stored in glance and restore it, and knows how to create a snapshot from a running VM and store it in glance.
+While ultimately we envision "volume snapshots" and "instance snapshots" being treated similarly, for now, the focus of this blueprint will be on creating an "instance snapshot" mechanism in Nova. Narrowing the scope even more, we will be providing an implemenation of "instance snapshots" for the XenAPI virt driver and leave the Libvirt implementation as future work.
-Nova virt/xenapi.py The XenAPI adapter will need to be modified to know whether it's using new-style glance or the old-style S3-like object store. For the time being, glance  implies raw-disk-images, though in the future that may not necessarily be the case.
+== Dependencies ==
+The goal of this blueprint is to recreate Rackspace style "instance-snapshots" in Nova. In order to accomplish this, we'll need several components in place, including:
+* Raw Disk Images (to support kernel within the instance volume)
+* Glance Image GET/PUT (to store the images in Swift)
+== Components Modified ==
+Several components will need to be modified to implement XenAPI snapshots, including:
+* Rackspace API (we will not be modifying EC2 for this blueprint)
+* compute/manager.py to add snapshot call on the compute worker
+* virt/libvirt_conn.py to add snapshot with [[NotImplmentedError]]
+* virt/xenapi/vmops.py to add implementation of [[XenServer]] snapshots on compute worker
+* /etc/xapi.d/plugins/glance A plugin which exists on the [[XenServer]] which will bundle the VHDs and upload the bundle into Glance
+== Description of Changes ==
+A snapshot call will come into the Rackspace API which will invoke via an RPC the snapshot method in the compute/manager.py. This will then call the snapshot method for the given instance's hypervisor.
+In the case of XenAPI, this will call virt/xenapi/vmops.py snapshot() which will cause a number of things to occur:
+# Snapshots will be unlocked (remove allowvssprovider config)
+# Snapshot will be trigged via the XenAPI (either VM.snapshot or VM.snapshot_with_queisce depending on the option passed). This will return an opaque reference to the template VM, snapshot_opaque_ref
+# The XenAPI will then call the "put_vdi" method of the glance plugin as pass the snapshot_opque_ref as an argument.
+# The put_vdi method will lookup the VDIs associated with the template vm (using the VBD).
+# The glance plugin will then bundle (using tar and gzip) the VHDs in the storage repository
+# The glance plugin will then stream the bundle into Glance (which will in turn register the image in Parallax)
+# The glance plugin will then return to the snapshot method of xenapi driver where the template VM and VDIs will be destroyed.
+# Snapshots will be locked (add allowvssprovider=false config)
+== Open Questions ==
+* Will we need to support a size constraint? Will this be implemented as a gflag?
+* Will we need to add an snapshot_in_progress flag to instance to prevent multiple snapshots from taking place
+* Will we need to add a queue to rate limit the number of snapshots taking place on the server.
+* Will snapshots be directly tied to an instance; is there a way to specify that it's not tied to an instance?
+* Will VHD chainging and coalescing difference in [[XenServer5]].6 affect us?
+== Related Blueprints ==
+* Scheduled Backups - Kicking-off and replacing daily and weekly backups

Difference between revisions of "XenServerSnapshotBlueprint"