Open Stack

Thanks Solly and Alessandro!

@Solly,

Yes, I also want to make the code change not VMWare-specific, but perhaps
we can consider of what @Alessandro said, we are going to have hyper-V
cluster support in next cycle, and maybe Power HMC in the future. All of
them can be managed in cluster level and one cluster can have multiple
hypervisors.

So I think that it might be a time to enhance live migration to handle not
only the case of single hypervisor but also multiple hypervisors managed by
one cluster.

Hope we can also get some comments from VMWare guys.

Thanks.


2014-04-01 6:57 GMT+08:00 Alessandro Pilotti <
apilotti at cloudbasesolutions.com>:

>
> On 31 Mar 2014, at 18:13, Solly Ross <sross at redhat.com> wrote:
>
> > 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.
> >
>
> In terms of driver specific features, we're evaluating cluster support for
> Hyper-V in the next cycle which would encounter the same issue for live
> migration.
> Hyper-V does not require clustering for supporting live migration (it's
> already available since Grizzly), but various users are requesting Windows
> clustering support
> for supporting specific scenarios, which requires a separate Nova Hyper-V
> failover clustering driver with resemblances to the VCenter driver in terms
> of
> cells / hosts management. Note: this is not related to Microsoft System
> Center.
>
> Evaluating such a feature solely in base of blueprints barely under
> drafting for other drivers and never discussed for approval isn't obviously
> requested, but it might be
> useful to consider the possibility that VMWare's might not be the only
> Nova driver with this requirement in the relatively short term future.
>
> Thanks,
>
> Alessandro
>
>
> > Best Regards,
> > Solly Ross
> >
> > ----- Original Message -----
> > From: "Jay Lau" <jay.lau.513 at gmail.com>
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> > 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 < john at johngarbutt.com > :
> >
> >
> >
> > On 31 March 2014 10:11, Jay Lau < jay.lau.513 at gmail.com > 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
> > 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
>
>
> _______________________________________________
> 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/20140401/adf3eafc/attachment.html>