qemu-kvm virtual machine virtio congelamento de rede sob carga

Question

Estou tendo um problema com minhas máquinas virtuais, onde a rede congelará sob carga pesada. Estou usando o CentOS 6.2 como host e guest, não usando libvirt, apenas executando o qemu-kvm diretamente da seguinte maneira:

/usr/libexec/qemu-kvm \
   -drive file=/data2/vm/rb-dev2-www1-vm.img,index=0,media=disk,cache=none,if=virtio \
   -boot order=c \
   -m 2G \
   -smp cores=1,threads=2 \
   -vga std \
   -name rb-dev2-www1-vm \
   -vnc :84,password \
   -net nic,vlan=0,macaddr=52:54:20:00:00:54,model=virtio \
   -net tap,vlan=0,ifname=tap84,script=/etc/qemu-ifup \
   -monitor unix:/var/run/vm/rb-dev2-www1-vm.mon,server,nowait \
   -rtc base=utc \
   -device piix3-usb-uhci \
   -device usb-tablet

/ etc / qemu-ifup (usado pelo comando acima) é um script muito simples, contendo o seguinte:

#!/bin/sh

sudo /sbin/ifconfig $1 0.0.0.0 promisc up
sudo /usr/sbin/brctl addif br0 $1
sleep 2

E aqui está a informação sobre a br0 e outras interfaces:

avl-host3 14# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.180373f5521a       no              bond0
                                                        tap84
virbr0          8000.525400858961       yes             virbr0-nic
avl-host3 15# ip addr show 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
    link/ether 18:03:73:f5:52:1a brd ff:ff:ff:ff:ff:ff
3: em2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
    link/ether 18:03:73:f5:52:1a brd ff:ff:ff:ff:ff:ff
4: em3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 18:03:73:f5:52:1e brd ff:ff:ff:ff:ff:ff
5: em4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 18:03:73:f5:52:20 brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 18:03:73:f5:52:1a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::1a03:73ff:fef5:521a/64 scope link 
       valid_lft forever preferred_lft forever
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 18:03:73:f5:52:1a brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.46/24 brd 172.16.1.255 scope global br0
    inet6 fe80::1a03:73ff:fef5:521a/64 scope link 
       valid_lft forever preferred_lft forever
8: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 52:54:00:85:89:61 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
9: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
    link/ether 52:54:00:85:89:61 brd ff:ff:ff:ff:ff:ff
12: tap84: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether ba:e8:9b:2a:ff:48 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b8e8:9bff:fe2a:ff48/64 scope link 
       valid_lft forever preferred_lft forever

bond0 é uma ligação de em1 e em2.

virbr0 e virbr0-nic são interfaces vestigiais remanescentes da instalação padrão do CentOS. Eles não são usados (até onde eu sei).

O convidado funciona perfeitamente até que eu execute um grande 'rsync', quando a rede irá congelar depois de algum tempo aparentemente aleatório (geralmente menos de um minuto). Quando congela, não há atividade de rede dentro ou fora do convidado. Ainda consigo me conectar ao console do convidado via vnc, mas não consigo falar sua interface de rede. Qualquer tentativa de "pingar" do convidado fornece um erro "Destination Host Unreachable" para 3/4 pacotes e nenhuma resposta para cada quarto pacote.

Às vezes (talvez dois terços do tempo), posso trazer a interface de volta à vida fazendo um "reinício de rede de serviço" no console do convidado. Se isso funcionar (e se eu fizer isso antes do tempo limite do rsync), o rsync será retomado. Normalmente, ele irá congelar novamente dentro de um ou dois minutos. Se eu repetir, o rsync terminará, e presumo que a máquina volte a esperar por outro período de carga pesada.

Durante todo o processo, não há erros de console ou mensagens syslog relevantes (que eu possa ver) em qualquer convidado ou máquina host.

Se a "reinicialização da rede de serviços" não funcionar na primeira vez, tentar de novo (e de novo e de novo) nunca parece funcionar. O comando é concluído normalmente, com saída normal, mas a interface permanece congelada. No entanto, uma reinicialização suave da máquina convidada (sem reiniciar o qemu-kvm) sempre parece trazê-lo de volta.

Estou ciente do problema de atribuição "menor endereço mac", onde a bridge assume o endereço mac da interface slave com o menor endereço mac. Isso causa o congelamento temporário da rede, mas definitivamente não é o que está acontecendo comigo. Meus congelamentos são permanentes até a intervenção manual, e você pode ver na saída 'ip addr show' acima que o endereço MAC usado por br0 é o da Ethernet física.

Não há outras máquinas virtuais em execução no host. Eu verifiquei que cada máquina virtual na sub-rede tem seu próprio endereço MAC exclusivo.

