[SOLVED] kvm: is VDE still the recommended way to set up virtual networking?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
kvm: is VDE still the recommended way to set up virtual networking?
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 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.
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 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:
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?
Nice one. The positional parameter idea is a good idea which I'll adopt if you don't mind.
I have to admit that I stole that from work, my original script was not as elegant.
Quote:
Originally Posted by gezley
1) Is qemu64 a decent cpu?
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.
Quote:
Originally Posted by gezley
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?
I haven't messed with any drive controllers, though you present an interesting idea.
Quote:
Originally Posted by gezley
3) Your network parameter? Does the helper script not have to be explicitly set?
From what I understand, the helper program is called based not calling user mode and my /etc/qemu/bridge.conf
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.