XenServerSnapshotBlueprint

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:

1. Snapshots will be unlocked (remove allowvssprovider config)
2. 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
3. The XenAPI will then call the "put_vdi" method of the glance plugin as pass the snapshot_opque_ref as an argument.
4. The put_vdi method will lookup the VDIs associated with the template vm (using the VBD).
5. The glance plugin will then bundle (using tar and gzip) the VHDs in the storage repository
6. The glance plugin will then stream the bundle into Glance (which will in turn register the image in Parallax)
7. The glance plugin will then return to the snapshot method of xenapi driver where the template VM and VDIs will be destroyed.
8. 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