[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

Jay Lau jay.lau.513 at gmail.com
Fri Apr 4 05:30:11 UTC 2014


2014-04-04 12:46 GMT+08:00 Jay Pipes <jaypipes at gmail.com>:

> On Fri, 2014-04-04 at 11:08 +0800, Jay Lau wrote:
> > Thanks Jay and Chris for the comments!
> >
> > @Jay Pipes, I think that we still need to enable "one nova compute
> > live migration" as one nova compute can manage multiple clusters and
> > VMs can be migrated between those clusters managed by one nova
> > compute.
>
> Why, though? That is what I am asking... seems to me like this is an
> anti-feature. What benefit does the user get from moving an instance
> from one VCenter cluster to another VCenter cluster if the two clusters
> are on the same physical machine?
>
@Jay Pipes, for VMWare, one physical machine (ESX server) can only belong
to one VCenter cluster, so we may have following scenarios.
DC
 |
 |---Cluster1
 |      |
 |      |---host1
 |
 |---Cluser2
        |
        |---host2

Then when using VCDriver, I can use one nova compute manage both Cluster1
and Cluster2, this caused me cannot migrate VM from host2 to host1 ;-(

The bp was introduced by
https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service

>
> Secondly, why is it that a single nova-compute manages multiple VCenter
> clusters? This seems like a hack to me... perhaps someone who wrote the
> code for this or knows the decision behind it could chime in here?
>
> >  For cell, IMHO, each "cell" can be treated as a small "cloud" but not
> > a "compute", each "cell cloud" should be able to handle VM operations
> > in the small cloud itself. Please correct me if I am wrong.
>
> Yes, I agree with you that a cell is not a compute. Not sure if I said
> otherwise in my previous response. Sorry if it was confusing! :)
>
> Best,
> -jay
>
> > @Chris, "OS-EXT-SRV-ATTR:host" is the host where nova compute is
> > running and "OS-EXT-SRV-ATTR:hypervisor_hostname" is the hypervisor
> > host where the VM is running. Live migration is now using "host" for
> > live migration. What I want to do is enable migration with one "host"
> > and the "host" managing multiple "hyperviosrs".
> >
> >
> > I'm planning to draft a bp for review which depend on
> > https://blueprints.launchpad.net/nova/+spec/vmware-auto-inventory
> >
> >
> > Thanks!
> >
> >
> >
> > 2014-04-04 8:03 GMT+08:00 Chris Friesen <chris.friesen at windriver.com>:
> >         On 04/03/2014 05:48 PM, Jay Pipes wrote:
> >                 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.
> >
> >
> >         Here is where precise definitions of "compute node",
> >         "OS-EXT-SRV-ATTR:host", and
> >         "OS-EXT-SRV-ATTR:hypervisor_hostname", and "host" as
> >         understood by novaclient would be nice.
> >
> >         Currently the "nova live-migration" command takes a "host"
> >         argument. It's not clear which of the above this corresponds
> >         to.
> >
> >         My understanding is that one nova-compute process can manage
> >         multiple VMWare physical hosts.  So it could make sense to
> >         support live migration between separate VMWare hosts even if
> >         they're managed by a single nova-compute process.
> >
> >         Chris
> >
> >
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Thanks,
> >
> >
> > Jay
> >
> > _______________________________________________
> > 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/20140404/f23d9cec/attachment.html>


More information about the OpenStack-dev mailing list