Os convidados do KVM perdem a conectividade após o reinício da rede

Question

estamos configurando um host 10.04 do servidor Ubuntu com o kvm. O host é configurado com uma ligação e interfaces em ponte para permitir que os convidados acessem a rede sem precisar de permissão. Nossa configuração atual está funcionando bem, exceto quando estamos reiniciando a rede com uma reinicialização /etc/init.d/networking. Depois de reiniciar a rede, os convidados perdem a conectividade. A única maneira de restaurá-lo é parar o convidado e iniciá-lo novamente.

Estou procurando, mas não consigo encontrar nenhum bug / problema / relatório desse comportamento.

Aqui segue o nosso arquivo de configuração de rede:

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

Obrigado

ADDENDUM - brctl mostra a saída antes e depois do nw restart:

BRCTL SHOW ANTES DE NW REINICIAR

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 APÓS REINICIAR NW

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

aparentemente, as duas interfaces virtuais não voltam após a reinicialização da rede.

PS ANTES DO NW REINICIAR

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 APÓS REINICIAR NW

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

    

Answer 1

Bem, existe o problema, quando você reinicia a rede, os dispositivos tap vnetX não são reconectados, fazendo com que as VMs percam a conectividade com a ponte.

Eu acho que você poderia reconectá-los manualmente à bridge, pois eles ainda estão em execução, mas a maneira correta de fazer isso seria migrar as VMs de um host onde você faz alterações de rede, ou desative as VMs, se você estiver em um único modo de host. Na maioria dos sistemas de nível corporativo, isso é chamado de "modo de manutenção", e alterar a configuração da rede é definitivamente a manutenção.