usermodelinux-howto.txt

linux 内核源代码

  yourself inside a little virtual machine. Our filesystems have a
  variety of commands and utilities installed (and it is fairly easy to
  add more), so you will have a lot of tools with which to poke around
  the system.

  There are a couple of other ways to log in:

  +o  On a virtual console



     Each virtual console that is configured (i.e. the device exists in
     /dev and /etc/inittab runs a getty on it) will come up in its own
     xterm.  If you get tired of the xterms, read ``Setting up serial
     lines and consoles''  to see how to attach the consoles to
     something else, like host ptys.



  +o  Over the serial line


     In the boot output, find a line that looks like:



       serial line 0 assigned pty /dev/ptyp1




  Attach your favorite terminal program to the corresponding tty.  I.e.
  for minicom, the command would be


       host% minicom -o -p /dev/ttyp1






  +o  Over the net


     If the network is running, then you can telnet to the virtual
     machine and log in to it.  See ``Setting up the network''  to learn
     about setting up a virtual network.

  When you're done using it, run halt, and the kernel will bring itself
  down and the process will exit.


  33..33..  EExxaammpplleess

  Here are some examples of UML in action:

  +o  A login session <http://user-mode-linux.sourceforge.net/login.html>

  +o  A virtual network <http://user-mode-linux.sourceforge.net/net.html>







  44..  UUMMLL oonn 22GG//22GG hhoossttss




  44..11..  IInnttrroodduuccttiioonn


  Most Linux machines are configured so that the kernel occupies the
  upper 1G (0xc0000000 - 0xffffffff) of the 4G address space and
  processes use the lower 3G (0x00000000 - 0xbfffffff).  However, some
  machine are configured with a 2G/2G split, with the kernel occupying
  the upper 2G (0x80000000 - 0xffffffff) and processes using the lower
  2G (0x00000000 - 0x7fffffff).




  44..22..  TThhee pprroobblleemm


  The prebuilt UML binaries on this site will not run on 2G/2G hosts
  because UML occupies the upper .5G of the 3G process address space
  (0xa0000000 - 0xbfffffff).  Obviously, on 2G/2G hosts, this is right
  in the middle of the kernel address space, so UML won't even load - it
  will immediately segfault.




  44..33..  TThhee ssoolluuttiioonn


  The fix for this is to rebuild UML from source after enabling
  CONFIG_HOST_2G_2G (under 'General Setup').  This will cause UML to
  load itself in the top .5G of that smaller process address space,
  where it will run fine.  See ``Compiling the kernel and modules''  if
  you need help building UML from source.










  55..  SSeettttiinngg uupp sseerriiaall lliinneess aanndd ccoonnssoolleess


  It is possible to attach UML serial lines and consoles to many types
  of host I/O channels by specifying them on the command line.


  You can attach them to host ptys, ttys, file descriptors, and ports.
  This allows you to do things like

  +o  have a UML console appear on an unused host console,

  +o  hook two virtual machines together by having one attach to a pty
     and having the other attach to the corresponding tty

  +o  make a virtual machine accessible from the net by attaching a
     console to a port on the host.


  The general format of the command line option is device=channel.



  55..11..  SSppeecciiffyyiinngg tthhee ddeevviiccee

  Devices are specified with "con" or "ssl" (console or serial line,
  respectively), optionally with a device number if you are talking
  about a specific device.


  Using just "con" or "ssl" describes all of the consoles or serial
  lines.  If you want to talk about console #3 or serial line #10, they
  would be "con3" and "ssl10", respectively.


  A specific device name will override a less general "con=" or "ssl=".
  So, for example, you can assign a pty to each of the serial lines
  except for the first two like this:


        ssl=pty ssl0=tty:/dev/tty0 ssl1=tty:/dev/tty1




  The specificity of the device name is all that matters; order on the
  command line is irrelevant.



  55..22..  SSppeecciiffyyiinngg tthhee cchhaannnneell

  There are a number of different types of channels to attach a UML
  device to, each with a different way of specifying exactly what to
  attach to.

  +o  pseudo-terminals - device=pty pts terminals - device=pts


     This will cause UML to allocate a free host pseudo-terminal for the
     device.  The terminal that it got will be announced in the boot
     log.  You access it by attaching a terminal program to the
     corresponding tty:

  +o  screen /dev/pts/n

  +o  screen /dev/ttyxx

  +o  minicom -o -p /dev/ttyxx - minicom seems not able to handle pts
     devices

  +o  kermit - start it up, 'open' the device, then 'connect'





  +o  terminals - device=tty:tty device file


     This will make UML attach the device to the specified tty (i.e


        con1=tty:/dev/tty3




  will attach UML's console 1 to the host's /dev/tty3).  If the tty that
  you specify is the slave end of a tty/pty pair, something else must
  have already opened the corresponding pty in order for this to work.





  +o  xterms - device=xterm


     UML will run an xterm and the device will be attached to it.





  +o  Port - device=port:port number


     This will attach the UML devices to the specified host port.
     Attaching console 1 to the host's port 9000 would be done like
     this:


        con1=port:9000




  Attaching all the serial lines to that port would be done similarly:


        ssl=port:9000




  You access these devices by telnetting to that port.  Each active tel-
  net session gets a different device.  If there are more telnets to a
  port than UML devices attached to it, then the extra telnet sessions
  will block until an existing telnet detaches, or until another device
  becomes active (i.e. by being activated in /etc/inittab).

  This channel has the advantage that you can both attach multiple UML
  devices to it and know how to access them without reading the UML boot
  log.  It is also unique in allowing access to a UML from remote
  machines without requiring that the UML be networked.  This could be
  useful in allowing public access to UMLs because they would be
  accessible from the net, but wouldn't need any kind of network
  filtering or access control because they would have no network access.


  If you attach the main console to a portal, then the UML boot will
  appear to hang.  In reality, it's waiting for a telnet to connect, at
  which point the boot will proceed.





  +o  already-existing file descriptors - device=file descriptor


     If you set up a file descriptor on the UML command line, you can
     attach a UML device to it.  This is most commonly used to put the
     main console back on stdin and stdout after assigning all the other
     consoles to something else:


        con0=fd:0,fd:1 con=pts








  +o  Nothing - device=null


     This allows the device to be opened, in contrast to 'none', but
     reads will block, and writes will succeed and the data will be
     thrown out.





  +o  None - device=none


     This causes the device to disappear.



  You can also specify different input and output channels for a device
  by putting a comma between them:


        ssl3=tty:/dev/tty2,xterm




  will cause serial line 3 to accept input on the host's /dev/tty3 and
  display output on an xterm.  That's a silly example - the most common
  use of this syntax is to reattach the main console to stdin and stdout
  as shown above.


  If you decide to move the main console away from stdin/stdout, the
  initial boot output will appear in the terminal that you're running
  UML in.  However, once the console driver has been officially
  initialized, then the boot output will start appearing wherever you
  specified that console 0 should be.  That device will receive all
  subsequent output.



  55..33..  EExxaammpplleess

  There are a number of interesting things you can do with this
  capability.


  First, this is how you get rid of those bleeding console xterms by
  attaching them to host ptys:


        con=pty con0=fd:0,fd:1




  This will make a UML console take over an unused host virtual console,
  so that when you switch to it, you will see the UML login prompt
  rather than the host login prompt:


        con1=tty:/dev/tty6




  You can attach two virtual machines together with what amounts to a
  serial line as follows:

  Run one UML with a serial line attached to a pty -


        ssl1=pty




  Look at the boot log to see what pty it got (this example will assume
  that it got /dev/ptyp1).

  Boot the other UML with a serial line attached to the corresponding
  tty -


        ssl1=tty:/dev/ttyp1




  Log in, make sure that it has no getty on that serial line, attach a
  terminal program like minicom to it, and you should see the login
  prompt of the other virtual machine.


  66..  SSeettttiinngg uupp tthhee nneettwwoorrkk



  This page describes how to set up the various transports and to
  provide a UML instance with network access to the host, other machines
  on the local net, and the rest of the net.


  As of 2.4.5, UML networking has been completely redone to make it much
  easier to set up, fix bugs, and add new features.


  There is a new helper, uml_net, which does the host setup that
  requires root privileges.


  There are currently five transport types available for a UML virtual
  machine to exchange packets with other hosts:

  +o  ethertap

  +o  TUN/TAP

  +o  Multicast

  +o  a switch daemon

  +o  slip

  +o  slirp

  +o  pcap

     The TUN/TAP, ethertap, slip, and slirp transports allow a UML
     instance to exchange packets with the host.  They may be directed
     to the host or the host may just act as a router to provide access
     to other physical or virtual machines.


  The pcap transport is a synthetic read-only interface, using the
  libpcap binary to collect packets from interfaces on the host and
  filter them.  This is useful for building preconfigured traffic
  monitors or sniffers.


  The daemon and multicast transports provide a completely virtual
  network to other virtual machines.  This network is completely
  disconnected from the physical network unless one of the virtual
  machines on it is acting as a gateway.


  With so many host transports, which one should you use?  Here's when
  you should use each one:

  +o  ethertap - if you want access to the host networking and it is
     running 2.2

  +o  TUN/TAP - if you want access to the host networking and it is
     running 2.4.  Also, the TUN/TAP transport is able to use a
     preconfigured device, allowing it to avoid using the setuid uml_net
     helper, which is a security advantage.

  +o  Multicast - if you want a purely virtual network and you don't want
     to set up anything but the UML

  +o  a switch daemon - if you want a purely virtual network and you
     don't mind running the daemon in order to get somewhat better
     performance

  +o  slip - there is no particular reason to run the slip backend unless
     ethertap and TUN/TAP are just not available for some reason

  +o  slirp - if you don't have root access on the host to setup
     networking, or if you don't want to allocate an IP to your UML

  +o  pcap - not much use for actual network connectivity, but great for
     monitoring traffic on the host

     Ethertap is available on 2.4 and works fine.  TUN/TAP is preferred
     to it because it has better performance and ethertap is officially
     considered obsolete in 2.4.  Also, the root helper only needs to
     run occasionally for TUN/TAP, rather than handling every packet, as
     it does with ethertap.  This is a slight security advantage since
     it provides fewer opportunities for a nasty UML user to somehow
     exploit the helper's root privileges.


  66..11..  GGeenneerraall sseettuupp

  First, you must have the virtual network enabled in your UML.  If are
  running a prebuilt kernel from this site, everything is already
  enabled.  If you build the kernel yourself, under the "Network device
  support" menu, enable "Network device support", and then the three
  transports.


  The next step is to provide a network device to the virtual machine.
  This is done by describing it on the kernel command line.

  The general format is


       eth <n> = <transport> , <transport args>




  For example, a virtual ethernet device may be attached to a host
  ethertap device as follows:


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




  This sets up eth0 inside the virtual machine to attach itself to the
  host /dev/tap0, assigns it an ethernet address, and assigns the host
  tap0 interface an IP address.



  Note that the IP address you assign to the host end of the tap device
  must be different than the IP you assign to the eth device inside UML.
  If you are short on IPs and don't want to consume two per UML, then
  you can reuse the host's eth IP address for the host ends of the tap
  devices.  Internally, the UMLs must still get unique IPs for their eth
  devices.  You can also give the UMLs non-routable IPs (192.168.x.x or
  10.x.x.x) and have the host masquerade them.  This will let outgoing
  connections work, but incoming connections won't without more work,
  such as port forwarding from the host.
  Also note that when you configure the host side of an interface, it is
  only acting as a gateway.  It will respond to pings sent to it
  locally, but is not useful to do that since it's a host interface.
  You are not talking to the UML when you ping that interface and get a
  response.


  You can also add devices to a UML and remove them at runtime.  See the
  ``The Management Console''  page for details.