Open Stack

@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 <
divakar.padiyar-nandavar at hp.com>:

> 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:sgordon at redhat.com]
> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/7c4e3a06/attachment.html>