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.
Jan 31, 2017 - Execute the following to shut down your Windows Server VM and leave it powered off for cloning: sysprep /generalize /shutdown. Vmkfstools -i. Vmkfstools command offers the ability to clone the contents of VMware virtual machines(VM) from (.vmdk ) disk format to another without the help vCenter. This To change the virtual machine disks from one type to another, you must perform the following steps: 1.
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. 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. 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 : vmkfstools -i /vmfs/volumes/InternalSSD/”Windows 2012 r2 Template”/”Windows 2012 r2 Template0-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/InternalSSD/Windows 2012 r2 Template/Windows 2012 r2 Template0-000001.vmdk’ Clone: 100% done. 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 ( ).
Recently we had a weird issue in our office. We had one virtual machine with a snapshot. That by itself isn’t an issue, a snapshot is nothing special. But someone created that snapshot before a software upgrade and forget to delete it. So this snapshot was growing and growing. We found out that there is a snapshot when the VM or service owner requested some additional disk space.
We weren’t able to add disk space because of that snapshot. So we scheduled a maintenance window to delete the snapshot. Faster said than done.
The VM went offline because of disk consolidation. That could happen, depending on snapshot size and storage system. But the VM not only went offline for some time, but unexpectedly for hours. Together with VMware support we were able to stop the snapshot deletion. The VM came back online but with the known “Disk Consolidation Needed status”. We found out that this snapshot was about 400 GB in size.
![Vmkfstools Vmkfstools](http://blog.mrpol.nl/wp-content/uploads/2013/10/100913_1510_VCAP5DCAObj2.png)
What a bummer! So we scheduled another maintenance window to consolidate that snapshot. Unfortunately that didn’t work well. Consolidation timed at around 96%, not sure why. “Error communicating with the host” isn’t very helpful in that moment. Some research and again having a chat with VMware support led us towards cloning the disk files. During the cloning of a disk file the snapshot will be consolidated.
And as you’re doing a disk clone locally on the ESXi host with “vmkfstools” and not withing vCenter, there shouldn’t be a timeout either. So we had out action plan. And we scheduled another maintenance window with the service owner.