[openstack-dev] Proposal for instance-level snapshots in Nova
mark.washenberger at markwash.net
Wed Jan 8 17:51:51 UTC 2014
On Mon, Jan 6, 2014 at 3:50 PM, Jon Bernard <jbernard at tuxion.com> wrote:
> Hello all,
> I would like to propose instance-level snapshots as a feature for
> inclusion in Nova. An initial draft of the more official proposal is
> here , blueprint is here .
> In a nutshell, this feature will take the existing create-image
> functionality a few steps further by providing 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 volume snapshot is both
> consistent within itself and with respect to its sibling snapshots.
> I still have some open questions on a few topics:
> * API changes, two different approaches come to mind:
> 1. Nova already has a command `createImage` for creating an image of an
> existing instance. This command could be extended to take an
> additional parameter `all-volumes` that signals the underlying code
> to capture all attached volumes in addition to the root volume. The
> semantic here is important, `createImage` is used to create
> a template image stored in Glance for later reuse. If the primary
> intent of this new feature is for backup only, then it may not be
> wise to overlap the two operations in this way. On the other hand,
> this approach would introduce the least amount of change to the
> existing API, requiring only modification of an existing command
> instead of the addition of an entirely new one.
> 2. If the feature's primary use is for backup purposes, then a new API
> call may be a better approach, and leave `createImage` untouched.
> This new call could be called `createBackup` and take as a parameter
> the name of the instance. Although it introduces a new member to the
> API reference, it would allow this feature to evolve without
> introducing regressions in any existing calls. These two calls could
> share code at some point in the future.
> * Existing libvirt support:
> To initially support consistent-across-multiple-volumes snapshots,
> we must be able to ask libvirt for a snapshot of an already paused
> guest. I don't believe such a call is currently supported, so
> changes to libvirt may be a prerequisite for this feature.
> Any contribution, comments, and pieces of advice are much appreciated.
> : https://wiki.openstack.org/wiki/Nova/InstanceLevelSnapshots
> : https://blueprints.launchpad.net/nova/+spec/instance-level-snapshots
In your specification in the Snapshot Storage section you say "it might be
nice to combine all of the snapshot images into a single OVF file that
contains all volumes attached to the instance at the time of snapshot." I'd
love it if, by the time you get to the point of implementing this storage
part, we have an option available to you in Glance for storing something
akin to an Instance template. An instance template would be an entity
stored in Glance with references to each volume or image that was uploaded
as part of the snapshot. As an example, it could be something like
"/dev/sdb": "<some url for a cinder volume-like entity>"
Essentially, this kind of storage would bring the OVF metadata up into
Glance rather than burying it down in an image byte stream where it is
harder to search or access.
This is an idea that has been discussed several times before, generally
favorably, and if we move ahead with instance-level snapshots in Nova I'd
love to move quickly to support it in Glance. Part of the reason for the
delay of this feature was my worry that if Glance jumps out ahead, we'll
end up with some instance template format that Nova doesn't really want, so
this opportunity for collaboration on use cases would be fantastic.
If after a bit more discussion in this thread, folks think these templates
in Glance would be a good idea, we can try to draw up a proposal for how to
implement the first cut of this feature in Glance.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev