Cannot Start VIrtual Machine

[cyb2rg3]

Hey there,

I'got an Problem with starting an Virtual Machine.

I have Windows 10

VMWare Workstation 15 Pro

Error Msg:

Cannot open the disk '.....'

Module 'Disk' power on failed

This machine was running several times.. but now it's no more running...

br

[Alex_Romeo]

Hi,

Try to close VMware Workstation completely and check that there are no files with the extension ".lck" in the virtual machine folder, if there is you need to remove it.

ARomeo

[cyb2rg3]

Hi Alessandro,

thanks for your help.

But still the same.

Once i close VMware completely the ".lck" folder is removed, if y try to restart the vm again the same error.

If I try to remove this ".lck" folder my self when VMWare is open, then it's still not running.

[Alex_Romeo]

Hi FB,

after you have removed the "*.lck" file inside the virtual machine folder, restart the host (...the computer where you have installed vmware Workstation)

ARomeo

[cyb2rg3]

Hi Alessandro,

I did it, but still the same.

What i saw its.. after deleting the ".lck" file inside, and restart the host... Once i start then Vmware again (without to start the virtual machine, just opening the control panel) the ".lck" is again created automatically.

Its normal?

[Alex_Romeo]

No, this is not normal. The *.lck file is created when the virtual machine is powered on (for protection).

can you please post an image of the contents of the folder that contains the virtual machine? (also hidden files)

ARomeo

[scott28tt]

A listing of ALL the files with a VMDK extension will be needed - it is those files that make up a virtual disk.

Also, does the VM have any snapshots?

[cyb2rg3]

so here is the screenshot:

No Snapshots are disabled

[a_p_]

To rule out disk/file system issues, please see whether it is possible to copy/backup the VM's folder.

Does the VM's vmware.log contain details about the error? If yes. please attach the vmware.log to a reply post.

One more question. Have the files been renamed?

"Windows-10-x64-EN.vmdk" contains metadata about the data .vmdk files that make up the vittual disk. Do these names match the file names?

André

[cyb2rg3]

yes i can without problems edit the files or make a copy as backup....

well yes the log contains something, i will attach it: for your information... cause the pathes showed in LOG are confidential (internal names, etc.. of the company, so i did replace the path names with "dummy" string.

about the other question:

1. yes i did rename the workstation (but with the GUI Interface, not directly the Files) and yes it was running for several Time. since few Days is no more running.. but i started it every week 2-3 times.

2. yes i think its fine, take a look:

"

# Extent description

RW 8323072 SPARSE "Windows-10-x64-EN-s001.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s002.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s003.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s004.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s005.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s006.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s007.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s008.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s009.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s010.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s011.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s012.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s013.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s014.vmdk"

RW 8323072 SPARSE "Windows-10-x64-EN-s015.vmdk"

RW 983040 SPARSE "Windows-10-x64-EN-s016.vmdk

"

thanks for your help!

[wila]

Hello,

VMware Workstation is having trouble reading the very first disk slice "Windows-10-x64-EN-s001.vmdk"

Is the VM stored locally or on a network disk?

Somehow "dummypath" doesn't help with determining that

--

Wil

[cyb2rg3]

Hi,

well it's stored in google file stream, but set the parent folder on "available offline" so that i don't need network to access the file.

[wila]

Hi,

well it's stored in google file stream,

Ouch.

Well I suppose that explains the error "Read beyond the end of file (9)" on the initial slice.

Virtual machine disks don't tend to work well with cloud features such as (but not limiting to) drop box, one drive etc..

This might work well for files that are not open for write such as documents and images, but not for mounted file systems that has another operating system running in it.

That's a combination with a very high likelyhood of ending up with disk corruption on the virtual machine.

Looks like your disk slice got truncated, but perhaps not everything is lost.

In your case I would first try to move the whole VM out of the google file stream area, then register it again in Workstation on its new location and see if you can open the VM then.

--

Wil

[cyb2rg3]

Hi,

well... I'm not sure if it's about Google File Stream.

Because I'm using since several Years Several Virtual Machines with Google File Stream on my Mac, but there with Parallels for Mac (Virtualizing Windows, Linux, and Mac). And had never Problems like this.

with VMWare workstation now on an Windows 10 and Virtualizing Windows and Linux, and here the Linux ones without Problems... since few Months.

I had also a talk with Google Support, and talking about this Problems... and they did tell me it should not be an problem.

So i think there is something else... because is only happening to windows virtual machines... since few days.. maybe an configuration or something else

I did try to move the whole VM but it was still the same.

[a_p_]

To run a quick check on the virtual disk files, 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 the s001-s005 "xxx-....bin" files, and attach the .zip archive to a reply post.

for %i in (Windows-10-x64-EN-s???.vmdk) do @dsfo.exe "%i" 0 524288 "xxx-%~ni.bin"

Note: This command will extract only the .vmdk files' metadata, i.e. no user data.

You may of course use any other tool to extract the required data from the .vmdk files.

André

[wila]

Hi,

I had also a talk with Google Support, and talking about this Problems... and they did tell me it should not be an problem.

Interesting statement from Google Support. I really hope that they are right, but personally still have my doubts.

The reason for that is that file locking on Windows does work quite different from how it works on macOS/Linux.

Although there's more worries that I have, it will have to wait until I get a closer look at Google File Stream.

Anyways, I suggest to follow the steps from André, getting your data back and the machine up and running is the first priority.

He's the best person who can help you with that.

--

Wil

[cyb2rg3]

Hi Andre,

i did this extraction..

hope i didi it correct and that will help?

[a_p_]

If you can confirm the following file sizes (running e.g. dir *.vmdk), then I don't see any issues with the files' metadata.

4.261.937.152 Windows-10-x64-EN-s001.vmdk

4.261.937.153 Windows-10-x64-EN-s002.vmdk

1.459.879.936 Windows-10-x64-EN-s003.vmdk

3.888.316.416 Windows-10-x64-EN-s004.vmdk

  488.701.952 Windows-10-x64-EN-s005.vmdk

To further troubleshoot the issue, please copy the VM's folder to your local drive (e.g. to "c:\temp"), and try to start the VM from there. Then attach the vmware.log file to a reply post to see whether the error is still the same, or slightly different.

Right after copying the folder/files, please double-check the above shown file sizes in the lokal folder.

Although less likely, check the files for Alternate Data Streams (ADS) by running e.g. dir /R in the VM's folder.

André

[cyb2rg3]

yes i can confirm that this are the file sizes...

what is curious is..

I copied the whole VM to another two pathes.. one to C:\.... and the other to Google File Stream path..

and boths locations the VMs are running

I did also check about ADS.. but i did see nothing there.

[a_p_]

Interesting, but great to hear that you are now able to run the VM again.

I'm not familiar with Google File Stream, and I don't want to do finger pointing, but I assume that there was a synchronization issue, and copying the files somehow triggered a resync!?

André