<div dir="ltr">Hi all,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 19, 2013 at 11:49 PM, Bob Ball <span dir="ltr"><<a href="mailto:bob.ball@citrix.com" target="_blank">bob.ball@citrix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I agree with the below from a XenServer perspective. As with vmware, XenServer supports live snapshotting and creating multiple clones from that live snapshot.<br>
<br>
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.<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>[1] <a href="https://review.openstack.org/#/c/34036/">https://review.openstack.org/#/c/34036/</a></div><div>[2] <a href="https://review.openstack.org/#/c/43777/">https://review.openstack.org/#/c/43777/</a> </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Tim</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Bob<br>
________________________________________<br>
From: Shawn Hartsock [<a href="mailto:hartsocks@vmware.com">hartsocks@vmware.com</a>]<br>
Sent: 19 August 2013 20:59<br>
To: Daniel P. Berrange; OpenStack Development Mailing List<br>
<div class=""><div class="h5">Subject: Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines<br>
<br>
For what it's worth... this doesn't seem too bad to me...<br>
<br>
I was planning on using this part of the vSphere API:<br>
* <a href="https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.CloneSpec.html" target="_blank">https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.CloneSpec.html</a><br>
<br>
...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...<br>
* <a href="https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.customization.IPSettings.html" target="_blank">https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.customization.IPSettings.html</a><br>
<br>
... I was going to use this to plumb together the "live-snapshot" bit ...<br>
* <a href="https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.VirtualMachine.html#createSnapshot" target="_blank">https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.VirtualMachine.html#createSnapshot</a><br>
<br>
... which includes stuff about how to handle memory.<br>
<br>
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.<br>
<br>
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)<br>
<br>
<br>
<br>
# Shawn Hartsock<br>
<br>
----- Original Message -----<br>
> From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
> To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Monday, August 19, 2013 5:24:59 AM<br>
> Subject: Re: [openstack-dev] [nova] live-snapshot/cloning of virtual machines<br>
><br>
> On Mon, Aug 19, 2013 at 08:28:58AM +1200, Robert Collins wrote:<br>
> > On 17 August 2013 07:01, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
> ><br>
> > >> Maybe we've grown up to the point where we have to be more careful and<br>
> > >> not introduce<br>
> > >> these kind of features and the maintenance cost of introducing<br>
> > >> experimental features is<br>
> > >> too great. If that is the community consensus, then I'm happy keep the<br>
> > >> live snapshot stuff<br>
> > >> in a branch on github for people to experiment with.<br>
> > ><br>
> > > My feeling after following this discussion is that it's probably best to<br>
> > > keep baking in another branch (github or whatever). The biggest reason<br>
> > > is because of the last comment quoted from Daniel Berrange above. I<br>
> > > feel that like that is a pretty big deal.<br>
> ><br>
> > So, reading between the lines here, I guess you're worried that we'd<br>
> > let code paths that violate what upstream will support leak into the<br>
> > main codepaths for libvirt - and thus we'd end up with a situation<br>
> > where we aren't supported by upstream for all regular operations.<br>
><br>
> Yes, if you perform a live clone of a VM, then you have effectively<br>
> tainted that VM for the rest of its lifetime. From the virt host<br>
> vendors' POV, any unexpected or problematic behaviour you get from<br>
> that VM thereafter will be outside scope of support. The onus would<br>
> be on the openstack sysadmin to demonstrate that the same problem<br>
> occurs without the use of live cloning.<br>
><br>
> Running a production cloud using a feature that your virt host<br>
> vendor considers unsupported would be somewhat reckless IMHO, unless<br>
> you think your sysadmins think they have the skills to solve all<br>
> possible problems in that area themselves, which is unlikely for most<br>
> cloud vendors.<br>
><br>
> Regards,<br>
> Daniel<br>
> --<br>
> |: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
> |: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
> |: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
> |: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>