etc/init.d/hostd restartįollowing a successful restart of the hostd service, re-run the snapshot consolidation. Now the host has been identified, place in Maintenance Mode and restart the Management Agent/host daemon service (hostd) via the below command. Resolve the Locked VMDKs and Consolidate the Disks The MAC address shown in the above output can be used to identify the ESXi host via vSphere. We are specifically interested in the ‘RO Owner’, which (in the below example) shows both the lock itself and the MAC address of the offending ESXi host (in this example, ending ‘f1:64:09’). vmkfstools -D /vmfs/volumes/volume-name/vm-name/locked-vm-disk-name.vmdk Next, we need to identify which ESXi host is holding the lock on the vmdk by using vmkfstools. File lock errors, detailed via the hostd.log, should be fairly easy to identify, and will enable you to identify the locked vmdk.
In my instance, the file-lock error detailed in the Storage vMotion screenshot above is confirmed via the hostd.log output (below), and clearly shows the locked disk in question. Keep an eye on the hostd.log output while the snapshot consolidation task attempts to run, as any/all file lock errors will be displayed. While the log is being displayed, jump back to either the vSphere Client for Windows (C#) or vSphere Web Client and re-run a snapshot consolidation ( Virtual Machine > Snapshot > Consolidate). To do this, SSH to the ESXi host hosting the VM in question, and launch the hostd.log. Identify the Locked FileĪs a first step, we’ll need to check the hostd.log to try and identify what is happening during the above tasks. Storage vMotion attempts fail, identifying the locked file. Manual attempts at consolidating snapshots fail with either DISKLOCKED errors… …and/or ‘’ errors. So, how do we identify a) the locked file, b) the source of the lock, and c) resolve the locked vmdks and consolidate the disks? Disk consolidation required. A larger and slightly more pressing concern that arose (due to the size and amount of delta disks being held) meant the underlying datastore had blown it’s capacity, taking a number of VMs offline. As a result, a number of virtual machines reported disk consolidation alerts and, due to the locked vmdks, I was unable to consolidate the snapshots or Storage vMotion the VM to a different datastore. In my case, this was due to a failure of a Veeam Backup & Replication disk backup job which had, effectively, failed to remove it’s delta disks following a backup run. A reoccurring issue this one, and usually due to a failed backup.
0 kommentar(er)
