An error occurred while consolidating disks msg fileio lock

12 Apr

You can check this very easily in the settings of the backup server: All crossed the disks are the remnants of failed backups.

Just delete them to drive consolidation was completed correctly.

That MAC Address represents the MAC of a network adapter of the ESXi Host that the problem VM lock originates from. the Host holding the lock on the problem VM’s vmdk.

Hi All, Case: #00510773I thought I'd share some information regarding an issue we've been experiencing since moving to ESX 5.5 and Veeam 7 R2a.

Both solutions, Veeam and VDP, use the same method.

an error occurred while consolidating disks msg fileio lock-76an error occurred while consolidating disks msg fileio lock-54

Tried creating and deleting snapshot - succeeded, but didn't allow me to consolidate snapshot 3. The clone had consolidated disks, but didn't want the outage of switching VMs, plus the hassle of new mac address on the cloned VM with ghost v NIC issue. 2) Trying to delete them from Data Store browser doesn't work. Shouldn't be as the file is empty and the disks referenced as active by the VM is no longer the delta VMDK. I hope this helps someone avoid an outage for their VMs.

I hope this will help anyone who has same issues with consolidating VM disks.

One of the appliances failed to backup a VM last night.

I then specifically looked at the error for this VM in the backup job (“Error: Failed to open VDDK disk datastore-name] VM-directory/VM-name-000014.vmdk] ( is read-only mode – [true] ) Failed to open virtual disk Logon attempt with parameters [VC/ESX: [vcenter-name]; Port: 443; Login: [domain\user]; VMX Spec: [moref=vm-101]; Snapshot mor: [snapshot-17944]; Transports: [nbd]; Read Only: [true failed because of the following errors: Failed to open disk for read. v Center again returned an error: This was better information because it let me know the explicit disk (the parent vmdk & not any of its subsequent deltas) that was locked.After a bit more digging through Google and some VMware KB’s (specifically, these 2 posts – and ), I was able to lock down what object/device had a lock on the VM.Background: We've been running Veeam for just shy of 4 years.Our Veeam server was a 2008R2 box and it backed up a 3 host ESX 5.1 cluster. in the region of 8TB large (although using a bunch of 2TB VMDK's).To find the lock, open an SSH session to the ESXi Host the problem VM currently resides on then run this command: vmkfstools -D /vmfs/volumes/48fbd8e5-c04f6d90-1edb-001cc46b7a18/VM-directory/, gen 336, links 1, type reg, flags 0x0, uid 0, gid 0, mode 100600 Take note of the text after the word “owner”, specifically the red highlighted text above.Those 12 digits represent a MAC Address and that is the key. This originating problem was caused by VADP backup. Haven’t you ever attempted some operation on a v Sphere VM – VMotion, disk consolidation, etc.

]]