Re: KVM doesn't send an arp announce after live migrating a domain

[Gleb Natapov <gleb@redhat.com>]

On Wed, Aug 25, 2010 at 12:37:21PM +0400, Michael Tokarev wrote:
> 25.08.2010 11:52, Nils Cant wrote:
> > Hey guys,
> > 
> > not sure if this is a bug or a feature request. It's just something
> > we've noticed and are having problems with.
> > 
> > We're using the qemu-kvm lenny-backports package on Debian 5.0.5.
> > 
> > When doing a live migration from the virsh shell, the server in question
> > becomes unreachable because the ARP cache on our switches still thinks
> > the server is on another port.
> > 
> > As soon as the server sends out some traffic, such as a ping, the ARP
> > cache get's updated as expected. If it does nothing, the server remains
> > unreachable until the ARP cache expires on the switches. (in our case 4
> > hours)
> > 
> > We would like to be able to do live migration for customer machines on
> > which we have no access, so we really need KVM to send out an ARP
> > announcement/gratuitous ARP when doing a live migration.
> > 
> > Could anyone tell me if this is a bug in KVM, libvirt, or the debian
> > qemu-kvm package? (or if I'm doing something wrong? :-) )
> 
> It's probably a bug in your understanding ;)
> 
> Jokes aside, the thing is that kvm does not know what is
> an ARP and what is an IP address.  It emulates a hardware
> network card, which never sends any ARP out by its own,
> it is the operating system IP stack who's doing that.
> That network card as emulated by kvm does not know what
> IP addresses are assigned to it inside the guest (there
> may be many, or may be none at all), so it just can not
> send the ARPs.
> 
True. Although qemu sends gratuitous ARP the IP field there is
incorrect. It is done to update layer 2 topology, not layer 3.

> These ARPs should be sent by guest.  Another question is
> how to force/tell it to do so, and this is, again, depends
> on the guest operating system, number of addresses assigned
> to the interface and so on.
> 
> The mechanism to trigger it may be based on link status
> of the card for example - kvm may lower it for a few ms
> right after migration, to indicate that the "cord" were
> un-plugged and plugged back, to force the guest to do
> whatever it needs to do...  But that's just a possibility
> for future development.
> 
> /mjt
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
			Gleb.