[openstack-dev] Proposal for instance-level snapshots in Nova

Vishvananda Ishaya vishvananda at gmail.com
Thu Jan 16 22:53:18 UTC 2014

On Jan 16, 2014, at 1:28 PM, Jon Bernard <jbernard at tuxion.com> wrote:

> * Vishvananda Ishaya <vishvananda at gmail.com> wrote:
>> On Jan 14, 2014, at 2:10 PM, Jon Bernard <jbernard at tuxion.com> wrote:
>>> <snip>
>>>> 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
>>> For the first milestone to offer crash-consistent snapshots you are
>>> correct.  We'll need some additional support from libvirt, but the
>>> patchset should be straightforward.  The biggest question I have
>>> surrounding initial work is whether to use an existing API call or
>>> create a new one.
>> I think you might have missed the “client side” part of this point. I agree
>> that the snapshot multiple volumes and package it up is valuable, but I was
>> trying to make the point that you could do all of this stuff client side
>> if you just add support for snapshotting ephemeral drives. An all-in-one
>> snapshot command could be valuable, but you are talking about orchestrating
>> a lot of commands between nova, glance, and cinder and it could get kind
>> of messy to try to run the whole thing from nova.
> If you expose each primitive required, then yes, the client could
> implement the logic to call each primitive in the correct order, handle
> error conditions, and exit while leaving everything in the correct
> state.  But that would mean you would have to implement it twice - once
> in python-novaclient and once in Horizon.  I would speculate that doing
> this on the client would be even messier.
> If you are concerned about the complexity of the required interactions,
> we could narrow the focus in this way:
>  Let's say that taking a full snapshot/backup (all volumes) operates
>  only on persistent storage volumes.  Users who booted from an
>  ephemeral glance image shouldn't expect this feature because, by
>  definition, the boot volume is not expected to live a long life.
> This should limit the communication to Nova and Cinder, while leaving
> Glance out (initially).  If the user booted an instance from a cinder
> volume, then we have all the volumes necessary to create an OVA and
> import to Glance as a final step.  If the boot volume is an image then
> I'm not sure, we could go in a few directions:
>  1. No OVA is imported due to lack of boot volume
>  2. A copy of the original image is included as a boot volume to create
>     an OVA.
>  3. Something else I am failing to see.

> If [2] seems plausible, then it probably makes sense to just ask glance
> for an image snapshot from nova while the guest is in a paused state.
> Thoughts?

This already exists. If you run a snapshot command on a volume backed instance
it snapshots all attached volumes. Additionally it does throw a bootable image
into glance referring to all of the snapshots.  You could modify create image
to do this for regular instances as well, specifying block device mapping but
keeping the vda as an image. It could even do the same thing with the ephemeral
disk without a ton of work. Keeping this all as one command makes a lot of sense
except that it is unexpected.

There is a benefit to only snapshotting the root drive sometimes because it
keeps the image small. Here’s what I see as the ideal end state:

Two commands(names are a strawman):
  create-full-image — image all drives
  create-root-image — image just the root drive

These should work the same regardless of whether the root drive is volume backed
instead of the craziness we have to day of volume-backed snapshotting all drives
and instance backed just the root.  I’m not sure how we manage expectations based
on the current implementation but perhaps the best idea is just adding this in
v3 with new names?

FYI the whole OVA thing seems moot since we already have a way of representing
multiple drives in glance via block_device_mapping properites.


> -- 
> 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/20140116/07198ede/attachment.pgp>

More information about the OpenStack-dev mailing list