Network Performance on 1.6

[oeginc]

OK, I just uploaded new version to the pvetest repository:

pve-qemu-kvm_0.13.0-2_amd64.deb
qemu-server_1.1-23_amd64.deb

That new qemu-server package loads vhost-net module on startup, uses the new -device syntax, and use vhost=on if available. Please can you test?

What's the status on this? Has it made it into production yet?

 

[JustaGuy]

new -device syntax

What's the status on this? Has it made it into production yet?

Whoa, I didn't see that- thanks for piping up oeginc.
I'll start testing qdev -device this week.

 

[JustaGuy]

uses the new -device syntax

I must not understand this correctly.
I still get 'start failed' when I add a 30th NIC.
Syslog says the failing command looks (in part) like this:

-netdev type=tap,id=vlan1d0,ifname=vmtab1003i1d0,script=/var/lib/qemu-server/bridge-vlan,vhost=on -device virtio-net-pci,mac=1A:A5:A8:96:E9:97,netdev=vlan1d0

I'm under the impression that this limit should no longer be an issue based on this statement from the linux-kvm mailing list.

> While adding a 20-interface trunk of virtio adapters to bring in a dual 10GB bond, I've discovered an 8 NIC limit in QEMU.

Have you tried creating NICs with -device? The limit shouldn't apply there.

This "new -device syntax" is later referred to as "the qdev way", and it's re-iterated that the legacy limitation is overcome by it. The link referenced shows a command just like what we have now, so I'm assuming it's the same.

this limitation is only for legacy command
line option. The modern qdev way[1] should not hit this same limitation.

Further along the thread there's this script that acheives well over 30, which although I barely understand scripting, appears to insert some values into what looks like our new command.

args=""
for slot in 5 6 7 8 9 10 11 12 13 14 15 16 17; do
for fn in 0 1 2 3 4 5 6 7; do
     args="$args -netdev user,id=eth${slot}_${fn}"
     args="$args -device 
virtio-net-pci,addr=${slot}.${fn},netdev=eth${slot}_${fn},multifunction=on,romfile="
done
done

x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img ${args} 
-enable-kvm

 

[dietmar]

Further along the thread there's this script that acheives well over 30, which although I barely understand scripting, appears to insert some values into what looks like our new command.

Sorry, but we do not support multifunction devices now. All that stuff is brand new, and the future of that is unclear (for me). The time frame for such things is after 2.0.

 

[dietmar]

What's the status on this? Has it made it into production yet?

So far it runs quite stable - maybe we will release this week.

 

[JustaGuy]

Sorry, but we do not support multifunction devices now. All that stuff is brand new

Ok, so that's understandable.

When I saw this I thought >29 would be possible.

uses the new -device syntax

So I don't understand yet why still >29 of this fails:

-netdev type=tap,id=vlan1d0,ifname=vmtab1003i1d0,script=/var/lib/qemu-server/bridge-vlan,vhost=on -device virtio-net-pci,mac=1A:A5:A8:96:E9:97,netdev=vlan1d0

Isn't all that new from pve-qemu-kvm 0.13.0-2, or is it just the 'vhost=on' part that's new in that?

 

[Ninjix]

We've been running it in production for three weeks. No problems only benefits.

 

[dietmar]

So I don't understand yet why still >29 of this fails:

because we are still limited to 32 pci addresses.

 

[JustaGuy]

Oh, well. I had the wrong idea about the implications of new kvm. :-/
Thanks for clarifying.

Even still, vhost=on seems to promise an enormous jump.
Looks like now I can bring the 10Gb bonds into Vyatta with 8 less NICs per bond!