qemu-kvm虚拟机virtionetworking负载下冻结

我的虚拟机出现问题，networking在重负载下会冻结。我使用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”，当networking将冻结一些看似随机的时间（通常不到一分钟）。当它冻结时，没有networking活动进出客人。我仍然可以通过vnc连接到客人的控制台，但是无法说出它的networking接口。任何尝试从客人“ping”给出3/4包的“目标主机无法到达”错误，没有答复每个第四个数据包。

有时（也许是三分之二的时间），我可以通过从客户端控制台执行“服务networking重启”来使界面恢复生机。如果这有效（如果我在rsync超时之前执行此操作），rsync将恢复。通常它会在一两分钟内冻结。如果我再说一遍，rsync将最终完成，我认为机器回到等待另一个重负载的时期。

在整个过程中，在客户机或主机上都没有控制台错误或相关（我可以看到）syslog消息。

如果“服务networking重新启动”不能第一次工作，再次尝试（一次又一次）似乎永远不会工作。该命令正常完成，正常输出，但接口保持冻结状态。但是，客户机的软重启（不重启qemu-kvm）似乎总是把它重新启动。

我知道“最低的MAC地址”分配问题，其中网桥采用具有最低MAC地址的从接口的MAC地址。这导致暂时的networking冻结，但绝对不是我正在发生的事情。我的冻结是永久的，直到手动干预，你可以从上面的'ip addr show'输出看到br0使用的mac地址是物理以太网的地址。

主机上没有其他虚拟机正在运行。我已经validation了子网上的每个虚拟机都有自己的唯一MAC地址。

我已经多次重build了客机，并且在三台不同的主机（相同的硬件，相同的构build）上尝试过。奇怪的是，我确实有一个虚拟主机（这个系列的第二个），这似乎没有问题。当它在构build期间运行相同的rsync时，它的networking从未冻结。这是特别奇怪的，因为它是第二个版本。首先，在不同的主机上，确实有冻结的问题，但第二个没有。当时我假设我在第一次构build时做了一些错误，并且问题解决了。不幸的是，当我构build第三个VM时，问题再次出现。另外不幸的是，我不能用虚拟机做很多testing，因为现在正在使用虚拟机，而且我希望能够在机器出现问题之前find问题的原因。在工作机器上运行rsync的时候，我可能真的很幸运，而且有一次它没有冻结。

当然有可能我不知不觉地改变了构build脚本并重新打破了一些东西，但我找不到任何这样的东西。

无论如何，我希望有人有一些想法可能会导致这一点。

附录：初步testing表明，如果我在第一个networking标志中将e1000replace为qemu-kvm，我没有问题。我不认为这是一个解决scheme，但它是适合权宜之计。有没有其他人（或更好的解决）与virtionetworking驱动程序的这个问题？

我遇到一个类似的问题在debian机器上运行qemu kvm（我通过libvirt运行它）。我通过将ftp磁盘克隆到在这个主机上运行的3个虚拟机之一来触发nic冻结，只有这个虚拟机可能受到影响。其他2个vm和主机继续正常工作。对我来说，这似乎也是导致冻结。

主机内核（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

