Site Home Page
The UML Wiki
UML Community Site
The UML roadmap
What it's good for
Case Studies
Kernel Capabilities
Downloading it
Running it
Compiling
Installation
Skas Mode
Incremental Patches
Test Suite
Host memory use
Building filesystems
Troubles
User Contributions
Related Links
The ToDo list
Projects
Diary
Thanks
Contacts
Tutorials
The HOWTO (html)
The HOWTO (text)
Host file access
Device inputs
Sharing filesystems
Creating filesystems
Resizing filesystems
Virtual Networking
Management Console
Kernel Debugging
UML Honeypots
gprof and gcov
Running X
Diagnosing problems
Configuration
Installing Slackware
Porting UML
IO memory emulation
UML on 2G/2G hosts
Adding a UML system call
Running nested UMLs
How you can help
Overview
Documentation
Utilities
Kernel bugs
Kernel projects
Screenshots
A virtual network
An X session
Transcripts
A login session
A debugging session
Slackware installation
Reference
Kernel switches
Slackware README
Papers
ALS 2000 paper (html)
ALS 2000 paper (TeX)
ALS 2000 slides
LCA 2001 slides
OLS 2001 paper (html)
OLS 2001 paper (TeX)
ALS 2001 paper (html)
ALS 2001 paper (TeX)
UML security (html)
LCA 2002 (html)
WVU 2002 (html)
Security Roundtable (html)
OLS 2002 slides
LWE 2005 slides
Fun and Games
Kernel Hangman
Disaster of the Month

Sharing Filesystems between Virtual Machines

A warning
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.
Using layered block devices
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.
Note!
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.
Another warning
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.

Moving a backing file
Because UML stores the backing file name and its mtime in the COW header, if you move the backing file, that information becomes invalid. So, the procedure for moving a backing file is
  • Move it in a way that preserves timestamps. Usually, this is a "-p" switch. "cp -a" works because "-a" implies "-p".
  • Update the COW header by booting UML on it, specifying both the COW file and the new location of the backing file
    host% ubd0=COW file,new backing file location
    UML will notice the mismatch between the command line and COW header, check the size and mtime of the new backing file path, and update the COW header to reflect it if it checks out.
If you forget to preserve the timestamps when you move the backing file, you can fix the mtime by hand as follows
host% mtime=whatever UML says mtime should be ; \ touch --date="`date -d 1970-01-01\ UTC\ $mtime\ seconds`" backing file
Note that if you do this on a backing file that has truly been changed, and not just moved, then you will get file corruption and you will lose the filesystem.
uml_moo : Merging a COW file with its backing file
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. This usage is

host% uml_moo -d COW file

uml_moo is installed with the UML deb and RPM. If you didn't install UML from one of those packages, you can also get it from the UML utilities tar file in tools/moo.

uml_mkcow : Create a new COW file
The normal way to create a COW file is to specify a non-existant COW file on the UML command line, and let UML create it for you. However, sometimes you want a new COW file, and you don't want to boot UML in order to get it. This can be done with uml_mkcow, which is a little standalone utility by Steve Schnepp.

The standard usage is

host% uml_mkcow new COW file existing backing file
If you want to destroy an existing COW file, then there is a -f switch to force the overwriting of the old COW file
host% uml_mkcow -f existing COW file existing backing file

uml_mkcow is available from the UML utilities tar file in tools/moo.

Hosted at SourceForge Logo