Cloning a VM in ESXi 5.x standalone hypervisor using vmkfstools

If you run ESXi 5.5 hypervisor in a standalone setup and not managed by vCenter you do not have the ability to clone a VM via the GUI. Any VM that is managed by vCenter can be cloned by simply right-clicking on it and selecting Clone, per the below:

20150606002506

When you have spent many man hours configuring a VM, it’s guest OS and the applications that run within it, it makes no sense re-doing all the same work if you need to deploy a new server that will run the same applications and perform the same role. This is one of the main reasons cloning a VM is such as useful feature. My current setup contains only 1 x Centos VM called lnx-svr-01.vsysad.local, per the below:

20150606001634

As you can see, the clone option is not available in the GUI:

20150606001753

The aim here is to clone lnx-svr-01.vsysad.local and create new VM called lnx-svr-02.vsysad.local. So I will clone the existing  VM via CLI using vmkfstools to produce the new one. So to proceed perform the following steps:

1. Shutdown he VM you are going to clone, in my case this is lnx-svr-01.vsysad.local.

2. Connect to the ESXi hypervisor via ssh.

3. Browse the datastore that contains the VM folders, the datastore in question here is hyp1-local-1:

~ # ls /vmfs/volumes/hyp1-local-1/
ISO lnx-svr-01.vsysad.local
Imports vmkdump
~ #

As you can see from the above the only VM folder is lnx-svr-01.vsysad.local because it’s the only one I have running on this hypervisor at the moment.

4. Create a new folder called lnx-svr-02.vsysad.local. This is where our new VM is going to reside on the datastore. To do so run:

~ # mkdir /vmfs/volumes/hyp1-local-1/lnx-svr-02.vsysad.local

Then run ls to verify it has been created:

~ # ls /vmfs/volumes/hyp1-local-1/
ISO lnx-svr-01.vsysad.local vmkdump
Imports lnx-svr-02.vsysad.local
~ #

We can see from the output that a folder called lnx-svr-02.vsysad.local has been successfully created.

5. Now list the contents of the folder lnx-svr-01.vsysad.local by running:

~ # ls /vmfs/volumes/hyp1-local-1/lnx-svr-01.vsysad.local
lnx-svr-01.vsysad.local-dabdb809.vswp
lnx-svr-01.vsysad.local-flat.vmdk
lnx-svr-01.vsysad.local.nvram
lnx-svr-01.vsysad.local.vmdk
lnx-svr-01.vsysad.local.vmsd
lnx-svr-01.vsysad.local.vmx
lnx-svr-01.vsysad.local.vmx.lck
lnx-svr-01.vsysad.local.vmxf
lnx-svr-01.vsysad.local.vmx~
vmware-1.log
vmware.log
vmx-lnx-svr-01.vsysad.local-3669866505-1.vswp

We can see all the VM files above. The one we are going to copy is called lnx-svr-01.vsysad.local.vmx.

6. Copy lnx-svr-01.vsysad.local.vmx to the folder lnx-svr-02.vsysad.local we created in step 3 above by running:

~ # cp /vmfs/volumes/hyp1-local-1/lnx-svr-01.vsysad.local/lnx-svr-01.vsysad.local.vmx /vmfs/volumes/hyp1-local-1/lnx-svr-02.vsysad.local/lnx-svr-02.vsysad.local.vmx

Notice that we are copying it and renaming it to lnx-svr-02.vsysad.local.vmx.

7. Next, we use the vmkfstools command to clone the virtual hard disk (vmdk) of lnx-svr-01.vsysad.local into a new vmdk. If you look back at step 4 you will see the file called lnx-svr-01.vsysad.local.vmdk – we will clone this file into a new one called lnx-svr-02.vsysad.local.vmdk located in the lnx-svr-02.vsysad.local folder we created in step 3. To proceed, I run the following:

~ # vmkfstools -i /vmfs/volumes/hyp1-local-1/lnx-svr-01.vsysad.local/lnx-svr-01.vsysad.local.vmdk /vmfs/volumes/hyp1-local-1/lnx-svr-02.vsysad.local/lnx-svr-02.vsysad.local.vmdk -d zeroedthick

You will see the following output:

~ # vmkfstools -i /vmfs/volumes/hyp1-local-1/lnx-svr-01.vsysad.local/lnx-svr-01.vsysad.local.vmdk /vmfs/volumes/hyp1-local-1/lnx-svr-02.vsysad.local/lnx-svr-02.vsysad.local.vmdk -d zeroedthick
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/hyp1-local-1/lnx-svr-01.vsysad.local/lnx-svr-01.vsysad.local.vmdk'...
Clone: 10% done.

