I recently had the need to ‘prep’ a VM after converting it to vSphere. By ‘prep’ I mean (after you’ve installed VMware tools) do the usual grind of updating the virtual hardware to the latest supported by ESXi, update the vNIC to VMXNET3, and change the SCSI controllers to ParaVirtual. I thought about the times when I was in customer land and we would have to convert VMs from some other platform or in some cases, correct a VM that had been built incorrectly.
Note: A bit more testing on my end has found this script is only valuable if your VMDKs are on separate datastores. I am working to find a better metric to pull the data per VMDK. Background Have you ever heard of “Uncommitted Space” in vSphere? It’s one of those things we all seem to ‘know’ without really knowing. It’s a pretty standard metric most commonly found against vSphere Datastores. It’s effectively calculated based on the provisioned and used storage of a datastore and its contents.
Introduction We all know the immense pain of managing Windows Server VM templates, regardless of the platform you’re using. Sure, you can build them once then update them manually on a schedule. However, it’s tedious to document and even worse to execute, making sure the template is identical every time (except for your new updates of course). In my experience, you also have to maintain multiple versions and editions of Windows Server.