raw disk access on windows host stopped working

[TuXator]

I am using raw disk access to run a linux VM on a windows host (Windows 10 1909).

The current setup worked fine for several years until the VM recently crashed with an IO error.
From that point on, the linux vm boot sequence gets paused as soon as the first write access happens on the linux root filesystem. (When the root filesystem is re-mounted read-write.)

00:00:16.170390 AioMgr0-N: Request 0x000000069072f0 failed with rc=VERR_ACCESS_DENIED, migrating endpoint \\.\PhysicalDrive0 to failsafe manager.
00:00:16.170631 I/O cache: Error while writing entry at offset 343468421120 (4096 bytes) to medium "ahci-0-0" (rc=VERR_ACCESS_DENIED)

The partition layout didn't change and according to the vmdk definition, the offset 343468421120 is inside the linux LVM partition. (343468421120 /512 = 670836760).

I verified the disk attributes using diskpart: The disk is not flagged read only and there is no volume assigned to the LVM partition that produces the error.
The host event log does not show any relevant info.

Additional info like disk layout, vmdk definition and logs are provided here: https://cloud.kloburg.at/s/PDr7gBSByJ6e2NF

Do you have any hints?

[mpack]

Raw disk access and EFI? That seems a bit adventurous.

00:00:16.170390 AioMgr0-N: Request 0x000000069072f0 failed with rc=VERR_ACCESS_DENIED, migrating endpoint \\.\PhysicalDrive0 to failsafe manager.
00:00:16.170631 I/O cache: Error while writing entry at offset 343468421120 (4096 bytes) to medium "ahci-0-0" (rc=VERR_ACCESS_DENIED)

I'm going to hazard a guess that the VMDK describes the Fedora partition incorrectly. Plus I don't know of any practical way to debug this for you - raw disk access is an experts-only feature.

[TuXator]

I'm going to hazard a guess that the VMDK describes the Fedora partition incorrectly.

I don't think so.
This setup worked fine for years now and the log clearly states that the offset is inside the LVM partition:

00:00:16.170390 AioMgr0-N: Request 0x000000069072f0 failed with rc=VERR_ACCESS_DENIED, migrating endpoint \\.\PhysicalDrive0 to failsafe manager.
00:00:16.170631 I/O cache: Error while writing entry at offset 343468421120 (4096 bytes) to medium "ahci-0-0" (rc=VERR_ACCESS_DENIED)

The sector offset is:
343468421120 / 512 = 670836760

If you look at gdisk partition output, this is definitely inside partition 6:

6       657981440      1000194047   163.2 GiB   8E00  Linux LVM

The corresponding line in the vmdk description is:

RW 342212608 FLAT "\\.\PhysicalDrive0" 657981440

Is there any windows expert with insights into the windows kernel windows block device layers who knowns how to debug such errors?

[BillG]

Probably, but you would be more likely to find one in a Windows forum than here!

[scottgus1]

One thought to consider, this problem may not be caused by Virtualbox:

The current setup worked fine for several years until the VM recently crashed with an IO error.

IO errors probably come from disks. Disks do have glitches. (I just had a bunch of CRC fails on some files on one of my backup disks, had to format & rebuild the backup, comparing files with my other two backups & the original now.... A glitch happened, no idea why.)

If you are certain, as in you can compare to your backups, that the raw disk definition file has not changed, then it could be that the physical disk's sector went bad. Could be this is an essential part of the VM's OS, and you'll have to restore the physical disk from a backup.

[TuXator]

One thought to consider, this problem may not be caused by Virtualbox:

The current setup worked fine for several years until the VM recently crashed with an IO error.

IO errors probably come from disks. Disks do have glitches.

The block device is OK.
Booting from the same partition natively (without the windows host) works fine.
Reading and writing sector 670836760 from the natively booted Linux works without problems. Even reading and writing that sector from the Windows host with a disk editor works.
There are no SMART errrors logged.
Besides a physical disk error error wouldn't raise VERR_ACCESS_DENIED.

I rather suspect some block device layer inside the windows host OS preventing VirtualBox from accessing the data.
However in that case I'd also expected the disk editor to fail too..

[mpack]

Booting from the same partition natively (without the windows host) works fine.

That is not a thorough disk surface test. Far from it.

[TuXator]

Booting from the same partition natively (without the windows host) works fine.

That is not a thorough disk surface test. Far from it.

I never claimed that.

[scottgus1]

If the VM run has trouble but the bare metal run doesn't, it would seem like there's a glitch in Virtualbox. However, the VM run was working before the VM crashed, and the crash could have introduced a problem that only VM operation shows. Just a guess....

My only suggestion is to restore this important VM from your backups, and see if the backed up VM works OK. Then transfer data from the the crashing V to the restored VM.

I doubt there's much we fellow users of Virtualbox could do to fix this.