Eventually it will complete successfully:

~ # vmkfstools -i /vmfs/volumes/hyp1-local-1/lnx-svr-01.vsysad.local/lnx-svr-01.vsysad.local.vmdk /vmfs/volumes/hyp1-local-1/lnx-svr-02.vsysad.local/lnx-svr-02.vsysad.local.vmdk -d zeroedthick
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/hyp1-local-1/lnx-svr-01.vsysad.local/lnx-svr-01.vsysad.local.vmdk'...
Clone: 100% done.
~ #

Please note the option -d zeroedthick that I run in the vmkfstools command. I wanted the disk to be created as zeroed thick, you can change this option to thin if you want it to be thin provisioned. More options are listed on this VMware KB article.

8. So at this stage, we have a new folder called lnx-svr-02.vsysad.local that contains three new files:

~ # ls /vmfs/volumes/hyp1-local-1/lnx-svr-02.vsysad.local/
lnx-svr-02.vsysad.local-flat.vmdk lnx-svr-02.vsysad.local.vmdk
lnx-svr-02.vsysad.local.vmx
~ #

We copied the lnx-svr-02.vsysad.local.vmx file and lnx-svr-02.vsysad.local.vmdk was created by the clone process. But you’ll notice a third file, lnx-svr-02.vsysad.local-flat.vmdk. This is the actual virtual disk that contains the data, lnx-svr-02.vsysad.local.vmdk is a descriptor file that simply points to it. The clone process created this file also.

9. The next thing we need to to is edit the lnx-svr-02.vsysad.local.vmx file using vi. I am making an assumption that you know how to use vi to edit files. If you don’t, see this link, which covers the basics. To do so, run:

~ # vi /vmfs/volumes/hyp1-local-1/lnx-svr-02.vsysad.local/lnx-svr-02.vsysad.local.vmx

Find any string that contains lnx-svr-01.vsysad.local and change it to lnx-svr-02.vsysad.local. So in my case the following lines were changed:

nvram = "lnx-svr-02.vsysad.local.nvram"
displayName = "lnx-svr-02.vsysad.local"
extendedConfigFile = "lnx-svr-02.vsysad.local.vmxf"
scsi0:0.fileName = "lnx-svr-02.vsysad.local.vmdk"
sched.swap.derivedName = "/vmfs/volumes/55627693-62f7625a-65ce-a82066349979/lnx-svr-02.vsysad.local/lnx-svr-02.vsysad.local-15fdf1aa.vswp"

Save the changes made to lnx-svr-02.vsysad.local.vmx.

10. So we are now ready to register our VM. Run this command to register it:

~ # vim-cmd solo/registervm /vmfs/volumes/hyp1-local-1/lnx-svr-02.vsysad.local/lnx-svr-02.vsysad.local.vmx

In the vSphere Client you will see the corresponding task:

20150606083412

And BOOM! There it is in your inventory:

20150606125246

A couple of points to mention:

When you power the VM on you will see the following question:

20150606083914

Check I Copied It and click OK and the VM will power on OK.

The next thing to mention is that you should make sure the new VM being powered on doesn’t cause an IP conflict with the VM it was cloned from. If the original VM has a static IP configured then an IP conlfict will ensue by powering on the new/cloned version. So to avoid this, disable the NIC in the VM settings of the new/cloned VM, by un-checking Connect at power on, like so:

20150606083727

Then you can power on the VM, login to the console, re-IP it and then check Connected and Connect at power on in the VM settings. Those actions will avoid causing an IP conflict and potential havoc on your network.

Reference:
Cloning and converting virtual machine disks with vmkfstools (1028042)
Registering or adding a virtual machine to the inventory on vCenter Server or on an ESX/ESXi host (1006160)

High I/O on VM causes clone to fail

When creating a hot clones of VMs that have high I/O you may encounter the following error:

Cannot create a quiesced snapshot because the snapshot 
operation exceeded the time limit for holding off I/O in the 
frozen virtual machine

This is s common issue when trying to perform clones of very busy production servers such as SQL Server or Exchange Server. As these applications perform constant reads/writes the usual quiescing function (when initiating a clone or snapshot  fails to flush all of the operations to disk. Below is an example of this error when trying to hot clone a very busy Exchange server:

A quick and dirty fix if you simply want to clone the VM is to stop the VMware Tools Service on the guest and then re-run the clone. It should complete OK. This basically bypasses the quiescing of the file system and produces a crash-consistent clone:

VMware KB article 1018194 highlights this issue and prescribes various fixes depending on your circumstance.