Looking back, I tend not to post about non-Perl geekery. This is clearly because I'm trying to impress you with all my Perl knowledge - what I don't know about Perl could, err, fit a big book. Moving quickly on, I've been playing with something which isn't Perl recently. I know, I know. In fact, most of it is quite low level and bits of it are in Python. I've been playing with the Xen virtual machine monitor.
Apart from sounding cool, it also does something quite useful. It allows one real computer to run multiple unreal (virtual) computers, which you can start, stop, pause and unpause. I reckon most software eventually reaches a level when it must be virtualised (clearly this is a stage after themes or sending mail), because the flexibility makes it so much more useful. Think of it as object indirection but for software packages.
While we hate software, it must also be remembered that software runs on hardware, and that it can be hateful too. Sometimes, hardware needs to be upgraded or fixed. Xen comes to the rescue by being able to save, restore and do live migration of virtual machines. Fab! No wonder systems people are excited about it. I've installed and played with it and I'm completely impressed (running Ubuntu under Ubuntu). I'm going to use it on my live systems. I'm going to use it to test software. I'm going to use it to, errr, do many things. It has two annoyances: migration requires a network file system (anyone built a good one yet?), and amd64 support isn't entirely there yet (those Opterons sure are shiny). Of course, user mode Linux does a similar thing, but check out the performance charts.
Looks like I'm a bit behind. gnat noticed xen in February and sky noticed a while ago too:
14:00also, why didn't you tell me that xen was cool 14:00 I did 14:00 I HAVE BEEN TELLING EVERYONE XEN IS REALLY FUCKING AWESOME 14:00 then why did i ignore you 14:00 I love xen 14:00 no idea 14:00 xen is cool 14:00 you suck 14:00 ;)
One of the big disadvantages to solutions that provide a hardware monitor, like Xen or UML or VMWare or Bochs and of course complete system emulators like QEmu, is that you lose a fair bit of speed in the overhead.
Now, the vendor of Xen or whatever might come up with some over-simplified number to express the best performance they've seen for a conveniently chosen set of tasks, relative to applications running in the host system. "85% of host speed", they will shout. But the fact is that in addition to this, you'll still end up running multiple copies of the kernel, each of which requires its own IP stack, disk buffers, etc. Not only that, but if you have the same executables (such as, I don't know, the C library) running in these beasts you're looking at a huge hit to the memory caching systems to achieve this virtualisation - unless it can re-invent shared executable files. This will impact the system in different ways depending on what you're doing with it.
On the other hand, virtualisation has been achieved for donkey's years by chroot(2) , which has been extended via FreeBSD's jails, Linux-vserver, and OpenSolaris containers (to name solutions for Free operating systems), for when all you really want is virtualisation of the UNIX environment, along with casual resource boundaries and/or protection from letting the root account control the hardware. Generally these solutions can be considered as efficient as if they were not there at all, and make it a lot easier to poke around and manage the servers from an administrative point of view.
But there is one thing for sure - in the virtual machine monitor section of the OS virtualisation market, Xen is fast becoming best of breed.
