Open Stack

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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev