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. 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
