[Fixed] Cannot switch to different real Host Drive in running VM guest (#18288)

[Master101]

---

ModEdit; related ticket: #18288: Cannot switch to different real Host Drive in running VM guest

---

Yesterday I updated to latest VirtualBox version 6.0.0 r127566 (Qt5.6.2) on my Windows 10 64-Bit Build 1809 host.

Since then I am experiencing the following behavior on all of my VM guests:
- Under "Devices -> Optical Drives -> SATA (SATA Port 1)" my "Host Drive 'E:'" is currently selected (visible by the "OK" hook).
(- Optional step, but the result is the same if this step is omitted: Now I select "Remove disk from virtual drive" -> the "OK" hook disappears and the virtual disc is ejected.)
- Now I select a different "Host Drive" (e.g. 'F:' or 'G:'), but there is no "OK" hook visible next to the selected drive and the new Host Drive is not active in the VM.
- If I select the original first Host Drive ('E:') the "OK" hook appears again and the drive is active again in the guest VM.
- It is however possible to switch from a real physical Host Drive to an ISO by selecting "Choose disk image...".

If I wish to switch to a different real physical Host Drive, I need to shut down the VM guest, select the VM within the "Oracle VM VirtualBox Manager", open "Settings" of the VM, switch to the other physical Host Drive within the "Storage" options and then restart the VM guest.

This bug was not present under VirtualBox 5.2.x.
Does somebody know how to fix this issue?

[socratis]

For future reference, you should discuss any issues in the forums first, before opening a ticket...

I take it host drives F: and G: as also CD drives, right? Otherwise it won't work.

We need to see a complete VBox.log, from a complete VM run, where the problem occurs:

• Start the VM from cold-boot (not from a paused or saved state) / Observe problem / Shutdown the VM (force close it if you have to).
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

[Master101]

Hi!

Thank you for your message.

I did the following as you suggested:
- Start the VM from cold-boot (not from a paused or saved state).
- Verified that Host Drive E: is working in file manager of guest.
- Selected "Remove disk from virtual drive" (the "OK" hook disappears and the virtual disc is ejected).
- Selected Host Drive F: -> there is no "OK" hook visible next to the selected drive and the new Host Drive F: is not active in the VM.
- Selected Host Drive E: again -> the "OK" hook appears again and the drive is active again in the guest VM.
- Shutdown the VM.
- Saved latest VBox log file and attached it to this posting.

Thanks again for your help!

[socratis]

You didn't reply to a basic question:

I take it host drives F: and G: as also CD drives, right? Otherwise it won't work.

That's vital! Only actual CD drives can be attached, and the way that you have the issue phrased you seem to think that *all* drives can be attached. Which is not the case!

[Master101]

Oh, sorry, that I forgot to clarify.

Both Host Drives E: and F: are optical disc drives attached via SATA to the Host:
E: -> HL-DT-ST BDDVDRW GGC-H20L
F: -> HL-DT-ST BD-RE BH10LS30

I would like to repeat:
I did not change anything regarding the configuration on my Host or the letter assignments.
Thie issue did not occur at all with VirtualBox 5.x, but after updating to VirtualBox 6.x it does.

EDIT:
I think this issue might be the same as already reported in Bug Ticket #18273 on January, 3rd 2019 by another user.

[socratis]

Both Host Drives E: and F: are optical disc drives attached via SATA to the Host:

OK, thanks for clarifying that!

Thie issue did not occur at all with VirtualBox 5.x, but after updating to VirtualBox 6.x it does.

What if you downgrade to 5.2.22? Does it revert course, and it works?

I think this issue might be the same as already reported in Bug Ticket #18273 on January, 3rd 2019 by another user.

The reporter in ticket #18273 talked about a single CD/DVD drive on the host, but you're right they may be related. But on the other hand, for all I know it might have been a defective DVD, there weren't too many details given...

I have a Win host that I just resurrected, and I haven't quite put it up in working form again. It has two CDs there (hopefully working still), I'll try to recreate the scenario, probably tomorrow...

[Markm]

I wasn't sure if I am supposed to post here, since the issue seems close to the same.

I think I am having a similar problem. I've tried to make my VM recognize the host drive C: as virtual drive e: and host drive D: as virtual drive f:, but it often reassigns (or the host does, I'm not sure what) the D: to h: instead (resulting in applications, batch files, & macros & shortcuts not finding the files they are directed to.)
I occasionally get the VM to allow me access to the f: drive, but can't figure out how it happens; otherwise XP error box says "The local device name is already in use".

