usermodelinux-howto.txt

来自「Linux Kernel 2.6.9 for OMAP1710」· 文本 代码 · 共 2,578 行 · 第 1/5 页

  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
  convenient asynchronous IO thread.

  If you're using the uml_net helper, you can ignore the following host
  setup - uml_net will do it for you.  You just need to make sure you
  have ethertap available, either built in to the host kernel or
  available as a module.


  If you want to set things up yourself, you need to make sure that the
  appropriate /dev entry exists.  If it doesn't, become root and create
  it as follows:


       mknod /dev/tap <minor>  c 36  <minor>  + 16




  For example, this is how to create /dev/tap0:


       mknod /dev/tap0 c 36 0 + 16




  You also need to make sure that the host kernel has ethertap support.
  If ethertap is enabled as a module, you apparently need to insmod
  ethertap once for each ethertap device you want to enable.  So,


       host#
       insmod ethertap




  will give you the tap0 interface.  To get the tap1 interface, you need
  to run


       host#
       insmod ethertap unit=1 -o ethertap1







  66..99..  TThhee sswwiittcchh ddaaeemmoonn

  NNoottee: This is the daemon formerly known as uml_router, but which was
  renamed so the network weenies of the world would stop growling at me.


  The switch daemon, uml_switch, provides a mechanism for creating a
  totally virtual network.  By default, it provides no connection to the
  host network (but see -tap, below).


  The first thing you need to do is run the daemon.  Running it with no
  arguments will make it listen on a default pair of unix domain
  sockets.


  If you want it to listen on a different pair of sockets, use


        -unix control socket data socket





  If you want it to act as a hub rather than a switch, use


        -hub





  If you want the switch to be connected to host networking (allowing
  the umls to get access to the outside world through the host), use


        -tap tap0





  Note that the tap device must be preconfigured (see "TUN/TAP with a
  preconfigured tap device", above).  If you're using a different tap
  device than tap0, specify that instead of tap0.


  uml_switch can be backgrounded as follows


       host%
       uml_switch [ options ] < /dev/null > /dev/null




  The reason it doesn't background by default is that it listens to
  stdin for EOF.  When it sees that, it exits.


  The general format of the kernel command line switch is



       ethn=daemon,ethernet address,socket
       type,control socket,data socket




  You can leave off everything except the 'daemon'.  You only need to
  specify the ethernet address if the one that will be assigned to it
  isn't acceptable for some reason.  The rest of the arguments describe
  how to communicate with the daemon.  You should only specify them if
  you told the daemon to use different sockets than the default.  So, if
  you ran the daemon with no arguments, running the UML on the same
  machine with
       eth0=daemon




  will cause the eth0 driver to attach itself to the daemon correctly.



  66..1100..  SSlliipp

  Slip is another, less general, mechanism for a process to communicate
  with the host networking.  In contrast to the ethertap interface,
  which exchanges ethernet frames with the host and can be used to
  transport any higher-level protocol, it can only be used to transport
  IP.


  The general format of the command line switch is



       ethn=slip,slip IP




  The slip IP argument is the IP address that will be assigned to the
  host end of the slip device.  If it is specified, the helper will run
  and will set up the host so that the virtual machine can reach it and
  the rest of the network.


  There are some oddities with this interface that you should be aware
  of.  You should only specify one slip device on a given virtual
  machine, and its name inside UML will be 'umn', not 'eth0' or whatever
  you specified on the command line.  These problems will be fixed at
  some point.



  66..1111..  SSlliirrpp

  slirp uses an external program, usually /usr/bin/slirp, to provide IP
  only networking connectivity through the host. This is similar to IP
  masquerading with a firewall, although the translation is performed in
  user-space, rather than by the kernel.  As slirp does not set up any
  interfaces on the host, or changes routing, slirp does not require
  root access or setuid binaries on the host.


  The general format of the command line switch for slirp is:



       ethn=slirp,ethernet address,slirp path




  The ethernet address is optional, as UML will set up the interface
  with an ethernet address based upon the initial IP address of the
  interface.  The slirp path is generally /usr/bin/slirp, although it
  will depend on distribution.


  The slirp program can have a number of options passed to the command
  line and we can't add them to the UML command line, as they will be
  parsed incorrectly.  Instead, a wrapper shell script can be written or
  the options inserted into the  /.slirprc file.  More information on
  all of the slirp options can be found in its man pages.


  The eth0 interface on UML should be set up with the IP 10.2.0.15,
  although you can use anything as long as it is not used by a network
  you will be connecting to. The default route on UML should be set to
  use


       UML#
       route add default dev eth0




  slirp provides a number of useful IP addresses which can be used by
  UML, such as 10.0.2.3 which is an alias for the DNS server specified
  in /etc/resolv.conf on the host or the IP given in the 'dns' option
  for slirp.


  Even with a baudrate setting higher than 115200, the slirp connection
  is limited to 115200. If you need it to go faster, the slirp binary
  needs to be compiled with FULL_BOLT defined in config.h.



  66..1122..  ppccaapp

  The pcap transport is attached to a UML ethernet device on the command
  line or with uml_mconsole with the following syntax:



       ethn=pcap,host interface,filter
       expression,option1,option2




  The expression and options are optional.


  The interface is whatever network device on the host you want to
  sniff.  The expression is a pcap filter expression, which is also what
  tcpdump uses, so if you know how to specify tcpdump filters, you will
  use the same expressions here.  The options are up to two of
  'promisc', control whether pcap puts the host interface into
  promiscuous mode. 'optimize' and 'nooptimize' control whether the pcap
  expression optimizer is used.


  Example:



       eth0=pcap,eth0,tcp

       eth1=pcap,eth0,!tcp



  will cause the UML eth0 to emit all tcp packets on the host eth0 and
  the UML eth1 to emit all non-tcp packets on the host eth0.



  66..1133..  SSeettttiinngg uupp tthhee hhoosstt yyoouurrsseellff

  If you don't specify an address for the host side of the ethertap or
  slip device, UML won't do any setup on the host.  So this is what is
  needed to get things working (the examples use a host-side IP of
  192.168.0.251 and a UML-side IP of 192.168.0.250 - adjust to suit your
  own network):

  +o  The device needs to be configured with its IP address.  Tap devices
     are also configured with an mtu of 1484.  Slip devices are
     configured with a point-to-point address pointing at the UML ip
     address.


       host#  ifconfig tap0 arp mtu 1484 192.168.0.251 up






       host#
       ifconfig sl0 192.168.0.251 pointopoint 192.168.0.250 up





  +o  If a tap device is being set up, a route is set to the UML IP.


       UML# route add -host 192.168.0.250 gw 192.168.0.251





  +o  To allow other hosts on your network to see the virtual machine,
     proxy arp is set up for it.


       host#  arp -Ds 192.168.0.250 eth0 pub





  +o  Finally, the host is set up to route packets.


       host#  echo 1 > /proc/sys/net/ipv4/ip_forward










  77..  SShhaarriinngg FFiilleessyysstteemmss bbeettwweeeenn VViirrttuuaall MMaacchhiinneess




  77..11..  AA wwaarrnniinngg

  Don't attempt to share filesystems simply by booting two UMLs from the
  same file.  That's the same thing as booting two physical machines
  from a shared disk.  It will result in filesystem corruption.



  77..22..  UUssiinngg llaayyeerreedd bblloocckk ddeevviicceess

  The way to share a filesystem between two virtual machines is to use
  the copy-on-write (COW) layering capability of the ubd block driver.
  As of 2.4.6-2um, the driver supports layering a read-write private
  device over a read-only shared device.  A machine's writes are stored
  in the private device, while reads come from either device - the
  private one if the requested block is valid in it, the shared one if
  not.  Using this scheme, the majority of data which is unchanged is
  shared between an arbitrary number of virtual machines, each of which
  has a much smaller file containing the changes that it has made.  With
  a large number of UMLs booting from a large root filesystem, this
  leads to a huge disk space saving.  It will also help performance,
  since the host will be able to cache the shared data using a much
  smaller amount of memory, so UML disk requests will be served from the
  host's memory rather than its disks.




  To add a copy-on-write layer to an existing block device file, simply
  add the name of the COW file to the appropriate ubd switch:


        ubd0=root_fs_cow,root_fs_debian_22




  where 'root_fs_cow' is the private COW file and 'root_fs_debian_22' is
  the existing shared filesystem.  The COW file need not exist.  If it
  doesn't, the driver will create and initialize it.  Once the COW file
  has been initialized, it can be used on its own on the command line:


        ubd0=root_fs_cow




  The name of the backing file is stored in the COW file header, so it
  would be redundant to continue specifying it on the command line.



  77..33..  NNoottee!!

  When checking the size of the COW file in order to see the gobs of
  space that you're saving, make sure you use 'ls -ls' to see the actual
  disk consumption rather than the length of the file.  The COW file is
  sparse, so the length will be very different from the disk usage.
  Here is a 'ls -l' of a COW file and backing file from one boot and
  shutdown:
       host% ls -l cow.debian debian2.2
       -rw-r--r--    1 jdike    jdike    492504064 Aug  6 21:16 cow.debian
       -rwxrw-rw-    1 jdike    jdike    537919488 Aug  6 20:42 debian2.2




  Doesn't look like much saved space, does it?  Well, here's 'ls -ls':


       host% ls -ls cow.debian debian2.2
          880 -rw-r--r--    1 jdike    jdike    492504064 Aug  6 21:16 cow.debian
       525832 -rwxrw-rw-    1 jdike    jdike    537919488 Aug  6 20:42 debian2.2




  Now, you can see that the COW file has less than a meg of disk, rather
  than 492 meg.



  77..44..  AAnnootthheerr wwaarrnniinngg

  Once a filesystem is being used as a readonly backing file for a COW
  file, do not boot directly from it or modify it in any way.  Doing so
  will invalidate any COW files that are using it.  The mtime and size
  of the backing file are stored in the COW file header at its creation,
  and they must continue to match.  If they don't, the driver will
  refuse to use the COW file.




  If you attempt to evade this restriction by changing either the
  backing file or the COW header by hand, you will get a corrupted
  filesystem.




  Among other things, this means that upgrading the distribution in a
  backing file and expecting that all of the COW files using it will see
  the upgrade will not work.




  77..55..  uummll__mmoooo :: MMeerrggiinngg aa CCOOWW ffiillee wwiitthh iittss bbaacckkiinngg ffiillee

  Depending on how you use UML and COW devices, it may be advisable to
  merge the changes in the COW file into the backing file every once in
  a while.




  The utility that does this is uml_moo.  Its usage is


       host% uml_moo COW file new backing file




  There's no need to specify the backing file since that information is
  already in the COW file header.  If you're paranoid, boot the new
  merged file, and if you're happy with it, move it over the old backing
  file.




  uml_moo creates a new backing file by default as a safety measure.  It
  also has a destructive merge option which will merge the COW file
  directly into its current backing file.  This is really only usable
  when the backing file only has one COW file associated with it.  If
  there are multiple COWs associated with a backing file, a -d merge of
  one of them will invalidate all of the others.  However, it is
  convenient if you're short of disk space, and it should also be
  noticably faster than a non-destructive merge.