Keeping ahead of Skewed Time
This isn’t to say that the initial configuration process wasn’t without its foibles: while vSphere would happily see the Dell’s RAID as its data store, there seemed to be a minor snagette about actually booting from it.
As with almost everything that vexes people about VMware, the answer is easy to find if you’re a fully signed-up participant in the VMware Communities experience, and have the patience to wade through pages of web forum chat on your way to a post that may (or may not) contain the answer. It turned out we needed a minor version-number increment (or skew?) of the vSphere Installer, whereupon things settled nicely.
Those with long memories may recall an early promise that hypervisors as small as those from VMware would be best booted from solid-state storage on the server motherboard, and so servers have been shipping with USB ports on the inside with this trick in mind. Unfortunately, it’s so difficult to tell good USB keys from seriously bad ones in the current market, we’d chickened out of that option.
We didn’t move the VMs with an instant click of the mouse, we actually reconverted them
Our other crucial decision, it seems, was the means we chose to move the VMs from the old server to the new. Just taking an approximate view, there were three major version numbers and a complete hypervisor architecture change between the old host and new (from server 1.06 for Windows to 4 standalone based on custom Linux).
Tellingly, if you run the latest version of VMware Converter and go part way through a conversion, a dialog appears that requires you to choose the target format for the VM you’re making – and version 1.x is in an entirely different category from 3.5 and later.
Real World war stories
So despite what you might conclude from a quick scan of the publicity material, we didn’t move the VMs with an instant click of the mouse, we actually reconverted them.
There will be a couple of other Real World Contributors who will snort to hear that: there are all sorts of other ways to move from one virtual host to another, ranging all the way from instant SAN pointer-shifting through to equally instant, but subtly different, third-party utilities that keep different instances of a virtualised machine in sync. Not to mention the wide gap in versions. So I took advantage of the war stories in the VMware community forums and installed Converter on the (already converted) guest VMs.
You can get dragged a little too deeply into these war stories. There are people on there claiming to have cracked how to run a Linux VM host as a guest inside a Windows host (the kind of party chat that can clear a room of eligible women in a heartbeat). There are people who seem to spend their weekends building storage-optimised Beowulf clusters, or at least writing about doing so.
But Converter is the silver bullet among VMware utilities. It slips in as a slim system service and works very much like those old backup agents we used to have for tape backup software – it looks around the machine it’s loaded on, grabs a snapshot copy of everything it can see, and deposits it somewhere useful.
In this particular case, “somewhere useful” was directly into the data stores on the vSphere 4 server across the network, which cut out any intermediate external drives or recopying. That’s no bad thing with a chunky 50GB Exchange message store moving between VM file formats.