Lines Matching refs:a
18 How is UML Different from a VM using Virtualization package X?
22 hardware emulation. In fact, it does not. As long as a virtualization
24 has a driver for, the devices do not need to emulate real hardware.
25 Most OSes today have built-in support for a number of "fake"
28 is not a single real device in sight. It is 100% artificial or if
34 packages is that there is a distinct difference between the way the UML
36 The UML kernel is just a process running on Linux - same as any other
39 The UML userspace, however, is a bit different. The Linux kernel on the
41 on a UML instance is trying to do and making the UML kernel handle all
45 results in a number of advantages and disadvantages of UML over let's say
55 access any devices directly. It is, in fact, a process like any other.
57 * You can run a usermode kernel as a non-root user (you may need to
60 * You can run a very small VM with a minimal footprint for a specific
63 * You can get extremely high performance for anything which is a "kernel
82 **slow**. The root cause is that UML has a very high cost of creating
91 Building a UML instance
95 the shelf install media to install into a blank VM using a virtualization
97 your host to build a viable filesystem image.
106 Create a sparse raw disk image::
110 This will create a 16G disk image. The OS will initially allocate only one
113 Using TRIM inside the UML image by specifying discard as a mount option
117 Create a filesystem on the disk image and mount it::
124 Create a minimal OS installation on the mounted filesystem::
147 are creating its image. It is a good idea to change that to avoid
167 We now have a UML image which is nearly ready to run, all we need is a
170 Most distributions have a UML package. Even if you intend to use your own
171 kernel, testing the image with a stock one is always a good start. These
172 packages come with a set of modules which should be copied to the target
180 modules to a location" procedure by running::
196 connection may be either point-to-point (similar to a connection
197 between machines using a back-to-back cable) or a connection to a
198 switch. UML supports a wide variety of means to build these
246 * Daemon and bess require running a local switch. This switch may be
261 This can be achieved by granting the user a particular capability instead
262 of running UML as root. In case of vector transport, a user can add the
274 All vector transports support a similar syntax:
287 amount of packets UML will attempt to read or write in a single
307 if a packet will need to be re-encapsulated into for instance VXLAN.
309 * ``vec=0`` - disable multipacket IO and fall back to packet at a
315 * ``ifname=str`` Transports which bind to a local network interface
316 have a shared option - the name of the interface to bind to.
322 * ``v6=[0,1]`` to specify if a v6 connection is desired for all
339 tap0 can be configured as a point-to-point interface and given an IP
341 to connect UML to a tap interface which is connected to a bridge.
343 While tap relies on the vector infrastructure, it is not a true vector
346 is a privilege which is offered only to something which can hook up
365 and a raw socket for receive. The raw socket allows multi-packet
380 interface including a physical one, the most common use it to bind to
381 the "peer" side of a veth pair with the other side configured on the
407 * ``bpffile=str`` filename of raw bpf code to be loaded as a socket filter
414 presently limited to legacy bpf syntax (not ebpf), it is still a security
430 ``GREIRB``) tunnel which will connect the UML instance to a ``GRE``
450 GRE has a number of caveats:
456 * The key is not really a security feature. While it was intended as such
457 its "security" is laughable. It is, however, a useful feature to
460 An example configuration for a Linux host with a local address of
461 192.168.128.1 to connect to a UML instance at 192.168.129.1
475 Additionally, GRE has been tested versus a variety of network equipment.
482 _Warning_. L2TPv3 has a "bug". It is the "bug" known as "has more
484 easier (and less verbose) ways to connect a UML instance to something.
492 connect the UML instance to a L2TPv3 endpoint at host $dst_host using
524 L2TPv3 has a number of caveats:
531 Here is an example of how to configure a Linux host to connect to UML
557 BESS is a high performance modular network switch.
561 It has support for a simple sequential packet socket mode which in the
568 This will configure a BESS transport using the unix_src Unix domain
571 For BESS configuration and how to allocate a BESS Unix domain socket port
589 distribution or a custom built kernel has been installed on the host.
608 specify a root file system.
614 a separate file which can be discarded allowing a rollback to the
623 * UBD performs some heuristics on devices specified as a single
624 filename to make sure that a COW file has not been specified as
631 * ``root=`` root device - most likely ``/dev/ubd0`` (this is a Linux
640 xterm. This makes it nice and easy to use UML on a host with a GUI. It is,
641 however, the wrong approach if UML is to be used as a testing harness or run
642 in a text-only environment.
645 and wire it to one of the supported "line" channels. For this we need to map a
652 UML supports a wide variety of serial line channels which are specified using
667 * The port channel - start a telnet server on TCP port number. Example:
669 a telnetd package) and the port-helper from the UML utilities (see the
670 information for the xterm channel below). UML will not boot until a client
705 If you have not set up a password when generating the image, you will have to
714 it is possible to perform a number of low-level operations using the UML
715 management console. The UML management console is a low-level interface to the
716 kernel on a running UML instance, somewhat like the i386 SysRq interface. Since
717 there is a full-blown operating system under UML, there is much greater
720 There are a number of things you can do with the mconsole interface:
730 You need the mconsole client (uml\_mconsole) which is a part of the UML
734 kernel. When you boot UML, you'll see a line like::
738 If you specify a unique machine id on the UML command line, i.e.
754 You'll get a prompt, at which you can run one of these commands:
779 There are a couple actual uses for this. It's a simple no-op which
780 can be used to check that a UML is running. It's also a way of
781 sending a device interrupt to the UML. UML mconsole is treated internally as
782 a UML device.
787 This command takes no arguments. It prints a short help screen with the
804 "config" adds a new device to the virtual machine. This is supported
813 "remove" deletes a device from the system. Its argument is just the
824 This command takes one argument, which is a single letter. It calls the
840 This puts the UML in a loop reading mconsole requests until a 'go'
841 mconsole command is received. This is very useful as a
847 This resumes a UML after being paused by a 'stop' command. Note that
849 the UML is paused for a long period of time, crond might go a little
855 This takes one argument - the name of a file in /proc which is printed
861 This takes one argument - the pid number of a process. Its stack is
862 printed to a standard output.
873 from a shared disk. It will result in filesystem corruption.
878 The way to share a filesystem between two virtual machines is to use
884 machines, each of which has a much smaller file containing the changes
885 that it has made. With a large number of UMLs booting from a large root
886 filesystem, this leads to a huge disk space saving.
889 be able to cache the shared data using a much smaller amount of memory,
891 its disks. There is a major caveat in doing this on multisocket NUMA
892 machines. On such hardware, running many UML instances with a shared
897 bind UML to a set of logical CPUs residing on the same socket using the
898 ``taskset`` command or have a look at the "tuning" section.
900 To add a copy-on-write layer to an existing block device file, simply
926 Cows can moo - uml_moo : Merging a COW file with its backing file
931 a while.
943 ``uml_moo`` creates a new backing file by default as a safety measure.
944 It also has a destructive merge option which will merge the COW file
947 there are multiple COWs associated with a backing file, a -d merge of
950 noticeably faster than a non-destructive merge.
953 available as a part of UML utilities.
959 can treat it as a separate machine and either nfs mount directories
965 can mount a host directory into the UML filesystem and access the
972 confine hostfs to a specific "harmless" directory (for example ``/var/tmp``)
984 with hostfs configured into it or make sure that hostfs is built as a
994 specify a subdirectory to mount with the -o switch to mount::
1003 It's possible to boot from a directory hierarchy on the host using
1004 hostfs rather than using the standard filesystem in a file.
1021 Next, make sure that your UML kernel has hostfs compiled in, not as a
1032 host (outside UML). As a result, if a file is changed without UML's
1040 UML at present is strictly uniprocessor. It will, however spin up a
1044 idle, these threads will be migrated to other processors on a SMP host.
1046 all of the cache/memory synchronization traffic between cores. As a
1047 result, UML will usually benefit from being pinned on a single CPU,
1048 especially on a large system. This can result in performance differences
1054 needs to create a suitable tmpfs ramdisk bound to a particular node
1079 they are trying to emulate (for example 16 on a PCI bus in qemu).
1081 If you have something to contribute such as a patch, a bugfix, a
1092 you can always run UML under gdb and there will be a whole section
1094 debug a Linux kernel. Quite often adding tracing statements and/or
1101 When running, UML consists of a main kernel thread and a number of
1103 that are already ptraced by UML as a part of its MMU emulation.
1105 These are usually the first three threads visible in a ps display.
1133 This is a typical picture from a mostly idle UML instance.
1144 * ``clock_nanosleep`` is UML going into idle (similar to the way a PC
1147 As you can see UML will generate quite a bit of output even in idle. The output
1155 be started under it. If you are trying to track a runtime bug, it is
1156 much better to attach gdb to a running UML instance and let UML run.
1163 command line to request it to continue. It may be a good idea to make
1164 this into a gdb script and pass it to gdb as an argument.
1169 Nearly all UML drivers are monolithic. While it is possible to build a
1170 UML driver as a kernel module, that limits the possible functionality
1172 in order to really leverage UML, one needs to write a piece of
1177 reuse a lot of kernel concepts, it is generally just another piece of
1183 UML does not have a strictly defined kernel-to-host API. It does not
1184 try to emulate a specific architecture or bus. UML's "kernel" and
1187 limitations are purely technical. Due to a lot of functions and
1191 As a result a lot of userspace code consists of simple wrappers.
1192 E.g. ``os_close_file()`` is just a wrapper around ``close()``
1196 Using UML as a Test Platform
1223 between a driver and the host at the UML command line is OK
1224 security-wise. Allowing it as a loadable module parameter
1227 If such functionality is desirable for a particular application
1230 as a command line parameter at startup.
1236 a production application, it is recommended that all modules