Nova/InstanceLevelSnapshots

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.