Unable to open file .vmdk. One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot.

[gbartlett73]

Hello,

I am running a large VM on my c:\ drive for the past few months.  I had the original VM located on my d: drive which I had copied over to c.  In order to free up some space I deleted my old VM on the d:\ drive.

Now when I started my VM, I am presented with this error:

This is strange as all of the files are on c:\.  When I used the Browse... button and located the same .vmdk file on the c:\ drive, I now get presented with this error:

I had made a complete backup copy on an external drive a few days ago; however when I tried to open up the VM from this drive I received the same errors.

I find this very strange as the vmdk files on my c:\ drive have been accessed recently (i.e. the dates have been modified recently).  Therefore I am hoping there is a way to modify this in order to get it working correctly.

Thanks!

Graham

[a_p_]

The likely reason for this is that there's a reference to the 😧 drive somewhere in the VM's metadata.

Do you need the snapshot, i.e. would it be ok to delete the snapshot by merging its data to the VM's base disk?

If you don't need it, then - as a first step - please post a list of files that are in the VM's folder, i.e. the output of dir *.* from the command line. Please make sure that the VM's tab, or VMware Workstation is closed for that. In addition to this list, attach the VM's configuration (.vmx) file, as well as the latest vmware*.log file to a reply post.

André

[gbartlett73]

Hello - I have a number of snapshots in this VM.  That said, I don't need them all - assuming we can merge the data all into one.

