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

From: Amit Shah <amit.shah@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
	qemu list <qemu-devel@nongnu.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/1] migration: announce VM's new home just before VM is runnable
Date: Thu, 15 Oct 2015 13:34:10 +0530	[thread overview]
Message-ID: <20151015080410.GD31081@grmbl.mre> (raw)
In-Reply-To: <87zizkr62m.fsf@neno.neno>

On (Thu) 15 Oct 2015 [08:36:49], Juan Quintela wrote:
> Amit Shah <amit.shah@redhat.com> 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 <amit.shah@redhat.com> 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 <amit.shah@redhat.com>
> >> > 
> >> > Reviewed-by: Juan Quintela <quintela@redhat.com>
> >> > 
> >> > 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.

> 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