Eu reconstruí a máquina convidada várias vezes, e tentei isso em três máquinas host diferentes (hardware idêntico, construído de forma idêntica). Estranhamente, eu tenho um host virtual (o segundo desta série) que nunca pareceu ter um problema. Ele nunca teve sua rede congelada quando estava executando o mesmo rsync durante sua compilação. É particularmente estranho porque foi a segunda versão. O primeiro, em um host diferente, teve o problema de congelamento, mas o segundo não. Assumi na época que havia feito algo errado com a primeira compilação e que o problema estava resolvido. Infelizmente, o problema reapareceu quando eu criei a terceira VM. Também, infelizmente, não posso fazer muitos testes com a VM que está funcionando, já que agora ela está em uso de produção, e espero encontrar a causa desse problema antes que a máquina comece a ter problemas. É possível que eu tenha tido muita sorte ao executar o rsync na máquina em funcionamento e que uma vez ele não tenha congelado.

É claro que é possível que eu tenha mudado os scripts de construção sem perceber e quebrei novamente algo, mas não consigo encontrar nada disso.

De qualquer forma, espero que alguém tenha alguma ideia do que poderia causar isso.

Adendo: Testes preliminares sugerem que eu não tenho o problema se eu substituir e1000 por virtio no primeiro sinalizador -net para qemu-kvm. Eu não considero isso uma solução, mas é adequado para um paliativo. Alguém mais teve (ou melhor ainda, resolveu) esse problema com o driver de rede virtio?

    

Answer 1

Estou passando por um problema semelhante executando o qemu kvm em uma máquina debian (embora eu esteja rodando através da libvirt). Eu disparei o congelamento de nic clonando um disco sobre o ftp em direção a um dos 3 vm em execução neste host, apenas a vm em questão parece ser afetada. Os outros 2 vm e o host continuam funcionando bem. Para mim também parece que o virtio está causando o congelamento.

kernel do host (Debian Lenny 5.0.6):
Linux host_machine_1 2.6.32-bpo.5-amd64 #1 SMP Thu Oct 21 10:02:18 UTC 2010 x86_64 GNU/Linux

kernel convidado (Ubuntu Hardy Heron 8.04 LTS):
Linux virtual_machine_1 2.6.24-26-server #1 SMP Tue Dec 1 18:26:43 UTC 2009 x86_64 GNU/Linux

convidado syslog:

Feb 21 09:00:22 virtual_machine_1 kernel: [63114.151904] swapper: page allocation failure. order:1, mode:0x4020
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.151919] Pid: 0, comm: swapper Not tainted 2.6.24-26-server #1
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.151920] 
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.151921] Call Trace:
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.151925]    [__alloc_pages+0x2fd/0x3d0] __alloc_pages+0x2fd/0x3d0
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152256]  [new_slab+0x220/0x260] new_slab+0x220/0x260
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152260]  [__slab_alloc+0x2f5/0x410] __slab_alloc+0x2f5/0x410
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152281]  [virtio_net:__netdev_alloc_skb+0x2b/0x2eb0] __netdev_alloc_skb+0x2b/0x50
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152285]  [virtio_net:__netdev_alloc_skb+0x2b/0x2eb0] __netdev_alloc_skb+0x2b/0x50
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152287]  [__kmalloc_node_track_caller+0x121/0x130] __kmalloc_node_track_caller+0x121/0x130
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152290]  [ipv6:__alloc_skb+0x7b/0x4f0] __alloc_skb+0x7b/0x160
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152293]  [virtio_net:__netdev_alloc_skb+0x2b/0x2eb0] __netdev_alloc_skb+0x2b/0x50
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152312]  [virtio_net:try_fill_recv+0x61/0x1b0] :virtio_net:try_fill_recv+0x61/0x1b0
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152336]  [ktime_get_ts+0x1b/0x50] ktime_get_ts+0x1b/0x50
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152341]  [virtio_net:virtnet_poll+0x18c/0x350] :virtio_net:virtnet_poll+0x18c/0x350
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152346]  [tick_program_event+0x35/0x60] tick_program_event+0x35/0x60
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152355]  [net_rx_action+0x128/0x230] net_rx_action+0x128/0x230
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152358]  [virtio_net:skb_recv_done+0x2c/0x40] :virtio_net:skb_recv_done+0x2c/0x40
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152369]  [__do_softirq+0x75/0xe0] __do_softirq+0x75/0xe0
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152379]  [call_softirq+0x1c/0x30] call_softirq+0x1c/0x30
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152386]  [do_softirq+0x35/0x90] do_softirq+0x35/0x90
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152389]  [irq_exit+0x88/0x90] irq_exit+0x88/0x90
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152391]  [do_IRQ+0x80/0x100] do_IRQ+0x80/0x100
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152393]  [default_idle+0x0/0x40] default_idle+0x0/0x40
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152395]  [default_idle+0x0/0x40] default_idle+0x0/0x40
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152396]  [ret_from_intr+0x0/0x0a] ret_from_intr+0x0/0xa
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152398]    [default_idle+0x29/0x40] default_idle+0x29/0x40
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152404]  [cpu_idle+0x48/0xe0] cpu_idle+0x48/0xe0
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152471]  [start_kernel+0x2c5/0x350] start_kernel+0x2c5/0x350
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152475]  [x86_64_start_kernel+0x12e/0x140] _sinittext+0x12e/0x140
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152482] 
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152483] Mem-info:
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152484] Node 0 DMA per-cpu:
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152486] CPU    0: Hot: hi:    0, btch:   1 usd:   0   Cold: hi:    0, btch:   1 usd:   0
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152487] Node 0 DMA32 per-cpu:
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152489] CPU    0: Hot: hi:  186, btch:  31 usd: 122   Cold: hi:   62, btch:  15 usd:  55
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152492] Active:35252 inactive:200609 dirty:11290 writeback:193 unstable:0
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152492]  free:1597 slab:11996 mapped:2986 pagetables:3395 bounce:0
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152494] Node 0 DMA free:3988kB min:40kB low:48kB high:60kB active:1320kB inactive:4128kB present:10476kB pages_scanned:0 all_unreclaimable? no
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152497] lowmem_reserve[]: 0 994 994 994
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152499] Node 0 DMA32 free:2400kB min:4012kB low:5012kB high:6016kB active:139688kB inactive:798308kB present:1018064kB pages_scanned:0 all_unreclaimable? no
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152502] lowmem_reserve[]: 0 0 0 0
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152504] Node 0 DMA: 3*4kB 1*8kB 0*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 3988kB
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152509] Node 0 DMA32: 412*4kB 0*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 2400kB
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152514] Swap cache: add 188, delete 187, find 68/105, race 0+0
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152516] Free swap  = 3084140kB
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152517] Total swap = 3084280kB
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.152517] Free swap:       3084140kB
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.158388] 262139 pages of RAM
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.158390] 4954 reserved pages
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.158391] 269600 pages shared
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.158392] 1 pages swap cached
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.158461] swapper: page allocation failure. order:1, mode:0x4020
Feb 21 09:00:22 virtual_machine_1 kernel: [63114.158464] Pid: 0, comm: swapper Not tainted 2.6.24-26-server #1

