libvirt users - Feb 2015 - virtio nic dosent use 10gbe speed.

Hello all.

We are moving from Xenserver 6.5 environment to KVM because we can't use
10gbe speed in our VM's so we decided to test KVM.

To inicial test I've create script, using qemu commands, to build two
VM's
and test the nic speed.

Each VM has one nic, using virtio, into it own bridge. In this bridge we
associate one 10gbe physical nic.

They can communicate each other.

When we  try do a copy, through SCP, the speed is 300mbps. And if we open
another copy this speed been the half.

What we are using:

S.O:
    CentOS 7
    Kernel 3.10.0-123.el7.x86_64
    qemu-kvm.x86_64 10:1.5.3-60.el7
    libvirt-daemon.x86_64 1.1.1-29.el7

Hardware:
Dell PowerEdge R720
16GB RAM
2TB SAS
Two Broadcom Corporation NetXtreme II BCM57810 10 Gigabit

Command to start VM's:
/usr/libexec/qemu-kvm -m 1024 -enable-kvm -k en-us -hda teste1.img -net
nic,model=virtio,macaddr=00:01:02:aa:bb:cc -net
tap,ifname=tap1,script=no,downscript=no -vnc :0

What Do I doing wrong?

Is my test right?

Is my interpretation right?

Is my enviroment correct?

Can I improve or fix any think with my libvirt or command arguments?

Best regards

-- 
Atenciosamente,
Kalil de A. Carvalho

On 20.02.2015 12:38, Kalil de A. Carvalho wrote:
> Hello all.
> 
> We are moving from Xenserver 6.5 environment to KVM because we can't
use
> 10gbe speed in our VM's so we decided to test KVM.
> 
> To inicial test I've create script, using qemu commands, to build two
VM's
> and test the nic speed.
> 
> Each VM has one nic, using virtio, into it own bridge. In this bridge we
> associate one 10gbe physical nic.
> 
> They can communicate each other.
> 
> When we  try do a copy, through SCP, the speed is 300mbps. And if we open
> another copy this speed been the half.
> 
> What we are using:
> 
> S.O:
>     CentOS 7
>     Kernel 3.10.0-123.el7.x86_64
>     qemu-kvm.x86_64 10:1.5.3-60.el7
>     libvirt-daemon.x86_64 1.1.1-29.el7
> 
> Hardware:
> Dell PowerEdge R720
> 16GB RAM
> 2TB SAS
> Two Broadcom Corporation NetXtreme II BCM57810 10 Gigabit
> 
> Command to start VM's:
> /usr/libexec/qemu-kvm -m 1024 -enable-kvm -k en-us -hda teste1.img -net
> nic,model=virtio,macaddr=00:01:02:aa:bb:cc -net
> tap,ifname=tap1,script=no,downscript=no -vnc :0
> 
> What Do I doing wrong?
> 
> Is my test right?
> 
> Is my interpretation right?
> 
> Is my enviroment correct?
> 
> Can I improve or fix any think with my libvirt or command arguments?
Have you run the same test on the hosts to see if the problem is the
configuration on the host side?
In the guests have you looked at mpstat -P ALL while the test was
running to see if maybe a core was 100% utilized and you are dealing
with a cpu bottleneck?

Regards,
  Dennis

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 20/02/15 11:38, Kalil de A. Carvalho wrote:
> Hello all.
> 
> We are moving from Xenserver 6.5 environment to KVM because we 
> can't use 10gbe speed in our VM's so we decided to test KVM.
> 
> To inicial test I've create script, using qemu commands, to build 
> two VM's and test the nic speed.
> 
> Each VM has one nic, using virtio, into it own bridge. In this 
> bridge we associate one 10gbe physical nic.
> 
> They can communicate each other.
> 
> When we  try do a copy, through SCP, the speed is 300mbps. And if 
> we open another copy this speed been the half.
Assuming you mean 300MB/s then I suspect you are CPU bound as that's a
lot of crypto operations for scp.

Install iperf http://pkgs.repoforge.org/iperf/

Run iperf -s on one vm and iperf -c <ip of other vm> on the second one

I have benchmarked KVM with openvswitch at over 15Gbit/s on fairly
standard hardware (Second gen i5 desktop)

- -- 
Tim Fletcher <tim@night-shade.org.uk>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJU58jPAAoJEN542XhkDoF1ZBYH/2SjA93rtOwuM0vh81/ctlU/
Riws/r8R51LXpz5QICk9GSWNeGfGlvRUq3XVvteBX0GSpknewg3Aa7Jy7lUeXUp+
ULnjg28YlytgpVGzD5LKmzoW809ZwoVLHj0uVQ9pdDXa+6N1ztXR/O3fsV+4GaX9
lVHoX3HrRm/wK/Y/zyXplAu4Ylx61KDmZeBkuaL75XHXsIFbpUqhYOMlNRLsg4rr
buHcDZZNCXp6eMRRHJTdde9C53rky1JECVgctubVyxlI2Uu26CpDKsqR9AKLTPKm
mxb32BMEpajbckGiTSHH89XWg0CBy5XMc1G6oGGOcWjhhosanCtVorHGq+xQ/Uw=AOM8
-----END PGP SIGNATURE-----