Open Stack

On 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 [1], blueprint is here [2].
> 
> 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.

You’ve mentioned “If the feature’s use case is backup” a couple of times
without specifying the answer. I think this is important to the above
question. Also relevant is how the snapshot is stored and potentially
restored.

As you’ve defined the feature so far, it seems like most of it could
be implemented client side:

* pause the instance
* snapshot the instance
* snapshot any attached volumes

The only thing missing in this scenario is snapshotting any ephemeral
drives. There are workarounds for this such as:
 * use flavor with no ephemeral storage
 * boot from volume

It is also worth mentioning that snapshotting a boot from volume instance
will actually do most of this for you (everything but pausing the instance)
and additionally give you an image which when booted will lead to a clone
of all of the snapshotted volumes.

So unless there is some additional feature regarding storing or restoring
the backup, I only see one potential area for improvement inside of nova:
Modifying the snapshot command to allow for snapshotting of ephemeral
drives.

If this is an important feature, rather than an all in one command, I
suggest an extension to createImage which would allow you to specify the
drive you wish to snapshot. If you could specify drive: vdb in the snapshot
command it would allow you to snapshot all the components individually.

Vish

> 
> * 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.
> 
> [1]: https://wiki.openstack.org/wiki/Nova/InstanceLevelSnapshots
> [2]: https://blueprints.launchpad.net/nova/+spec/instance-level-snapshots
> 
> -- 
> Jon
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/8cbe8037/attachment.pgp>