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 <mi...@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....@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@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp