qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/1] migration: announce VM's new home just befo


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 1/1] migration: announce VM's new home just before VM is runnable
Date: Thu, 15 Oct 2015 11:19:53 +0300

On Thu, Oct 15, 2015 at 01:34:10PM +0530, Amit Shah wrote:
> On (Thu) 15 Oct 2015 [08:36:49], Juan Quintela wrote:
> > Amit Shah <address@hidden> wrote:
> > > On (Wed) 14 Oct 2015 [17:12:44], Michael S. Tsirkin wrote:
> > >> On Wed, Oct 14, 2015 at 03:21:15PM +0200, Juan Quintela wrote:
> > >> > Amit Shah <address@hidden> wrote:
> > >> > > We were announcing the dest host's IP as our new IP a bit too soon 
> > >> > > -- if
> > >> > > there were errors detected after this announcement was done, the
> > >> > > migration is failed and the VM could continue running on the src 
> > >> > > host --
> > >> > > causing problems later.
> > >> > >
> > >> > > Move around the qemu_announce_self() call so it's done just before 
> > >> > > the
> > >> > > VM is runnable.
> > >> > >
> > >> > > Signed-off-by: Amit Shah <address@hidden>
> > >> > 
> > >> > Reviewed-by: Juan Quintela <address@hidden>
> > >> > 
> > >> > applied.
> > >> > 
> > >> > I have the same question than Dave, but also agree that this is a
> > >> > movement in the right direction.
> > >> > 
> > >> > Why it is not only needed when we do a vm_start()?
> > >> 
> > >> It's a complex question.  We don't want to do this on each
> > >> vmstop/vmcont. But maybe we want to, on the 1st vmstart after
> > >> qemu is started.
> > >
> > > Why?  When a guest starts, it will issue ARP requests and everything
> > > will just work.  We need this announce_self only to tell the switches
> > > that the MAC belonging to the guest's IP has changed..
> > 
> > What happens if we stop a guest on one host and we start it on a
> > different host?
> 
> So the migration code doesn't get involved?  IOW, we don't call
> qemu_announce_self() at all?  I'd say that's a corner case: we provide
> live migration capability which sets up things fine; if people choose
> to use something else, they have to do their own setup.

I agree it's not a big deal.
Still, if someone is inclined to always announce self on first vm start,
that would also be OK.

> > If the communication is started from a different place, packets will go
> > to old host, until some TCP timeout happens, right?
> 
> Yes, packets from remote will keep going to the old host.  If the old
> host has since closed the qemu process, it will give tcp errors to the
> remote, and the remote will in time shut down its sockets.  Also, when
> the VM sends out any packets, switches could adjust their tables and
> send remote packets to the new host.  Depends on how smart the
> switches are.
> 
> 
>               Amit



reply via email to

[Prev in Thread] Current Thread [Next in Thread]