usermodelinux-howto.txt

linux 内核源代码

  The sections below describe this in more detail.


  Once you've decided how you're going to set up the devices, you boot
  UML, log in, configure the UML side of the devices, and set up routes
  to the outside world.  At that point, you will be able to talk to any
  other machines, physical or virtual, on the net.


  If ifconfig inside UML fails and the network refuses to come up, run
  tell you what went wrong.



  66..22..  UUsseerrssppaaccee ddaaeemmoonnss

  You will likely need the setuid helper, or the switch daemon, or both.
  They are both installed with the RPM and deb, so if you've installed
  either, you can skip the rest of this section.


  If not, then you need to check them out of CVS, build them, and
  install them.  The helper is uml_net, in CVS /tools/uml_net, and the
  daemon is uml_switch, in CVS /tools/uml_router.  They are both built
  with a plain 'make'.  Both need to be installed in a directory that's
  in your path - /usr/bin is recommend.  On top of that, uml_net needs
  to be setuid root.



  66..33..  SSppeecciiffyyiinngg eetthheerrnneett aaddddrreesssseess

  Below, you will see that the TUN/TAP, ethertap, and daemon interfaces
  allow you to specify hardware addresses for the virtual ethernet
  devices.  This is generally not necessary.  If you don't have a
  specific reason to do it, you probably shouldn't.  If one is not
  specified on the command line, the driver will assign one based on the
  device IP address.  It will provide the address fe:fd:nn:nn:nn:nn
  where nn.nn.nn.nn is the device IP address.  This is nearly always
  sufficient to guarantee a unique hardware address for the device.  A
  couple of exceptions are:

  +o  Another set of virtual ethernet devices are on the same network and
     they are assigned hardware addresses using a different scheme which
     may conflict with the UML IP address-based scheme

  +o  You aren't going to use the device for IP networking, so you don't
     assign the device an IP address

     If you let the driver provide the hardware address, you should make
     sure that the device IP address is known before the interface is
     brought up.  So, inside UML, this will guarantee that:



  UML#
  ifconfig eth0 192.168.0.250 up




  If you decide to assign the hardware address yourself, make sure that
  the first byte of the address is even.  Addresses with an odd first
  byte are broadcast addresses, which you don't want assigned to a
  device.



  66..44..  UUMMLL iinntteerrffaaccee sseettuupp

  Once the network devices have been described on the command line, you
  should boot UML and log in.


  The first thing to do is bring the interface up:


       UML# ifconfig ethn ip-address up




  You should be able to ping the host at this point.


  To reach the rest of the world, you should set a default route to the
  host:


       UML# route add default gw host ip




  Again, with host ip of 192.168.0.4:


       UML# route add default gw 192.168.0.4




  This page used to recommend setting a network route to your local net.
  This is wrong, because it will cause UML to try to figure out hardware
  addresses of the local machines by arping on the interface to the
  host.  Since that interface is basically a single strand of ethernet
  with two nodes on it (UML and the host) and arp requests don't cross
  networks, they will fail to elicit any responses.  So, what you want
  is for UML to just blindly throw all packets at the host and let it
  figure out what to do with them, which is what leaving out the network
  route and adding the default route does.


  Note: If you can't communicate with other hosts on your physical
  ethernet, it's probably because of a network route that's
  automatically set up.  If you run 'route -n' and see a route that
  looks like this:




  Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  192.168.0.0     0.0.0.0         255.255.255.0   U     0      0      0   eth0




  with a mask that's not 255.255.255.255, then replace it with a route
  to your host:


       UML#
       route del -net 192.168.0.0 dev eth0 netmask 255.255.255.0






       UML#
       route add -host 192.168.0.4 dev eth0




  This, plus the default route to the host, will allow UML to exchange
  packets with any machine on your ethernet.



  66..55..  MMuullttiiccaasstt

  The simplest way to set up a virtual network between multiple UMLs is
  to use the mcast transport.  This was written by Harald Welte and is
  present in UML version 2.4.5-5um and later.  Your system must have
  multicast enabled in the kernel and there must be a multicast-capable
  network device on the host.  Normally, this is eth0, but if there is
  no ethernet card on the host, then you will likely get strange error
  messages when you bring the device up inside UML.


  To use it, run two UMLs with


        eth0=mcast




  on their command lines.  Log in, configure the ethernet device in each
  machine with different IP addresses:


       UML1# ifconfig eth0 192.168.0.254






       UML2# ifconfig eth0 192.168.0.253




  and they should be able to talk to each other.

  The full set of command line options for this transport are



       ethn=mcast,ethernet address,multicast
       address,multicast port,ttl




  Harald's original README is here <http://user-mode-linux.source-
  forge.net/text/mcast.txt>  and explains these in detail, as well as
  some other issues.



  66..66..  TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr

  TUN/TAP is the preferred mechanism on 2.4 to exchange packets with the
  host.  The TUN/TAP backend has been in UML since 2.4.9-3um.


  The easiest way to get up and running is to let the setuid uml_net
  helper do the host setup for you.  This involves insmod-ing the tun.o
  module if necessary, configuring the device, and setting up IP
  forwarding, routing, and proxy arp.  If you are new to UML networking,
  do this first.  If you're concerned about the security implications of
  the setuid helper, use it to get up and running, then read the next
  section to see how to have UML use a preconfigured tap device, which
  avoids the use of uml_net.


  If you specify an IP address for the host side of the device, the
  uml_net helper will do all necessary setup on the host - the only
  requirement is that TUN/TAP be available, either built in to the host
  kernel or as the tun.o module.

  The format of the command line switch to attach a device to a TUN/TAP
  device is


       eth <n> =tuntap,,, <IP address>




  For example, this argument will attach the UML's eth0 to the next
  available tap device and assign an ethernet address to it based on its
  IP address


       eth0=tuntap,,,192.168.0.254






  Note that the IP address that must be used for the eth device inside
  UML is fixed by the routing and proxy arp that is set up on the
  TUN/TAP device on the host.  You can use a different one, but it won't
  work because reply packets won't reach the UML.  This is a feature.
  It prevents a nasty UML user from doing things like setting the UML IP
  to the same as the network's nameserver or mail server.


  There are a couple potential problems with running the TUN/TAP
  transport on a 2.4 host kernel

  +o  TUN/TAP seems not to work on 2.4.3 and earlier.  Upgrade the host
     kernel or use the ethertap transport.

  +o  With an upgraded kernel, TUN/TAP may fail with


       File descriptor in bad state




  This is due to a header mismatch between the upgraded kernel and the
  kernel that was originally installed on the machine.  The fix is to
  make sure that /usr/src/linux points to the headers for the running
  kernel.

  These were pointed out by Tim Robinson <timro at trkr dot net> in
  <http://www.geocrawler.com/lists/3/SourceForge/597/0/> name="this uml-
  user post"> .



  66..77..  TTUUNN//TTAAPP wwiitthh aa pprreeccoonnffiigguurreedd ttaapp ddeevviiccee

  If you prefer not to have UML use uml_net (which is somewhat
  insecure), with UML 2.4.17-11, you can set up a TUN/TAP device
  beforehand.  The setup needs to be done as root, but once that's done,
  there is no need for root assistance.  Setting up the device is done
  as follows:

  +o  Create the device with tunctl (available from the UML utilities
     tarball)




       host#  tunctl -u uid




  where uid is the user id or username that UML will be run as.  This
  will tell you what device was created.

  +o  Configure the device IP (change IP addresses and device name to
     suit)




       host#  ifconfig tap0 192.168.0.254 up





  +o  Set up routing and arping if desired - this is my recipe, there are
     other ways of doing the same thing


       host#
       bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

       host#
       route add -host 192.168.0.253 dev tap0






       host#
       bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp'






       host#
       arp -Ds 192.168.0.253 eth0 pub




  Note that this must be done every time the host boots - this configu-
  ration is not stored across host reboots.  So, it's probably a good
  idea to stick it in an rc file.  An even better idea would be a little
  utility which reads the information from a config file and sets up
  devices at boot time.

  +o  Rather than using up two IPs and ARPing for one of them, you can
     also provide direct access to your LAN by the UML by using a
     bridge.


       host#
       brctl addbr br0






       host#
       ifconfig eth0 0.0.0.0 promisc up






       host#
       ifconfig tap0 0.0.0.0 promisc up






       host#
       ifconfig br0 192.168.0.1 netmask 255.255.255.0 up







  host#
  brctl stp br0 off






       host#
       brctl setfd br0 1






       host#
       brctl sethello br0 1






       host#
       brctl addif br0 eth0






       host#
       brctl addif br0 tap0




  Note that 'br0' should be setup using ifconfig with the existing IP
  address of eth0, as eth0 no longer has its own IP.

  +o


     Also, the /dev/net/tun device must be writable by the user running
     UML in order for the UML to use the device that's been configured
     for it.  The simplest thing to do is


       host#  chmod 666 /dev/net/tun




  Making it world-writable looks bad, but it seems not to be
  exploitable as a security hole.  However, it does allow anyone to cre-
  ate useless tap devices (useless because they can't configure them),
  which is a DOS attack.  A somewhat more secure alternative would to be
  to create a group containing all the users who have preconfigured tap
  devices and chgrp /dev/net/tun to that group with mode 664 or 660.


  +o  Once the device is set up, run UML with 'eth0=tuntap,device name'
     (i.e. 'eth0=tuntap,tap0') on the command line (or do it with the
     mconsole config command).

  +o  Bring the eth device up in UML and you're in business.

     If you don't want that tap device any more, you can make it non-
     persistent with


       host#  tunctl -d tap device




  Finally, tunctl has a -b (for brief mode) switch which causes it to
  output only the name of the tap device it created.  This makes it
  suitable for capture by a script:


       host#  TAP=`tunctl -u 1000 -b`






  66..88..  EEtthheerrttaapp

  Ethertap is the general mechanism on 2.2 for userspace processes to
  exchange packets with the kernel.



  To use this transport, you need to describe the virtual network device
  on the UML command line.  The general format for this is


       eth <n> =ethertap, <device> , <ethernet address> , <tap IP address>




  So, the previous example


       eth0=ethertap,tap0,fe:fd:0:0:0:1,192.168.0.254




  attaches the UML eth0 device to the host /dev/tap0, assigns it the
  ethernet address fe:fd:0:0:0:1, and assigns the IP address
  192.168.0.254 to the tap device.



  The tap device is mandatory, but the others are optional.  If the
  ethernet address is omitted, one will be assigned to it.


  The presence of the tap IP address will cause the helper to run and do
  whatever host setup is needed to allow the virtual machine to
  communicate with the outside world.  If you're not sure you know what
  you're doing, this is the way to go.


  If it is absent, then you must configure the tap device and whatever
  arping and routing you will need on the host.  However, even in this
  case, the uml_net helper still needs to be in your path and it must be
  setuid root if you're not running UML as root.  This is because the
  tap device doesn't support SIGIO, which UML needs in order to use
  something as a source of input.  So, the helper is used as a