Xen is a Linux-based “virtual machine monitor”. This is an idea that is familiar to anyone who has used systems like the IBM System 390, in which the monitor software is used to divide up one single, large, physical machine into many smaller ones. This can be done for many different reasons, including testing, multi-platform package building, and hosting. Xen is extremely cool.
While VMWare offers a product which has similar results, that software is extremely expensive. To the tune of around 3 kilobucks. Long ago we had looked at using the VMWare server product to be able to offer less expensive “virtual dedicated hosting” to our clients, but with the cost of the software we figured that we'd have to purchase a very expensive system to have the huevos to handle enough virtual machines to make it less expensive than dedicated systems.
Several years ago, we started doing this virtual dedicated hosting using User Mode Linux. User Mode Linux (commonly called “UML”, probably just to conflict with the Universal Modeling Language) is a port of the Linux kernel to run under an existing kernel. So, you can run the kernel as just an executable, and point it at files or devices for it's root file-system, etc. It works pretty well, but has fallen into disrepair over the last year. It's included in the mainline kernel, but that version has had a lot of problems. The Sourceforge page has had patches to fix it, but the most recent patch there is from August for the 2.6.8 kernel. We also ran into scalability problems with it, but that may have actually been driver issues on the host system.
Over the last several weeks, I've been evaluating and switching systems over to Xen-based virtual machines. It's been going quite smoothly. Xen is working very well, and has lots of features which help out in an environment where you have many machines. It includes several different schedulers for giving different virtual machines fair pieces of the main machine, for example.
The way Xen works is that you boot a machine monitor, and have that monitor load your “xen0” privileged kernel. From this kernel you can access the system itself, and start up the virtual machines. These kernels are called “xenU”, and you can easily run 2.4 and 2.6 kernels under the privileged kernel. There's also a version for NetBSD which you may be able to run under a Linux host system. You allocate some small amount of memory for the host kernel, and the rest is available for the virtual machines.
So, on the host you would create the virtual machine root file-systems and the like, then you create a configuration file for the host listing things like how much memory it gets, if it uses DHCP or has a static IP, what kernel it uses, and more. Then you start the kernel. You can gain access to that systems console, or you can access it via the network if you have it configured properly to bring up the network when the virtual machine starts.
Xen also includes a “Balloon” driver which is supposed to allow you to shrink or grow the memory usage of a running virtual machine, but I've never seen that work. I haven't played with this much, but it includes support for suspending the kernel to the disc, and then resuming it at a later time. For example, if you had to reboot the host machine…
There's also a “live migration” mode where it will essentially move this a running system to another physical machine, with the system being unreachable for only a fraction of a second. Of course, this requires that both hosts be able to access the virtual systems back-end storage. That can be problematic unless you architect for that up front.
I found it extremely handy a couple of weeks ago when I was developing the vPostMaster packages. I built a script that created 20 virtual disc images and started up 20 virtual machines, each running a stock Fedora Core 3 install. Then I'd log into one, run tests of the install process, and if there were any problems I'd just delete that virtual machine and log into one of the other remaining hosts. Sped up my testing quite dramatically.comments powered by Disqus