@Divakar, exactly, we want do ESX server level live-migrations with vCenter (VCDriver) by leveraging nova scheduler. Thanks.
2014-04-09 23:36 GMT+08:00 Nandavar, Divakar Padiyar < [email protected]>: > Steve, > 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. > > Thanks, > Divakar > > -----Original Message----- > From: Steve Gordon [mailto:[email protected]] > Sent: Wednesday, April 09, 2014 8:38 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live > migration with one nova compute > Importance: High > > ----- Original Message ----- > > I'm not writing off vCenter or its capabilities. I am arguing that the > > bar for modifying a fundamental design decision in Nova -- that of > > being horizontally scalable by having a single nova-compute worker > > responsible for managing a single provider of compute resources -- was > > WAY too low, and that this decision should be revisited in the future > > (and possibly as part of the vmware driver refactoring efforts > > currently underway by the good folks at RH and VMWare). > > +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). > > 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. > > -Steve > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Thanks, Jay
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
