<div dir="ltr">@Divakar, exactly, we want do ESX server level live-migrations with vCenter (VCDriver) by leveraging nova scheduler. Thanks.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-09 23:36 GMT+08:00 Nandavar, Divakar Padiyar <span dir="ltr"><<a href="mailto:divakar.padiyar-nandavar@hp.com" target="_blank">divakar.padiyar-nandavar@hp.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Steve,<br>
The problem with the support of live-migrate would still exist even if we decide to manage only one cluster from a compute node, unless one is ok with only live-migrate functionality between clusters.  The main debate started with supporting the live-migrate between the ESX Hosts in the same cluster.<br>

<br>
Thanks,<br>
Divakar<br>
<div class="im HOEnZb"><br>
-----Original Message-----<br>
From: Steve Gordon [mailto:<a href="mailto:sgordon@redhat.com">sgordon@redhat.com</a>]<br>
Sent: Wednesday, April 09, 2014 8:38 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
</div><div class="im HOEnZb">Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute<br>
Importance: High<br>
<br>
</div><div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> I'm not writing off vCenter or its capabilities. I am arguing that the<br>
> bar for modifying a fundamental design decision in Nova -- that of<br>
> being horizontally scalable by having a single nova-compute worker<br>
> responsible for managing a single provider of compute resources -- was<br>
> WAY too low, and that this decision should be revisited in the future<br>
> (and possibly as part of the vmware driver refactoring efforts<br>
> currently underway by the good folks at RH and VMWare).<br>
<br>
+1, This is my main concern about having more than one ESX cluster under a single nova-compute agent as well. Currently it works, but it doesn't seem particularly advisable as on face value as such an architecture seems to break a number of the Nova design guidelines around high availability and fault tolerance. To me it seems like such an architecture effectively elevates nova-compute into being part of the control plane where it needs to have high availability (when discussing on IRC yesterday it seemed like this *may* be possible today but more testing is required to shake out any bugs).<br>

<br>
Now may well be the right approach *is* to make some changes to these expectations about Nova, but I think it's disingenuous to suggest that what is being suggested here isn't a significant re-architecting to resolve issues resulting from earlier hacks that allowed this functionality to work in the first place. Should be an interesting summit session.<br>

<br>
-Steve<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><br clear="all"><br>-- <br><div dir="ltr"><div>Thanks,<br><br></div>Jay<br></div>
</div>