upgrade to VMware-player-15.5.2-15785246 results in module disk power failed

[melgoth]

After upgrading from VMware-player-15.5.1-15018445 to VMware-player-15.5.2-15785246 I got the error module disk power failed.

I started the VmWarePlayer and got the wrning

At the beginning I got the warning that I'm using a SCSI physical disk, which wasn't and isn't correct.

After that I got the next error:

Then I repaired the installation completely without any effect.

After uninstalling VMware-player-15.5.2-15785246 and reinstalling VMware-player-15.5.1-15018445 VMware Player works fine as before.

So maybe the program has a bug or the installation.

Best Regards

melgoth

[dariusd]

Hi melgoth,

Thanks for reporting this and giving so much detail.

To investigate this a bit further, if you still have a vmware.log (or vmware-*.log) for the VM failing to start on Workstation Player 15.5.2, I'd like to look at that file, if that is OK with you.  It will be located in the VM's directory, and the build number 15785246 will appear in the first line of the logfile.  Could you possibly attach it to a reply here?

Depending on how the virtual disk was created, the file I:\VMWare\MorgothVm\MorgothVm-0disk_H-Misc_D-Data.vmdk might be either very small (less than a few kilobytes) or quite large.  If it is a small file, could you please also attach that file to your reply?  It might explain what is going on.

Thanks,

--

Darius

[melgoth]

Hi dariusd

Sorry for my late reply, lot of work to do.

I got the same error with  15.5.1 build-15018445 and there are a lot of log files.

in the location of the Vm file:

24.03.2020  20:24            71 292 vmware-0.log

24.03.2020  17:43           362 284 vmware-1.log

24.03.2020  17:38            71 269 vmware-2.log

24.03.2020  20:37           365 775 vmware.log

               4 File(s)        870 620 bytes

on the system disk of the host are several log files I archived only the last ones with the same date

but currently I don't know hot to attach files

[dariusd]

To attach files, look for the Attach button/link/thing in the bottom-right corner of the editor window when composing a reply.  It's not available within the quick-reply facility directly in your Inbox; You have to visit the full discussion thread and hit the appropriate Reply button on that page, then the Attach button should be available for use in the screen which appears next.

--

Darius

[melgoth]

Hi Darius!

Thank you for your patience.

•      log_save.rar includes all VMware-*.log from the location of the virtual machine.
•      vmware-user.rar includes the largest log files from the user directory
•      vmware-SYSTEM-600348704.rar includes the latest one from the system folder

melgoth

[dariusd]

Thanks for the logs!

The vmware-0.log shows that your VM is using a physical disk on a virtual SCSI controller.  (Perhaps the performance hint message is poorly-worded, but that is what it means when it says a "SCSI physical disk"... it doesn't matter what the disk's host hardware type is.)

It also shows that Workstation Player asked your host OS for exclusive access to the physical disk, but the OS was not able to allow exclusive access, probably because some other program was using the disk:

2020-03-24T20:24:31.350+01:00| worker-6940| I125: W32Util_DismountVolumes: FSTCL_LOCK_VOLUME failed on volume \\?\Volume{011468fd-a060-2110-d639-d501fad12802}: 5

When that error message appears, you will need to check which other programs you are using which might be accessing the physical disk mentioned in the error message.  This could potentially include background processes such as backup or replication utilities, virus scanners, or indexing services.  If you are unable to track down the cause, perhaps the Sysinternals Utilities from Microsoft can help... Try Process Explorer or Process Monitor, perhaps.

Interestingly, the error code from Windows is actually "access denied", but the vmware.log (and vmware-0.log, etc.) files suggest that this is unlikely to be a permission problem, and is most likely simply caused by the disk being in use by something else, and Windows is being weird about its error codes.

--

Darius

[melgoth]

Hi Darius!

Thanks for your answer!

So is it by design that all disks which are recognized by the virtual machine have to be used exclusively and the host are not able to access it?

Is there another better possibility to use a disk from host and the virtual machine at the same time?

With the current version I was able to start the VM after closing all the desktop processes, but with the 15.5.2-15785246 I couldn't do it successfully. So was i just unlucky because one background process was still active?

Thanks a lot for your time.

melgoth

[dariusd · Accepted solution]

That's right... Physical disks attached to a VM must be attached exclusively to the VM.  Attempting to share a physical disk between two OSes at the same time would almost certainly cause massive disk corruption, and the same applies for sharing a filesystem between host OS and guest OS, so we have to ask the host OS for exclusive access to the disk(s) before we can power on the VM.

(For completeness, I'll mention that there are solutions involving the use of a clustered file system and shared SCSI buses to allow multiple OSes to concurrently use a single filesystem, but doing that between a host and a VM seems like sheer madness, and you really don't want to go down that path unless you have an absolute need, a lot of time on your hands and a very good backup strategy... trust me.)

We made only one change in the physical disk support between 15.5.1 and 15.5.2, and that was to fix a possible crash while powering on a VM using physical disks on Windows hosts in extremely rare circumstances and a very unusual configuration, and it is not relevant to your VM at all.  Nothing else was changed in our disk support between 15.5.1 and 15.5.2.

You may have simply been unlucky with the background processes when you tried 15.5.2; The SysInternals tools might be able to give you more information if it still doesn't want to work correctly.

Random thought: Can you switch to using the Shared Folders functionality?  It allows for the guest to access files from the host, and because it behaves like a network filesystem it can allow concurrent access between the host and the guest.  (There certainly are use-cases where Shared Folders might not be suitable, but it is worth trying if you haven't already done so.)

--

Darius

[melgoth]

Hello Darius!

I have reinstalled the VMware-player-15.5.2-15785246 and changed the disks to shared folders. Now it works as expected - great software helps me a lot to keep older system at live.

Thanks for your help!

Best Regards

melgoth