Sure, there are many ways to make a copy of an OS or VM and spin it up in another instance.

But here is the proper way…

with vSphere at least.


I’m assuming you already have basic knowledge of templating and wiping the system’s unique identifiers (sysprep for windows, etc)

When  you have a VM crafted in the way that you like, with all the software installed or just simply up-to-date with Windows Updates and of course, past the installation.

The proper way to clone a VM in my opinion is to use the vmkfstool on the ESXi host itself. This can be used through the ESXi shell or SSH to the host.

You will use this tool to make a copy of the virtual hard drive, and later attach that new virtual hard drive to a new virtual machine you configure to spec. You make this the same way you would make any other VM, but instead of adding a new hard disk you attach one that already exists.

Let’s say for Windows Server 2012R2 we want to make a template.

In CMD, change directory to ../system32/sysprep

Execute the following to shut down your Windows Server VM and leave it powered off for cloning:

sysprep /generalize /shutdown /oobe

I will not go into detail about how this behaves other than you will end up with a template-able virtual hard disk.


Now that our VM is off,

we should SSH or console into our ESXi host. I’m running vSphere 6.5 but this should work on most versions.


You’re going to make a new directory on a datastore. Call it what you like:

I was working on a project, so here’s what I did:

mkdir /vmfs/volumes/CRUCIAL/11101-RDBRK02


For you and your environment, replace what is necessary including the brackets:

mkdir /vmfs/volumes/<your-datastore>/<choose-a-name>


Now change directory to your VM that you just powered off, or include that as part of the path in this next bit.


I’m going to clone the 11101-PRNT01.vmdk virtual disk to another file/folder.

This OS on the volume was sysprepped etc.

vmkfstools -i /vmfs/volumes/ULTRA/11101-PRNT01/11101-PRNT01.vmdk /vmfs/volumes/CRUCIAL/11101-RDBRK02/11101-RDBRK02.vmdk -d thin


It’s important to note the last bit -d thin

  • while optional, is definitely recommended unless you know what you are doing and why.
  • If you thin provisioned your disk originally, leaving that part out will cause it to thick provision and you could take up a lot of space quickly.

Here’s what you’ll do:

vmkfstools -i /vmfs/volumes/<your-datastore>/<your-vm-folder>/<your -vm-folder>.vmdk /vmfs/volumes/<your-datastore>/<your--new-vm-folder>/<your-new-vm-folder>.vmdk -d thin


you’ll see an output like this:

Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/ULTRA/11101-PRNT01/11101-PRNT01.vmdk'...
Clone: 10% ..


And eventually it will finish.


Now you can attach this virtual hard drive to a new virtual machine and boot it directly into the state you cloned it–with new unique identifiers.


For consistency, I ensure I’m creating the new VM on the datastore I cloned to (when I have more than one datastore) so all the files pertinent to that VM end up in one location.

When creating your new VM, do this exactly how you would any normal VM but this time delete the “New Hard Disk” and attach an existing hard disk. Browse your datastore and select the cloned disk.

Alternatively, you can preserve this clone as a template and continue to clone from that source until you make a new template.

In summary, here’s how I copied the hard disk of 11101-PRNT01 to 11101-RDBRK02, maintaining the thin provision, so I could attach it to a new instance.


The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
[root@localhost:~] mkdir /vmfs/volumes/CRUCIAL/11101-RDBRK02
[root@localhost:~] vmkfstools -i /vmfs/volumes/ULTRA/11101-PRNT01/11101-PRNT01.vmdk /vmfs/v
olumes/CRUCIAL/11101-RDBRK02/11101-RDBRK02.vmdk -d thin
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/ULTRA/11101-PRNT01/11101-PRNT01.vmdk'...
Clone: 100% done.



Baz Curtis · September 29, 2017 at 1:26 pm

A very helpful article. The only issue I have is the disk that is made comes in as thick. It was thin provisioned and the CLI says it is going to be thin. What have I missed? I am taking the clone from a snapshot

[root@localhost:~] vmkfstools -i /vmfs/volumes/Internal_SSD/”Windows 2012 r2 Template”/”Windows 2012 r2 Template_0-000001.vmdk” /vmfs/volumes/USB-Datastore/”Windows 2012 r2 Template”/”Windows 2012 r2 Template.v
mdk” -d thin
Destination disk format: VMFS thin-provisioned
Cloning disk ‘/vmfs/volumes/Internal_SSD/Windows 2012 r2 Template/Windows 2012 r2 Template_0-000001.vmdk’…
Clone: 100% done.

    scott ernest · October 18, 2017 at 12:33 am

    I have the same problem/outcome. The destination disk says it is to be “thin-provisioned”; yet, when I go to attach it to the new VM, I see that it is thick. Not sure what to do. Any ideas?

      scott ernest · October 18, 2017 at 12:53 am

      Well, I wrote too soon. Sorry. Refreshing the VM after setting up, the disk now says it is “Thin-Provisioned”. Not sure what’s up with that; but, I got what I wanted. Thanks for the instructions. Other than this little hick-up, it all went perfectly. Thanks, again.

        Baz Curtis · October 18, 2017 at 1:15 am

        That is interesting. It is strange, but my FTP client shows the full disk size, but if I browse to the store ESXi shows the thin size. I think it is working fine. Thanks for the blog post.

ptsapralis · August 4, 2017 at 7:50 am

Thanks for this post. Q: what happens to the source VM? In the first step of this procedure, we execute the “sysprep” utility to render the source VM “template-able” and then it shuts down automatically. When I power it up again, does it work like before? Do I need to do something to get it back into original shape (before “sysprep” execution)? What if the source VM is joined into an AD domain? Is it still joined after cloning is completed and I power it up again?

    Tyler Woods · August 11, 2017 at 9:56 am

    It’s not common practice to boot the source VM back up, unless it is to make a change and then sysprep/shutdown and clone again.

    It sounds like you are talking about sysprepping a VM that is already a production VM and then returning it to its original state which isn’t really recommended as the original VM won’t function the same after it boots back from sysprep. You should use this as a guide to create a new template rather than sysprepping one of your existing VMs.

    The importance of this article is to point out how to clone the virtual hard disks so they can be attached to a new VM. Sysprep is meant to provide you with a pre-configured windows environment that you can clone and boot whenever you want to create a new Windows VM, instead of running through the install process each time. Booting the source VM back up will cause you to configure the OS and you won’t be able to clone it again without another sysprep.

    More info about sysprep can be found on Microsoft Docs site (–generalize–a-windows-installation )

      ptsapralis · August 13, 2017 at 8:57 am

      Tyler, thank you very much for this reply – it clarifies thing very well.

Leave a Reply