Re: [Qemu-devel] Regarding Linux TUN/TAP

[Henrik Nordstrom]

On Fri, 15 Apr 2005, Hetz Ben Hamo wrote:

> The SLiRP solution for QEMU is great if a user want to connect to the 
> net and browse, do some updates, etc, but it's not a good solution if 
> someone want to stuff like:
>
> * Connect to host OS
> * Connect to other machines in the LAN
> * Use services from host OS
>
> What do people think could be a solution for end users? comments?

For all of the above the user-net (SLiRP based) solution works reasonably 
fine provided you do not need to rely on fixed source port numbers. What 
it does not work well for is connectivity in the opposite direction where 
something needs to connect to the guest.

 * Connect from host OS to guest
 * Connect from LAN to guest
 * Provide services to the LAN or host.

when using user-net this requires careful planning to map the ports in a 
desired manner, and can not be done for low port numbers unless you start 
qemu as root..

Note: For Windows guests you need to set up WINS for user-net to work 
reasonably OK for accessing the LAN.


For access to the guest the solution with persistent TUN devices is 
trivial to document in a no-brainer manner for these as it very much 
resembles your normal networking configuration, and with the help of 
bridgeing can even place the quest on the local broadcast LAN as if it was 
a host of it's own. The main hinderance is that the tuncfg tool is not 
easily available on all distributions to set up the virtual NICs 
connecting to your QEMU environment(s) and without it you have to rely on 
the qemu ifup script to set things up when you start qemu with all the 
security implications it gives of allowing users to run the ifup script 
with root privs..

For more advanced setups with more than one QEMU the vde user-space 
ethernet switch is probably the way to go for user friendlyness. It is 
also possible with multiple host TUN/TAP devices and bridgeing but the 
host configuration quickly becomes somewhat complex as one TUN/TAP host 
interface is required per QEMU nic.

Regards
Henrik