If it was locked by an ESXi host the MAC of the host would be shown in the owner readout above – all zeros indicates no R/W lock. vmdk “meta” files) are not so you need to check all the files individually: In the interests of completeness a cat of the other VMDK ( VM.vmdk ) showed the following were referenced:Ĭheck if the vmdk files are locked by any hosts, -delta, -ctk and -flat files should be locked when in active I/O use, descriptor files (just the.
We are interested in the two sections from above “Extent description” and “Change Tracking File”, from the above we can see the reference VMDKs files are: So this gives us all the vmdks mounted by the VM – we can then cat these files to check what underlying files on the datastore they reference (I have done one of the two disks as an example): To investigate further we can find out what vmdks are mounted by the vmx for that particular VM:
The first step is to snapshot the VM above and then run delete all to see if VMware can clear them all down – re-run the check above, if they still exist it is quite possible they are orphaned. So we’ve done all the above, don’t fancy doing a V2V to sort this as it shouldn’t really be a problem in the first place.įirst step is to find all snapshots and delta disks on the datastores:Īs you can see above there are 5 snapshot/tracking/vmdk files that are orphaned and we need to investigate.
#Download vmdk file from datastore flat manual#
To take care of these is quite a manual process after you have followed all the VMware KB advice: I have come across a number of environments where mystery “snapshot” files exist – they are not seen in snapshot manager, running a consolidation them doesn’t help, creating a snapshot (with memory, or guest OS quiescing) then running “Delete All” doesn’t resolve it, but some applications still think a snapshot is there.
0 kommentar(er)
