[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Regarding Linux TUN/TAP
From: |
Henrik Nordstrom |
Subject: |
Re: [Qemu-devel] Regarding Linux TUN/TAP |
Date: |
Mon, 18 Apr 2005 17:46:18 +0200 (CEST) |
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