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)

Remove VM swap file in ESXi 5.x

There may be specific scenarios where it is not desirable to have a VM swap file. In my most recent experience a customer was short on storage so wanted to save space occupied by the large VM swap files, which are equal in size to the memory allocation to the VM. As physical memory on the ESXi host was not over-subscribed this would not have negatively impacted the performance of the VMs .

To remove the VM swap files perform the following steps:

  1. In the vSphere client locate the VM, right-click on it and select Edit Settings.
  2. Go to the Resources tab and select Memory
  3. In the right-hand side check Reserve all guest memory (All locked) and click OK. The screenshot below shows this setting:

20130419130220

This setting reserves all 32GB of vRAM allocated to the VM on the ESXi host, and only if that memory is locked and guaranteed will that VM be able to power on.

Prior to making the configuration change the VM’s folder on the datastore contained a 32GB swap file:

/vmfs/volumes/514c4fc8-21030200-2f06-bc305bf615e3/VM1 # ls -al | grep vswp
-rw-------    1 root     root     34359738368 Apr 19 12:07 VM1-6d3a3a7d.vswp
-rw-------    1 root     root     119537664 Apr 19 12:07 vmx-VM1-1832532605-1.vswp

After locking the reserved guest memory, the swap file was zero-length, so occupied no storage space (0kb):

/vmfs/volumes/514c4fc8-21030200-2f06-bc305bf615e3/VM1 # ls -al | grep vswp
-rw-------    1 root     root             0 Apr 19 12:10 VM1-6d3a3a7d.vswp
-rw-------    1 root     root     119537664 Apr 19 12:10 vmx-VM1-1832532605-1.vswp

You can ignore the VMX swap file, above it is vmx-VM1-1832532605-1.vswp. These files are not related to ordinary host memory swapping but allow the swapping of the memory overhead associated with the VMX process. The ESX/ESXi host creates VMX swap files automatically when the VM is powered on, as long as there is sufficient free disk space. This is a new feature in ESXi 5.x and more info can be found here.

Note: Removing the swap file is not recommended in solutions where memory has been over-subscribed to VMs. Doing so precludes the use of and benefits VMware memory management techniques such as ballooning, TPS (transparent page sharing), memory compression and host swapping (in that order).