Inspired by Saltzer's classic End-to-End argument, as well as the original philosophy of the Xen Virtual Machine Monitor, described in Xen and the Art of Virtualization, and in Self-Paging in the Nemesis Operating System, we have implemented a Self-Migrating Linux Operating System on top of the Xen VMM.
See Jacob Gorm Hansen's home page for publications related to this project.
Operating System Migration is still a fairly new concept, and the common way of implementing it is as an external service, which will checkpoint a guest OS running atop a Virtual Machine Monitor, onto another host. However, in order to achieve good performance and low downtime, the migrating OS needs to cooperate in the migration, leading us to the conclusion that OS migration is better implemented inside the migrating OS. The migrating OS already has all the knowledge (access to pager and scheduler) and features (TCP stack) necessary, which means we can ultimately remove these from Trusted Computing Base, which is a good thing for security.
The current implementation is based on Xen, but the approach should generalize to other microkernels and VMMs as well.
Please see this page for the latest developments!
New: The latest unstable version, based on the upcoming Xen 3.0 and Linux 2.6, can be cloned with Mercurial/hg from here!
If you are interested in the Self-Migrating version of XenLinux, you will find the necessary files below. They are currently based on a Pre-NGIO version of Xen 1.3, and on XenLinux 2.4.26. To compile, you will also need a vanilla linux 2.4.26 source tree, see the Xen documentation for how to set up and compile XenLinux.
The tools you will need for Self-Migration are included in the
tools/migrate subdir of our version of the Xen package. There you
will also find a README.
Xen 1.3 source tarball, including a 'sparse' source tree of XenLinux 2.4.26: xen--migration--1.3--patch-110.tar.gz.
mstrap, the unprivileged domain for handling incoming migrations is now included in my Xen tarball (in extras/mstrap). The hardcoded limitations have been removed. The new ping-packet 'packet' server will, when presented with a correctly signed token, fire up an mstrap VM with specified IP and TCP port.
Precompiled Xen 1.3 and XenoLinux 2.4.26 binaries, along with mstrap and statically linked tools for self-migration: selfmig-bin.tar.gz.
domUinitrd.gz: Ramdisk(ext2 format, 3MB) which lets you play with self-migration without having to setup an NFS or iSCSI root.
dom0packet.gz: Ramdisk(ext2 format, 3MB) for running a 'packet' server in Xen Domain 0, into which you boot or migrate new domains across the network (only local network at this point). You need to give the IP address as ... evil_ip=220.127.116.11 at the end of the Grub command line.
Boot your domain with the ramdisk from above as initrd, and the correct ip=... parameters on the kernel commandline, and you should be able to telnet in as root, with password '123'. Fire up mstrap on a separate host, and use 'migrate' to migrate there. Right now, you need to tell mstrap it's IP address and port number as 32-bit hex values on the kernel command line, as in:
$ cat mstrap.cfg mem=4 kernel=/boot/mstrap ip= 18.104.22.168 (guest domain IP) ip2= 22.214.171.124 (mstrap's IP) cmdline=01020304 000004d2 $ create mstrap.cfg
... and in your unprivileged domain (where you just telnetted as root):
$ migrate 126.96.36.199 1234 (migrate to mstrap IP using port 1234, aka 0x4d2)