XenServerSnapshotBlueprint - Revision history

Ryan Lane: Text replace - "NOTOC" to ""

2013-02-17T23:30:52Z

Text replace - "__NOTOC__" to ""

RickH at 21:59, 13 December 2010

2010-12-13T21:59:25Z

RickH at 21:58, 13 December 2010

2010-12-13T21:58:11Z

RickH at 21:54, 13 December 2010

2010-12-13T21:54:21Z

RickH at 22:18, 7 December 2010

2010-12-07T22:18:02Z

RickH: Started work

2010-12-07T22:06:45Z

Started work

New page

__NOTOC__
[[XenServerSnapshots]]

Introduction

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:

* On demand snapshots (these are snapshots initiated by the user)
* Scheduled snapshots (these are snapshots automatically created by the system at a particular time determined by the user)

Components

These are the components that will need to be involved to implement this functionality.

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

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.

← Older revision		Revision as of 23:30, 17 February 2013
Line 1:		Line 1:
−	~~__NOTOC__~~	+
	= [[XenServer]] Snapshot Blueprint =		= [[XenServer]] Snapshot Blueprint =

← Older revision		Revision as of 21:59, 13 December 2010
Line 54:		Line 54:
	== Related Blueprints ==		== Related Blueprints ==

−	Scheduled Backups - Kicking-off and replacing daily and weekly backups	+	* Scheduled Backups - Kicking-off and replacing daily and weekly backups

@@ Line 1: / Line 1: @@
 __NOTOC__
-[[XenServer]] Snapshot Notes
+= [[XenServer]] Snapshot Blueprint =
-Introduction
+== 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.
@@ Line 12: / Line 12: @@
 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
+== 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:
@@ Line 19: / Line 19: @@
 * Glance Image GET/PUT (to store the images in Swift)
-Components Modified
+== Components Modified ==
 Several components will need to be modified to implement XenAPI snapshots, including:
@@ Line 29: / Line 29: @@
 * /etc/xapi.d/plugins/glance A plugin which exists on the [[XenServer]] which will bundle the VHDs and upload the bundle into Glance
-Description
+== 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.
@@ Line 35: / Line 35: @@
 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)
+# 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
+# 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 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 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 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 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.
+# 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)
+# Snapshots will be locked (add allowvssprovider=false config)
-Open Questions
+== Open Questions ==
-. Will we need to support a size constraint? Will this be implemented as a gflag?
+* 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 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 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 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?
+* Will VHD chainging and coalescing difference in [[XenServer5]].6 affect us?
-Related Blueprints
+== Related Blueprints ==
 Scheduled Backups - Kicking-off and replacing daily and weekly backups

@@ Line 1: / Line 1: @@
 __NOTOC__
-[[XenServerSnapshots]]
+[[XenServer]] Snapshot Notes
 Introduction
-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:
+The "snapshot" feature of [[OpenStack]] allows a user to make a point-in-time backup of a running VM without pausing or shutting down.
-* On demand snapshots (these are snapshots initiated by the user)
+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.
-Components
+The Rackspace API currently implements "instance snapshots" whereas the EC2/euca-tools tool-chain in Nova implements "volume snapshots".
-These are the components that will need to be involved to implement this functionality.
+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.
-[[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.
+Dependencies
-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.
+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:
-Nova api: We need expose On-demand snapshots through the API. In addition, we need to expose a way to schedule snapshots (aka backups).
+* Raw Disk Images (to support kernel within the instance volume)
-snapshot-scheduler: this component will be responsible initiating scheduled snapshots at the appropriate time
+Components Modified
-snapshot-pump: snapshots are long running events. We need a watcher (to kill jobs that timeout) and way of rate-limiting the number of snapshots that take place (to limit I/O on a particular host).
+Several components will need to be modified to implement XenAPI snapshots, including:

← Older revision		Revision as of 22:18, 7 December 2010
Line 16:		Line 16:

	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.		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.
		+
		+	Nova api: We need expose On-demand snapshots through the API. In addition, we need to expose a way to schedule snapshots (aka backups).
		+
		+	snapshot-scheduler: this component will be responsible initiating scheduled snapshots at the appropriate time
		+
		+	snapshot-pump: snapshots are long running events. We need a watcher (to kill jobs that timeout) and way of rate-limiting the number of snapshots that take place (to limit I/O on a particular host).