qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Rob Miller <rob@janerob.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] qemu 'networking howto' supplied
Date: Mon, 6 Sep 2004 19:37:23 +0100 (WAT)	[thread overview]
Message-ID: <Pine.LNX.4.60.0409061931280.23989@vista.rtm.home> (raw)


Hi,

I'm not subscribed but have been searching the archives trying to get 
networking going.  I think I've done it every way there is for my host and 
guest, here is my best effort at documenting it all in one place.

Please

(1) edit/revise whatever problems are there
(2) stick on dad-answers.com if you think it's appropriate -- the wiki 
doesn't seem to have much in terms of content beyond screenshots.

The main issue I was trying to get around was accessing samba shares on 
other hosts from a Windows guest.  I'll watch the archives to see if there 
is a simpler way to do it than what I came up with.

cheers,

rob.



Qemu Networking HOWTO


The following is a summary of setting up networking options for qemu 0.6.0
for a Linux host with Windows 98 as the guest OS.  Here are some shortcuts 
depending on your needs for the guest OS:

Internet (e.g. IE) only, no samba shares: use -user-net
No internet, samba shares on host only: use tun on same subnet
Internet only with IP masquerade control: use tun on different subnet
Internet and samba shares on other hosts: use tun with bridging

Tun and VDE can also be used to link multiple qemu guests, but this
document won't cover that.

Preparation (assuming your host has internet and/or samba already):

-user-net needs only --enable-slirp when qemu is 'configure'd before 'make'

tun, bridging and IP masquerade all require kernel modifications:
   tun: "Network device support" -> "Universal TUN/TAP device driver support"
   IP masquerade: "Networking options" -> "IP: Netfilter Configuration"
   bridging: "Networking options" -> "802.1d Ethernet Bridging"

additional software:

   tun can benefit from VDE, at http://www.sourceforge.net/projects/vde

   IP masquerade (net filter) needs iptables, from http://www.iptables.org/ but
     it should be in your Linux distribution already

   bridging needs bridge-utils from http://bridge.sourceforge.net/ if it
     is not in your Linux distribution.


The author's system:

I'm running Gentoo, which has packages for iptables and bridge-utils but 
not VDE.

The relevant parts of my home network look like:

192.168.1.2 ----- switch ----- 192.168.1.4
  laptop             |            Win98 PC
  with qemu          |            shared dirs
                 192.168.1.1      and printers
                 firewall PC
                     |
                   modem
                     |
                  Internet


Setting up tun0 (not for -user-net):

Once TUN/TAP is correctly in your kernel (e.g. 'modprobe tun') you should have

crw-------  1 root root 10, 200 Jan  1  1970 tun

in /dev/net.  Gentoo uses devfs so this just appears, on other distributions 
you may have to mknod the device node.

Now you have two choices for accessing qemu networking with tun as a normal 
(non-root) user: either weaken your system's security by changing permissions
on /dev/net/tun (chmod go+rw /dev/net/tun) and using sudo to configure it, 
or use VDE.  If you go the sudo route, you must add your username to 
/etc/sudoers and, depending on how you set it up, you may be asked for your 
password every time you start qemu.

For non-VDE use, you will need a script called /etc/qemu-ifup containing

#!/bin/sh
sudo /sbin/ifconfig $1 <tun interface ip>

VDE:

With VDE you set up a 'virtual switch' as root, then the qemu user is able 
to talk to it without additional permissions.  After doing the 'make' and
'make install' of VDE (vde-1.5.6 at this writing), execute the following 
commands as root to make it go:

# vde_switch -tap tun0 -daemon
# ifconfig tun0 <tun interface ip> up
# chmod 777 /tmp/vde.ctl

Note that -you- fill in the <tun interface ip> value depending on how you 
set the networking up as described below.

To use VDE there are special qemu wrappers, so instead of

# qemu -hda disk.img

you use

# vdeqemu -hda disk.img

or

# vdeq qemu -hda disk.img



Doing it:


Method 1: -user-net  (*not* tun)

Start qemu with something like

# qemu -hda disk.img -user-net

Under "Control Panel"->"Network"->"TCP/IP"->"Properties"->"IP Address", 
select "Obtain an IP address automatically" (a.k.a. DHCP).  Leave the 
"Gateway" tab empty.  After "OK"ing out and possibly a qemu-reboot, 
Internet Explorer should be able to see the Internet if your Linux host 
can see it.  "Network Neighborhood" will complain there's no network if 
you try it, and ping from the guest OS doesn't work past the host.


