Bug 7887

Yes,please. For example in intranet environemnts the 8.8.8.8 DNS is not reachable, so IP works, but no names get resolved - which is quite baffling experience.

Whilst there are some use cases which would improve, I'm not sure user mode networking is going to give a good experience overall, having to manually specify ports for example will not improve the user experience.

Having this as a commandline option is probably fine but I don't think its a high priority or should be the default. Cristi believes there are other networking solutions which may be better and will discuss those in a separate bug which may then better determine this one.

Personally speaking if user-mode networking gave me flawless connectivity (ie proper routing the external networks, working DNS, etc), I'm happy to pay the cost of a performance hit (performance isn't critical), non-working ICMP (a minor problem) and the need to open ports explicitly (runqemu can open SSH by default).

I guess others may feel differently so choice is good.

Created attachment 2597 [details]
qemu user mode networking iperf benchmark

Qemu user mode networking iperf benchmark

Tested qemu user mode networking using iperf:

iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.237.105.63 port 5001 connected with 10.237.105.63 port 56186
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   923 MBytes   774 Mbits/sec


See attachment for details.

The networking that are of interest to our project are:

1. TUN/TAP
2. Bridge
3. user mode networking

Let's discuss them a little bit:

1. TUN/TAP is now the mode in use by default with runqemu. However, due to the use of TUN/TAP, it does not easily offer: proper DHCP setup, pre-provisioned DNS server setup, access to internet (only qemu host can be accessed via network). It also requires sudo access.

2. Bridge mode is similar with TUN/TAP, however, a proper bonding between a physical Ethernet interface and qemu VM network interface is used (a network bridge). Setup is more complex, and it exposes the VM to the entire network, which may nor desirable and, in some intranets, not even allowed.  It also requires sudo access. This mode should be the most transparent one.

3. User mode networking is similar to what a home router does: NAT, routing to the outside world (Internet), DNS setup, DHCP server provided. Similar to a router, it does not offer access from the outside world (in this case, qemu host) to the qemu VM directly, but via port redirects (from the qemu host to qemu VM), but same sane defaults can be configured (SSH access, web server, Samba, FTP) and documented accordingly.
User mode networking is actually SLIRP networking that is provided by runqemu.
Only the port redirect is not implemented at this point, but that should be fairly easy and easily controllable from a test setup. Performance is good, as proven by my test. Another advantage is that it does not need sudo rights. The setup is almost non-existent (only port redirects). It's not clear to me at this point if network virtio acceleration is available, but performance is quite good even without virtio acceleration.

(In reply to comment #7)
> The networking that are of interest to our project are:
> 
> 1. TUN/TAP
> 2. Bridge
> 3. user mode networking
> 
> Let's discuss them a little bit:
> 
> 1. TUN/TAP is now the mode in use by default with runqemu. However, due to
> the use of TUN/TAP, it does not easily offer: proper DHCP setup,
> pre-provisioned DNS server setup, access to internet (only qemu host can be
> accessed via network). It also requires sudo access.

To be clear, on a network without proxies, this setup does offer access to the internet. It only fails in a proxy environment as we don't have a good way of pushing the right DNS servers and proxy setup into the guest.

On possible way of mitigating this may be to have a command which ssh's into the guest and pushes the right proxy config and DNS setup into it for use in network constrained environments. Ugly but would resolve some of the current issues.

> 2. Bridge mode is similar with TUN/TAP, however, a proper bonding between a
> physical Ethernet interface and qemu VM network interface is used (a network
> bridge). Setup is more complex, and it exposes the VM to the entire network,
> which may nor desirable and, in some intranets, not even allowed.  It also
> requires sudo access. This mode should be the most transparent one.

This one is probably the least preferred from a security standpoint and also its requires the most invasive root privileges.

> 3. User mode networking is similar to what a home router does: NAT, routing
> to the outside world (Internet), DNS setup, DHCP server provided. Similar to
> a router, it does not offer access from the outside world (in this case,
> qemu host) to the qemu VM directly, but via port redirects (from the qemu
> host to qemu VM), but same sane defaults can be configured (SSH access, web
> server, Samba, FTP) and documented accordingly.
> User mode networking is actually SLIRP networking that is provided by
> runqemu.
> Only the port redirect is not implemented at this point, but that should be
> fairly easy and easily controllable from a test setup. Performance is good,
> as proven by my test. Another advantage is that it does not need sudo
> rights. The setup is almost non-existent (only port redirects). It's not
> clear to me at this point if network virtio acceleration is available, but
> performance is quite good even without virtio acceleration.

Cristi mentioned that DNS is also not working in SLIRP mode. I can see some value in improving that mode as you mention and documenting the setup. Exactly how you support multiple qemus running and know which set of ports to connect to to get to which guest could be a challenge, or this mode will only support one qemu at a time.

I believe WR originally added this mode so it may also be worth talking to the people who added it originally and see if they have any plans or thoughts on how they'd like to see it extended?

In SLIRP (user) mode, the network in qemu machine is setup up by activating the IP PNP part of the Linux kernel (via ip=dhcp kernel parameter). While this will setup the network interface via DHCP, it will not setup proper DNS resolving (kernel not allowed to write to files). The above will happen for images that don't rely on connman for network setup (core-image-minimal and others).

At this moment, the state of qemu user mode networking is ok, so this will be re-analysed in time for M3.

qemu user mode can be activated via slirp option of runqemu.

Port redirection is not yet implemented.

Support for bridged mode would be beneficial as well. I sent a patchset which adds support for hostonly networking mode. hostonly mode can be considered as a first step towards bridged mode. It can be considered as an enabler to implement bridged mode without any need to change files in the poky folder.
The patchset provides all the changes which have to be applied on the poky folder (runqemu scripts). Further improvements like setting up a bridge on the host, running a DHCP/DNS server on the bridge or whatever users need can be implemented in a script located outside of the poky folder. The script might be implemented as a wrapper for runqemu-gen-tapdevs.

Here is the thread on the mailing list:
http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112823.html

Postponed due to technical limitations of the SLIRP mode.

*** Bug 8762 has been marked as a duplicate of this bug. ***

runqemu slirp works well now, also add help info for slirp mode.

Merged into master:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=b405712414de98cba3a645601419aceb32d52f02

Although you can specify QB_SLIRP_OPT in the configuration, most of the machines do not have the device in the configuration. So specify slirp on runqemu, ends up with no network device other than lo.

The other issue is that there is no way to specify the ports that are forwarded when using slirp from what I can tell.

I submitted a patch to add slirp support to all qemu machines available in oe-core. https://patchwork.openembedded.org/patch/134399/

M2 looms. Patch 2 no longer applies cleanly due to some lines moving a bit.  Robert, can you redo/resend and I'll try to stay on top of getting it in?

I think all of this is now in ross/mut2.  Someone doublechecking would be appreciated!

merged into master
commit be60ae52f2871b84db8cdc96f8ac18c09892104a
+2 previous and 
commit dcaeaf2df160163319a05f5ae23e4ada6b64ca4e
+1 previous and 
commit 28ef841440bbd27fcf89b1f73a8c5f8e5591d30a