VMware Communities
jhhaze
Contributor
Contributor

Unable to open my Windows 10 Virtual Disk.vmkd

I am following the structure for a similar help request.  I hope I provided all of the information you need.  Thank you in advance.

MacOS 10.13.4

VMWare Fusion Professional Version 10.1.1 (7520154)

I get the following error when trying to load my windows 10 image...

Screen Shot 2018-04-08 at 11.34.55 PM.png

UPDATED SINCE ORIGINAL POST: There are only a few specifics I remember which may help to explain this issue. (1) I was running out of space disk space on my image and almost every second I was getting an error message and it wouldn't allow me to delete files to make room... so I increased the size of the disk image once or twice.  Second, at some point in the process I opted for a cleanup files type option in vmware fusion. I'm afraid all my data is lost.

I am not a very sophisticated VMware fusion user, but, I am fairly PC and Mac savvy and hope to follow any directions you can provide or provide a link to.  I was able to collect some information and I attached it, as well.  I read something while researching my issue on another post about transporting the image to a windows PC, buying or using a specific piece of software and maybe it would be able to rebuild it.  Not sure if that would work in my situation.  Thank you so much in advance for attempting to help me with my problem.

Jack

0 Kudos
13 Replies
ColoradoMarmot
Champion
Champion

How old is the machine?  That may indicate that the underlying hard disk is failing.  If that's the case, then restoring form backup may be your only option.

0 Kudos
jhhaze
Contributor
Contributor

Thank you for the response.

My hardware is a MacbookAir6, 2. With the following specs...

1.7 GHz i7

8 GB of RAM

512 GB of SSD

I also ran first aid in disk utility on my Macintosh HD and it generated a "The volume... appears to be ok.... operation successful.

So, I'm not doubting your original conclusion, but, are there any alternatives I can try?

Thank you,

Jack

0 Kudos
wila
Immortal
Immortal

Hi,


Before you do anything else: make a copy of your VM to an external disk.

Luckily your VM is a sparse disk and consists of slices "Virtual Disk-s001.vmdk" to "Virtual Disk-s026.vmdk".

If you have a look within your VM folder (in Finder, right click -> "Show Package contents" ) can you check if all the disk slices are available?

There should be 26 slices, numbers incremented by 1.

The last vmware.log file from your support bundle sees problems in slice 8 and slice 10. There might be more issues.

There is a chance you can recover some data, but you would need the help from one of our Data Recovery specialists at the forum, which would be either a.p.​ or continuum​.

Please do not follow any steps by other people unless you have a good backup of your current files (which is a good idea anyways, the last thing you'd want is make matters worse)

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
0 Kudos
jhhaze
Contributor
Contributor

Hi Wil,

Thank you so much for responding.

I was able to verify that all 26 "slices" are there.  I included 2 screenshots (please ignore the highlighting on the first one as I accidentally highlighted a 27th file).  I also included a screenshot of the file sizes just in the unlikely case the file size could indicate a damaged slice. I apologize in advance for the burry screenshots.  I did a direct screen shot through MacOs, not a camera, so not sure what happened. Thanks again.

Screen Shot 2018-04-10 at 4.21.50 PM.png

Screen Shot 2018-04-10 at 4.37.56 PM.png

0 Kudos
ColoradoMarmot
Champion
Champion

If it's an SSD, it's highly unlikely to be disk failure - they tend to go out completely.  Wila's comments are your best bet.

0 Kudos
wila
Immortal
Immortal

Hey Dlhotka,

Off topic, but I could have been more clear. Your comments are always valuable.

Just afraid that some "want to score points" vmtn user jumps on the thread and says something that destroys the TS's valuable data if followed up on it.

Which is also why I will refrain from making suggestions on how-to try and fix the virtual disk.

It is much better if Andre or Ulli are able to help, as they have so much more experience with this scenario than me.

Hopefully one of them can help the topic starter.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
0 Kudos
jhhaze
Contributor
Contributor

Hi Dlhotka and Wil,

Thank you both for responding and sharing your knowledge.

I am going to fully backup my vmware files this evening and sit tight and hope that Andre, Ulli or someone will help.

If I don't get a response in a little while, we can always give it a go with the backed up files, since we don't have anything to lose. I know I have some important documents on there, but not knowing the majority of what I lost is the part that really sucks.  On the flip side, I guess you can't miss what you don't know.

Much Appreciated,

Jack

0 Kudos
huger
Contributor
Contributor

I have the same question.Smiley Sad

0 Kudos
a_p_
Leadership
Leadership

I took a look at the files, and it seems that the virtual disk already had issues in November!?

Anyway, I'm not a MAC user so maybe others (e.g. wila) can verify the dd commands I'll post later in this reply.

What I'd like to do as a first step, is to check each of the virtual disk files to find out which ones are corrupted.

To do this I need each ...-s###.vmdk file's the metadata. This metadata is located at the beginning of each file. To find out the exact size that I need, create another temporary VM in Fusion with the exact same virtual disk size. Unless I'm mistaken the broken VM's virtual disk has initially been created with 60GB, and then expanded twice, 30GB and 5GB (do you remember whether this is correct?) Please do the same thing for the temporary VM, i.e. create the VM with 60GB, and then expand the virtual disk twice. Once done, compare the two VMs' "Virtual Disk.vmdk" files to ensure that the number of extents, and their sizes. At that point the temporary VM's ...-s###.vmdk files will only contain metadata, i.e. have the size that we need for extracting the required information.

What now needs to be done next, is to extract the number of bytes (size of the corresponding temporary .vmdk files) from each of the broken VM's .vmdk files,

i.e. s.th. like: dd count=<temp-vmdk-size> if="Virtual Disk-s###.vmdk" of="Metadata-s###.bin" bs=1 for each file.

Once done. compress/zip all the .bin files and attach the .zip archive to a reply post.

André

0 Kudos
wila
Immortal
Immortal

Hi André,

Thanks for helping!

The dd command and suggested parameters are correct.

PS: The other user that replied here with "I have the same problem", please open your own new question at this forum and describe what happened.

Provide additional info such as a problem report or a recent vmware.log file to start with. Don't add that to this topic thread please.

Mixing up two active data restore jobs in one thread can be confusing.

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
0 Kudos
jhhaze
Contributor
Contributor

A.P.

Thank you for the response.

(1) You are correct. November seems like the correct month for when my virtual disk got corrupted.  I was very upset, so I first let some time pass, so it didn't sting as much. I also naively was hoping to reopen the virtual disk in the future,  after a vmware update, would give me an error message, but then the option to fix/repair.  Wishful and unrealistic thinking, I know, but I was putting off the inevitable ( (A) The information is gone forever or (2) the complicated process of learning how to attempt to recover it). So recently I decided to give it a shot cause I don't have anything (more) to lose Smiley Happy ).

