A client using ESX 3.5u3 had a VM that used a disk file from another defunct (but usable) VM. The defunct VM was finally deleted but the disk descriptor file was trashed in the process. I'm assuming that the only reason the flat VMDK file was still there was because it was in use by the second VM.

After restarting the second VM, it could no longer access or see the first VMs disk file. Looking in the Datastore Browser showed that the VMDK file was still there; what's going on?

The Datastore Browser hides the fact that there are two parts to the virtual disk. The first part is a small file called VMDisk.vmdk and the second part is a large file called VMDisk-flat.vmdk. The first file holds the drive characteristics and geometry, such as sectors and heads. The second file should be the size of the disk as the VM OS sees it.

In this case, the smaller file had been deleted and so the VM couldn't figure out how to address the virtual disk.

Here are links to two very helpful VMwareKB articles:

• Recreating a VMDK header file
• Verifying ESX virtual machine file integrity

The first link has the magic on how to recreate a standard header or descriptor file that should match your flat VMDK file. The second link is a good refresher on the file system parts of your VMs.

For this client, I created a new blank VMDK using the -thin option to save on space, deleted the larger VMDK disk file and renamed the smaller VMDK file to match the existing VM disk file.

I also commented out the existing UUID line in the descriptor file when cleaning it up. I've had issues with UUIDs not matching on Ubuntu VMs and didn't want to hit them here.

After that, the VM started up perfectly.

A client wanted to set up a backup solution for their VMware environment. My preference on the backup software itself was Vizioncore's vRangerPro software, but I couldn't immediately name a storage device. I've played with the Buffalo Terastation and I have a Netgear ReadyNAS NV+ for my home storage but they both are lacking horsepower being that they are just larger NAS devices.

Another blog pointed out the arrival of the ix4 series from Iomega, which is now owned by EMC, which also owns a large chunk of VMware. Nice synergy, right?

So, not only will the client get a storage device that is built well, supports rsync for offsite replication and offers a good chunk of storage, but they'll also have a DR-worthy pair of devices to use if needed. A thread on the VMware forums seems to support using one of these to run several, if not a dozen, somewhat demanding VMs via iSCSI or NFS mounts. Nice bonus.

The only disappointment is expected: I was hoping for block-level replication, not file-level. I know rsync is file-level, but I was hoping that some of EMC's data de-dupe functionality would trickle down and make the periodic full backups easier to handle.

Update: So much for good testing. The ix4 does support block-level replication, so only the changed portion of a file gets pushed across. Serves me right for using entirely different contents for a file of the same name. Don't do this at home, folks.

I give in.

I've been running a few virtual machines in Server 2.0 on Ubuntu 9.04 on my Lenovo T500 laptop. It worked well enough when it was working. However, getting Server installed on the 64-bit version of Ubuntu requires some serious manual tweaks. I'd get it working fine, then the tempting offer of an update would cause me to break my instance.

<sigh>

Recompile, move files, cross fingers, get Server running again.

I don't have a real hope that moving to the supported/non-free version of VMware will really fix the issues given what I see in the VMware forums, but the fixes do seem to be easier to deal with.

I'll have to see if Windows 7 seems stable. I'd originally moved to Ubuntu on the perception that it would actually allow me to reliably control my hardware.