Site Home Page
The UML Wiki
The Old UML Site

Configuring your virtual machine

Constructing a machine on the command line
Like a physical machine, a UML virtual machine has "hardware" that it controls. Unlike a physical machine, this hardware is virtual, and can be specified pretty arbitrarily on the command line.
The amount of memory a UML has is controlled by the "mem=" switch. For example, "mem=128M" will give the UML 128 megabytes of "physical" memory. The size is specified as a number followed by one of 'k', 'K", 'm', 'M", "g", or "G", which have the obvious meanings. The largest possible physical memory size on x86 is ~3G. On x86_64, it is more like 266G.
UML has both consoles and serial lines, which are practically identical. They can be attached to a variety of different host devices, including already-open file descriptors, pseudo-terminals, and ports. Here are some common uses:
con0=fd:0,fd:1 con=pts The main console is attached to stdin and stdout and all other consoles are attached to pts devices. Unless you know what you're doing, you should always specifically configure con0 this way when configuring all the other consoles.
con0=fd:0,fd:1 con1=null con=pts This is the same as above, except con1 is made to not exist. This is helpful with some distributions which run /sbin/hwclock during boot. The boot may hang at that point because hwclock tries to read from this console. Removing the device from the UML will cause the read to fail, and the boot to continue.
ssl=xterm All of the serial lines are attached to xterms, which will pop up when they are opened from inside UML.
ssl=port:9000 All of the serial lines are attached to the host's port 9000. They can be accessed with "telnet localhost 9000"
There is more flexibility in configuring consoles and serial lines than shown above. A complete description is given
Block devices
UML block devices are almost always files on the host which contain filesystem images. They can be host device files or normal files that don't contain filesystems. This is not common, but occasionally very useful. Here are some common recipes:
ubdb=swap "swap" should be an empty host file - a non-sparse one! Very odd things will happen if UML tries to swap when the host filesystem is full and can't allocate space for the swapped data. You can create a 1G file with
	host% dd if=/dev/zero of=swap count=$[ 1024 * 1024 ] bs=1024
Inside UML, enable it with
	UML# mkswap /dev/ubdb
	UML# swapon /dev/ubdb
If that complains about /dev/ubdb not existing, then create the device node with
	UML# mknod /dev/ubdb b 98 16
ubda=cow,root_fs This adds a COW (Copy-On-Write) layer to the root_fs, allowing multiple UMLs to boot from the same filesystem. Each UML must have its own private COW file, as that is where it will store its own changes. This page has a more complete description of COW files and how to use them.
ubdb=/dev/cdrom If you want to mount a filesystem from a CD-ROM or any other storage device, you can attach the host device node to a UML ubd device. UML will need permission to access the host device, which means you may need to make the host device node readable or writeable by the UML user. Inside UML, you can mount this filesystem just like any other filesystem.
ubdb=foo.tar This attaches a tarball to the UML /dev/ubdb. You can't mount it, but you can untar it directly from the device:
	UML# tar xf /dev/ubdb
When you hotplug the device, this is a quick way of importing data into a UML. For another quick method, see hostfs.
Hosted at SourceForge Logo