Назад | Перейти на главную страницу

qemu-kvm зависание сети virtio под нагрузкой

У меня проблема с виртуальными машинами, из-за которых сеть зависает при большой нагрузке. Я использую CentOS 6.2 как в качестве хоста, так и в качестве гостя, не используя libvirt, просто запустив qemu-kvm напрямую следующим образом:

/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 (используемый приведенной выше командой) - очень простой скрипт, содержащий следующее:

#!/bin/sh

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

А вот информация о br0 и других интерфейсах:

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 - это связь em1 и em2.

virbr0 и virbr0-nic - это рудиментарные интерфейсы, оставшиеся от установки CentOS по умолчанию. Они не используются (насколько мне известно).

Гость работает отлично, пока я не запустил большой «rsync», когда сеть зависнет через некоторое, казалось бы, случайное время (обычно менее минуты). Когда он зависает, нет никакой сетевой активности в гостевой системе или за ее пределами. Я все еще могу подключиться к гостевой консоли через vnc, но он не может сообщить свой сетевой интерфейс. Любая попытка «ping» от гостя дает ошибку «Destination Host Unreachable» для 3/4 пакетов и отсутствие ответа для каждого четвертого пакета.

Иногда (возможно, в двух третях случаев) я могу оживить интерфейс, выполнив «перезапуск служебной сети» с гостевой консоли. Если это сработает (и если я сделаю это до истечения времени ожидания rsync), rsync возобновится. Обычно он снова замерзает через минуту или две. Если я повторю, rsync в конечном итоге завершится, и я предполагаю, что машина вернется к ожиданию еще одного периода большой нагрузки.

На протяжении всего процесса на гостевой или хост-машине нет ошибок консоли или соответствующих (которые я вижу) сообщений системного журнала.

Если «перезапуск служебной сети» не работает с первого раза, повторная попытка (и снова и снова), похоже, никогда не сработает. Команда завершается нормально, с нормальным выводом, но интерфейс остается замороженным. Однако мягкая перезагрузка гостевой машины (без перезапуска qemu-kvm) всегда возвращает ее обратно.

Мне известно о проблеме назначения «наименьшего MAC-адреса», когда мост принимает MAC-адрес подчиненного интерфейса с наименьшим MAC-адресом. Это вызывает временное зависание сети, но это определенно не то, что происходит со мной. Мои зависания будут постоянными до ручного вмешательства, и вы можете видеть из вывода 'ip addr show' выше, что MAC-адрес, используемый br0, является адресом физического Ethernet.

На хосте нет других виртуальных машин. Я проверил, что каждая виртуальная машина в подсети имеет свой уникальный MAC-адрес.

Я перестраивал гостевую машину несколько раз и пробовал это на трех разных хост-машинах (идентичное оборудование, одинаково построенное). Как ни странно, у меня есть один виртуальный хост (второй из этой серии), с которым никогда не возникало проблем. У него никогда не было зависания сети, когда он запускал тот же самый rsync во время сборки. Это особенно странно, потому что это была вторая сборка. У первого, на другом хосте, была проблема с зависанием, а у второго - нет. В то время я предполагал, что сделал что-то не так с первой сборкой, и проблема была решена. К сожалению, проблема снова появилась, когда я построил третью виртуальную машину. Также, к сожалению, я не могу проводить много тестов с рабочей виртуальной машиной, так как она сейчас используется в производственной среде, и я надеюсь, что смогу найти причину этой проблемы до того, как на этой машине начнутся проблемы. Возможно, мне просто очень повезло, когда я запустил rsync на рабочей машине, и однажды он не завис.

Конечно, возможно, я как-то изменил скрипты сборки, не осознавая этого, и что-то сломал заново, но я не могу найти ничего подобного.

В любом случае, я надеюсь, что кто-то знает, что могло вызвать это.

Приложение: предварительные тесты показывают, что у меня не возникнет проблемы, если я заменю e1000 на virtio в первом флаге -net в qemu-kvm. Я не считаю это решением, но он подходит как временный промежуток. У кого-нибудь еще была (а еще лучше решена) эта проблема с сетевым драйвером virtio?

У меня аналогичная проблема с запуском qemu kvm на машине debian (хотя я запускаю его через libvirt). Я вызвал замораживание nic, клонировав диск по ftp в сторону одной из 3 виртуальных машин, работающих на этом хосте, но, похоже, затронут только рассматриваемый виртуальный компьютер. Остальные 2 виртуальных машины и хост продолжают работать нормально. Мне также кажется, что virtio вызывает замораживание.

ядро хоста (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

гостевое ядро (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

гость системного журнала:

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

Гостевая конфигурация для 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>

команда 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

Этот пост кажется связанным:
http://www.mail-archive.com/kvm@vger.kernel.org/msg26033.html

Также упоминается этот патч (я его еще не тестировал, но он должен решить проблему):
http://www.mail-archive.com/kvm@vger.kernel.org/msg26279.html