VMware Communities
JamesBama
Contributor
Contributor
Jump to solution

Crash during defrag - can't reopen

Workstation Pro - 11.1.4 build-3848939

Windows Server 2012 R2 Essentials Edition, 64-bit  (Build 9600) 6.3.960

Good morning! WSP suggested a defragmentation of the VS. I've done it before, no problem. This time however, there was some sort of error that locked the process up and left me with a temp file (VMDK-DFGSHKGRW-TMP File (.vmdk-dfgshkgrw-tmp)). So of course I get the 'File not found' error.

Well, I assumed I could just restore from our backup...I have no clue what has gone with that, but it won't work either. I'm getting an 'One of the disks in this virtual machine is already in use by a virtual machine or a by a snapshot.' error.

Any suggestions?

Thank you,

james

1 Solution

Accepted Solutions
a_p_
Leadership
Leadership
Jump to solution

Good question. According to the file listings that you've posted, the restored version is 2 months old.

Which version is the one with the correct metadata, i.e. "...-000003.vmdk" for which you've provided the complete metadata? As I mentioned before, the first set of .bin files that you've posted showed corrupted metadata in this file.

Maybe one more thought. Did you already run a chkdsk on the M: drive to ensure that the issue is not related to a hosts file system issue?

If issues with the file systems can be ruled out, I'd like you to try and clone the .vmdk from the command line by running the following command from within the VM's folder:

"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -r "kaos-000003.vmdk" -t 4 "kaos-clone.vmdk"

This command - if successful - will clone the virtual disk including its snapshots into a new base disk.

Note: "-t 4" is the format that's currently used. If this has net been used by intention, you may convert the virtual disk to the default format using "t -1" instead.

André

View solution in original post

25 Replies
a_p_
Leadership
Leadership
Jump to solution

Welcome to the Community,

which files do you have in the VM's folder? Please provide text output of dir *.*

In addition to the output, also attach the VM's configuration (.vmx) file to a reply post.


André

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

Thank you for the welcome.

This is the list of dir *.* (Well, the windows version anyway)

11/01/2018  07:49 AM 5,313,724,416 kaos-000001.vmdk
11/10/2018  10:30 PM 5,791,350,784 kaos-000002.vmdk
10/26/2019  02:41 PM63,128,535,040 kaos-000003.vmdk-dfgshkgrw-tmp
10/26/2019  01:46 PM    39,452,672 kaos-000004.vmdk
10/28/2019  08:38 PM    39,452,672 kaos-000005.vmdk
10/28/2019  08:39 PM    39,452,672 kaos-000006.vmdk
10/30/2019  09:24 AM    39,452,672 kaos-000007.vmdk

10/10/2018  07:39 AM   322,122,547,200 kaos-flat.vmdk

10/12/2018  09:20 AM        28,391 kaos-Snapshot5.vmsn
11/01/2018  07:49 AM        28,399 kaos-Snapshot6.vmsn
11/10/2018  10:30 PM        28,399 kaos-Snapshot7.vmsn
10/26/2019  01:45 PM        28,398 kaos-Snapshot8.vmsn
10/28/2019  08:38 PM        28,457 kaos-Snapshot9.vmsn
10/30/2019  09:24 AM         8,684 kaos.nvram
07/08/2018  09:25 AM           519 kaos.vmdk
10/28/2019  08:38 PM         1,721 kaos.vmsd
10/30/2019  09:24 AM         2,934 kaos.vmx
10/30/2019  09:24 AM           362 kaos.vmxf
08/12/2019  07:06 AM       964,749 vmware-0.log
08/11/2019  03:01 AM    16,822,400 vmware-1.log
01/18/2019  10:57 AM     6,328,941 vmware-2.log
10/26/2019  01:25 PM    11,825,972 vmware.log
08/12/2019  07:06 AM         2,291 vprintproxy-0.log
01/18/2019  11:16 AM         2,033 vprintproxy-1.log
01/18/2019  10:56 AM         2,293 vprintproxy-2.log
10/26/2019  01:25 PM         2,291 vprintproxy.log
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

I can't tell whether the "in-work" tmp file can simply be renamed to make the VM work again. In any case please make sure that you backup the current files/folder to ensure that there's a way back to the current state!

What I'd like to see is how the virtual disk's snapshot chain looks like. To get the required metadata, I need the first 1,536 bytes of each snapshot .vmdk file, as well as the base disk's .vmdk descriptor file (kaos.vmdk).To extract the metadata, please download dsfok.zip from http://faq.sanbarrow.com/index.php?action=artikel&cat=47&id=111&artlang=en, extract the executables to the VM's folder, run the below mentioned command in the VM's folder, then compress/zip all the "xxx-....bin" files along with the mentioned .vmdk descriptor file, and attach the .zip archive to a reply post

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

André

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

Thank you André.

Please see attached.

James

0 Kudos
a_p_
Leadership
Leadership
Jump to solution

Just to make sure that I understand this correctly.

Did you restore "kaos-000003.vmdk" from a backup?

This file has a some - at least to me - unknown data in it's header. Maybe it's a corruption, which can be fixed.

To find out about this, please extract the complete metadata (header + grain tables) from this file using the following command, and attach the .bin file as a compressed .zip archive to your next reply.

dsfo.exe "kaos-000003.vmdk" 0 39452672 "meta-kaos-000003.bin"

André

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

I have tried with just restoring "kaos-000003.vmdk" from backup to no avail. I have also tried renaming the working temp to "kaos-000003.vmdk" and that produces the same issue as the backup, a 'One of the disks in this virtual machine is already in use by a virtual machine or a by a snapshot.' error. I also tried pulling the entire directory from back up and I get the same errors.

James