(2) Yes, the sizes and expansions sound correct.  I very well could have created it at 60 gb originally.  Then, increase it by 50% to 90gb when I ran out of room the first time and the last expansion is when the shit hit the fan.  As I recall, then was absolutely nothing I could do because i kept getting out of hard drive space messages in either vmware or windows 10 (I don't recall) and it wouldn't allow me to execute any commands in windows because as soon as I hit ok, it would popup again before I could do anything.  I really wanted to just delete some files but I wasn't allowed to. So I probably paused or shut down the image, increased by 5 gb and tried to boot the image again and I have been getting the error I attached a screenshot of in my first message ever since.

(3) Thank you for the steps. I follow what I need to do overall and the reasoning behind it.  Thank you for explaining.  Just a few of follow-up questions.  I apologize in advance for being such a novice.

          (A)          My Question: I don't believe I have the same windows 10 image.  Can I create the virtual disk and do the same expansions prior to installing an operating system?  I just don't recall the exact steps and order of operations when I created my windows 10 virtual disk originally.

          (B)  "compare the two VMs' "Virtual Disk.vmdk" files to ensure that the number of extents, and their sizes."

                         My question: when you say extents, so you mean?  I can compare the sizes of both of the virtual disk.vmdks by going into "get info" (MacOs' version of windows' properties) in Finder (MacOs' version of windows explorer), but want to confirm what you mean by extents. Is that just an initial check to make sure there are 26 "...-s###.vmdk "files?  Also, there is nothing that you want me to attach to my reply post related to the temporary files that this time, correct?

          (C)          " dd count=<temp-vmdk-size> if="Virtual Disk-s###.vmdk" of="Metadata-s###.bin" bs=1 "

                         My Question: Is this the exact command, just minus the " on each end of my quote above and changing the ### to my exact file names, 001 - 026?  I don't have a very much experience in terminal (the MacOs equivalent windows command prompt), but I believe I know how to launch it from the specific folder vmware folder we need.  If not I will reply back and maybe a more experienced mac terminal user can help.  The reason I have vmware in the first place is because I'm much more familiar with windows.

I can't thank you all enough for all your time and help on this recovery.  Also, I hope my specific questions above will help others in the future if they are unfortunate enough to run into a corrupt virtual disk like me.

~ Jack

0 Kudos
a_p_
Leadership
Leadership

(A) Do not install an operating system. Just create the VM, and expand the disk twice.

(B) Virtual disks are comprised of several files, a descriptor file (e.g. "Virtual Disk.vmdk"), and data files (e.g. "Virtual Disk-s###.vmdk"). The descriptor file is just a small text file which contains details about e.g. the virtual disk's geometry, extents and their max. sizes, ...). After creating the temporary VM, make sure that the extent's block sizes match in both "Virtual Disk.vmdk" files(original and temporary VM). The only reason for creating the temp. VM, is to get the file sizes of the newly created ...-s###.vmdk files, because they are needed for extracting the metadata from the original files.

(C) You'l have to run the command for each one of the data .vmdk files.

dd count=<temp-vmdk-size> if="Virtual Disk-s###.vmdk" of="Metadata-s###.bin" bs=1

For each data .vmdk file replace "###" with the number in the file name, and "<temp-vmdk-size>" with the exact size in bytes of the matching temp. .vmdk file.

Example: Assuming a temp. "Virtual Disk-s123.vmdk" with a file size of 123456 Bytes, the command would be:

dd count=123456 if="Virtual Disk-s123.vmdk" of="Metadata-s123.bin" bs=1

André

0 Kudos
ColoradoMarmot
Champion
Champion

Nope, no offense taken, and completely agree - and that's what I meant in my post.  Those are the only two folks I'd trust in that situation.  I tend to look for root cause - no point in repairing a VMDK on a failing drive 🙂

0 Kudos