Here is a list of files in the VM directory.  Note - I did remove the LCK directories and tried to start the VM (which didn't work - so I put them back).

As well I have attached the .vmx file and latest .log file.  I did find in the log file some references pointing to the original location of the VM on d:...

[a_p_]

It seems that the "...-Apr2017-000005.vmdk" file contains a link to the 😧 drive, and need to be adjusted.

Since you mentioned that you have a backup on an external disk, I guess we can start right away.

Please download dsfok.zip from http://faq.sanbarrow.com/index.php?action=artikel&cat=47&id=111&artlang=en, extract the executables, run the below mentioned command in the VM's folder, then compress/zip all the "xxx-....bin" files and attach them to a reply post.

for %i in (*.vmdk) do @dsfo.exe "%i" 0 1536 "xxx-%~ni.bin"

The command will extract only metadata (i.e. no user data) from the .vmdk files.

André

[gbartlett73]

Ok - I ran the dsfo.exe in the VM folder and it created 8 .bin files - see attached zip file.

Thanks!

Graham

[a_p_]

I see that the snapshot chain is broken, and it looks like the VM has a snapshot tree.

Did you try to open the VM by changing the .vmdk file name in the .vmx file?

It is important to understand the correct chain to avoid data loss!

In case that the backup on the external disk has not been modified, then run the dfso command for the files on that disk, and attach the bin files as well as the .vmx file to a reply post.

André

[gbartlett73]

No - I did not try to change the vdmk file in the vmx file.  Referring back to my original post, it was searching for a vdmk file on my d: drive and I used the "browse" command to locate the one on my c: drive.  So it may looked changed because I did this on startup...?

I have attached the bin files from my backup drive.

I had done some cleanup on my snapshots (I had deleted some unneccesary ones) in order to clean up some disk space.  I cannot recall whether I did this before or after I made my backup copy (you will probably be able to tell based on the bin files...?)  See attached.

[gbartlett73]

Sorry - I forgot to attach the VMX file from the backup - see attached

Thanks!

Graham

[a_p_]

Ok, let's see whether we can fix this without needing to clone the whole VM.

Close VMware Workstation (important!), then extract the two files from the attached archive in to the VM's folder on the C: drive, and run

dsfi.exe "Base_I1_Siemensdc_Apr2017-000005.vmdk" 0 1536 "xxx-Base_I1_Siemensdc_Apr2017-000005.fix"

to inject the modified metadata (the "ParentCID" has been modified) into the corrupted .vmdk file.

Next, create a sub-directory, and move all *.vmsd, *.vmsn, *.gz, *.lck, caches, Base_I1_Siemensdc_Apr2017-000003.vmdk, Base_I1_Siemensdc_Apr2017-000004.vmdk files/foldes to the new sub-directory. Unless I'm mistaken these files are obsolete.

At that point you should be able to open VMware Workstation and the VM (don't power it on yet). Try to see whether you can create a new snapshot. If that works, open Snapshot Manager, select all snapshots (you will actually see only the new one), and press the Delete button. Depending on the sizes of the snapshot files, deleting them might take some time, so please remain patient.

Once done you should end up with a single .vmdk file in the VM's folder. In this case you may consider the sub-directory with the obsolete files.

André

PS: I have to sign off for today. but will be back tomorrow.

[gbartlett73]

Hi Andre,

I believe I followed your steps correctly - once I ran the command in a dos prompt window, it showed this:

I then moved all the files you suggested into a temp folder.

When I opened VMWorkstation and opened the VM, I was successful in creating a new snapshot - and yes all of my other snapshots were missing in the Snapshot manager view.

However I received and error message when I tried to delete the new snapshot - ie.

Any ideas?

Graham

[a_p_]

I see,The vmware.log you posted earlier shows an error:

... Base_I1_Siemensdc_Apr2017-000007.vmdk" : failed to open (14): Disk needs repair.

What you may try is to repair the .vmdk file using the vmware-vdiskmanager utility that you can find in the VMware Workstation installation directory

Note that according to the documentation you will need to specify the complete path, and file name, i.e.

vmware-vdiskmanager -R "C:\VMs\TC11.3_AWS_3.3\Base_I1_Siemensdc_Apr2017\Base_I1_Siemensdc_Apr2017-000007.vmdk"

Since this command tries to fix errors in the file, and not always succeeds, please ensure that you backup the file prior to running the command!

If the tool isn't able to fix the error(s), restore the file from the backup, extract the metadata, and attach the .bin file to a reply post, including the .vmdk file's exact size in bytes!

for %i in (*-000007.vmdk) do @dsfo.exe "%i" 0 19726336 "xxx-%~ni.bin"

I can't promise anything, but maybe I can fix using my own tools.

André

[gbartlett73]

Hi Andre,

Its working!

I was able to successfully run the vdiskmanager utility and it corrected the issues with the vdmk file - I.e.

After this, I opened up the VM in VMWorkstation - and ran through your process of creating a snapshot and deleting a snapshot.  When I deleted the snapshot, it took about 3-5 minutes but ultimately it deleted (and consolidated the vdmk files I assume) the snapshot.

I then opened the VM - which it did successfully!

Questions (for the future):  I am assuming that this consolidated all of my snapshots into one?  (i.e. I did not loose any data?)  I haven't looked around in the VM but it looks like nothing is missing.

Next Question:  I leverage snapshots a lot (it allows me to stage different software/demonstrations at different points in time - big benefit in sales).  That said, I believe I messed this VM up when I deleted some snapshots...  Is there a better (or different process) I should use?  Similarly what is the best approach to making back-up copies of my VM - in the past I simply copy/pasted my VM's on my file server; however I am wondering if using the clone functionality would be a better result?

Thanks again for all your help!

[gbartlett73]

Whoops - I spoke too soon...

I was successful in logging into the VM; however my database inside the VM is corrupted...

Is there any chance we can use my back-up copy and run through the similar steps - but perhaps clone the envinroment and/or not consolidate the snapshots....somehow along the line it messed up my environment inside the VM.  Please let me know the best course of action.

Thanks!

Graham

[a_p_]

The way you are making use of snapshots - preserving different states for demos - is actually one point what they are there for. So there's nothing wrong about this.

We can certainly try different things, but I'm afraid that this won't help much. The broken snapshot chain between the first, and the second snapshot exists in your backup files too.

Would it be acceptable for you to revert to a previous state (I understand this is not a production system)?

If that's ok with you, then try the following to see what state of your VM/database you get.

• close VMware Workstation
• move all of the VM's files on the C: drive to a new sub directory (or consider to delete them, since - if I understood you correctly the VM isn't useful anymore)
• copy all of the backup files to the VM's directory on the C: drive
• open  the Snapshot Manager, select the second snapshot in the chain, and hit "Go To"

Check whether the VM works , and is state is acceptable for you.

If the database is still corrupt, you may try to "Go To" to the first snapshot in the chain to see whether this contains a healthy (although old) database.

If you end up with a working VM in an acceptable state, then we will proceed with cleaning up the obsolete files, and metadata.

André

[gbartlett73]

Hi Andre,

I removed the corrupted VM from C: and copied/pasted my backup version onto C.

I opened it and tried to go back to an older snapshot - ie.

However I was presented with this error:

And of course when I simply started the VM, it first asked me to locate the _000001.vdmk file (which was there in the same folder) - I browsed to that location and then when I hit open I got this message:

Not sure where to go with this now?  This is the same as the original - that said, can we try a different method (such as cloning it somehow)???  Please advise.

Thanks!

[a_p_]

We can certainly try, and clone the virtual disk from different snapshots. However, let's first find out which snapshot is usable.

So let's start with the snapshot that I assume should be healthy.

Steps:

1. close VMware Workstation
2. create a temporary sub-directory in the VM's folder
3. move all files/folders except for:
   Base_I1_Siemensdc_Apr2017.vmx
   Base_I1_Siemensdc_Apr2017.vmdk
   Base_I1_Siemensdc_Apr2017-000001.vmdk
   to the sub directory
4. edit the .vmx file, and set the virtual disk's file name to Base_I1_Siemensdc_Apr2017-000001.vmdk
5. Check whether the VM powers on, and is in a healthy state (i.e. has a useful DB)

André

[gbartlett73]

Hi Andre,

Good news.  I followed your directions and was able to open the VM to what looked like my first snapshot (mid-September).  I was also successful in opening my db's in there - so everything was working as expected.

So, I am assuming then that we can walk through this process with the next snapshot(s) until we get to the corrupted one?  I am really hoping to retrieve a more recent snapshot... Please advise on how to proceed...

Thanks!

Graham

[a_p_]

Yes, you can try to open the VM from the latest snapshot, and go back one step/snapshot if the data is corrupted.

The virtual disk files are in the following order (newest to oldest):

Base_I1_Siemensdc_Apr2017-000007.vmdk (bad - you already tried this, after fixing it)

Base_I1_Siemensdc_Apr2017-000006.vmdk

Base_I1_Siemensdc_Apr2017-000002.vmdk

Base_I1_Siemensdc_Apr2017-000005.vmdk

Base_I1_Siemensdc_Apr2017-000001.vmdk (good - contains data from September)

Base_I1_Siemensdc_Apr2017.vmdk

So what you want to do is to restore the VM's .vmx file as well as the above mentioned .vmdk files. Once restored, extract the metadata fixes from attached archive and inject them into the appropriate .vmdk files:

dsfi.exe "Base_I1_Siemensdc_Apr2017-000001.vmdk" 0 1536 "xxx-Base_I1_Siemensdc_Apr2017-000001.fix"

dsfi.exe "Base_I1_Siemensdc_Apr2017-000002.vmdk" 0 1536 "xxx-Base_I1_Siemensdc_Apr2017-000002.fix"

dsfi.exe "Base_I1_Siemensdc_Apr2017-000005.vmdk" 0 1536 "xxx-Base_I1_Siemensdc_Apr2017-000005.fix"

dsfi.exe "Base_I1_Siemensdc_Apr2017-000006.vmdk" 0 1536 "xxx-Base_I1_Siemensdc_Apr2017-000006.fix"

dsfi.exe "Base_I1_Siemensdc_Apr2017-000007.vmdk" 0 1536 "xxx-Base_I1_Siemensdc_Apr2017-000007.fix"

dsfi.exe "Base_I1_Siemensdc_Apr2017.vmdk" 0 1536 "xxx-Base_I1_Siemensdc_Apr2017.fix"

Note: I modified the metadata for those files to a.) fix the snapshot chain, and b.) remove absolute paths for the parent files.

With the above files/changes done, you may now edit the configuration (.vmx) file, and set the virtual disk name as required, starting with "...-000006.vmdk". Please remember that you can go back with the snapshot files, but once the VM has been powered on with that specific file, you won't be able to use a newer snapshot file anymore. That's probably nothing you will need to do, but I just wanted to mention it.

Please ensure that VMware Workstation (or at least the VM's tab) is closed when you edit the VM's .vmx file, so that it is re-read after the modification.

In case the VM works from snapshot "...-000006.vmdk", then - if you want - extract the metadata from the "...-000007.vmdk" (for details see a previous post) so that I can take a closer look at its corruption.

André

PS: Updated reply with additional metadata fixes.

[gbartlett73]

Hi Andre,

I applied the fixes you sent and started with the .000006.vdmk file and modified the vmx file to look at that one.  Note this is what my directory looked like:

When I did this and opened it in VMware, I received this error:

I tried the other 2 vdmk files (by modifying the vmx file) and also ran into this error.

Any ideas?

Thanks!

[a_p_]

I somehow seem to have used the metadata of the original, non-working VM, rather then those which you've extracted from the backup files.

Please use the attached files to update the metadata for the corresponding .vmdk files.

André