[openstack-dev] [OpenStack-dev][Nova][Discussion]Blueprint : Auto VM Discovery in OpenStack for existing workload

Daniel P. Berrange berrange at redhat.com
Wed Oct 30 16:38:21 UTC 2013


On Wed, Oct 30, 2013 at 11:51:01AM -0400, Mike Spreitzer wrote:
> Swapnil Kulkarni <swapnilkulkarni2608 at gmail.com> wrote on 10/30/2013 
> 02:36:37 AM:
> 
> > I had a discussion with russellb regarding this for yesterday, I 
> > would like to discuss this with the team regarding the blueprint 
> > mentioned in subject.
> > 
> > 
> https://blueprints.launchpad.net/nova/+spec/auto-vm-discovery-on-hypervisor
> 
> > 
> > Description: Organizations opting to use openstack can have varied 
> > amount of workload that they would like to be available directly 
> > with the use of some discovery workflows. One common usage of this 
> > would be exising virtual machines present on the hypervisors. If 
> > this instances can be disovered by the compute agent during 
> > discovery, it would help to use Openstack to manage the existing 
> > workload directly. Auto VM Discovery will enable this functionality 
> > initially for KVM guests, the widely used hypervisor configuration 
> > in OpenStack deployments and enhance it further for other hypervisors.
> 
> I agree with the doubts about asking Nova to adopt non-Nova VMs.  However, 
> there is another use case that may make more sense.  I am told that 
> sometimes a VM creation or deletion operation will fail partially, in such 
> a way that the controller thinks the VM does not exist but the hypervisor 
> is still reserving some resources for that VM.  If Nova had a way to check 
> its facts against the hypervisors, confusion would not have to reign.

That targetted use case is quite easy to address - at least for
libvirt. You just need to include a <metadata> blob with the XML
for the guest, providing a record that Nova was the original VM
creator. If nova ever sees a VM for which it is listed as creator
and without a record in the DB, then it can just reap that rogue
VM. This avoids any need to deal with the hard problems of adopting
arbitrary VMs.

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



More information about the OpenStack-dev mailing list