One of my users asked me for a VM last week to test out some demo software.  I created the VM and handed it off.  Later, he told me that something was wrong with the server because he couldn’t get his demo to run.  It turns out that the demo was provided as a zipped-up collection of virtual machine files.  The software vendor had instructed him to install VMWare Player, load up the files, and run it that way.  Of course, the VM I provided him wasn’t set up to run a nested player, so I told him to give me the files and I would load them up as a native (and un-nested) virtual machine.

The files were simply a bunch of VMDK segments, a .vmx, and some .vbs scripts to put it all together.  I have no idea how the files were packaged or why they weren’t deployed as an OVF.  An OVF would have allowed easy direct import into my virtualization environment.  Alas, I decided to simply upload the entire folder into a data store and see what would happen.  I imported the .vmx into the vCenter client and attempted to boot the machine and…it errored out:

Cannot open the disk ‘/vmfs/volumes/{datastore_path}/{vm_folder}/{vm_name}.vmdk’ or one of the snapshot disks it depends on.

Well, the file was definitely there, so I cracked open the .vmdk descriptor file to see this:

/vmfs/volumes/{volume GUID}/BASE3 # cat BASE3.vmdk
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=954745d4
parentCID=ffffffff
isNativeSnapshot="no"
createType="twoGbMaxExtentSparse"

# Extent description
RW 4192256 SPARSE "BASE3-s001.vmdk"
RW 4192256 SPARSE "BASE3-s002.vmdk"
RW 4192256 SPARSE "BASE3-s003.vmdk"
RW 4192256 SPARSE "BASE3-s004.vmdk"
RW 4192256 SPARSE "BASE3-s005.vmdk"
RW 4192256 SPARSE "BASE3-s006.vmdk"
RW 4192256 SPARSE "BASE3-s007.vmdk"
RW 4192256 SPARSE "BASE3-s008.vmdk"
RW 4192256 SPARSE "BASE3-s009.vmdk"
RW 4192256 SPARSE "BASE3-s010.vmdk"
RW 4192256 SPARSE "BASE3-s011.vmdk"
RW 4192256 SPARSE "BASE3-s012.vmdk"
RW 4192256 SPARSE "BASE3-s013.vmdk"

Ah….  These are sparse disks, which are not supported in my ESXi 5.1-based infrastructure.  Guess we’ll have to convert it!  In this case, I’m going to convert directly to thin-provisioned using vmkfstools:

/vmfs/volumes/{volume GUID}/BASE3 # vmkfstools -i BASE3.vmdk BASE3-thin.vmdk -d thin

And…it failed.  Oh, yeah, I have to load the multi-extent module since it’s not included in 5.1 by default:

/vmfs/volumes/{volume GUID}/BASE3 # vmkload_mod multiextent

I ran my clone command again and ten minutes later I had my brand new thin-provisioned volume.  Success!  Just delete the old sparse .vmdk files and power the machine on.

This command will clone the disk into a new thin-provisioned .vmdk.  I chose to give it a new name just in case something went wrong.  You could easily clone it to a different directory and use the same name.  Because it has a new name, I then had to go into the VM settings and remove the old hard disk and add a new one that pointed to the new .vmdk.  You can also do it by manually editing the .vmx file.