Configuração do convidado para o qemu:

<domain type='kvm'>  
  <name>virtual_machine_1</name>  
  <uuid>41c1bf76-2aaa-3b32-8868-f28748db750a</uuid>  
  <memory>2097152</memory>  
  <currentMemory>2097152</currentMemory>  
  <vcpu>1</vcpu>  
  <os>  
    <type arch='x86_64' machine='pc'>hvm</type>  
    <boot dev='hd'/>  
  </os>  
  <features>  
    <acpi/>  
    <apic/>  
    <pae/>  
  </features>  
  <clock offset='utc'/>  
  <on_poweroff>destroy</on_poweroff>  
  <on_reboot>restart</on_reboot>  
  <on_crash>restart</on_crash>  
  <devices>  
    <emulator>/usr/bin/kvm</emulator>  
    <disk type='block' device='disk'>  
      <driver name='qemu'/>  
      <source dev='/dev/drbd1'/>  
      <target dev='hda' bus='ide'/>  
      <address type='drive' controller='0' bus='0' unit='0'/>  
    </disk>  
    <disk type='block' device='cdrom'>  
      <driver name='qemu'/>  
      <target dev='hdc' bus='ide'/>  
      <readonly/>  
      <address type='drive' controller='0' bus='1' unit='0'/>  
    </disk>  
    <controller type='ide' index='0'/>  
    <interface type='bridge'>  
      <mac address='52:54:00:2d:95:e5'/>  
      <source bridge='br0'/>  
      <model type='virtio'/>  
    </interface>  
    <serial type='pty'>  
      <target port='0'/>  
    </serial>  
    <console type='pty'>  
      <target port='0'/>  
    </console>  
    <input type='mouse' bus='ps2'/>  
    <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>  
    <video>  
      <model type='cirrus' vram='9216' heads='1'/>  
    </video>  
  </devices>  
</domain>

Comando

kvm:

/usr/bin/kvm -S -M pc  
-enable-kvm  
-m 2048  
-smp 1,sockets=1,cores=1,threads=1  
-name virtual_machine_1  
-uuid 41c1bf76-2aaa-3b32-8868-f28748db750a  
-nodefaults  
-chardev socket,id=monitor,path=/var/lib/libvirt/qemu/virtual_machine_1.monitor,server,nowait  
-mon chardev=monitor,mode=readline -rtc base=utc  
-boot c -drive file=/dev/drbd1,if=none,id=drive-ide0-0-0,boot=on,format=raw  
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0  
-drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0  
-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:2d:95:e5,bus=pci.0,addr=0x3  
-net tap,fd=17,vlan=0,name=hostnet0  
-chardev pty,id=serial0  
-device isa-serial,chardev=serial0 -usb  
-vnc 0.0.0.0:1  
-k en-us  
-vga cirrus  
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4

Esta postagem parece estar relacionada: link

Esse patch também é mencionado (ainda não testei, mas ele deve resolver o problema): link