系统日志客人：

  2月21日09:00:22 virtual_machine_1内核：[63114.151904] swapper：页面分配失败。 顺序：1，模式：0x4020
 2月21日09:00:22 virtual_machine_1 kernel：[63114.151919] pid：0，comm：swapper没有污染2.6.24-26-server＃1
 2月21日09:00:22 virtual_machine_1内核：[63114.151920] 
 2月21日09:00:22 virtual_machine_1内核：[63114.151921]通话跟踪：
 2月21日09:00:22 virtual_machine_1内核：[63114.151925] [__alloc_pages + 0x2fd / 0x3d0] __alloc_pages + 0x2fd / 0x3d0
 2月21日09:00:22 virtual_machine_1内核：[63114.152256] [new_slab + 0x220 / 0x260] new_slab + 0x220 / 0x260
 2月21日09:00:22 virtual_machine_1内核：[63114.152260] [__slab_alloc + 0x2f5 / 0x410] __slab_alloc + 0x2f5 / 0x410
 2月21日09:00:22 virtual_machine_1内核：[63114.152281] [virtio_net：__ netdev_alloc_skb + 0x2b / 0x2eb0] __netdev_alloc_skb + 0x2b / 0x50
 2月21日09:00:22 virtual_machine_1内核：[63114.152285] [virtio_net：__ netdev_alloc_skb + 0x2b / 0x2eb0] __netdev_alloc_skb + 0x2b / 0x50
 2月21日09:00:22 virtual_machine_1内核：[63114.152287] [__kmalloc_node_track_caller + 0x121 / 0x130] __kmalloc_node_track_caller + 0x121 / 0x130
 2月21日09:00:22 virtual_machine_1内核：[63114.152290] [ipv6：__ alloc_skb + 0x7b / 0x4f0] __alloc_skb + 0x7b / 0x160
 2月21日09:00:22 virtual_machine_1内核：[63114.152293] [virtio_net：__ netdev_alloc_skb + 0x2b / 0x2eb0] __netdev_alloc_skb + 0x2b / 0x50
 2月21日09:00:22 virtual_machine_1内核：[63114.152312] [virtio_net：try_fill_recv + 0x61 / 0x1b0]：virtio_net：try_fill_recv + 0x61 / 0x1b0
 2月21日09:00:22 virtual_machine_1 kernel：[63114.152336] [ktime_get_ts + 0x1b / 0x50] ktime_get_ts + 0x1b / 0x50
 2月21日09:00:22 virtual_machine_1内核：[63114.152341] [virtio_net：virtnet_poll + 0x18c / 0x350]：virtio_net：virtnet_poll + 0x18c / 0x350
 2月21日09:00:22 virtual_machine_1内核：[63114.152346] [tick_program_event + 0x35 / 0x60] tick_program_event + 0x35 / 0x60
 2月21日09:00:22 virtual_machine_1内核：[63114.152355] [net_rx_action + 0x128 / 0x230] net_rx_action + 0x128 / 0x230
 2月21日09:00:22 virtual_machine_1内核：[63114.152358] [virtio_net：skb_recv_done + 0x2c / 0x40]：virtio_net：skb_recv_done + 0x2c / 0x40
 2月21日09:00:22 virtual_machine_1内核：[63114.152369] [__do_softirq + 0x75 / 0xe0] __do_softirq + 0x75 / 0xe0
 2月21日09:00:22 virtual_machine_1内核：[63114.152379] [call_softirq + 0x1c / 0x30] call_softirq + 0x1c / 0x30
 2月21日09:00:22 virtual_machine_1内核：[63114.152386] [do_softirq + 0x35 / 0x90] do_softirq + 0x35 / 0x90
 2月21日09:00:22 virtual_machine_1内核：[63114.152389] [irq_exit + 0x88 / 0x90] irq_exit + 0x88 / 0x90
 2月21日09:00:22 virtual_machine_1内核：[63114.152391] [do_IRQ + 0x80 / 0x100] do_IRQ + 0x80 / 0x100
 2月21日09:00:22 virtual_machine_1内核：[63114.152393] [default_idle + 0x0 / 0x40] default_idle + 0x0 / 0x40
 2月21日09:00:22 virtual_machine_1内核：[63114.152395] [default_idle + 0x0 / 0x40] default_idle + 0x0 / 0x40
 2月21日09:00:22 virtual_machine_1 kernel：[63114.152396] [ret_from_intr + 0x0 / 0x0a] ret_from_intr + 0x0 / 0xa
 2月21日09:00:22 virtual_machine_1内核：[63114.152398] [default_idle + 0x29 / 0x40] default_idle + 0x29 / 0x40
 2月21日09:00:22 virtual_machine_1内核：[63114.152404] [cpu_idle + 0x48 / 0xe0] cpu_idle + 0x48 / 0xe0
 2月21日09:00:22 virtual_machine_1内核：[63114.152471] [start_kernel + 0x2c5 / 0x350] start_kernel + 0x2c5 / 0x350
 2月21日09:00:22 virtual_machine_1内核：[63114.152475] [x86_64_start_kernel + 0x12e / 0x140] _sinittext + 0x12e / 0x140
 2月21日09:00:22 virtual_machine_1内核：[63114.152482] 
 2月21日09:00:22 virtual_machine_1 kernel：[63114.152483] Mem-info：
 2月21日09:00:22 virtual_machine_1 kernel：[63114.152484] Node 0 DMA per-cpu：
 2月21日09:00:22 virtual_machine_1内核：[63114.152486] CPU 0：热点：hi：0，btch：1 usd：0冷：hi：0，btch：1 usd：0
 2月21日09:00:22 virtual_machine_1内核：[63114.152487]节点0 DMA32 per-cpu：
 2月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
 2月21日09:00:22 virtual_machine_1内核：[63114.152492]活动：35252无效：200609脏：11290回写：193不稳定：0
 2月21日09:00:22 virtual_machine_1 kernel：[63114.152492] free：1597 slab：11996 mapped：2986 pagetables：3395 bounce：0
 2月21日09:00:22 virtual_machine_1内核：[63114.152494]节点0无DMA：3988kB最低：40kB低：48kB高：60kB有效：1320kB不活动：4128kB目前：10476kB pages_scanned：0 all_unreclaimable？ 没有
 2月21日09:00:22 virtual_machine_1内核：[63114.152497] lowmem_reserve []：0 994 994 994
 2月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？ 没有
 2月21日09:00:22 virtual_machine_1内核：[63114.152502] lowmem_reserve []：0 0 0 0
 2月21日09:00:22 virtual_machine_1内核：[63114.152504]节点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
 2月21日09:00:22 virtual_machine_1内核：[63114.152509]节点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
 2月21日09:00:22 virtual_machine_1内核：[63114.152514]交换caching：添加188，删除187，find68/105，比赛0 + 0
 2月21日09:00:22 virtual_machine_1内核：[63114.152516] Free swap = 3084140kB
 2月21日09:00:22 virtual_machine_1内核：[63114.152517]总掉期= 3084280kB
 2月21日09:00:22 virtual_machine_1内核：[63114.152517]免费调用：3084140kB
 2月21日09:00:22 virtual_machine_1内核：[63114.158388] 262139页的RAM
 2月21日09:00:22 virtual_machine_1内核：[63114.158390] 4954保留页面
 2月21日09:00:22 virtual_machine_1内核：[63114.158391] 269600页共享
 2月21日09:00:22 virtual_machine_1内核：[63114.158392] 1页交换caching
 2月21日09:00:22 virtual_machine_1内核：[63114.158461] swapper：页面分配失败。 顺序：1，模式：0x4020
 2月21日09:00:22 virtual_machine_1 kernel：[63114.158464] pid：0，comm：swapper没有污染2.6.24-26-server＃1

qemu的客户configuration：

 <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，套接字= 1，核心= 1，线程= 1  
名为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  
设备ide驱动器，总线= ide.0，单元= 0，驱动器=驱动器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卷云  
 -device virtio-balloon-pci，id = balloon0，bus = pci.0，addr = 0x4

这个post似乎是相关的：
http://www.mail-archive.com/[email protected]/msg26033.html

这个补丁也被提到（我还没有testing过，但它应该可以解决这个问题）：
http://www.mail-archive.com/[email protected]/msg26279.html