Open Stack

I agree with the below from a XenServer perspective.  As with vmware, XenServer supports live snapshotting and creating multiple clones from that live snapshot.

I understand that there is a XenAPI equivalent in the works and therefore would argue the API changes need to be accepted as a minimum.

In order to minimize the feature divergence between hypervisors, I'd also argue that we should accept the libvirt implementation even if it uses unsupported APIs - perhaps disabled by default with a suitable warning that it isn't considered safe by libvirt/QEmu.

Bob
________________________________________
From: Shawn Hartsock [hartsocks at vmware.com]
Sent: 19 August 2013 20:59
To: Daniel P. Berrange; OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines

For what it's worth... this doesn't seem too bad to me...

I was planning on using this part of the vSphere API:
* https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.CloneSpec.html

...to accomplish the clone part of the BP. The API contains a "spec" section where you tell the ESX hypervisor how to handle things like network identity...
* https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.customization.IPSettings.html

... I was going to use this to plumb together the "live-snapshot" bit ...
* https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.VirtualMachine.html#createSnapshot

... which includes stuff about how to handle memory.

So, I didn't read this blueprint as especially hard to accomplish in the vmwareapi driver. It just would eat more time than I have right now and would require a deeper level of understanding of how the vSphere hypervisor suite works than most of the other features currently use. I'm fully planning on playing with this in IceHouse just to see how it would go, it's probably one of the more nifty new features we could add.

Note: these are old features for the API and they are a tad complicated, but it's all well within the realm of supported! In fact, it's standard operating procedure to use the clone feature to scale-out an application in some vSphere shops. (albeit, in production the admins I know personally, use clone with power-off from a 'template' and the system comes up with a new MAC/etc on first boot... cloning from a running system is possible, but I would recommend cloning from a power-off state unless you've got a hot-plug feature in your guest OS)



# Shawn Hartsock

----- Original Message -----
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
> Sent: Monday, August 19, 2013 5:24:59 AM
> Subject: Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines
>
> On Mon, Aug 19, 2013 at 08:28:58AM +1200, Robert Collins wrote:
> > On 17 August 2013 07:01, Russell Bryant <rbryant at redhat.com> wrote:
> >
> > >> Maybe we've grown up to the point where we have to be more careful and
> > >> not introduce
> > >> these kind of features and the maintenance cost of introducing
> > >> experimental features is
> > >> too great. If that is the community consensus, then I'm happy keep the
> > >> live snapshot stuff
> > >> in a branch on github for people to experiment with.
> > >
> > > My feeling after following this discussion is that it's probably best to
> > > keep baking in another branch (github or whatever).  The biggest reason
> > > is because of the last comment quoted from Daniel Berrange above.  I
> > > feel that like that is a pretty big deal.
> >
> > So, reading between the lines here, I guess you're worried that we'd
> > let code paths that violate what upstream will support leak into the
> > main codepaths for libvirt - and thus we'd end up with a situation
> > where we aren't supported by upstream for all regular operations.
>
> Yes, if you perform a live clone of a VM, then you have effectively
> tainted that VM for the rest of its lifetime. From the virt host
> vendors' POV, any unexpected or problematic behaviour you get from
> that VM thereafter will be outside scope of support. The onus would
> be on the openstack sysadmin to demonstrate that the same problem
> occurs without the use of live cloning.
>
> Running a production cloud using a feature that your virt host
> vendor considers unsupported would be somewhat reckless IMHO, unless
> you think your sysadmins think they have the skills to solve all
> possible problems in that area themselves, which is unlikely for most
> cloud vendors.
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev