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.
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.
A way to indicate to create_image() that all attached volume should be included in a snapshot.
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
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?
* Cinder volume naming scheme for snapshot correlation
* 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.