Using Thin Provisioning for virtual disks of your VM can save you a lot of useful space on your datastore and significantly speed up maintenance tasks that involve copying or moving of the VMDK files. Apparently, switching from one provisioning format to another can be done easily via Clone Virtual Machine wizard, where Storage tab allows you to specify the virtual disk format for the cloned VM. There you can select either to keep the same disk format as source VM had or choose another one, including Thin Provision. However, the choice of Thin Provision disk format will be silently ignored when the source format is Thick Provisioned and both source and target are located in the same datastore. This behavior is somehow understandable when you think about the underlying implementation, but not user friendly.
So, how can you change the provisioning type of your VM from Thick to Thin anyway? Here is your algorithm.
- Do you have more than one datastore available? You can migrate your VM to another datastore, modifying the virtual disk provisioning mode on the way, and then migrate it back if needed. This way is covered in details in the second part of KB2014832 article on VMware Knowledge Base.
- Do you have only one datastore or all your datastores are under the same Storage DRS? You can create a clone of your VM with the help of vCenter Converter Standalone. This tool runs on your desktop and allows you to convert one VM format into another, changing most of the VM setting on the way. This includes change of disk provisioning type from Thick to Thin even when both source and destination are located on the same datastore.
- Do you prefer the hard and risky ways? If so, dealing with vmkfstools if for you 🙂
Some time ago I managed to isolate an ugly vSphere 5 bug that caused me some unpleasant moments. Today I finally reproduced this behavior in a clean lab environment, so I feel confident enough to describe it in public. Don’t worry, the way to recover is described also!
Take a vSphere 5 environment with a template (say, “MyTemplate”) that you want to deploy a virtual machine from. Step through a regular deployment wizard and select “Edit Virtual Hardware” on the last page. In the VM properties, choose the hard disk and change its size. The new VM (say, “MyVM”) will be created successfully, but the next time you’ll go through the deployment process it will fail with a strange message: “Unable to access file ‘MyTemplate/MyTemplate.vmdk’ since it is locked”…
A quick search in VMware KB (or just in Google) will tell you that the vmdk (the virtual disk of the VM) is usually locked when some other VM uses the same disk. Hey, this is a template! No other VMs are supposed to use the template disk, right? Well, the truth is that this disk is now attached to MyVM – yes, that one with different disk size… But let the lock alone. Your lovely template is now gone, since the disk that belonged to the template is now owned by the running virtual machine – with new name, settings and maybe even software!
Well, how do you recover from this situation? The good news are that the original disk from MyTemplate is not gone. In fact, vSphere really cloned a new vmdk file for MyVM and placed it where it should usually reside – in ‘MyVM/MyVM.vmdk’ – but for some reason set the MyVM to use a template file instead. At this moment you can take a deep breath, shut down MyVM, point it to the right virtual disk and physically swap the files in the datastore… Continue reading “Deployment of New VM from Template Fails with VMDK Locked Error”
Did it ever happen to you that you want to revert some VM to another snapshot and get “The object has already been deleted or has not been completely created” error message? It is really painful, especially if you lab heavily relies on excellent snapshot functionality provided by vSphere… It appears that sometimes it can be fixed by deleting the VM from the inventory and adding it back. The process is really simple, but requires administrative credentials.
So, here it goes:
- Go to the Summary tab for your VM, find the relevant datastore and choose “Browse Datastore…” option.
- Find the folder that belongs to your VM and make sure you see the “.vmx” file (you’ll need it in step 5).
- Go back to your VM in the vSphere tree and choose “Remove from Inventory” in the context menu. Be careful – “Delete from Disk” is the next option, and it is not reversible!
- Wait while vSphere performs your request.
- Go to datastore window, open context menu of the “.vmx” file and choose “Add to Inventory”
- Go through the wizard, selecting relevant options for VM import.
That’s all – wait until the VM will be fully imported and try to revert to your favorite snapshot now.