Gleb Natapov wrote: > On Wed, Aug 25, 2010 at 02:51:31PM +0400, Michael Tokarev wrote: [] >> For example, we may teach libvirt or kvm about IP addresses >> the guest is using, so that kvm will send these ARPs automatically >> after migration has completed. [] >> Kvm is the most natural place to do that, I think, and it's >> easy to implement there too (it has the tun device which can >> inject packets on behalf of the guest) Yes, the configuration >> will be duplicated somehow, but that's not a big problem, and >> it will make things much more reliable. >> > KVM is certainly not the most natural place to do that. Even gratuitous > ARP we have today will not work if guest changes mac address. KVM > couldn't care less about host network protocols. Management may implement > guest daemon that will take appropriate action to restore networking > after migration on demand (send gratuitous pigeon if IP over pigeons are > used by guest). I mean something else. When using standard, the most common configuration, without fancy settings or technologies like IP over pigeons, the most easy way to do that is in kvm, it should be just about 20 lines of code or so. Yes that will not work in some complex setups, where in-guest solution will be needed, but in that case a guest daemon alone wont help, it will need to run some script to do custom actions. For the MAC address changes for example -- the solution is simple: don't change MAC address in guest. Or if you do, either teach kvm about that (so it'll send proper ARP), or implement custom solution in guest, or don't migrate, or live with delays after migration. There are multiple choices. Yet doing it the simplest way (in kvm) will cover some 99% cases, and doing it as some daemon in the guest will cover that same 99% cases anyway (for the rest some custom script will be needed). So I think it's the best to implement it in kvm in the most stright-forward and easy way. Yes, some guest notification is probably needed anyway - not only for this case with networks but also in order to notify guest about, say, resume from freeze (after loadvm or migrate from file), afrer migration and so on, so guest can react to such events in a meaningful way. But this is in parallel with the ability to send an ARP after migration. Just IMHO ofcourse. /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
