QEmu network running slowly

[JHD]

root@vmhost1:~# qemu-system-x86_64 --version
QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u2)

This is the latest version served by Debian, but QEmu itself is at 4.1, so I may be getting confused by version-related issues when reading the docs. I am running a host using Debian 10 and am trying to get a Windows 10 guest running. I have succeeded, but networking is hideously slow. The following looks at the guest from the host:

root@vmhost1:~# traceroute 192.168.1.7
traceroute to 192.168.1.7 (192.168.1.7), 30 hops max, 60 byte packets
1 vmhost1 (192.168.1.6) 3079.710 ms !H 3079.691 ms !H 3079.685 ms !H

I have read that I should try using virtio. My command file to launch the VM is:
qemu-system-x86_64 -vnc 0.0.0.0:1 -enable-kvm -m 32768 \
-netdev user,id=blue,net=192.168.1.0/24,dns=192.168.1.101 \
-hda /srv/vm/blue/blue0.qcow2 \
-net nic,macaddr=00:01:01:01:01:01 \
-net nic,model=virtio \
-net user,hostfwd=tcp::33891-:3389,hostfwd=tcp::3306-:3306
with several more port forwarding options scrolling off the screen. I have installed the Red Hat drivers in the VM and get two cards, a Red Hat virtual one and an e1000.

Any suggestions as to what I should try next would be appreciated. I have read that bridging is a good idea, but without the information being sufficiently detailed for me to get it right.

TIA & regards,
JHD

[trinidad]

Qemu is no longer maintained as a "current" package in Debain thus the number confusion. There are many packages that make up qemu now. You will have to be selective as to what you install. As far as bridge helper I found this fairly decent run through:

https://mike42.me/blog/2019-08-how-to-u ... -debian-10

TC

[JHD]

<strike>trinidad: thanks, but I'm afraid I have tripped over the first hurdle. "After installation, you will also need to ensure that libvirtd is running". I have installed qemu-system-common and have qemu-bridge-helper available, but I can see no reference to libvirtd. I have tried installing libvirt-daemon via apt, but this has got me no further, as there is no libvirt service file of any variety revealed by find.</strike>

It seems that there are several libvirt packages and I had not installed enough. I am now progressing.

Regards,

JHD

[CwF]

Qemu is a 'current' package in the same sense all others in the repository are "current".
qemu-bridge-helper however does not exit.

I can't speak for Win10, but for prior versions I find little speed difference between emulation e1000 and virtio, mainly only a cpu usage difference.

macvtap is a better choice than virbr0. Personally I think bridging is a bad idea. macvtap will bridge all vm's on that interface, but not the host.

Also better to use the standard pattern for the mac's 52:54:00:xx:xx:xx

It's libvirt-daemon-system, type libvirtd into a terminal for status.

[JHD]

I have got bridging working, but this has not reduced the traceroute time. I have also created a Debian 10 VM to see whether it is guest OS dependent (it isn't). CwF: would you mind giving your reasons why bridging is a bad idea? http://www.linux-kvm.org/page/Tuning_KVM seems to recommend it quite explicitly.

Can anyone suggest anything else I should try?

TIA & regards,

JHD

[CwF]

CwF: would you mind giving your reasons why bridging is a bad idea?

Yes, I would say my comment is too generic. The older method of creating a separate virtual bridge, virbr0 'seemed' to clog up.
I say 'seemed' because I haven't used it for a few years, so I might be missing something, your same something. Ultimately I decided not to have the host on the VM leg at all, this is of course dependant on how you do things. The host has other means of access to vm's, so it a question of whether vm's need access to things on the host. I found eliminating that option helps performance, and I prefer not to have a path to the host, at least a persistent one.
If the idea is a debian machine with a single windows vm I do understand the desire to have good networking between the two for convenience. Maybe I never got it right, but the solution consumed cpu's.
So I'm only luke warm on solving this bridging issue, but listening for things I've missed.
Since on a desktop, I use additional vfio hardware, it's actaully simpler. It's also easy to pass a virtual drive around. It's easy to work around no bridge.