Unable to clean up deleted files: The specified virtual disk needs repair.

[OSX-XP]

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.

[OSX-XP]

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.

[OSX-XP]

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?

[aetm]

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.

[OSX-XP]

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.

[OSX-XP]

I just downloaded the hex editor 0xED. Opening my "Windows XP Professional-000007.vmdk" file, I see:

1. Disk DescriptorFile

version=1

CID=d68a51e9

parentCID=0f2affac

createType="monolithicSparse"

parentFileNameHint="Windows XP Professional-000006.vmdk"

1. Extent description

RW 62914560 SPARSE "Windows XP Professional-000007.vmdk"

1. 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:

1. Disk DescriptorFile

version=1

CID=0f2affac

parentCID=4f68007f

createType="monolithicSparse"

parentFileNameHint="Windows XP Professional-000005.vmdk"

1. Extent description

RW 62914560 SPARSE "Windows XP Professional-000006.vmdk"

1. The Disk Data Base

#DDB

ddb.toolsVersion = "7362"

-

---

1. Disk DescriptorFile

version=1

CID=4f68007f

parentCID=f84b6fae

createType="monolithicSparse"

parentFileNameHint="Windows XP Professional-000004.vmdk"

1. Extent description

RW 62914560 SPARSE "Windows XP Professional-000005.vmdk"

1. The Disk Data Base

#DDB

ddb.toolsVersion = "7362"

-

---

1. Disk DescriptorFile

version=1

CID=f84b6fae

parentCID=70ff3ee4

createType="monolithicSparse"

parentFileNameHint="Windows XP Professional-000003.vmdk"

1. Extent description

RW 62914560 SPARSE "Windows XP Professional-000004.vmdk"

1. The Disk Data Base

#DDB

ddb.toolsVersion = "7362"

-

---

1. Disk DescriptorFile

version=1

CID=70ff3ee4

parentCID=6f72c929

createType="monolithicSparse"

parentFileNameHint="Windows XP Professional-000002.vmdk"

1. Extent description

RW 62914560 SPARSE "Windows XP Professional-000003.vmdk"

1. The Disk Data Base

#DDB

ddb.toolsVersion = "7362"

-

---

[OSX-XP]

OK, I was able to get the CID from the base vmkd file:

1. Disk DescriptorFile

version=1

CID=d978680a

parentCID=ffffffff

createType="monolithicSparse"

1. Extent description

RW 62914560 SPARSE "Windows XP Professional.vmdk"

1. 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":

1. Disk DescriptorFile

version=1

CID=f2b91b5b

parentCID=9fce9787

createType="monolithicSparse"

parentFileNameHint="Windows XP Professional.vmdk"

1. Extent description

RW 62914560 SPARSE "Windows XP Professional-000001.vmdk"

1. 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!

[OSX-XP]

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!

[admin]

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).

[OSX-XP]

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.

[admin]

Is there some instability with DirectX and Fusion 1.1?

Not that I know of, something sounds strange about your setup.

[AaronLaughton]

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.

[xltrader]

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?

[OSX-XP]

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

[xltrader]

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

[EdBuchwalter]

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

[OSX-XP]

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:

[EdBuchwalter]

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

[OSX-XP]

Ed,

Is this a typo, or real?

cid 00452146

pcid f9df0c0b <--'b'

0003

cid f9df0c0d <- 'd'

pcid e0708592

[admin]

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.