Open Stack

Hi all,

On Mon, Aug 19, 2013 at 11:49 PM, Bob Ball <bob.ball at citrix.com> wrote:

> 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.
>

Can nova technical leadership provide clarification on the current standing
of this blueprint? Two hypervisor vendors have expressed plans for
supporting this feature, and one has specifically requested that the API
changes be merged, but it appears that both the API changeset [1] and
novaclient support [2] have both been rejected pending libvirt support
(which has assumedly been ruled out for the Havana release).

[1] https://review.openstack.org/#/c/34036/
[2] https://review.openstack.org/#/c/43777/


> 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.
>

It's understandable that changes to the libvirt driver would be held back
until libvirt/qemu-upstream support for live snapshotting is established
(if ever), but given that other vendors whose release cadences don't
necessarily align with the nova release schedule have expressed plans to
support the interface it's unclear why lack of libvirt driver support would
block the entire blueprint.

Thanks,
Tim



>
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130826/873373db/attachment.html>