VMware Communities
AnnikaW
Contributor
Contributor

Accidently deleted one or to .vmdk files

Hi all,

I have a VM running on Workstation Pro and unfortunately, I deleted on or two .vmdk filed used by the VM.

They were named "Windwos 7 x64-000006.vmdk" for example.

When I try to start the VM I get an error "File not found: -filename.vmfk".

This file is requierd to power on this virtual machine.

If this file was moved, specify the new Location.

I do have Snapshots which are a couple of days old and tried to revert back to those, but wasn't able to.

Is there any help?

I read that some of you are able to perform miraces Smiley Happy

Greetings

Annika

14 Replies
a_p_
Leadership
Leadership

Welcome to the Community,

I'm afraid we won't be able to perform miracles, but we can at least take a look at the issue to see what's possible.

As a first step please provide a complete list of files, i.e. run

dir *.* /one > filelist.txt (or ls -lisa > filelist.txt if you have a Linux host)

in the VM's folder. Then compress/zip the resulting filelist.txt along with the VM's .vmx, .vmsd, and all the vmware*.log files, and attach the .zip archive to a reply host.

One more question, do you have backup(s) of the VM's files (even if it's an older one)?

André

Reply
0 Kudos
dprows33
Contributor
Contributor

Ouch.  I can feel your pain.  I have done that before and never could figure out a way to get it back.  I assume you have check your recycle bin and that you do not have versioning turned on in windows?  What I have done for myself is use Veeam's free edition to backup my VMs so I can restore them if/when needed.

David Prows Fort Wayne VMUG Leader
Reply
0 Kudos
AnnikaW
Contributor
Contributor

Thanks for welcoming me.

Attached are the files you requested. Please note that I already tried to solve my problem on friday so I hope I haven't already messed up the logfiles.

I have two or three Snapshots of the VM. The newest is a couple of days old and I would be absolutely satisfied if I could revert back to one of those.

Tanks in advance for you help!

Reply
0 Kudos
AnnikaW
Contributor
Contributor

dprows33

Yeah, I checked those options as soon as I realized, what I have done. Smiley Sad

Reply
0 Kudos
a_p_
Leadership
Leadership

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 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é

Reply
0 Kudos
AnnikaW
Contributor
Contributor

Thanks for your quick response.

I attached the *.bin files.

Reply
0 Kudos
a_p_
Leadership
Leadership

With the deleted files, and the fact that you've tried to run the VM from the base virtual disk (at least it has a modified CID), the best we can do is to try, and see whether we can restore the state form January, 24th.

To do this:

  • close VMware Workstation
  • backup the VMs folder/files unless already done (it's up to you, but I strongly recommend it)
  • create a new, temporary sub-directory
  • move all files except for "Windows 7 x64.vmdk", "Windows 7 x64-000001.vmdk", and "Windows 7 x64-000001.vmdk" to the newly created directory
  • extract the three files from the attached .zip archive to the VM's folder
  • inject the modified header data into "Windows 7 x64-000001.vmdk" using the utility that you've downloaded before
    dsfi.exe "Windows 7 x64-000001.vmdk" 0 1536 "xxx-Windows 7 x64-000001.vmdk.bin"
  • open VMware Workstation, and create a new snapshot for this VM to avoid modifications to the existing files

Depending on which data was modified when you tried to run the VM from the base disk, you may see some data corruption. In any case you should run chkdsk c: /f to have Windows check, and fix the file system if necessary.

Once the VM runs stable with the expected data, you may consider to delete the temporary directory with the now obsolete files, and delete the existing snapshots.

André

Reply
0 Kudos
AnnikaW
Contributor
Contributor

Hi, thanks for trying to help me.

I have two questions:

move all files except for "Windows 7 x64.vmdk", "Windows 7 x64-000001.vmdk", and "Windows 7 x64-000001.vmdk" to the newly created directory

Did you mean "Windows 7 x64-000001.vmdk", and "Windows 7 x64-000002.vmdk?

And the script you posted:

dsfi.exe "Windows 7 x64-000001.vmdk" 0 1536 "xxx-Windows 7 x64-000001.vmdk.bin"

There is no *01.vmdk.bin.

Regards!

Reply
0 Kudos
a_p_
Leadership
Leadership

Sorry about the typos (copy& past issues), yes it'indeed

"Windows 7 x64.vmdk", "Windows 7 x64-000001.vmdk", and "Windows 7 x64-000002.vmdk"

and

"xxx-Windows 7 x64-000001.bin"


André

Reply
0 Kudos
AnnikaW
Contributor
Contributor

Hi André,

the injection worked fine (OK, written 1536 bytes at offset 0) but when I try to start the VM i get an error message:

File not found: Windows 7 x64-Snapshot1.vmsn

Thanks again for you help!

Reply
0 Kudos
a_p_
Leadership
Leadership

In this case please close VMware Workstation, delete the .vmsd file, and then try to start the VM again.

If the VM powers on, and everything looks as expected, then don't forget to delete the existing snapshots, as they actually consume considerable disk space, and I assume that this was the reason why you deleted the files in first place!?

To delete the snapshots, shut down the VM, create a new snapshot, then open the Snapshot Manager, select the newly created snapshot, and hit the "Delete" button. Note that this will delete/consolidate all snapshots, and this may take considerable time due to their sizes.

André

Reply
0 Kudos
AnnikaW
Contributor
Contributor

Hi André,

thank you so much for your help. Everything worked as you said.

Yes, you are right. i deleted the files in order to get some free disk space. That was obviously not a good idea.

Could you please give me a hint how to manage the disk consuming files in the future?

Thanks again!

a_p_
Leadership
Leadership

The huge disk usage was caused by keeping multiple snapshots for a long time. Each of these snapshots can theoretically grow up to the provisioned size of the VM's virtual disk.

Best practice is to keep snapshots only as long as needed. Rather than keeping snapshots, consider to backup the VM's folder/files from time to time.

In this case the VM had "Auto Protect" enabled. This feature automatically creates snapshots, which IMO is only a good idea if the user is well aware of the impact. Btw. I've disabled "Auto Protect" (unless I missed a setting) in the VM's configuration (.vmx) file that I provided earlier.


André

AnnikaW
Contributor
Contributor

Hi André

thanks again for your help and the useful tipps that came along!

Regards!

Reply
0 Kudos