Pierre Labastie wrote:
Le 01/12/2014 23:13, Bruce Dubbs a écrit :
Pierre Labastie wrote:
I can do that, but would like to discuss first.
As the book says, networking can be brought up by adding -net nic -net
user to the qemu line. The problem with that is that it doesn't set up
forwarding or configure the host.
For example, my local network is set up on 192.168.0.x and the qemu
dhcp server sets up the client as 10.0.2.15. I can't ping anything on
the 192 network from the client or vice versa.
If we do expand the discussion to add
-net user,hostfwd=tcp::2222-10.0.2.15:22
we still would have problems getting out. For instance ntp or dns
would not work on the guest AFAICT. We also couldn't ping the client
from the host or other network system. In other words, I think the
hostfwd solution is a limited solution.
I may be wrong here. If so, please tell me what else is needed.
When using "-net user":
I think (almost) everything on tcp and udp works _from_ the guest. There
is a virtual DNS at IP 10.0.2.3. I am not sure about NTP, and sure that
ping does not reach anything beyond the host at 10.0.2.2. There is also
a samba server, which I have never tried.
Yes, ICMP does not seem to work, but standard tcp connections are
handled on my system.
In the other direction, you have to set up a port forwarding for each
port, which may become complicated if you need several accesses to the
guest. Furthermore, only tcp and udp protocols can be forwarded (so not
ping for example).
Interesting idea. I'll try to test this. I frequently have multiple
connections to a system. What *should* happen is that connections based
on source port should be differentiated, but I'll have to check to make
sure. However I do note that as a minimum a port forward instruction
would be needed for each service (e.g. ssh, http, mail, etc).
When using "-net tap" + bridging:
As said in the book, you can make the VM appear as a machine on the
local network, allowing two-way accesses. The only reason for not using
it, is that qemu, ip and brctl need to be setgid and as noted wy the OP,
their capabilities have to be changed using setcap. Otherwise, running
qemu as root is possible too.
sgid isn't enough. ip and brctl need to have root (or network
capabilities). qemu will not run if it is suid. I'll also not that the
root (or /usr) partition needs to have the acl,user_xattr options set to
use setcap.
So surely, when full access is needed, bridging is the way to go (some
docs talk also about VDE, but I have never tried). But the user network
stack provides a quick and dirty way to access internet from the guest,
while port forwarding allows to provide limited access from the exterior
to the guest.
Some doc:
https://people.gnome.org/~markmc/qemu-networking.html (concise
introduction to all qemu networking possibilities).
https://wiki.archlinux.org/index.php/Qemu (more detailed).
I like these and will add them to the book.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
