For the past year and a half we’ve been running one VMware product or another. We started with VMware Workstation and Server, and while Workstation proved to be (and continues to be) an invaluable tool, Server just wasn’t cutting it. I had used Server 1.x at home to host a few virtual servers without any issues for the better part of a year. Server 2.x, however, which we used at the office, was a nightmare. To those not too familiar with VMware’s products, Server is a Windows (or Linux) application hypervisor. It is just like Microsoft Virtual Server. You install Windows on the hardware, install VMware Server, then install virtual machines on top of VMware Server. For a server with enough horsepower and that is not running any critical applications, installing VMware Server on top seems like a great way to break into the virtualization world.
Not so much, we found, with VMware Server 2.x. The way virtualization works is that hard drives are stored as a single container file, 1 per virtual hard drive (from here on out referred to as “VMDK”). Over the course of a number of months when we ran Server, we had a number of instances, on both machines that were running Server, where the VMDK files would become corrupt (multiple files at a time) and render the VM useless. Not only that, but VMware Server would not start the services necessary to run or manager the VMs when it detected these corrupt files. This was a bug in the software; there were no problems with the physical hard drives. After dozens of hours of trial and error, I came up with a method of recovering the corrupt VMDK files and rescuing the contents to a new, useable VMDK. After a while, we finally had enough, and moved on to ESXi.