2019 0108 150927 Virtual box forum help preparation:
version of VirtualBox and installed the Guest Additions: 5.2.22 r126460 (Qt5.6.2) with installed Guest Addition matching version number.
Host & Guest make, version including 32 or 64 bit, and the amount of memory available to both.:
Host: ASUS i7-8750H @ 2.20GHz 2.21 GHz; 16.0(15.9 usable) GB; 64 bit x64-based processor, Win 10 Home; Workgroup: WORKGROUP
Guest: XP Home Service Pack 3, 32 bit, Base Memory 2048 MB, Video Memory 60 MB Screens: 2 [currently & usually run only 1 screen]

VM log files See below, including Hardening logs.

I've tried ideas from online, including remarks between socratis & the user who posted this problem initially. Socratis has been a great help in the past (?2016?) on a Win7Pro host issue with the same WinXP guest machine (now running on this Win10 host).

I tried unsuccessfully to attach a PDF file, but it's not allowed, so here's some of that:

History:
2018 1230 174519 more efforts on not having XP VM settings for host hard drive access being interfered with;
Earlier, I found that if any external drives were assigned a drive letter by Win10, it could be they'd get "E" and "F", and then the XP VM's effort to use E & F for XP shortcuts, etc., would be thrown off;
Recently, I found that somehow the CD drive(? actually, the ASUS/Hos has no optical drive, so this isn't quite right) could also get assigned the E or F drive letter & this would also interfere w/ the xpvm trying to use F for the main My Documents folder (i.e. mapping to the Win10 D drive My Documents &/or XP using the F drive as the drive for the Win10 D drive);
So, I used unchecked the User Interface Device the "Insert Guest Additions CD image . . . " because either Vbox or the XP VM or something was assigning the "F:" as the drive for the CD, which would interfere with all my Office & Explorer, etc., references to the F drive (i.e. the Win10 Host's "D" drive)

2019 0103 233202 Have uninstalled vbox guest additions to make sure only one version is installed - 5.2.22r126460
The issue is solving the shifting drive letter assignments given to my XPVM;
I solved it, so that my XPVM has two drive maps to the Host: E: drive & F: Drive;
E: is for the ASUS C: drive & F: is for the ASUS D: drive; most data is on the D: drive;
I got this set up with help from the following site:
https://www.howtogeek.com/189974/how-to ... l-machine/
The above site didn't actually match everything I had to do, but was so close that the ideas were understandable, etc.;

2019 0107 142353 Unfortunately my believed solution as described in my 2019 0103 notes above hasn't panned out.
I'm still getting problems w/ access to the D: (aka XPVM F: drive), I think because automatically assigned drive letters!

2019 0108 154225 In preparation, I reviewed an issue that seemed close; viewtopic.php?f=6&t=91161
Socratis mentioned only actual CD drives can be attached; I'll ck & see about that; Having seen an "optical drive" entry, I clicked to remove it from the Oracle VM VirtualBox Manager's Storage section; I'll restart after that;

2019 0108 160113 So far this actually worked, so maybe that's a long term solution, I'll watch;
Actually, I'll restart the Host system & then the guest watch results

2019 0108 161327 Nope, it didn't work; the VM won't let me access the virtual f: drive at all.

My Host drives are C:, a 256G SSD, & D:, a 1TB HD; both came with the laptop;

01 & 02 - VBox Logs - Drive letter problem (b4 removing optical drive) 2019-01-08-15-15-43.log.zip

This is before implementing an idea by removing optical drive.

(51.29 KiB) Downloaded 13 times

03 & 04 - VBox Logs - Drive letter problem 2019-01-08-16-12-29(no optical drive).log.zip

This is after removing the optical drive. It allowed the VM to see the host d: drive correctly, but the fix went away after saving & restarting vbox.

(49.02 KiB) Downloaded 11 times

[Master101]

What if you downgrade to 5.2.22? Does it revert course, and it works?

As I did not want to mess with my regular productive system/host, I tested the behavior on my laptop, also with two optical disc drives attached to the host.

VirtualBox 5.2.22 -> The issue does NOT occur. It is possible to switch between Host Drive D: and E: while the guest/VM is running.
VirtualBox 6.0.0 -> The issue DOES occur. It is NOT possible to switch between Host Drive D: and E: while the guest/VM is running. Switching between Host Drives D: and E: is only possible via VM settings while the guest/VM is in shut down state.
Downgrade to VirtualBox 5.2.22 -> The issue does NOT occur. It is possible to switch between Host Drive D: and E: while the guest/VM is running.

Additional notes:
My laptop (host) has Windows 10 64-Bit Build 1803 installed and my regular PC (host) has Build 1809.
The issue occurs on both Windows 10 Builds using VirtualBox 6.0.0.

To me it seems to be obvious that this is a bug and that it has been introduced with VirtualBox 6.0.0.

[Markm]

One issue, one thread. I'm doubting my inquiry/post belongs here.

Initially, it seemed to me it was a very similar issue, but I'm using ver 5.2.22 (not 6) & though a virtual optical disk is a problem, the drives I'm trying to get a stable map to are internal hard drives(SSD & HD), not external or internal optical ones.

Also, the initial posting person indicates he didn't have his problem in 5.2.22 version he was using.

What does seem to be common is a Win10 64 bit host & unstable drive assignment problems on the VM.

[Markm]

Hope this is of value. I, at least temporarily, fixed my drive mapping problem. There are two solution components, the first I can only stab in the dark at the resolution, the second I tested about 27 different ways to replicate failure and resolve it again:

1. For some reason, using a Clone of my XPVM (hereafter XPVMC), I compared about 15 different drive & network settings & fiddled around with getting some shared folders finally set up. In the XPVMC, I removed shared folders & put them back without ("w/o") specifying permanence or non-transience. Permanence was assumed by VBox Mngr (no surprise). I noticed then, that my non-Cloned (original) XPVM (hereafter XPVMO) had the two shared folders pop up. Since it was a very long time waiting to see them, it seemed connected to my fiddling with the clone, but (a) that doesn't really make sense to me unless VB Mngr can actually affect the Windows 10(hereafter "W10")/host and (b) it's possible the XPVMO was just taking forever to populate. Nevertheless, I was able to again map the Host D: drive to the XPVMO Guest F: drive. That stuck through the rest of my testing, though the F: map was still sometimes non-operational, as discussed following.

2. I eventually figured out that my 3 HP Printers plugged into a chain of 2 unpowered USB 2.0 Hubs ("Device3") resulted in interference w/ the drive assignments. D: either could not be mapped to F: (F: would not even be in the mapping list as an option) or, once I had it mapped, it would not work if the host gave a drive letter (never F:, I think always "H:", but that was enough to interfere, apparently) USB assignment to Device3. Device 3 would either prevent F: from being available for mapping, or would block it's operation in the XPVMO if it was already mapped. The XPVMO error msg when clicking on the F: drive once it was mapped, but still interfered with was as follows: Windows. An error occurred while connecting F: to \\vboxsvr\d_drive. Virtual Box shared Folders: the local device name is already in use. This connection has not been restored.[line breaks removed, punctuation added] I tested this through, I estimate, at least 15 permutations (of application & computer restarts from different levels & USB configurations) to reproduce the failure and reproduce success.

One course of testing involved differentiating between results if Device3 was simply unplugged & replugged in or unplugged & disconnected from power at the USB 3.0 Hub level preceding the Device3 chain & replugged in. By the way, I tried to be vigilant about listening to the sequential relationship between (a) the clunks (WXP) and beeps (W10) that the OSes give when plugging in and unplugging usb devices and (b) the operational states of VBox Manager, W10 & WXP.

Conclusion: I hypothesize that unpowered usb devices (especially with insufficient residual electricity "pressure" in the wires) in a Win10 Host will result in a low power USB device state that W10 will interpret as a need for a supplemental drive assignment (some devices use 2 USBs for power + data) which can then interfere with drive letter assignments or operations. I am no expert on USB power states or Win10, this is a guess.

The reason I think this may be relevant to your thread is that you've got two external USB devices that may draw substantial power (even if powered) to spin data devices.

I am hypothesizing, but somewhat confident that my problem, at least, may be resolved.

Let me know what you think.

[Master101]

As the issue I reported in this thread only occurs regarding regularly attached optical disc drives and there are no USB devices involved and it could be reproduced on a completely different host, it seems clear to me that Markm's issue is a different topic which should not be covered here.

So again my questions:
Are there any news or suggestions regarding my original issue?
Will a future release of VirtualBox fix this issue?

[Master101]

Just to provide an update:
The issue is fixed with the latest release VirtualBox v6.0.2.

[Markm]

I find Master101's comment that my post is "a different topic" at least plausible.

In fact, my later posts do not include a solution, but the basis for a work-around. My work-around is to not plug in the USB device (which I've isolated using the Disk Management tool to being my HP Color Laser Printer CP1518ni ) until the XPVM has validated my mapping of the host D: drive to the guest F: drive. I've also added, as a work-around, a forced assignment by the host of "Z:" as the drive for the USB culprit device (HPCP1518ni color laser printer) (using the Disk Management drive letter change utility, also operational through the the command line diskpart volume letter assignment tools). I'm not sure that's going to be a solution, but I'm trying it.

I still expect that I need control of either the Host or Guest to prevent an override of my mapping of the host D: to the guest F:. Master101 indicates his problem is resolved in VirtualBox v6.0.2. I don't know if my problem's resolution, or the capacity for a resolution, is also included in VirtualBox v6.0.2, and I'm reluctant to upgrade and cause any different problems or set of problems.

I'll start a new topic (if I'm allowed).