Windows 2008/7 Guest to Guest Very slow 10-20Mbit/s

Bug #1202289 reported by Mike Nielsen
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
QEMU
Expired
Undecided
Unassigned

Bug Description

I'm not sure if I'm submitting this to the proper place or not, if not, please direct me accordingly.

At this point I'm starting to get desperate, I'll take any options or suggestions that spring to mind:

Anyway, the problem exists on multiple hosts of various quality. From 4 core 8g mem machines to 12 core 64Gig mem machines with LVM and Raid-10.

Using iperf as the testing utility: (windows guest can be either Windows 7 or 2008R2)
-Windows Guest -> Windows Guest averages 20Mbit/s (The problem)
-Windows Guest -> Host averages 800Mbit/s
-Host -> Windows Guest averages 1.1Gbit/s
-Linux Guest -> Host averages 12GBit/s
-Linux Guest -> Linux Guest averages 10.2Gbit/s

For windows guests, switching between e1000 and virtio drivers doesn't make much of a difference.

I use openvswitch to handle the bridging (makes bonding nics much easier)

Disabling TSO GRO on all the host nics, and virtual nics, as well as modding the registry using:
netsh int tcp set global (various params here) can slightly improve Windows -> windows throughput. up to maybe 100Mbit/s but even that is spotty at best.

The Particulars of the fastest host which benchmarks about the same as the slowest host.

Ubuntu 12.04 64bit (updated to lastest as of July 15th)
Linux cckvm03 3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20 18:21:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

libvirt:
Source: libvirt
Version: 0.9.8-2ubuntu17.10

qemu-kvm
Package: qemu-kvm
Version: 1.0+noroms-0ubuntu14.8
Replaces: kvm (<< 1:84+dfsg-0ubuntu16+0.11.0), kvm-data, qemu

openvswitch
Source: openvswitch
Version: 1.4.0-1ubuntu1.5

/proc/cpuifo

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2440 0 @ 2.40GHz
stepping : 7
microcode : 0x70d
cpu MHz : 2400.226
cache size : 15360 KB
physical id : 0
siblings : 12
core id : 0
cpu cores : 6
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdt
scp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc ap
erfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdc
m pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm
ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips : 4800.45
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

-Sample KVM line
usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 4096 -smp 2,sockets=2,cores=1,threads=1 -name gvexch01 -uuid d28ffb4b-d809-3b40-ae3d-2925e6995394 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/gvexch01.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=dc,menu=on -drive file=/dev/vgroup/gvexch01,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/dev/vgroup/gvexch01-d,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -drive if=none,media=cdrom,id=drive-ide0-0-0,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=18,id=hostnet0,vhost=on,vhostfd=21 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:bf:4e:1c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:2 -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

Revision history for this message
Ingo Krabbe (ikrabbe-ask) wrote :

I'm not sure yet, but I think the TSO problem affects much more setups, not only windows guests. You might try to set GSO to off in windows guests too, if there is such an option (GSO might be a linux kernel feature).

I currently think that we have similar problems with centos7 hosts and guests as well as with some windows7 guests.

I also read about similar centos6 problems. There is even a original setup guide for centos6 from redhat, to set "tso off gso off" in the host bridge adapter, when you use virtio.

This whole topic is disturbingly distributed through several setups. The diagnosis of this problem is far from being trivial.

Revision history for this message
Thomas Huth (th-huth) wrote :

Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?

Changed in qemu:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for QEMU because there has been no activity for 60 days.]

Changed in qemu:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.