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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
