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.
OK... found the syntax problem...
Terminal doesn't like the spaces in the paths, so I escaped them with the backslash:
/Applications/VMware\ Fusion.app/Contents/MacOS/diskTool -f /Users/username/Documents/Virtual\ Machines.localized/Windows\ XP\ Professional.vmwarevm/Windows\ XP\ Professional.vmdk
Now, I get the following response:
Disk needs repair
Disk has scary/unexplainable errors
Failed to open disk '/Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional.vmdk' : Failed to lock the file (16392).
Any ideas on how to repair this? This has been very frustrating.
Thanks.
Further...
Running -S, I get:
Sanity testing...
test 0.
test 1.
test 2.
test 3.
test 4.
test 5.
test 6.
passed.
Failed to open disk '/Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional.vmdk' : Failed to lock the file (16392).
Running -x :
Disk is error free
Failed to open disk '/Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmwarevm/Windows XP Professional.vmdk' : Failed to lock the file (16392).
So, is it some sort of 'lock' problem?
Was this vm created with Fusion (and not imported from ESX, WS etc)?
Is this virtual machine on Mac OS X internal hard disk? Or if in an external one, could it be in an NTFS formatted one by any chance? I haven't seen this particular error with Fusion (but with other software yes), and among the things to verify would usually be the permissions (755) and ownership for the files... if this occurs on an NTFS formatted volume it would not surprise me since OS X can have rw but not rwx access to the volume - therefore whatever needs to be removed would fail for the -x part.
This vm was created with Fusion. It is on the OSX hard drive. I believe it is NTFS format.
I restarted my machine. Now... I cannot open the vm. I get this ridiculous message:
"Canoot open the disk 'Users/username/Documents/Virtual Machines.localized/Windows XP Professional.vmware.vm/Windows XP Professional-000007.vmdk' or one of the snapshot disks it depends on.
Reason: The parent virtual disk has been modified since the child was created."
Please help! I have very important work in my Windows vm.
Incidentally, a 30 day support time frame from vmware is ridiculous. Chances are, you'll run into problems like this outside of 30 days, and not even know what the problem is. This is crazy! I've seen others in this discussion area have had the same problems.
I just downloaded the hex editor 0xED. Opening my "Windows XP Professional-000007.vmdk" file, I see:
Disk DescriptorFile
version=1
CID=d68a51e9
parentCID=0f2affac
createType="monolithicSparse"
parentFileNameHint="Windows XP Professional-000006.vmdk"
Extent description
RW 62914560 SPARSE "Windows XP Professional-000007.vmdk"
The Disk Data Base
#DDB
ddb.toolsVersion = "7362"
Is the problem that the CID and parent's CID don't match? Is there an easy fix?
When I open "Windows XP Professional.vmdk" in the hex editor, I don't see a CID.
Here are the others, 000006 through 000001:
Disk DescriptorFile
version=1
CID=0f2affac
parentCID=4f68007f
createType="monolithicSparse"
parentFileNameHint="Windows XP Professional-000005.vmdk"
Extent description
RW 62914560 SPARSE "Windows XP Professional-000006.vmdk"
The Disk Data Base
#DDB
ddb.toolsVersion = "7362"
-
Disk DescriptorFile
version=1
CID=4f68007f
parentCID=f84b6fae
createType="monolithicSparse"
parentFileNameHint="Windows XP Professional-000004.vmdk"
Extent description
RW 62914560 SPARSE "Windows XP Professional-000005.vmdk"
The Disk Data Base
#DDB
ddb.toolsVersion = "7362"
-
Disk DescriptorFile
version=1
CID=f84b6fae
parentCID=70ff3ee4
createType="monolithicSparse"
parentFileNameHint="Windows XP Professional-000003.vmdk"
Extent description
RW 62914560 SPARSE "Windows XP Professional-000004.vmdk"
The Disk Data Base
#DDB
ddb.toolsVersion = "7362"
-
Disk DescriptorFile
version=1
CID=70ff3ee4
parentCID=6f72c929
createType="monolithicSparse"
parentFileNameHint="Windows XP Professional-000002.vmdk"
Extent description
RW 62914560 SPARSE "Windows XP Professional-000003.vmdk"
The Disk Data Base
#DDB
ddb.toolsVersion = "7362"
-
OK, I was able to get the CID from the base vmkd file:
Disk DescriptorFile
version=1
CID=d978680a
parentCID=ffffffff
createType="monolithicSparse"
Extent description
RW 62914560 SPARSE "Windows XP Professional.vmdk"
The Disk Data Base
#DDB
ddb.toolsVersion = "7362"
ddb.adapterType = "buslogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "3916"
ddb.virtualHWVersion = "6"
-
So, I see that the CID of the base vmdk file is d978680a. From "000001.vmdk":
Disk DescriptorFile
version=1
CID=f2b91b5b
parentCID=9fce9787
createType="monolithicSparse"
parentFileNameHint="Windows XP Professional.vmdk"
Extent description
RW 62914560 SPARSE "Windows XP Professional-000001.vmdk"
The Disk Data Base
#DDB
ddb.toolsVersion = "7362"
So, "000001.vmdk is calling for a parentCID of "9fce9787", while the CID od the base vmdk file is "d978680a". I take it that is the problem.
Can I just change the CID of the base "Windows XP Professional.vmdk" file in 0xED and save it? Then, the parentCID->parent's CID chain will be good from 0000007 back through the chain to the base file.
Thanks!
SOLVED! Here was the fix:
Opened all the vmdk files in 0xED (a hex editor). Followed the chain of CID's / ParentCID's to see that each called the next, in descending order (000007->000006->...base.vmdk).
My 000001.vmdk called for a parentCID that was different from the CID of the base vmdk. I edited the parentCID in 000001.vmdk and saved it.
Then, I was able to boot up, and was even able to run a clean snapshot, with it cleaning up and deleting the necessary files.
Let's hope I have a stable system again, as this was extrememly frustrating!
Yep, what you did was the right thing for fixing a CID chain problem. It's come up more often in the Workstation subforum. Note that if you had used split disks, you wouldn't need a hex editor to make the edits since the disk descriptors would be plain text files.
As an aside, it's strange that you have 7 snapshot disks, you should have at most one (since Fusion only supports a single snapshot, and any new ones should merge the old ones back to the base disk).
I think I ended up with 7 because of the 'unable to delete' errors I was getting last night, before running the disk repair utility.
Now, I just have one.
But this is still HIGHLY UNSTABLE, and frustrating the heck out of me!
Is there some instability with DirectX and Fusion 1.1? Sometimes my program works, and sometimes I get some 'cannot load' errors, when trying to load a video file. I am tired of registering/unregistering/installing/uninstalling files to try to get something stable. It acts like some sort of video codec instability.
Trying: DirectX, DirectShow, Klite codecs, etc.
Is there some instability with DirectX and Fusion 1.1?
Not that I know of, something sounds strange about your setup.
Hi there
I am using VMware Fusion to run Solaris and I have got the same error message when taking snapshot.
My VMware environment is two processors, 1536MB ram, 24GB HDD, 4GB swap. I am configuring JES on Solaris so I have taken/reverted snapshot many times. Last night after successfully configuring, I restarted the VMWare then took a snapshot; it went through the normal process of creating snapshot, then clean up the deleted files; but then I got this error message.
Have had a look at this thread and run the diskTool but the result said my virtual HDD is "error free".
And now I can't startup Solaris in VMware. Could anyone please tell me what should to do to solve this.
Thank you very much.
This thread is shown to be Answered, but for me it's not answered at all. I have the identical setup as OSX-XP with the same error messages and the same level of frustration. These Fusion VMs are as fragile as fine china. You better have a religious backup schedule, and don't rely on snapshots because they're just as fragile. And what's with the 15 seconds to take a snapshot, and 15 minutes to clean up old files?
OSX-XP solved his own problem but I'm not up for hex editors and such so what do I do? If the cause is known then is there a dumbed down procedure that a civilian could follow?
Hey, xltrader, don't sweat it. It was over my head too, but easy to learn.
First, download the hex editor 0xED (it is free online). Then, open your vmdk files in it to see the chain of "CID's" and "parentCID's". My last vmdk file was named: "Windows XP Professional-000007.vmdk"
What happened to me (and it sounds like the same for you), was that somehow, it lost the chain of CID->parentCID, parentCID->grandparentCID, etc.
What you are looking for is a the call to the parent CID, and you'll find that the parent's actual CID is not that. The chain is lost. So, change the value of the CID for that parent to match the call, and it should work.
Remember, each vmdk file has its own CID, and it calls to the one above it in the chain (it links to it by calling the 'parentCID'). If those don't stay in order, then you'll get that message. The only way to see the CID and parentCID, and to edit them, is with a hex editor.
When I opened mine in 0xED, I saw:
Disk DescriptorFile
version=1
CID=f2b91b5b <- these are what you are looking for
parentCID=9fce9787 <- these are what you are looking for
Hope that helps. If you get lost, post here what you can
Thanks for getting back. I'm gaining more confidence by the minute here.
Here's the list of my CID's. They look pretty messed up. Am I right that it's only the 000004.vmdk CID that has to match the vmdk parentCID, and the rest don't matter?
vmdk CID = 20efc093 parentCID = ffffffff
000004.vmdk CID = 1b172b62 parentCID = 8a63e8d1
000003.vmdk CID = 8a63e8d1 parentCID = 581ard72
000002.vmdk CID = f576fe32 parentCID = 8a63e8d1
000001.vmdk CID = =581afd72 parentCID = f576fe32
Hello,
On MAC / Fusion
Your posts have been most helpful - my situation is very similar but different as follows:
I have 4 vmdk files and the base file (0004-0001 and the base file). My CID/ParentCID order is as follows:
0004->0003->0001->0002->base
I am also unable to get a snapshot - this is a vm I just spent 1 day setting up VS '05 with all the settings downloads etc. it took all day
so I don't want to lose it!
Do these files HAVE to be in a particular order? It is puzzling how they would have gotten out of order. Do I need to reorder them in
some way?
Thanks for any help,
Ed
Ed,
You need to open each in the hex editor to see the CID paths. Please provide the following for each:
0004
CID:
parentCID:
0003
CID:
parentCID:
0001
CID:
parentCID:
0002
CID:
parentCID:
base
CID:
parentCID:
As follows:
0004
cid 00452146
pcid f9df0c0b
0003
cid f9df0c0d
pcid e0708592
0002
cid c1499bb0
pcid e4b5bf3e
0001
cid e0708592
pcid c1499bb0
base
cid e4b5bf3e
pcid ffffffff
Thanks for you help,
Ed
Ed,
Is this a typo, or real?
cid 00452146
pcid f9df0c0b <--'b'
0003
cid f9df0c0d <- 'd'
pcid e0708592
This thread is shown to be Answered, but for me it's not answered at all. I have the identical setup as OSX-XP with the same error messages and the same level of frustration.
This issues noted in this thread are strange; since Fusion supports only one snapshot, you should not be getting chains of 4 or 7 (or anything more than 1) child disk.
what's with the 15 seconds to take a snapshot, and 15 minutes to clean up old files?
Think of a snapshot as a record of all the changes since you took it. When you first take a snapshot, there is very little difference (so creation is fast), but when you delete a snapshot and it gets merged back to the base, Fusion has to update the base disk with every change in the child disk - depending on your snapshot size and disk speed, it'll take a while just to read all that data.