<tt><font size=2>Swapnil Kulkarni <swapnilkulkarni2608@gmail.com>
wrote on 10/30/2013 02:36:37 AM:<br>
<br>
> I had a discussion with russellb regarding this for yesterday, I <br>
> would like to discuss this with the team regarding the blueprint <br>
> mentioned in subject.<br>
> <br>
> </font></tt><a href="https://blueprints.launchpad.net/nova/+spec/auto-vm-discovery-on-hypervisor"><tt><font size=2>https://blueprints.launchpad.net/nova/+spec/auto-vm-discovery-on-hypervisor</font></tt></a><tt><font size=2><br>
> <br>
> Description: Organizations opting to use openstack can have varied
<br>
> amount of workload that they would like to be available directly <br>
> with the use of some discovery workflows. One common usage of this
<br>
> would be exising virtual machines present on the hypervisors. If <br>
> this instances can be disovered by the compute agent during <br>
> discovery, it would help to use Openstack to manage the existing <br>
> workload directly. Auto VM Discovery will enable this functionality
<br>
> initially for KVM guests, the widely used hypervisor configuration
<br>
> in OpenStack deployments and enhance it further for other hypervisors.<br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>