|
|
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
here
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.
|
|
