Posted by January 16, 2012on
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…
Here are more detailed instructions, just to be on the safe side:
- Shut down MyVM (either from the OS or via the Power options of the VM)
- Point MyVM to the cloned virtual disk (one under ‘MyVM’ folder):
- Open ‘Edit Settings’ dialog of MyVM
- Find the hard disk that points to ‘MyTemplate/MyTemplate.vmdk’
- Write down the virtual device node of the hard disk
- Remove this hard disk from the VM
- Add new hard disk, use existing ‘MyVM/MyVM.vmdk’ and device node you wrote down earlier
- Click ‘OK’
- Log in with SSH to the ESX box that has access to the datastore where MyTemplate and MyVM reside
- Swap the data files for ‘MyTemplate.vmdk’ and ‘MyVM.vmdk’:
- Move ‘MyVM/MyVM-flat.vmdk’ to ‘MyTemplate/MyTemplate-original.vmdk’
- Move ‘MyTemplate/MyTemplate-flat.vmdk’ to ‘MyVM/MyVM-flat.vmdk’
- Move ‘MyTemplate/MyTemplate-original.vmdk’ to ‘MyTemplate/MyTemplate-flat.vmdk’
- Power on MyVM
UPD (Jan 2012): It appears that the issue is not new in vSphere 5 – it exists at least since ESX 3.5 (back in 2008). I wish this post was higher in the search results when I originally looked for explanations…
UPD (Nov 2013): VMware claims that the bug that the disk size modification bug was fixed in vSphere 5.0U2 and 5.1U1. I did not have a chance to check this yet.