0 Kudos
a_p_
Leadership
Leadership
Jump to solution

I'm a bit confused now. The current file's header is different from the previous one? Did you replace that .vmdk file in the meantime?

Anyway, the current metadata looks fine, so what you want to check is whether there's some process in the background which may still access one of the VM's files. Is it possible to just reboot your host PC, to see whether this helps?

André

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

I tried renaming the temp file. Maybe that's probably why it's different? I tried rebooting the host already. I will try that again.

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

Ok, reboot of host machine did not 'free' the "kaos-000004.vmdk" file. Do I start deleting snapshots? This is a production server and the office is dead-in-the-water.

Thank you André.

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

I'm trying to work on the restored VM and I noticed there is a lock in the group. Might that be the underlying issue?

11/01/2018  07:49 AM 5,313,724,416 kaos-000001.vmdk
11/10/2018  10:30 PM 5,791,350,784 kaos-000002.vmdk
08/12/2019  07:07 AM63,147,671,552 kaos-000003.vmdk
10/26/2019  01:46 PM    39,452,672 kaos-000004.vmdk
10/12/2018  09:20 AM        28,391 kaos-Snapshot5.vmsn
11/01/2018  07:49 AM        28,399 kaos-Snapshot6.vmsn
11/10/2018  10:30 PM        28,399 kaos-Snapshot7.vmsn
10/26/2019  01:45 PM        28,398 kaos-Snapshot8.vmsn
01/18/2019  10:56 AM         8,684 kaos.nvram
07/08/2018  09:25 AM           519 kaos.vmdk
10/26/2019  04:56 PM         1,409 kaos.vmsd
10/30/2019  10:40 AM         2,934 kaos.vmx
10/30/2019  09:18 AM<DIR>      kaos.vmx.lck
10/30/2018  07:42 AM           362 kaos.vmxf
08/12/2019  07:06 AM       964,749 vmware-0.log
08/11/2019  03:01 AM    16,822,400 vmware-1.log
01/18/2019  10:57 AM     6,328,941 vmware-2.log
10/26/2019  01:25 PM    11,825,972 vmware.log
08/12/2019  07:06 AM         2,291 vprintproxy-0.log
01/18/2019  11:16 AM         2,033 vprintproxy-1.log
01/18/2019  10:56 AM         2,293 vprintproxy-2.log
10/26/2019  01:25 PM         2,291 vprintproxy.log
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

Deleting .lck files, and folders for a powered off VM at least doesn't hurt.

André

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

Ok, I got the restored VM to load into Workstation, but I still can't open it. It can't find the .vmdk file?!?!?!? I'm looking at it sitting in the directory.

James

0 Kudos
a_p_
Leadership
Leadership
Jump to solution

That's indeed interesting.

Is the M: drive a mapped drive? Are you running the VM as a shared VM (server mode), or as a regular VM (user mode)?

The virtual machines configuration (.vmx) file that you posted earlier contains a seach path

fileSearchPath = "M:\ServerFolders\VIRTUAL SERVERS\kaos;."

Assuming that you restored the VM to another folder, please remove this line from the configuration file, with VMware Workstation, or at least the VM's tab closed, so that the configuration gets reread after the modification.

André

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

The M drive is a physical drive and Workstation is in server mode (I believe).

I have created a series of folders that the various stages of the VM have been restored/backed-up (physical via copy-paste). I removed the line and reloaded the restored copy only to realize the flat file was not restored from back-up. Once I copied the flat file back to the restored location, I'm getting a 'file is in use' error again.

Could the flat file be locking the .vmdk file?

0 Kudos
a_p_
Leadership
Leadership
Jump to solution

Unless the VM is registered twice, and/or something goes wrong with the search path, that message doesn't make any sense.

Please use e.g. the Task Manager to see whether the file is in use by another process, and check if *.vm* files (or at lease *.vmdk files) are excluded from being scanned by your A/V application.

How much free disk space do you have on the host? Maybe it's possible to clone the VM from the Workstation GUI, and start then the clone!?

André

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

I'm at a loss here...I can't see anyway it could be registered twice. There is nothing tied to that specific vmdk file and A/V is currently disabled (just to be sure!). I can't even clone the VM because of the file being locked!

I even downloaded the latest version (15.5), tried opening it, tried reverting snapshot, moved it to another PC and tried. Should I work on the restored version or the one that got locked up when doing the defrag?

0 Kudos
a_p_
Leadership
Leadership
Jump to solution

Good question. According to the file listings that you've posted, the restored version is 2 months old.

Which version is the one with the correct metadata, i.e. "...-000003.vmdk" for which you've provided the complete metadata? As I mentioned before, the first set of .bin files that you've posted showed corrupted metadata in this file.

Maybe one more thought. Did you already run a chkdsk on the M: drive to ensure that the issue is not related to a hosts file system issue?

If issues with the file systems can be ruled out, I'd like you to try and clone the .vmdk from the command line by running the following command from within the VM's folder:

"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -r "kaos-000003.vmdk" -t 4 "kaos-clone.vmdk"

This command - if successful - will clone the virtual disk including its snapshots into a new base disk.

Note: "-t 4" is the format that's currently used. If this has net been used by intention, you may convert the virtual disk to the default format using "t -1" instead.

André

a_p_
Leadership
Leadership
Jump to solution

continuum​: Do you have an idea what may be causing this?

André

0 Kudos
JamesBama
Contributor
Contributor
Jump to solution

Well, that was some time to create, but it just finished successfully. I now have kaos-clone.vmdk and kaos-clone-flat.vmdk. While that is great, I'm not sure what to do with the clone at this point. Google has not been friendly with describing what I should do with the clone at this point. LOL! Do I create a adhoc .vmx file?

HELP!

James

0 Kudos