Method 2: tun on the same subnet

Pick two IPs on your LAN subnet, on my system 192.168.1.9 and 192.168.1.5 
were unassigned (plug in your own numbers as appropriate).  I put 
192.168.1.9 in for <tun interface ip> and set the guest IP to 192.168.1.5
in "Control Panel"->"Network"->etc.  Set the "Gateway" tab to the 
<tun interface ip>, 192.168.1.9 for me.  Now add a route from the host to 
the guest IP through the tun interface with (as root, substitute your IPs)

# route add -host 192.168.1.5 gw 192.168.1.9

Now you still can't ping past the host (192.168.1.2), but you can see samba
shares on the host and use them to share files with the guest and vice-versa.
No Internet connectivity (a "secure Windows installation" :-) and 
IP masquerade/ip-forwarding won't help because that's only for different 
subnets.  You can probably get to other host shares and printers by 
mounting and re-sharing it on your host, e.g. set up a printer in CUPS as 
a networked printer shared by some other box, then set your local samba 
install to share this CUPS printer -- but I didn't try it because it 
sounded too ugly.


Method 3: tun on a different subnet

Pick two IPs on a completely different subnet, I chose 10.0.0.1 and 10.0.0.5.
As per method 2, set <tun interface ip> in /etc/qemu-ifup (or the vde_switch 
command line) and "Control Panel" ... "Gateway" in the guest OS to 10.0.0.1. 
Set the guest's IP ("Control Panel" ... "IP Address") to 10.0.0.5.  Now the 
guest OS also needs to know a DNS ("Control Panel" ... "DNS Configuration"), 
this should be as found in the host's /etc/resolv.conf (or possibly 
/etc/ppp/resolv.conf after your ISP connection is made)  Under this 
configuration you don't need the extra route from the host back to the guest, 
but you do need to set up IP masquerade.  This needs to happen AFTER setting 
up the tun interface, either by starting qemu (perhaps put these commands into 
/etc/qemu-ifup after the ifconfig command) or running the VDE set up commands 
above.  The thing to do is set up the rules first, most distributions have 
some wrappers in /etc/init.d/iptables or /etc/rc.d/init.d/iptables to help 
with this (as root):

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# /etc/init.d/iptables save

You can only turn on forwarding when iptables is stopped, so if you've just 
added the rules you'll need something like:

# /etc/rc.d/init.d/iptables stop
# echo "1" >&/proc/sys/net/ipv4/ip_forward
# /etc/rc.d/init.d/iptables start

to get it going.  Once everything is configured you should be able to ping 
all over and use the Internet (e.g. IE) from the guest, but samba shares 
("Network Neighborhood") won't be visible because they need to be on the 
same subnet.  There may be a way to fix this for Linux samba shares, at 
least on the host, by tweaking the samba configuration -- but I haven't 
worked it out yet.



Method 4: tun with bridging

The problem with method 2 above is that there's nothing on the host to 
connect packets from the tun0 interface with the eth0 interface or 
vice-versa.  The next step is to 'bridge' the two interfaces, creating a 
new device that subsumes the other two.  Under this situation, neither 
eth0 nor tun0 get an IP, but the new br0 device gets one that connects to 
both interfaces.  Once you've done the kernel changes and installed 
bridge-utils, qemu setup is as follows (by root):

If you're using VDE, don't set the IP for the tun0 device as was done above,
just do

# vde_switch -tap tun0 -daemon
# chmod 777 /tmp/vde.ctl

the remaining commands are the same whether you use VDE or tun0 directly:

# ifconfig eth0 down

# brctl addbr br0
# ifconfig eth0 0.0.0.0 promisc up
# ifconfig tun0 0.0.0.0 promisc up
# ifconfig br0 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 up

# brctl stp br0 off
# brctl setfd br0 1
# brctl sethello br0 1
# brctl addif br0 eth0
# brctl addif br0 tun0
# route add default gw 192.168.1.1

Remember, 192.168.1.2 is my laptop's normal static IP, and 192.168.1.1 is my
normal gateway box.  For the guest I can either set it up with a static IP
of 192.168.1.5, gateway of 192.168.1.1  and DNS as appropriate, or just let 
DHCP supply everything to it automatically.

Notes:

After setting up the bridge (in particular once the 'ifconfig eth0 down' line 
is run) you may need to stop and restart samba on your host.

There's no IP masquerade / iptables needed for this configuration.

                 reply	other threads:[~2004-09-06 18:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.60.0409061931280.23989@vista.rtm.home \
    --to=rob@janerob.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).