vDR – causing problems…
For those new to vSphere 5's GUI, there's a new column that's been added to the Virtual Machine view by the name of "Needs Consolidation".
This option was put in due to the occasional problem when Snapshots did not delete properly and would leave the delta files remaining in the VM's folder while the Snapshot Manager would show no snapshots existing.
With this option added to the columns, you should also take note of the option within the Snapshot options for each VM which will now allow a user to select the "Consolidate" function
As noticed with the first screenshot, we had a couple systems which were requiring some consolidation to them. So another admin went through and hit the consolidated button and got hit with a "Unable to access file
I still decided to dive into the CLI and check it out. I was stunned...
18 deltas... 18! Regardless of the vmsn file in there, there was no record of there being any snapshots.
In this case, that system probably hasn't even been rebooted 18 times much less been snapshot that many times... Except, vDR (VMware Data Recovery) is setup on it to do daily snaps. So I checked the vDR appliance settings and I found 8 disks too many attached.
After removing all of those extra hard disks, the consolidations would succeed. Note, it took a while, but they did succeed.
Just another reminder of while vDR is a great tool to have on hand, it should definitely not be the one and only method of backup




10 GHz Total CPU
16 GB Total RAM
7,578 GB Total Disk
1 Host(s)
1 RPs
8 VMs
0 vMotions
(4)
(4)
(0)
3 Physical NICs
3 Virtual PGs
April 26th, 2012 - 12:25
Also, if you let vDR run long enough (failing every night, creating lots of those delta files), you will get to a point where you vSphere 5 host will simply disappear from the cluster view (disconnected). While you can still manually connect to that specific vSphere host, you won’t be able to add it back to the cluster (in vCenter) as it will fail with “Unknown communication error with vpxa agent” – giving timeout errors in the logs.
Finding which VMs has all those un-consolidated vmdk is left to the sysadmin, but your solution will fix it… I’ve also had to create and delete a snapshot for all of them to be gone from the disk, as I didn’t knew about consolidate option and I didn’t saw them in snapshot view. In my situation, they weren’t being used by the VM.