VMware often leaves behind orphaned vmdks after snapshots are deleted. There is no clear way to consolidate this into the main vmdk file from the gui. But by googling around, it appears that people are fixing this by cloning a virtual machine.
But there is a much better and less intrusive method. Internally, vmware clones a virtual machine by using vmware-vdiskmanager.exe, which can be found in the vmware installation directory. It appears that the following command will consolidate the snapshot in the vmdk to a different one (beware, it does not accept paths containing spaces, and will give some spurious error messages).
"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -r main-000002.vmdk -t 0 C:\test.vmdk
The story should’ve ended here, but vmware-vdiskmanager.exe gave me a spurious error message:
Failed to convert disk: One of the parameters supplied is invalid (0x100003e80).
Googling this gave me dozens of dozens of problems associated with this generic error message. But vmware-vdiskmanager.exe does in fact have logs, located in the %temp%\vmware-%username%. Scrolling through these logs, vdiskmanager.log. Scrolling through this, some less generic but not any less confusing error message showed up:
DISKLIB-LIB : DB: incorrect set operation 'consolidateDestFileName' = '(null)'.
DISKLIB-LIB : Failed to clone : One of the parameters supplied is invalid (1).
DISKLIB-LIB : DB: incorrect set operation 'resumeConsolidateSector' = '(null)'.
DISKLIB-LIB : Failed to clone : One of the parameters supplied is invalid (1).
The fields referenced by the error isn’t documented anywhere at all. However, by looking at the snapshot vmdk’s using a hex editor, it appears that these are internal settings within the vmdk files. consolidateDestFileName should point to the main vmdk file, but was missing in the snapshot vmdk file vmware-vdiskmanager.exe choked on. Copying this into the snapshot vmdk file seemed easy enough, but I had no idea what resumeConsolidateSector meant.
Fortunately, it appears that these fields can be restored by creating a new snapshot in vmdk and deleting it. vmware-vdiskmanager.exe finally started working correctly, and I managed to consolidate my snapshots.
> There is no clear way to consolidate this [orphaned vmdk's]...
ReplyDeleteWell, the simplest way is to create another snapshot and delete it immediately, and then VMware starts up consolidation automatically.
It looks as if VMware removes snapshots from the "list" as soon as it begun writing the snapshot sparse files into the base file. From that moment on the base file is not valid anymore (it already contains a part of the snapshot), but the combination base file plus snapshot file still is.
The other day when attempting to do such compaction I got an error "The requested operation could not be completed due to a file system limitation.". Apparently this message translates to "A heavily fragmented file in an NTFS volume may not grow beyond a certain size" - which wordings were probably to difficult for Windows QA. Defragging the disk fixed the problem indeed.
Before doing that consolidation, and due to the said "limitation" error, I had tried to clone the disk. However, I got a "Cloning failed: One of the parameters supplied is invalid." very soon. This is an excerpt of the log I found:
DISKLIB-DSCPTR: "Y:\Virtual Machines\Andre380XP-5\andre380 C+D-cl1.vmdk" : creation successful.
...
DISKLIB-LIB : DB: incorrect set operation 'consolidateDestFileName' = '(null)'.
FILE: FileDeletionRetry: Non-retriable error encountered (Y:\Virtual Machines\Andre380XP-5\andre380 C+D-cl1.vmdk): The system cannot find the file specified (2)
DISKLIB-LIB : Failed to clone : One of the parameters supplied is invalid (1).
OBJLIB-FILEBE : FileBEOpen: can't open 'Y:\Virtual Machines\Andre380XP-5\andre380 C+D-cl1.vmdk' : Could not find the file (393218).
So it created a file which moments later it could not find... (yes, the three paths in the log are really identical).
When the above compaction was done I tried "Clean Up Disks" and it promised me to free another bunch of memory. I had an identical copy of that VM on another disk, so I expected the same message for that VM. However VMware said "This VM does not have any virtual disks that can be cleaned up". The log revealed that the copy VM was still looking for an old snapshot which was compacted earlier!! Completly stopping and restarting VMware was the cure.
Andre
I had stupid strange errors with a VM.
ReplyDeleteFirst, I had set it up with 40 GB, then, after a while, I increased the disk size to 80 GB - all thin provisioned on a SSD. Again after a while I checked the folder the VMs resides in and noticed I had three VMDK files, all together almost 130 GB total size. What?! Though the settings of the VM's hard drive showed everything correctly I wasn't able to do anything that would help.
Within the VM (XP SP 3) I cleaned up the disk space, did a defrag. Outside I tried this for the VM within VMware Workstation (the software I run the VM in), couldn't compact because of general disk space issues, but at least I could defrag. But this wouldn't help, the file size remained the same.
Then I did a manual file copy / merge, or at least I tried. The process created a new thin provisioned file but I wasn't able to run this because the disk seemed not to be consolidated in any way so I couldn't use it.
Also I could neither clone nor export the VM to a single file, I copied all files to an external hard drive and tried to register it with my ESXi host I'm also running at home. Nothing worked. I tried two different versions of the VMware Converter, but they stopped the conversion each at 1%. That was not very satisfying because not a single error message pointed to a specific (or at least helpful) direction. Also I changed the Workstation version from 11 to 12 - same error.
Eventually I created a snapshot on the powered off VM. This, as it is normal, took a few seconds. After that I immediately removed the snapshot file without changing anything on the VM -- and this suddenly took like 15 minutes. Even if nothing has changed, at all, the directory was cleaned up and I got rid of the additional VMDK files. Now, due to thin provisioning, the file size is app. 30 GB and all is back to normal. It could have been so easy if I had just tried that snapshot thingy before ... well, lesson learned!
I followed the command line and created a new set of files for my image. It reduced my 150GB set of files down to 75GB which I what I required (and expected). But how to I point to the new image? I copied the .vmx file but it still points to the old image. I have tried editing it, but I seem to keep running into errors. How do I create a new .vmx file to point to the new image? I'm using VMWorkstation version 11.1.
ReplyDeleteYou saved my life! Thanks!
ReplyDeleteI thought this was a pretty interesting read when it comes to this topic. Thank you
ReplyDeletedrive-snapshot-crack