On Mon, 2014-03-31 at 17:11 +0800, Jay Lau wrote: > Hi, > > Currently with VMWare VCDriver, one nova compute can manage multiple > clusters/RPs, this caused cluster admin cannot do live migration > between clusters/PRs if those clusters/PRs managed by one nova compute > as the current live migration logic request at least two nova > computes. > > > A bug [1] was also filed to trace VMWare live migration issue. > > I'm now trying the following solution to see if it is acceptable for a > fix, the fix wants enable live migration with one nova compute: > 1) When live migration check if host are same, check both host and > node for the VM instance. > 2) When nova scheduler select destination for live migration, the live > migration task should put (host, node) to attempted hosts. > 3) Nova scheduler needs to be enhanced to support ignored_nodes. > 4) nova compute need to be enhanced to check host and node when doing > live migration.
What precisely is the point of "live migrating" an instance to the exact same host as it is already on? The failure domain is the host, so moving the instance from one "cluster" to another, but on the same host is kind of a silly use case IMO. But... if this really is something that is considered useful, then it seems to me that it would be more useful to simply expand the definition of the "compute node" object within Nova to be generic enough that a compute node could be a VCenter cluster/PR. That way there would be no need to hack the scheduler to account for more than the host (compute node internally in Nova)? In the same way, a cell could be a "compute node" as well, and we wouldn't need separate hacks in the scheduler and elsewhere that treated cells differently than "regular" compute nodes. Best, -jay > I also uploaded a WIP patch [2] for you to review the idea of the fix > and hope can get some comments from you. > > > [1] https://bugs.launchpad.net/nova/+bug/1192192 > [2] https://review.openstack.org/#/c/84085 > > > -- > Thanks, > > > Jay > > _______________________________________________ > 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
