Open Stack

Hi Michael,
Currently Raksha project takes the snapshot of vm and all its volumes in
one atomic operation. We leverage libvirt snapshot_as command to achieve
that and it works great.
We are planning to extend this functionality to VMware too.

An ideal place to snapshot both vm and volumes is in the hypervisor layer.
The workflow based snapshots still work fine, but involves pausing vm and
invoking multiple Apis to achieve the same affect.

However in order to leverage array based snspshot functionality, we do need
have workflow based solution. This solution may leverage cinder
backup/snapshot Apis to achieve a consistent snapshot of vms and attached
volumes.

Murali Balcha

On Friday, September 20, 2013, Michael Basnight wrote:

>
> On Sep 20, 2013, at 10:25 AM, Caitlin Bestler wrote:
>
> > On 9/20/2013 8:37 AM, Michael Basnight wrote:
> >>
> >> On Sep 18, 2013, at 8:30 AM, Giuseppe Galeota wrote:
> >>
> >>> Dear all,
> >>> can you give me more informations about the status of the Backup
> Design project?
> >>> Is it an active project or only a proof-of-concept?
> >>
> >> Its been implemented in the trove codebase. Id think its closer to
> active than proof of concept. If you search the git log for backup you will
> see that a good ammt of commits have gone into making the backup plugins
> code pretty solid. But i havent seen a company deploy it yet, since its a
> pretty new feature. So i imagine there might be tweaks here or there during
> the Icehouse release.
> >>
> >>>
> >
> > In my opinion, to be truly effective snapshotting of VMs needs to be
> co-ordinated with with snapshotting of volumes. I think that
> state-management's taskflows would be the correct solution.
>
> We fully agree that state management's taskflow will be in trove. Ive had
> many chats virtually and in person w/ josh harlow on the subject. I think
> there is a place for volume snapshotting in trove, but there is no
> guarantee that a installation will be using volumes, and there are likely
> some code paths we can improve on in order to make this optionally happen.
> But its a fair point nonetheless.
>


-- 
Muralidhar Balcha
508 494 5007
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130920/0c91ae69/attachment.html>