The State of Hypervisors: Meh

I've been dinking around with the various virtualization technologies: VMWare ESX, Solaris xvm, MS Hyper-V, and Ubuntu/Linux kvm (I still have VirtualBox on the todo list).

kvm and xvm, despite different underlying technologies, are pretty similar. They get the job done, but they aren't much fun to manage. The various crowds are making it better, everyday (eucalyptus, which uses Xen on Linux, is especially promising, but personally untested).

VMWare wins the management crown, hands down. Highly complex configurations, an abundance of tools, simple administration, and well-known in the industry.

They need to be doing a lot more, though. MS' Hyper-V 2.0 promises to have live migrations (a big selling point for VMWare), and is nearly as easy to manage. It won't take long for MS to catch up, and it is almost free with Windows.

Here's something that kills me for all of them, though. It can be difficult to move VMs from one version of the software to another version, which kills flexibility. If I want to run the VM on my laptop on a big fat server for awhile, moving it from the workstation version to the server was not simple.

It should be simple. I realize that if I wanted to do something similar on a large scale, I could do it by implementing some conventions and standards, with a bunch of scripts to hold it together. I'm lazy. That's the point here.

My Hypervisor Grail is this: a seamless transition from any hardware, to any hardware. At the moment, I'm whining about moving from my laptop to a server, but I'd like to be able to move it out to a cloud of some flavor also (right now, I'm using AWS EC2, and it is sufficient).

It would be super-cool if I could choose among images at boot, and have it backed up at shutdown, without the compromise of hard drive space and/or performance.

We're getting there, at least:

Xen 3.3 also contains a wealth of new features contributed by vendors collaborating in the new Xen Client Initiative (XCI), a Xen.org community effort to accelerate and coordinate the development of fast, free, compatible embedded Xen hypervisors for laptops, PCs and PDAs. The XCI is targeting three use cases: using Xen to run "embedded IT" VMs that allow remote support, security and service of PCs through embedded IT applications without any impact on the user's primary desktop OS;
"instant on" applications that can be immediately available as separate VMs from the user's primary desktop OS; and "application compatibility" VMs, which allow legacy PC applications to run as VMs, alongside the user's primary desktop OS. XCI member companies are already shipping Xen client hypervisors embedded in chipsets, PCs and laptops.

I think, for my next build-out, I'm going to try Eucalyptus on a server (sacrificing the Win2008 machine - good OS, but not as good as Solaris, which stays and gets big fat hard drives). I like the idea of being able to push VMs from inside the datacenter (okay, in this case, my closet) to the cloud.

MSBuild, and Cancelling Long Running Processes

I really like the syntax and organization associated with the various build tools for getting stuff done. I'd hoped to leverage those qualities to handle some system tasks - and I will, anyway.

I ran into a snag, though. If a task involves a long-running external process - say, robocopy'ing a large directory structure, killing the msbuild process doesn't kill the child process. Robocopy keeps on running, leading to a lot of cursing about how slow the network is until you notice it running two dozen times.

BTW, here's a powershell snippet to kill all robocopy processes:

get-process -Name robocopy | foreach-object { $_.Kill() }

Under normal circumstances, the runaway processes shouldn't be a problem. Under other circumstances, this could be a big deal.

MSBuild exposes its object model. It should be possible to either write a wrapper, or a better exec task. One way or the other, it isn't as cut and dried as I'd hoped.

SocketShifter - Redirect Sockets on Windows

A trick I've often used to get around firewalls is ssh port forwarding. Basically, after SSH connects to a server, you can get it to forward local ports through the tunnel to arbitrary ports on the other end.

So, if I connect from work to my ssh server listening on my home router, I can forward my local port 1000 (which isn't being used) to port 80 on one of my internal machines, and connect to that webserver via http://localhost:1000.

Windows servers don't have many good options for an ssh server. The only one I've used was the version that comes with Cygwin, and it wasn't really all that good (hangs, crashes, non-killable).

Introducing SocketShifter, an app that performs a similar magic, only on Windows.

But wait, there's more!

It uses something called the .NET Service Bus, an offering from Microsoft's Azure. This promises to allow two machines to connect, regardless of intermediate firewalls (and how do I prevent this?). It also means you have to sign up for an account in order to use it.

I'll be sticking with ssh, for now, but this service bus thing looks kind of interesting.

msbuildtasks - A collection of MSBuild Tasks (duh)

I'm starting to use MSBuild for some system-level stuff. I've been torn between that, NAnt, and Powershell for commonly executed admin tasks (backups, deploys, things like that).

The most tempting choice was PowerShell. It can do just about anything I'd need it to. That flexibility creates a problem, too: I don't want to have to maintain these things. If I use a full-featured language, then follow up maintainers will fall into two camps: the ones who add more complexity until it becomes too hard to maintain, and the ones who won't understand any of it at all.

I was a little jealous of NAnt, because it has matured very nicely. That has to be installed - never mind how easy - and needs to be justified.

Then I ran across msbuildtasks, from the same people who brought us Subversion. Lots of shiny stuff (I love it!) including tasks for IIS sites (I don't know if it does IIS7), a slew of build and deploy related tasks, SQL tasks, Registry tasks, and more.

Then I found the MSBuild Extension Pack, which is chock-full of shiny promise, too.

So, MSBuild is our winner (found a good tutorial, and yet another). It comes with .Net 2.0, which is installed anyway (okay, you have to copy those extensions, but that could be the first task :) ), it has the features I'm looking for, thanks to Tigris, and it is proven in the field. I'm sure it will suck, too, but at least I'll know how much and in what ways it sucks. If it doesn't work out, I'll look for something else.

Update: Despite the title of this article, I'm not even using the msbuildtasks package, yet. The MSBuild Extension Pack has a lot more goodies, and everything that I've needed so far.

Unattended, A Windows Deployment System

Unattended. From their site:

Features include:

• Automated install of operating system, hotfixes and applications.
• Full documentation and source code.
• Support for floppy, CD-ROM, and "nothing but net" installs.
• True unattended installation, not disk imaging.
• No Windows servers required; use your Unix servers instead.
• No Unix servers required; use your Windows servers after all.
• Completely free.

When you are finished setting up Unattended, you will be able to boot any PC from a floppy, from a CD-ROM, or directly from the network, answer a few questions, and come back an hour or two later to a fully-installed Windows workstation.

Update: I gave it a look-see, and it looks like it would be useful for Windows 2003, and that's about it. Considering deployments of that are dropping off of a cliff, it doesn't look useful.