VMware titles its interm releases as “Update 1″ or “Update 2″, etc. But in vSphere client, the version is displayed with a build number. And in the VMware HCL, the versions are displayed using the “Update” number.

Trying to make sense of this can be difficult, but luckily Virten.Net (@viFlorian) has an ESXi Release and Build Number History page which helps make sense of it all.

On a related note, if you need to decipher a SQL Server build number and relate it to version and service pack, check out SQLServerBuilds.

Recently had a situation arise where a stand-alone ESXi 5 host that was not managed by vCenter (it’s standalone, get it?) needed one of its VMs cloned, but the source VM was important and could not be powered off for a cold-clone to be performed.

Thanks to VMETC.COM’s Cloning a running Virtual Machine using the Service Console, (who gives credit to Eric Siebert), the process is pretty simple, and really just uses vmkfstools to make a copy of the source VM’s disk after a snapshot has been created. This frees up the source VM’s disk(s) for reading by vmkfstools to make a copy.

1. Create a new VM with identical settings as the source VM
   1. Memory
   2. CPU
   3. Disk (SCSI controller, etc)
   4. Network
      1. Set the NIC to not connect at startup, and change the portgroup assigned to a vSwitch with no other guest VMs or physical uplinks, in order to isolate it so it does not interfere with the source VM.
2. Using the vSphere client connected to the host, take a snapshot of the source VM – do not include guest memory. Name the snapshot whatever you’d like.
3. Now that a snapshot has been taken, the source VM is writing to its delta disk and not its main disk (still reads from it though) so it can be cloned using the command line.
4. SSH to the ESXi host (or get on the ESXi host console) and navigate to the new VM’s directory and delete the vmdk files: rm *.vmdk
   1. This clears the way for the disk copy to be succcessful, but keeps the disk registration in the new VM’s vmx configuration file.
5. Navigate to the source VM directory and use vmkfstools to clone the disk: vmkfstools -i sourceVM.vmdk -d thin /vmfs/volumes/datastore01/newVM/newVM.vmdk
   1. This will create a thin-provisioned (-d thin) copy (-i) of sourceVM.vmdk from the source VM’s directory to the newVM’s directory (/vmfs/volumes/datastore01/newVM).
6. Clone any other disks
7. When the clone is finished, power it on (making sure it’s on an isolated portgroup with its NIC disconnected)
   1. The OS will act like it was hard-powered-off so it may do some disk checks at boot in order to mark the filesystem as clean.
8. Open up the console of the VM and change its IP address and hostname and anything else that would conflict with the source VM.
9. Once done, connect it back to the appropriate portgroup and you should be all set!
10. Don’t forget to remove the snapshot on the source VM!

The process is incredibly simple and much faster than spinning up a win2k8 instance with a demo instance of vCenter, just to make a clone of a VM. It’s also easier than using VMware Converter to do a V2V conversion.

If using this method to clone a Windows guest, there may be some extra work involved (such as re-joining to the domain, etc).