4

I noticed the following differences in the networking experience between QEMU/KVM (used through libvirt) and VirtualBox:

  • For anything else than usermode or manual networking, QEMU/KVM needs a virbr0 network interface to be created and it adds a bunch of rules to iptables. VirtualBox, on the other hand, can operate both in NAT and bridged modes without touching iptables or creating any network interfaces.

  • Probably related to the above, in non-root user sessions, QEMU/KVM only allows usermode (or manual) networking, while VirtualBox supports most/all of the various networking modes even without root privileges.

I would like to understand the underlying reasons behind these differences and their implications. A few specific questions that come to my mind:

  • VirtualBox's networking solution seemingly requires less privileges. Is this the result of a user-space implementation of various networking protocols similar to QEMU/KVM's usermode networking (just with more options) or are there privileged operations executed behind the scenes, allowed by the user's membership in the vboxusers group?

  • Is QEMU/KVM's usermode networking inferior in any way to VirtualBox's NAT mode networking? According to the libvirt FAQ, usermode networking "has nonobvious limitations, so its usage is discouraged", but I could not find what those limitations are (other than being restricted to NAT). It seems perfectly fine to me for doing just a simple NAT (and in fact it seems to be the trivial if not only way that avoids the iptables modifications).

  • How does the security and performance of the three NAT alternatives (VirtualBox NAT, QEMU/KVM "proper" NAT, QEMU/KVM usermode networking) compare to each other?

3
  • "in non-root user sessions, QEMU/KVM only allows usermode networking" That's not true. You can pass a simple file descriptor referring to the "other" end of a tap interface to qemu via -net tap,fd=FD, which can be opened by a simple setuid/setcap wrapper. You can configure the tap interface as you see fit (add it to a bridge, etc). No need whatsoever to choose between running qemu as root or only using the slirp ("usermode") networking.
    – user313992
    Feb 8, 2021 at 22:19
  • If you're interested how slirp works and what its limitations are, ask a specific question about it.
    – user313992
    Feb 8, 2021 at 22:41
  • I just added an "or manual" clause to that sentence based on you feedback. Thanks for pointing out that usermode networking uses Slirp. I was not aware of that, so you gave me a new direction to explore by mentioning that.
    – Zoltan
    Feb 9, 2021 at 8:57

1 Answer 1

0

Due to the lack of answers, I'm posting my own findings here, however limited they may be.

According to the QEMU wiki, user networking has the following limitations:

  • slow
  • no ICMP (e.g., can't use ping from the guest)
  • the usual limitations of NAT

Both QEMU and VirtualBox have userspace networking implementations based on SLiRP, so their limitations should be comparable (although VirtualBox seems to have lwIP as well).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .