6

we're setting up an ubuntu server 10.04 host with kvm. The host is setup with a bond and bridged interfaces to allow the guests access to the network without natting. Our current configuration is working fine, except when we're restarting the network with an /etc/init.d/networking restart. After restarting the network, the guests lose connectivity. The only way to restore it is to halt the guest and start it again.

I've been looking around but I can't seem to find any known bug/issue/report of this behavior.

Here follows our network configuration file:

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
    bond-slaves none
    bond-mode active-backup
    bond-downdelay 250
    bond-updelay 120
    bond-miimon 100

auto eth0
iface eth0 inet manual
    bond-master bond0
    bond-primary eth0 eth1

auto eth1
iface eth1 inet manual
    bond-master bond0
    bond-primary eth0 eth1

#bridge used by host
auto br-vlan180
iface br-vlan180 inet static
    address 10.0.0.200
    netmask 255.255.255.0
    gateway 10.0.0.1
    vlan-raw-device bond0
    bridge_ports vlan180
    bridge_maxwait 0
    bridge_fd 0
    bridge_stp off
#bridge without address, used by vm
auto br-vlan120
iface br-vlan120 inet manual
    vlan-raw-device bond0
    bridge_ports vlan120
    bridge_maxwait 0
    bridge_fd 0
    bridge_stp off

Thank you

ADDENDUM - brctl show output before and after nw restart:

BRCTL SHOW BEFORE NW RESTART

brctl show
bridge name bridge id       STP enabled interfaces
br-vlan120      8000.984be1644072   no      vlan120
                            vnet0
                            vnet1
br-vlan180      8000.984be1644072   no      vlan180
virbr0      8000.000000000000   yes 

BRCTL SHOW AFTER NW RESTART

brctl show
bridge name bridge id       STP enabled interfaces
br-vlan120      8000.984be1644072   no      vlan120
br-vlan180      8000.984be1644072   no      vlan180
virbr0      8000.000000000000   yes

apparently, the two virtual interfaces fail to come back after network restart.

PS BEFORE NW RESTART

ps -ef | grep qemu
root      1784     1  6 11:45 ?        00:00:40 /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 512 -smp 1 -name test02 -uuid ee6d84b6-dbf8-d93c-b32f-8ae6b7d9b80e -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/test02.monitor,server,nowait -monitor chardev:monitor -boot c -drive file=/dev/sysvg/test02,if=virtio,index=0,boot=on,format=raw -drive file=/root/ubuntu-10.04.2-server-amd64.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=52:54:00:2c:d1:26,vlan=0,name=nic.0 -net tap,fd=48,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 127.0.0.1:0 -vga cirrus -soundhw es1370
root      2711     1 89 11:55 ?        00:00:14 /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 512 -smp 2 -name nttest -uuid 04ca381e-0510-7d3c-c7e2-8f7d7b6ea58f -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nttest.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/dev/sysvg/nttest,if=ide,index=0,boot=on,format=raw -drive file=/root/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_English_w_SP1_MLF_X17-22580.ISO,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=52:54:00:62:1b:2e,vlan=0,name=nic.0 -net tap,fd=51,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:1 -vga cirrus -soundhw es1370

PS AFTER NW RESTART

ps -ef | grep qemu
root      1784     1  4 11:45 ?        00:00:59 /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 512 -smp 1 -name test02 -uuid ee6d84b6-dbf8-d93c-b32f-8ae6b7d9b80e -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/test02.monitor,server,nowait -monitor chardev:monitor -boot c -drive file=/dev/sysvg/test02,if=virtio,index=0,boot=on,format=raw -drive file=/root/ubuntu-10.04.2-server-amd64.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=52:54:00:2c:d1:26,vlan=0,name=nic.0 -net tap,fd=48,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 127.0.0.1:0 -vga cirrus -soundhw es1370
root      2711     1 39 11:55 ?        00:03:51 /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 512 -smp 2 -name nttest -uuid 04ca381e-0510-7d3c-c7e2-8f7d7b6ea58f -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nttest.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/dev/sysvg/nttest,if=ide,index=0,boot=on,format=raw -drive file=/root/SW_DVD5_Windows_Svr_DC_EE_SE_Web_2008_R2_64Bit_English_w_SP1_MLF_X17-22580.ISO,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=52:54:00:62:1b:2e,vlan=0,name=nic.0 -net tap,fd=51,vlan=0,name=tap.0 -chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:1 -vga cirrus -soundhw es1370
3
  • 1
    can you also show the running VM cmd line (ps -ef | grep qemu) and brctl show before and after the networking restart happens
    – dyasny
    Oct 19, 2011 at 9:08
  • Added output to question text since characters allowed in comment are not enough. Oct 20, 2011 at 12:13
  • 1
    We had the same problem and came up with that script: github.com/makinacorpus/makina-states/blob/stable/files/etc/…
    – kiorky
    Nov 28, 2014 at 16:35

1 Answer 1

6

Well, there is the problem, when you restart the networking, the vnetX tap devices are not reconnected, causing the VMs to lose connectivity with the bridge.

I guess you could manually reconnect them to the bridge, since they are still running, but the right way to do this would be to migrate the VMs away from a host where you make network changes, or take the VMs down, if you're in a single host mode. In most corporate level systems this is called "maintenance mode", and changing the network config is definitely maintenance.

5
  • Well, it makes sense, I agree. Restarting the network is ok on a simple host, but destructive on a kvm host. The big problem arises when you setup a new vlan bridge or such. Due to this behavior, the only way is to add vlan and bridge manually and update the network configuration file to let the system setup the interfaces at reboot. Adding the interfaces to the bridge manually restores the network flow. Thanks for the follow up. Oct 20, 2011 at 14:06
  • I don't see the point in a reboot, just take the VMs down before you introduce changes, make the changes, and start the VMs up.
    – dyasny
    Oct 20, 2011 at 15:13
  • I didn't express myself clearly, sorry: I meant, the /etc/networking/interfaces will take care of setting up the interfaces after a reboot (for example if you need to do some maintenance or kernel upgrade). Regards. Oct 20, 2011 at 15:33
  • You mean change the settings in the config file, but do not apply them, until you reboot? That can work, but sometimes you really need an extra vlan right now :) anyhow, glad it worked out for you
    – dyasny
    Oct 20, 2011 at 18:33
  • Exactly! :D For that need, I'll proceed with manual setup! :) Regards and thank you one more time. I'll open a case with Canonical (we have a support contract) and post back what they think about this. Knowing the reason of the network interruption is already a success, so I consider this solved :) Oct 21, 2011 at 8:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .