Building on what John said, I'm a bit wary of introducing semantics into the 
Conductor's live migration code
that are VMWare-specific.  The conductor's live-migration code is supposed to 
be driver-agnostic.  IMHO, it
would be much better if we could handle this at a level where the code was 
already VMWare-specific.

Best Regards,
Solly Ross

----- Original Message -----
From: "Jay Lau" <[email protected]>
To: "OpenStack Development Mailing List (not for usage questions)" 
<[email protected]>
Sent: Monday, March 31, 2014 10:36:17 AM
Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live 
migration with one nova compute

Thanks John. Yes, I also think that this should be a bp as it is going to make 
some changes to enable live migration with only one nova compute, will file a 
blueprint later. 

For your proposal "specify the same host as the instance", this can resolve the 
issue of live migration with target host, but what about the case of live 
migration without target host? If we still allow "specify the same host as the 
instance", the the live migration will goes to dead loop. 

So it seems we definitely need to find a way to specify the node for live 
migration, hope someone else can show some light here. 

Of course, I will file bp and go through the new bp review process for this 
feature. 

Thanks! 


2014-03-31 21:02 GMT+08:00 John Garbutt < [email protected] > : 



On 31 March 2014 10:11, Jay Lau < [email protected] > 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. 
> 
> 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 

Long term, finding a way to unify how cells and the VMware driver 
manages multiple hosts, seems like the best way forward. It would be a 
shame for this API to be different between cells and VMware, although 
right now, that might not work too well :( 

A better short term fix, might be to allow you to specify the same 
host as the instance, and the scheduling of the node could be 
delegated to the VMware driver, which might just delegate that to 
vCenter. I assume we still need some way to specify the node, and I 
can't immediately think of a good way forward. 

I feel this should really be treated as a blueprint, and go through 
the new blueprint review process. That should help decide the right 
approach to take. 

John 

_______________________________________________ 
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

_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to