Open Stack

Thanks Michael for the answer, just want to dig more.

>From your answer, it seems that we do not want libvirt on one node opens up
a connection to the other, but from the Gerrit code diff, I did not notice
any change on nova compute, but only move the logic of live
migraiton/resize/code migration from scheduler to conductor, and conductor
still call nova compute directly and once the request cast to nova compute,
libvirt on one node still opens up a connection to the another, so what is
the difference?

Thanks,
Jay



2013/6/1 Michael Still <mikal at stillhq.com>

> IIRC the discussion from the summit, there was concern about compute
> nodes talking directly to each other. The way live migration works in
> libvirt is that the libvirt on one node opens up a connection to the
> other and then streams the instance across. If this is bounced off a
> conductor, then it makes firewall rules much easier to construct.
>
> Cheers,
> Michael
>
> On Sat, Jun 1, 2013 at 2:53 PM, Lau Jay <jay.lau.513 at gmail.com> wrote:
> > Hi Stackers,
> >
> > I noticed that there are some blueprints trying to move the logic of live
> > migration/resize/code migration/provision from nova scheduler to nova
> > conductor, but the blueprint did not describe clearly the benefits of
> doing
> > so, can some experts give some explanation on this?
> >
> > I know the original design for nova conductor is for a non-db nova
> compute,
> > but what's the reason of moving scheduling logic to nova conductor?
> >
> > Thanks,
> >
> > Jay
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130601/8a1c7080/attachment.html>