我的虚拟机出现了问题，网络在负载过大时会冻结。我使用 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”的尝试都会在 3/4 个数据包中给出“目标主机无法访问”错误，并且每 4 个数据包都没有回复。
有时（大概三分之二的时间），我可以通过从客户机的控制台执行“服务网络重启”来恢复界面。如果此操作有效（并且我在 rsync 超时之前执行此操作），rsync 将恢复。通常它会在一两分钟内再次冻结。如果我重复此操作，rsync 最终将完成，我估计机器将返回等待另一段重负载。
在整个过程中，客户机或主机上都没有控制台错误或相关的（我能看到）系统日志消息。
如果“服务网络重启”第一次不起作用，那么重试（一次又一次）似乎永远都不起作用。该命令正常完成，输出正常，但界面保持冻结状态。但是，软重启客户机（不重启 qemu-kvm）似乎总能恢复。
我知道“最低 MAC 地址”分配问题，即网桥采用具有最低 MAC 地址的从属接口的 MAC 地址。这会导致网络暂时冻结，但绝对不是我遇到的情况。我的冻结是永久的，除非手动干预，您可以从上面的“ip addr show”输出中看到，br0 使用的 MAC 地址是物理以太网的 MAC 地址。
主机上没有运行其他虚拟机。我已验证子网上的每个虚拟机都有自己唯一的 mac 地址。
我已经多次重建了客户机，并在三台不同的主机上尝试过（相同的硬件，相同的构造）。奇怪的是，我确实有一个虚拟主机（本系列中的第二个），它似乎从来没有出现过问题。在构建期间运行相同的 rsync 时，它从未出现过网络冻结。这尤其奇怪，因为这是第二次构建。第一次在另一台主机上确实存在冻结问题，但第二次没有。我当时认为我在第一次构建时做错了什么，问题已经解决了。不幸的是，当我构建第三个 VM 时，问题再次出现。同样不幸的是，我无法对工作 VM 进行许多测试，因为它现在正在生产中使用，我希望在那台机器开始出现问题之前找到这个问题的原因。有可能我在工作机器上运行 rsync 时真的很幸运，那一次它没有冻结。
当然，有可能我在不知不觉中以某种方式更改了构建脚本并重新破坏了某些东西，但我找不到任何这样的事情。
无论如何，我希望有人知道是什么原因造成的。
附录：初步测试表明，如果我在 qemu-kvm 的第一个 -net 标志中用 e1000 替换 virtio，就不会出现问题。我不认为这是一个解决方案，但它适合作为权宜之计。有没有其他人在使用 virtio 网络驱动程序时遇到过（或者更好的是，解决了）这个问题？
答案1
我在 debian 机器上运行 qemu kvm 时遇到了类似的问题（虽然我通过 libvirt 运行它）。我通过 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
系统日志访客：
2 月 21 日 09:00:22 virtual_machine_1 内核：[63114.151904] swapper：页面分配失败。顺序：1，模式：0x4020 2 月 21 日 09:00:22 virtual_machine_1 内核：[63114.151919] Pid：0，通信：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 内核：[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 内核：[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 内核：[63114.152483] 内存信息： 2 月 21 日 09:00:22 virtual_machine_1 内核：[63114.152484] 节点 0 每 CPU DMA： 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 每个 CPU： 2 月 21 日 09:00:22 virtual_machine_1 内核：[63114.152489] CPU 0：热：hi：186，btch：31 usd：122 冷：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 内核：[63114.152492] 空闲：1597 slab：11996 映射：2986 页表：3395 跳出：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 内核：[63114.152499] 节点 0 DMA32 空闲：2400kB 最小：4012kB 最低：5012kB 最高：6016kB 活动：139688kB 非活动：798308kB 当前：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] 交换缓存：添加 188，删除 187，找到 68/105，竞争 0+0 2 月 21 日 09:00:22 virtual_machine_1 内核：[63114.152516] 可用交换 = 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 页交换缓存 2 月 21 日 09:00:22 virtual_machine_1 内核：[63114.158461] swapper：页面分配失败。顺序：1，模式：0x4020 2 月 21 日 09:00:22 virtual_machine_1 内核：[63114.158464] Pid：0，通信：swapper 未受污染 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 启用 kvm -m 2048 -smp 1，插槽=1，核心=1，线程=1 -name 虚拟机 1 示例： -无默认值 -chardev 套接字，id=monitor，路径=/var/lib/libvirt/qemu/virtual_machine_1.monitor，服务器，nowait -mon chardev=monitor，模式=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，总线=pci.0，地址=0x3 -net tap，fd=17，vlan=0，名称=hostnet0 -chardev pty，id = serial0 -device isa-serial，chardev = serial0 -usb -vnc 0.0.0.0:1 -k en-us -VGA 卷云 -设备 virtio-气球-pci，id=balloon0，总线=pci.0，地址=0x4
这篇文章似乎与此相关：
http://www.mail-archive.com/[电子邮件保护]/msg26033.html
还提到了此补丁（我还没有测试过但它应该可以解决问题）：
http://www.mail-archive.com/[电子邮件保护]/msg26279.html