Difference between revisions of "Nova/InstanceLevelSnapshots"
(→Nova Instance-level snapshots) |
(→Nova Instance-Level Snapshots) |
||
| Line 1: | Line 1: | ||
= Nova Instance-Level Snapshots = | = Nova Instance-Level Snapshots = | ||
| − | + | In a nutshell, we want the ability to take a snapshot of a running instance along with all attached volumes as a single psuedo-atomic operation. This gives the user a filesystem-consistent snapshot (with qemu-assisted) or application-consistent snapshot (with guest-assisted) of all local storage accessible to a particular virtual machine at that time. | |
| − | + | == Current Behaviour == | |
| − | + | Today a user can request a snapshot of a VM and that snapshot will contain only the contents of the rool volume. Both image-backed and volume-backed root volumes are supported. For image-backed instances, the resulting snapshot will be contained by glance as an available image. For volume-backed instances, the resulting snapshot is contained by cinder as an available volume. At snapshot-time, any additional attached volumes must be snapshotted separately, leaving no option to capture them all at once. | |
| − | + | == Desired Behaviour == | |
| − | + | A way to indicate to create_image() that all attached volume should be included in a snapshot. | |
| − | * Instead of snapshotting the instance, could we get away with *only* the attached volumes? | + | == Proposed Changes == |
| + | |||
| + | The entry point to the Nova API for this feature is create_image(). This method will be modified to look for an additional aoption 'all_volumes'. If this option is presen and is set to True, then create_image() will ensure that a snapshot request is issued for all attached volumes. The resulting snapshot will be a combination of the root volume snapshot along with additional cinder volume snapshots. These snapshots will be named in such a way to make correlation by the user an easy operation. The naming scheme will be covered later in this document. | ||
| + | |||
| + | The all_volumes flag will be passed to the compute_api, either snapshot() for image-backed instances or snapshot_volume_backed() for volume-backed instances. Regardless of the different snapshot implementations, the modified logic will be similar to the following pseudocode: | ||
| + | |||
| + | * volumes = get_all_attached_volumes() | ||
| + | * freeze_instance() | ||
| + | * snapshot_root_volume() | ||
| + | * for volume in volumes: | ||
| + | snapshot_volume(volume, clever_name) [volume_api.create_snapshot() via cinder] | ||
| + | * thaw_instance() | ||
| + | * collect metadata for response | ||
| + | * return response | ||
| + | |||
| + | == Missing Pieces == | ||
| + | |||
| + | The primary missing piece is freeze/thaw. | ||
| + | |||
| + | * Does this functionality exist currently? | ||
| + | * If so, can we use it similarily to what is described above? | ||
| + | * What other pieces are missing? | ||
| + | |||
| + | == Todo == | ||
| + | |||
| + | * Cinder volume naming scheme for snapshot correlation | ||
| + | |||
| + | == Resolved Questions == | ||
| + | |||
| + | * Instead of snapshotting the instance, could we get away with *only* the attached volumes? | ||
| + | I don't see any reason that a user would want all attached volumes without the root volume. If a need does arise for this behaviour, it can be added without too much trouble. | ||
Revision as of 01:15, 17 December 2013
Contents
Nova Instance-Level Snapshots
In a nutshell, we want the ability to take a snapshot of a running instance along with all attached volumes as a single psuedo-atomic operation. This gives the user a filesystem-consistent snapshot (with qemu-assisted) or application-consistent snapshot (with guest-assisted) of all local storage accessible to a particular virtual machine at that time.
Current Behaviour
Today a user can request a snapshot of a VM and that snapshot will contain only the contents of the rool volume. Both image-backed and volume-backed root volumes are supported. For image-backed instances, the resulting snapshot will be contained by glance as an available image. For volume-backed instances, the resulting snapshot is contained by cinder as an available volume. At snapshot-time, any additional attached volumes must be snapshotted separately, leaving no option to capture them all at once.
Desired Behaviour
A way to indicate to create_image() that all attached volume should be included in a snapshot.
Proposed Changes
The entry point to the Nova API for this feature is create_image(). This method will be modified to look for an additional aoption 'all_volumes'. If this option is presen and is set to True, then create_image() will ensure that a snapshot request is issued for all attached volumes. The resulting snapshot will be a combination of the root volume snapshot along with additional cinder volume snapshots. These snapshots will be named in such a way to make correlation by the user an easy operation. The naming scheme will be covered later in this document.
The all_volumes flag will be passed to the compute_api, either snapshot() for image-backed instances or snapshot_volume_backed() for volume-backed instances. Regardless of the different snapshot implementations, the modified logic will be similar to the following pseudocode:
* volumes = get_all_attached_volumes()
* freeze_instance()
* snapshot_root_volume()
* for volume in volumes:
snapshot_volume(volume, clever_name) [volume_api.create_snapshot() via cinder]
* thaw_instance()
* collect metadata for response
* return response
Missing Pieces
The primary missing piece is freeze/thaw.
* Does this functionality exist currently? * If so, can we use it similarily to what is described above? * What other pieces are missing?
Todo
* Cinder volume naming scheme for snapshot correlation
Resolved Questions
* Instead of snapshotting the instance, could we get away with *only* the attached volumes?
I don't see any reason that a user would want all attached volumes without the root volume. If a need does arise for this behaviour, it can be added without too much trouble.
