[libvirt-users] Restarting network on host completely cuts off guests. Why? How to prevent?
Hi list, this probably isn't a completely libvirt-specific question but I'll try anyway. Please ignore if it is too much off-topic. On an Ubuntu (9.10) virtualisation host, running KVM and libvirt and several guests (Debian, Ubuntu, Windows Server 2003) in a bridged network fashion [1,2] I noticed that performing /etc/init.d/networking restart on the host completely cuts off all guests from the network. I have to manually shutdown and restart (virsh shutdown GUEST && virsh start GUEST, a mere reboot doesn't suffice) them to get them onto the network again. Obviously that's not ideal. Is this the expected behaviour? Can I somehow re-establish guest network connectivity without shutting down the guest first? Is my setup somehow wrong or do I expect too much? Any insight, explanation or pointers would be much appreciated! Thanks, Andreas [1] http://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging [2] http://wiki.libvirt.org/page/Networking#Guest_configuration_2 -- Andreas Ntaflos GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
2010/4/18 Andreas Ntaflos <daff@pseudoterminal.org>:
On an Ubuntu (9.10) virtualisation host, running KVM and libvirt and several guests (Debian, Ubuntu, Windows Server 2003) in a bridged network fashion [1,2] I noticed that performing
/etc/init.d/networking restart
on the host completely cuts off all guests from the network. I have to manually shutdown and restart (virsh shutdown GUEST && virsh start GUEST, a mere reboot doesn't suffice) them to get them onto the network again. Obviously that's not ideal.
Confirmed, I have the same problem. Even with bridged configuration, do you have dnsmasq running elsewhere (maybe with --bind-inferfaces flag)? If i got it right, an application can bind to an "handle" of an ethernet device and not its name, so when you restart networking, the handle will change and apps binded to the previous handle will stop working. Maybe it's the hypervisor itself (the ubuntu default is kvm) to bind to the interface, so it maybe not be related at all with libvirt. Another thing I have observerd in a NAT configuration is that there are problems in setting port forwarding from the host to guests when libvirt is not yet started (= default network "libvirt0" bridge not created and proper route to the NATed subnetwork not added). It seems it just doesn't work, and it seems strange to me because I thought iptables rules should have held even devices or hosts/networks didn't exist. I "sorted" editing libvirt-bin init script adding a line that adds port forwarding after libvirt have been started. This is the kind of "ugly workarounds" I hate, but at the time it was the quicker working (and safe) solution and din't have time to do a proper reporting. Maybe it does worth report this to ubuntu and/or kvm. Greetings, Francesco
On 04/17/2010 09:38 PM, Andreas Ntaflos wrote:
Hi list,
this probably isn't a completely libvirt-specific question but I'll try anyway. Please ignore if it is too much off-topic.
On an Ubuntu (9.10) virtualisation host, running KVM and libvirt and several guests (Debian, Ubuntu, Windows Server 2003) in a bridged network fashion [1,2] I noticed that performing
/etc/init.d/networking restart
on the host completely cuts off all guests from the network. I have to manually shutdown and restart (virsh shutdown GUEST && virsh start GUEST, a mere reboot doesn't suffice) them to get them onto the network again. Obviously that's not ideal.
Is this the expected behaviour? Can I somehow re-establish guest network connectivity without shutting down the guest first? Is my setup somehow wrong or do I expect too much?
Unfortunately, that is the expected behavior. If you do: # brctl show # /etc/init.d/networking restart # brctl show You'll see that the list of interfaces attached to the bridge is different before and after. The problem is that as libvirt starts a guest, it plugs the virtual interface into the bridge device. When you do a networking restart, all of those interfaces are lost from the bridge, and there is no way currently to re-attach them. It's probably fix-able, but non-trivial; libvirt would have to be notified by the system (via D-bus?) that the bridge was restarted, and then it would have to re-plug the interfaces on the "new" bridge. -- Chris Lalancette
On Mon, Apr 19, 2010 at 6:02 AM, Chris Lalancette <clalance@redhat.com>wrote:
Unfortunately, that is the expected behavior. If you do:
# brctl show # /etc/init.d/networking restart # brctl show
I also have this problem when I net-destroy/net-start the libvirt network in order to load a new network definition (typically, new DHCP hosts). I made a script which captures the br interfaces, restarts the network, then reattaches, but it seems like there should be a way for libvirt to do this for me since I'm restarting it's network and it's the one that plugged the interfaces in. Is there something I'm missing? Ubuntu 9.10 / libvirt 0.7.0. .:. jeremy
On Monday 19 April 2010 15:02:59 Chris Lalancette wrote:
On 04/17/2010 09:38 PM, Andreas Ntaflos wrote:
Hi list,
this probably isn't a completely libvirt-specific question but I'll try anyway. Please ignore if it is too much off-topic.
On an Ubuntu (9.10) virtualisation host, running KVM and libvirt and several guests (Debian, Ubuntu, Windows Server 2003) in a bridged network fashion [1,2] I noticed that performing
/etc/init.d/networking restart
on the host completely cuts off all guests from the network. I have to manually shutdown and restart (virsh shutdown GUEST && virsh start GUEST, a mere reboot doesn't suffice) them to get them onto the network again. Obviously that's not ideal.
Is this the expected behaviour? Can I somehow re-establish guest network connectivity without shutting down the guest first? Is my setup somehow wrong or do I expect too much?
Unfortunately, that is the expected behavior. If you do:
Hi, thank you for the clarification and confirmation. I'll be keeping it in mind. Hopefully libvirt will someday support restarting the network; unfortunately there isn't much I can do to help except testing. Thanks, Andreas -- Andreas Ntaflos GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
participants (4)
-
Andreas Ntaflos -
Chris Lalancette -
Francesco Pretto -
jeremy avnet