Thursday, November 20, 2014

VirtualBox Raw Disk Access Problem on Windows 7

For quite a while I have enjoyed running a guest Mint Linux virtual machine on a laptop that must run Windows 7: I pulled out the PC's SATA CD/DVD drive and put a second SSD in its place. To run a VM from a raw disk, VirtualBox has to be manually configured to do that and it must be run as Administrator in Windows.

All that was well, although not without a few kinks I considered minor, until this morning. All of a sudden, I got a dialog box from VirtualBox saying that it failed to start due to permission issues. Here is a list of relevant messages I've copied from the log file, which should read better than the small dialog box:

00:00:01.774460 VDInit finished
00:00:01.775010 AIOMgr: Endpoint for file 'D:\MEMEME\vbox\mint.vmdk' (flags 00040723) created successfully
00:00:01.775716 AIOMgr: Endpoint for file 'D:\MEMEME\vbox\mint.vmdk' (flags 00040781) created successfully
00:00:01.775867 AIOMgr: Endpoint for file '\\.\PhysicalDrive1' (flags 000c0781) created successfully
00:00:01.775885 VMSetError: D:\tinderbox\win-4.3\src\VBox\Devices\Storage\DrvVD.cpp(3061) int __cdecl drvvdConstruct(struct PDMDRVINS *,struct CFGMNODE *,unsigned int); rc=VERR_VD_IMAGE_READ_ONLY
00:00:01.775911 VMSetError: Failed to open image 'D:\MEMEME\vbox\mint.vmdk' for writing due to wrong permissions
00:00:01.775923 VD: Opening the disk took 1593453 ns
00:00:01.776149 VMSetError: D:\tinderbox\win-4.3\src\VBox\Devices\Storage\DrvBlock.cpp(1077) int __cdecl drvblockConstruct(struct PDMDRVINS *,struct CFGMNODE *,unsigned int); rc=VERR_VD_IMAGE_READ_ONLY
00:00:01.776153 VMSetError: Failed to attach driver below us! Image is read-only.
00:00:01.776169 VMSetError: D:\tinderbox\win-4.3\src\VBox\Devices\Storage\DevAHCI.cpp(8450) int __cdecl ahciR3Construct(struct PDMDEVINS *,int,struct CFGMNODE *); rc=VERR_VD_IMAGE_READ_ONLY
00:00:01.776171 VMSetError: AHCI: Failed to attach drive to Port0
00:00:01.776180 PDM: Failed to construct 'ahci'/0! VERR_VD_IMAGE_READ_ONLY (-3205) - Image is read-only.
00:00:01.910243 ERROR [COM]: aRC=E_FAIL (0x80004005) aIID={8ab7c520-2442-4b66-8d74-4ff1e195d2b6} aComponent={Console} aText={Failed to open image 'D:\MEMEME\vbox\mint.vmdk' for writing due to wrong permissions (VERR_VD_IMAGE_READ_ONLY).
00:00:01.910298 Failed to attach driver below us! Image is read-only. (VERR_VD_IMAGE_READ_ONLY).
00:00:01.910299 AHCI: Failed to attach drive to Port0 (VERR_VD_IMAGE_READ_ONLY)}, preserve=false
00:00:01.927049 Power up failed (vrc=VERR_VD_IMAGE_READ_ONLY, rc=E_FAIL (0X80004005))
00:00:02.011279 UIMachineLogicFullscreen::maybeAdjustGuestScreenSizeOpenGL Error: Render SPU: (MakeCurrent) failed to make 0xe00112d5, 0x10000 current with 0x6 error.

I have checked the permissions on the "mint.vmdk" file, both my account and the local Administrators group had full control on the file. So that couldn't have been the file with read-only permission causing this indigestion.

I have also run DISKPART and checked that the disk was not set to READ-ONLY.

I have discarded my saved image and tried to start the VM from a clean state. All to no avail.

I am trying to fix this problem, but thought I may be able to get some help from the community by posting it to the VirtualBox forum.

[EDIT 2014-12-02]:Upgraded to VirtualBox 4.3.20. The problem persists. My suspicion of DDP|E grows deeper.

[EDIT 2014-11-25]: No progress on this issue. Sent email to Credent support (DDP|E was purchased from Credent, I guess.) Falling back to boot Linux on the laptop.

[EDIT 2014-11-23]: From every troubleshooting I could think of, it seems that the disk is held by some process that prevents VirtualBox from being able to write to it.

C:\Program Files\Oracle\VirtualBox>.\VBoxManage.exe internalcommands
listpartitions -rawdisk \\.\PhysicalDrive1
VBoxManage.exe: error: Cannot open the raw disk: VERR_SHARING_VIOLATION

C:\Program Files\Oracle\VirtualBox>.\VBoxManage.exe internalcommands
listpartitions -rawdisk \\.\PhysicalDrive2
Number  Type   StartCHS       EndCHS      Size (MiB)  Start (Sect)
1       0x07  0   /130/3   1023/254/63        122747         8192

From the SystemInternals Process Explorer, it seems that the Dell Data Protection's CmgShieldSvc.exe process is the most suspicious.

[EDIT 2015-05-08]: The issue is resolved in the latest DDP|E release --- kudos to our Windows image team and their working with the Dell (Credent) engineers.

1 comment:

  1. I read a "solution" - to plug out and back plug in the SATA cabel (really when Win is started), then drive is not shared anymore and rawdisc access works (I am not sure if it will work after Win reboot)...

    ReplyDelete