Man, this has been a nightmare. For the time I've wasted trying to get this working again, i could have purchased a new Windows machine.
I ended up having to completely delete Fusion and the old virtual disk, then reinstall everything from scratch. I finally got it to a working state, and tried to "Take Snapshot". It takes the snapshot, then says, "Unable to clean up deleted files: The specified virtual disk needs repair."
I went into the Windows C: > Tools > Error-checking and ran the dskchk
I went to Mac OSX's Disk Utility and repaired permissions, and verified that the disk has no errors.
I went to Terminal, and typed in:
/Applications/VMware Fusion.app/Contents/MacOS/diskTool -f /Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional.vmdk
and also:
/Applications/VMware Fusion.app/Contents/MacOS/diskTool -f
/Users/username/Documents/Virtual Machines.localized/Windows XP
Professional.vmwarevm/Windows XP Professional-000006.vmdk (I have several of these, all of varying sizes!)
and got, "-bash: /Applications/VMware: No such file or directory"
{I think that Terminal doesn't like the space in the filename "VMware Fusion.app". Is that it? Is there a %20 or similar that can be used to represent a space in a filename?}
I checked the log, and it says:
Mar 11 23:00:24.095: vmx| SNAPSHOT: Consolidating from '/Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional-000006.vmdk' to '/Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional.vmdk'.
Mar 11 23:00:24.215: vmx| DISKLIB-SPARSECHK: GT Error (ZG): [261] 0/13310592
Mar 11 23:00:24.215: vmx| DISKLIB-SPARSECHK: Resolving [261] = 13310592
Mar 11 23:00:24.461: vmx| DISKLIB-SPARSE: "/Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional.vmdk" : failed to open (15): Disk needs repair.
Mar 11 23:00:24.461: vmx| DISKLIB-DSCPTR: Failed to open extents for embedded descriptor file in normal mode
Mar 11 23:00:24.461: vmx| DISKLIB-LINK : "/Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional.vmdk" : failed to open (The specified virtual disk needs repair).
Mar 11 23:00:24.461: vmx| DISKLIB-CHAIN : "/Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional.vmdk" : failed to open (The specified virtual disk needs repair).
Mar 11 23:00:24.461: vmx| DISKLIB-LIB : Failed to open '/Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional.vmdk' with flags 0x18 (The specified virtual disk needs repair).
Mar 11 23:00:24.461: vmx| SNAPSHOT: SnapshotCombineDisks failed: 5
Mar 11 23:00:24.461: vmx| SNAPSHOT: SnapshotConsolidate failed 5
Mar 11 23:00:24.461: vmx| SNAPSHOT: Consolidate failed 5
I repaired my registries in Windows.
Is there some precedural or syntax error I am making?
Thank you.
No, sorry a typo - they are both 0c0b
Thanks,
Ed Buchwalter
Principal Engineer
Binary Systems
2233 102nd Place S.E.
Bellevue, WA 98004
tel: 425.503.9741
fax: 425.452.8448
eeb@binary.com
--"Fusion supports only one snapshot, you should not be getting chains of 4 or 7 (or anything more than 1) child disk."
Well, obviously that's not true, as we are getting multiples. I think this happens with some form of crash... it gets lost, and retains the others.
When I was able to rebuild the chain, the extras disappeared, and were re-absorbed into the main snapshot.
--"Fusion supports only one snapshot, you should not be getting chains of 4 or 7 (or anything more than 1) child disk."
Well, obviously that's not true, as we are getting multiples. I think this happens with some form of crash... it gets lost, and retains the others.
I'm not saying it doesn't happen (obviously it does), just noting that this is unusual and unexpected.
Ed,
I think it's time for womeone at VMware to chime in here, as this seems to be a prevalent problem for us users.
If they don't chime in, I would not do anything until you at least BACK UP those files. Then, i would try rebuilding the chain. Here is what you have:
{base - cid e4b5bf3e - pcid fffffff} -> {
0002 cid c1499bb0 pcid e4b5bf3e} -> {
0001 cid e0708592 pcid c1499bb0} -> {
0003 cid f9df0c0b pcid e0708592} -> {
0004 cid 00452146 pcid f9df0c0b}
NOTE: I do not understand the spawning process here, but i'm guessing that 0002 should not come before 0001. I think those filenames are given chronologically, but linked via the CID's, so therein lies the corruption.
I would try (after making duplicates!) swapping out the CID and parentCID's between 0001 and 0002. That would make a valid chain:
{base - cid e4b5bf3e - pcid fffffff} -> {
0001 cid c1499bb0 pcid e4b5bf3e} -> {
0002 cid e0708592 pcid c1499bb0} -> {
0003 cid f9df0c0b pcid e0708592} -> {
0004 cid 00452146 pcid f9df0c0b}
NOTE 2: I am not talking about changing their filenames... I mean to go into the hex editor and exchanging the CID and parentCID's in 0001 and 0002, so their internal pointers link to the files created in chronological order.
NOTE 3: I do not know what i am talking about. I am just a user like you. I had to gamble on editing these things to fix my error, and it worked. Following my advice here is also a gamble.
Well, OSX-XP, since you seem to have authored the de facto standard format for diagnosing this problem, and I'm sure we're not the only ones going down this path, let me reformat my CID numbers from above and see what you think. And I took to heart your backup suggestion.
{base - cid 20efc093 - pcid fffffff} -> {
000004 cid 1b172b62 pcid 8a63e8d1} -> {
000003 cid 8a63e8d1 pcid 581ard72} -> {
000002 cid f576fe32 pcid 8a63e8d1} -> {
000001 cid 581afd72 pcid f576fe32}
Thanks
--Roy
hello,
fusion-mac 1.1.3 (94249) - multiple snapshot files due to running out of space trying to 'delete snapshot'. I use 2gb split files ("of course") and the chains all checked out. diskTool -x showed a-ok on all but the 'original' ( un-numbered ) disk file which showed scary errs - which somehow were fixable by -f.
To clear the snapshots, what I did was:
- start the guest up again
- stop it at a 'simple' spot early in the boot with not much happening (in this case, the GRUB bootloader, but the built in bios would probably work)
- took a snapshot
- deleted that snapshot
logfile showed: Jul 09 22:14:04.454: vmx| DISKLIB-LIB : Combine 4 links at offset 0 in chain 0x9f57d4.
and indeed, it ground away for about 20 min, and then combined the 4 disk files (original, + 000001, +000002, +000003) back into the original.
hope this helps. thanks for the pointers contained in this thread.
in my case, the id chain is correct, even though the same error message is returned after Take Snapshot using VMware Fusion 1.x.x on Mac OS X.
the solution is as follows:
install VMware 2.x.x (beta)
look in vmware.log for .vmdk files that need repair
run the command on .vmdk files needing repair:
/Library/Application\ Support/VMware\ Fusion/vmware-vdiskmanager -R Windows\ XP\
Professional-00000x.vmdk
after which Snapshot operations should be OK.
I have been receiving the same "Unable to clean up deleted files: The specified virtual disk needs repair." message whenever I try to take a snapshot. I have posted my question her a few time before and have never had a reply. I am running Leopard on a IMac/2.4GHz/4 GB memory, I am running WinXP on the VM. Is my problem answered here? If so where exactly would I begin to make the repair? My computer programming knowledge is not that sophisticated, I really need step by step instructions! Is there anyone that can help me out?
Thanks,
Todd
Not a complete guide, but if anyone else is still reading this thread:
0. quit fusion and back up your entire virtual machine
1. run the Terminal.app program (Applications/Utilities)
2. Type in:
/Library/Application\ Support/VMware\ Fusion/vmware-vdiskmanager -R /xsrl/vm2/GenToo.vmwarevm/GenToo.vmdk
Where the part in bold is the path to your vmdk file that needs repair. You can just type a space after the "-R" and then drag the vmdk file into the terminal window, and it will type in the path.
I just saw the post from srl; I just deleted a snapshot, after which I received an error message stating "unable to clean up deleted files" or something similar. Now disk cleanup does not complete and I cannot change the size of the drive.
On a Mac OS X Sierra (macOS) machine running VMWare Fusion 8.5 I got the same error.
To identify the damaged file I ran the following command from within Terminal:
find "/Users/<userid>/Documents/Virtual Machines/<name of VM>/" -name "*.vmdk" -type f -exec "/Applications/VMware Fusion.app/Contents/Library/vmware-vdiskmanager" -e '{}' \;
This command finds all the .vmdk files in a VM and then runs the vmware-vdiskmanager command against them individually.
One of the files reported:
Failed to open the disk '/Users/<userid>/Documents/Virtual Machines/<name of VM>/<damaged file>.vmdk' : The specified virtual disk needs repair (0x3e86).
This file was repaired using the "-R" flag on vmware-vdiskmanager:
"/Applications/VMware Fusion.app/Contents/Library/vmware-vdiskmanager" -R /path/to/damaged.vmdk
The virtual disk, '/path/to/damaged.vmdk', was corrupted and has been successfully repaired.
I was then able to Clean Up and start the VM normally.
Reference:
"/Applications/VMware Fusion.app/Contents/Library/vmware-vdiskmanager" --help
/Applications/VMware Fusion.app/Contents/Library/vmware-vdiskmanager: illegal option -- -
VMware Virtual Disk Manager - build 4352717.
Usage: vmware-vdiskmanager OPTIONS <disk-name> | <mount-point>
Offline disk manipulation utility
Operations, only one may be specified at a time:
-c : create disk. Additional creation options must
be specified. Only local virtual disks can be
created.
-d : defragment the specified virtual disk. Only
local virtual disks may be defragmented.
-k : shrink the specified virtual disk. Only local
virtual disks may be shrunk.
-n <source-disk> : rename the specified virtual disk; need to
specify destination disk-name. Only local virtual
disks may be renamed.
-p : prepare the mounted virtual disk specified by
the volume path for shrinking.
-r <source-disk> : convert the specified disk; need to specify
destination disk-type. For local destination disks
the disk type must be specified.
-x <new-capacity> : expand the disk to the specified capacity. Only
local virtual disks may be expanded.
-R : check a sparse virtual disk for consistency and attempt
to repair any errors.
-e : check for disk chain consistency.
-D : make disk deletable. This should only be used on disks
that have been copied from another product.
Other Options:
-q : do not log messages
Additional options for create and convert:
-a <adapter> : (for use with -c only) adapter type
(ide, buslogic, lsilogic). Pass lsilogic for other adapter types.
-s <size> : capacity of the virtual disk
-t <disk-type> : disk type id
Disk types:
0 : single growable virtual disk
1 : growable virtual disk split in 2GB files
2 : preallocated virtual disk
3 : preallocated virtual disk split in 2GB files
4 : preallocated ESX-type virtual disk
5 : compressed disk optimized for streaming
6 : thin provisioned virtual disk - ESX 3.x and above
The capacity can be specified in sectors, KB, MB or GB.
The acceptable ranges:
ide/scsi adapter : [1MB, 8192.0GB]
buslogic adapter : [1MB, 2040.0GB]
ex 1: vmware-vdiskmanager -c -s 850MB -a ide -t 0 myIdeDisk.vmdk
ex 2: vmware-vdiskmanager -d myDisk.vmdk
ex 3: vmware-vdiskmanager -r sourceDisk.vmdk -t 0 destinationDisk.vmdk
ex 4: vmware-vdiskmanager -x 36GB myDisk.vmdk
ex 5: vmware-vdiskmanager -n sourceName.vmdk destinationName.vmdk
ex 6: vmware-vdiskmanager -r sourceDisk.vmdk -t 4 -h esx-name.mycompany.com \
-u username -f passwordfile "[storage1]/path/to/targetDisk.vmdk"
ex 7: vmware-vdiskmanager -k myDisk.vmdk
ex 8: vmware-vdiskmanager -p <mount-point>
(A virtual disk first needs to be mounted at <mount-point>)