CoNetrix

Blog: VMDK

I recently needed to move several VMDK files from a VMware datastore that had filled up due to an old snapshot. To move the first VMDK I used SSH to connect to the vSphere host, browsed to the datastore, and entered:

"cp –R /source/directory/ /dest/directory/"

to recursively copy the VMDK and snapshots to the new datastore. Because of the size of this VMDK this copy command took just over 24 hours to finish. Once it completed I unfortunately found that not only had the VMDK had been converted from thin provisioned to thick, but the snapshots had also ballooned to the size of the thick base disk.
 
It turns out that vSphere provides a much better way to copy VMDKs that will not only retain thin provisioning, but will also merge snapshots while copying. I used a command similar to the following to clone a VMDK:
 
vmkfstools -i "/vmfs/volumes/Datastore/examplevm/examplevm-000001.vmdk" "/vmfs/volumes/Datastore 2/newexamplevm/newexamplevm.vmdk" -d thin -a buslogic
 
The ‘-i’ flag tells vmkfstools that we want to clone the drive, the ‘-d’ flag specifies the disk type and the ‘-a’ flag specifies the storage adapter type (in this case SCSI with the BusLogic controller).
 
VMware has a KB on cloning VMDKs with vmkfstools, available here.

Networking, VMDK, VMware, ESX, snapshot,
 

I was setting up Backup Exec 12.5 to function as a VCB proxy to back up our VMs at a VMDK level and ran into a few problems. Version 12.5 has this functionality built in so it was fairly simple to back up a VM from the SAN to the VCB proxy. Restoring it back to the vCenter cluster, on the other hand, was a different story. The first problem I ran into was in running a simple restore. The job would fail as it would try and convert the machine. Simple fix: Install VMWare Converter Standalone on the proxy. [more]

Problem 2: The job would fail and give me a suggestion that I might try restoring the machine as a redirected restore job.

Problem 3: When I tried to set up the job for a redirected restore, I receive “Access is denied.” when it attempts to connect to the vCenter and datastores.

Solution: UAC was causing the access to be denied. If I started Backup Exec as an administrator or disabled UAC on the machine, I was able to get access to the datastores and set up the redirected restore. From there, my restore jobs were successful. Now I did run into other slight problems with this restore, but I’ll save that for another time.

Backup, Backup Exec, VMDK, VMware,
 

I’ve never been a fan of (nor seen much reason in) splitting VMDKs into 2GB chunks… though that is often the default setting when creating a virtual machine. However, the other day I found a pretty good reason. When you split your VMDK, VMware creates a single VDisk.VMDK meta file, and several VDisk-s001.VMDK files (which actually contain the data). The meta file is a pretty simple text file with contents that look something like this: [more]

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=9fb33447
parentCID=ffffffff
isNativeSnapshot="no"
createType="twoGbMaxExtentSparse"

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

# The Disk Data Base
#DDB

ddb.deletable = "true"
ddb.virtualHWVersion = "7"
ddb.toolsVersion = "8259"
ddb.longContentID = "0bdf39e8f7c80d6f09a431949fb33447"
ddb.uuid = "60 00 C2 9e da ee dc 72-7f ba f5 58 c8 a7 75 58"
ddb.geometry.cylinders = "3263"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

The nice thing about this is you can edit the paths to the SPARSE files. This can allow you to put the SPARSE files in a “template” directory for VM clones (preferably read only), then just edit the meta file to point to your template directory. Whenever you want to create a clone, just copy the meta file VMDK to the new VM directory, edit the paths (can be relative or full), and then snapshot your new clone (to make sure it doesn’t change the template files… which would break all your linked clones!).

Networking, VMDK, VMware,