Difference between revisions of "Nova/InstanceLevelSnapshots"

Revision as of 23:05, 20 December 2013

Instance-Level Snapshots

Openstack should have the ability to take a snapshot of a running instance that includes all of its attached volumes. A coordinated snapshot of multiple volumes for backup purposes. The snapshot operation should occur while the instance is in a paused and quiesced state so that each snapshot is both consistent within itself and with respect to its sibling snapshots.

Existing Behaviour

There are two snapshot operations that exist in Openstack at the moment.

1. A user can create an image of a running instance using the createImage API call. This will create a "template" that can be used to spin up new instances from and is referred to by Glance, regardless of where it's stored. This operation will only capture the contents of the root volume.
2. A user can create a snapshot of an attached volume through Cinder. This snapshot is a new volume that can be managed just as any other Cinder volume.

The user must choose between one of these two, thus I propose adding functionality that allows a user to create a snapshot that includes both the root volume and all attached cinder volumes in a single pseudo-atomic operation.

Timeline

Maybe Icehouse 3 dependent on required libvirt changes. Libvirt may need to expose additional operations for this feature to be properly supported. See below for further details.

API Changes

There are two obvious choices:

1. Foo
2. Bar

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.

Snapshot Consistency

We should be able to support crash-consistent snapshots without too many requirements on libvirt by simply pausing the VM, requesting snapshots, and resuming. A stretch-goal would be to quiesce the instance to provide filesystem-consistent snapshots. The end goal is to use guest-assisted snapshots for application-consistent snapshots across all volumes.

Volume Naming Scheme

We will need a way for the user to tell which Cinder volumes are members of a particular snapshot. I propose we can store the Glance snapshot UUID in the volume snapshot metadata for each Cinder volume.

New Snapshot Logic

The basic pseudocode might look like:

volumes = get_all_attached_volumes()

PAUSE(quiesce=True)

UUID = snapshot_root_volume()

for volume in volumes:
    snapshot_volume(volume, UUID)             [volume_api.create_snapshot() via cinder]

wait for snaphots to complete

collect metadata for response

RESUME()

return response

Libvirt Support

I still have some pending questions about what is possible in the current version of libvirt:

1. Foo
2. Bar
3. Baz