In his wiki entry, last modified 8 years ago, Eric Hameleers recommends using VDE for virtual networking with Qemu. Is this still recommended?

The Qemu documentation suggests VDE is not the right backend to use. Some years ago I set up virtual networks for kvm-qemu with basic shell scripts which brought up bridges, dummy devices and TAP adapters. It was fast and reliable and I was about to do the same thing until I saw Eric's recommendation. Any suggestions, clarifications?

I never used vde. I converted a couple years ago from tunctl/brctl to macvlan/macvtap interfaces for kvm/qemu and lxc. They work well and have been stable in testing and production.

I have been using tun via the qemu-bridge-helper provided with qemu, it's simple and works.

1 members found this post helpful.

I don't think there's a single "best" or "recommended" way for qemu networking. It all depends on what you're trying to achieve.

SLIRP is the most easy and despite its drawbacks an excellent choice if all the networking you need is e.g. a working browser in the VM.

Tap has no external dependencies and will give you full network access with best performance but needs root privileges.

VDE is propably geared towards working with very complex virtual networks.

I don't do that, but I still use VDE because it's very convenient for my use case as my VMs get full network access, yet I can start/stop them as an ordinary user without root privileges. With only 4 lines (a few more if you want proper IPv6) in rc.local and no need to handle tap-devices the setup is also very simple.

1 members found this post helpful.

Thanks for the tips everybody. I've been studying qemu more closely over the past couple of days and I'm happy with the qemu-bridge-helper method, suggested by slacker1337. I had to make some adjustments because I installed qemu from source, completely forgetting I could have used the slackbuild instead. It meant I had to put udev rules in place, and also chmod u+s /usr/local/libexec/qemu-bridge-helper to allow regular users run qemu (but adding the setuid bit to this script doesn't seem to be in the slackbuild, so perhaps there's another way?). I also had to echo "allow br0" > /usr/local/etc/qemu/bridge.conf.

At some point I will look again at VDE, and compare it with the netdev bridge backend set up by the helper.

Thanks again.

Glad to see you got it working the way you want. I've been pleased with the throughput using the qemu-bridge-helper. I had a host machine running 6 virtual machines with no issues. I'll share one of my startup scripts for you as well. Here is a startup script I use for my -current VM:

Nice one. The positional parameter idea is a good idea which I'll adopt if you don't mind.

Some questions for you, and you can take your time answering them because I'll be hitting the hay in 5 minutes as it's after 2 here! I know they're not strictly Slack-related but I might as well pick your brains while you're here! ;-)

1) Is qemu64 a decent cpu?
2) Regarding hda, I was under the impression the default storage controller was IDE. Take a look at my own new thread started in the LQ Virtualization forum, titled "Qemu storage for Windows 2012 guest" and let me know what you think. I realise this is all emulated hardware but I assume a SAS controller with a SCSI disk under qemu will still perform better than the default IDE disk on ATA?
3) Your network parameter? Does the helper script not have to be explicitly set?

I have to admit that I stole that from work, my original script was not as elegant.
I've been pretty satisfied with it. I had that cpu set for a multitude of servers as well as a Windows 7 VM that ran quickly. I admit though that I haven't tried any others.
I haven't messed with any drive controllers, though you present an interesting idea.
From what I understand, the helper program is called based not calling user mode and my /etc/qemu/bridge.conf

OK thanks. I'm getting the impression with the kvm accelerator it doesn't really matter whether the emulated hardware is a Celeron or i7, IDE adapter or SCSI. But I do wonder, if that's the case why go to the trouble of maintaining all those different pieces of hardware in Qemu? And surely the internal Qemu code for each of these emulated devices is different, leading possibly to one device possibly ending up more buggy than another? Just some questions I have in my head; no need to answer. Thanks.

There's more that one way to skin a cat.

1 members found this post helpful.