VBox 6.1.32 problems with VMs located on network share

[watson]

I'm trying to upgrade VirtualBox to 6.1.32 from 6.1.30 and having problems with a couple of guests that are located on network shares. Both guests happen to be Win 10, but I don't think that's an issue. I also have a couple of Linux guests that are located on my local hard drive, and no apparent problems there, although I haven't yet upgraded VMWare Tools. My host is also Windows 10 Pro.

After I install 6.1.32, both of the network-located guests show the same error:

Runtime error opening 'V:\Emerald\Emerald.vbox' for reading: -103 (Path not found.).
F:\tinderbox\win-6.1\src\VBox\Main\src-server\MachineImpl.cpp[754] (long __cdecl Machine::i_registeredInit(void)).
Result Code: E_FAIL (0x80004005)
Component: MachineWrap
Interface: IMachine {85632c68-b5bb-4316-a900-5eb28d3413df}

The host machine does not have a mapped F: drive, much less having tinderbox installed. I'm puzzled as to why that error is turning up.

If I navigate to V:\Emerald and try to open Emerald.vbox with VirtualBox, I get the same error, plus one additional line:

Callee: IVirtualBox {d0a0163f-e254-4e5b-a1f2-011cf991c38d}

This guest is completely shut down when I try to launch, and I don't see any log content relating to a failed attempt to start.

I do have Hyper-V active on this host (I have not been successful in getting a Win 11 instance to install in VirtualBox), and it's my suspicion that that may be a part of this problem. However, as noted, I'm not having problems with VBox guests that are in local storage. I know that I did have problems with Hyper-V with VirtualBox 6.1.28, and I ended up passing on that one until 6.1.30 was released.

Ideally, I'd like not to shut down Hyper-V, although if I can find a way of reliably setting up Windows 11, I really don't need Hyper-V. For the moment, I've downgraded back to 6.1.30, but I believe there is a security fix in 6.1.32, and I'd like to be running on that version.

Is there some sort of hack/work-around for the current situation, or do I get to choose between shutting down Hyper-V or staying with 6.1.30 until 6.1.34 is released (and hopefully, this problem fixed)?

[scottgus1]

F:\tinderbox is the development folder on the Virtualbox devs' build computer; you can ignore that part of the message.

This is the pertinent part:

Runtime error opening 'V:\Emerald\Emerald.vbox' for reading: -103 (Path not found.).

This literally means that Virtualbox cannot find the .vbox file it is set to find on that path.

From this:

I'm not having problems with VBox guests that are in local storage.

I gather that there is a problem with Virtualbox interpreting the correct path to the V: drive, which apparently is a mapped network drive.

If Hyper-V was enabled when 6.1.30 was installed and the V: drive VMs were working, then it's not likely that Hyper-V is getting in the way of 6.1.32 reading the V: drive. However, if Hyper-V was enabled at the same time 6.1.32 was installed, then we can't say for certain. Please clarify if Hyper-V was enabled when these VMs used to run.

Now that you have downgraded Virtualbox back to 6.1.30, are the V: drive .vboxes accessible again?

[watson]

Definitely odd that VirtualBox is having problems finding something. Yes, it's a mapped network drive. I didn't mention before that if I use the VirtualBox open file dialog to navigate to that location, Emerald.vbox is not visible. That happens both if I navigate to the mapped drive V: or I specify by \\hostname\location (or even IP address). At that point, VirtualBox is simply not recognizing the existence of a .vbox file where one existed.

I've downgraded to .30 (and have done this on a previous attempt), and after I remember to reinstall the .30 Extension Pack, things are back to normal, where I'm able to start any of the guests, whether local or network located. Just for grins, I did start up my Hyper-V VM, and at the moment, I have that one running alongside the VirtualBox guest located on the LAN drive, and no apparent difficulties for either one, except perhaps some residual slowness on the VBox guest. That's hard to tell, as I don't make a lot of use of that guest, and have deliberately under-allocated memory to it. I'm used to slow, but it might be a little slower if the Hyper-V instance is also running.

In any case, it looks like the primary issue with .32 seems to be a bug that is causing it to not recognize a network-located guest correctly. I don't know if this is a problem imposed by the presence of Hyper-V, or something more simple, in not recognizing configs located in a networked location.

[scottgus1]

if I use the VirtualBox open file dialog to navigate to that location, Emerald.vbox is not visible. That happens both if I navigate to the mapped drive V: or I specify by \\hostname\location (or even IP address).

If you open the "V:\Emerald" folder in Windows while Virtualbox is failing to show the .vbox file, does the .vbox file show in the folder?

[watson]

It shows from the Windows Explorer, but not from the open file dialog in VirtualBox.

[watson]

With VirtualBox 6.1.34 released, I've just tried an upgrade again. Behavior seems to be a little bit different, but still problems.

As with 6.1.32, the host still isn't finding guests that are located on network drives. If I go to Machine -> New, it's not showing me any mapped drives at all, just local drives. As noted previously, I normally have a guest located on V:\Emerald. However, on 6.1.34, VirtualBox doesn't acknowledge that any mapped drives exist, neither V:, nor any other drives. That's a little bit different than 6.1.32, but no more productive (or less frustrating). In a similar way, if if I browse to \\hostname\location\Emerald using the VirtualBox dialog, I can see Emerald.vdi, but now I need to remember how to move a guest to a new location. I'm not sure if reference without a mapped drive solves the problem or not, but definitely worth trying.

In the meantime, one thing that comes to mind is wondering if Oracle has quietly changed licensing structure, especially for unpaid use. I know that for other classes of software that they differentiate between home use with unpaid versions and business use that requires a paid license is with networking support. Backup software commonly does that, where there aren't very many options that allow backing up to a networked drive with an unpaid version. I wonder if Oracle may be doing that with VirtualBox, of disallowing access to network-located guests from an unpaid version.

[fth0]

Please provide a (zipped) copy of the C:\Users\<username>\.VirtualBox folder. The (tenfold rotating) log files should contain logging information about your latest attempts.

[watson]

Looks like I managed to follow a rabbit trail to an irrelevant conclusion.

I had to do a reboot of the Windows host for other reasons, and when I came back to looking at VirtualBox issues, that seems to have cleared any problems. After getting the proper Extension Pack installed, I'm not having any problems with getting to network-located assets.

I have one guest launched right now and am starting up a second, so that I can get the Extension Pack installed inside each of the guests.

I'm going to assume that the resolution to my problem is something that was specific to 6.1.32 and that .34 seems to have fixed the problems I've been having, even if I don't see anything obvious from the release notes.

[scottgus1]

Since you're up and running, that's good! I haven't heard of folks running VMs on network drives having issues, aside from your setup. So while a system-wide bug might be there, it could also be something local on your computer/network that got knocked loose finally. Glad you're up and running, though!

wondering if Oracle has quietly changed licensing structure...

Not in this particular manifestation, no.

I can get the Extension Pack installed inside each of the guests.

You'll mean the Guest Additions, not the Extension Pack. The EP is installed in the main Virtualbox Manager window on the host. There is no installation mechanism for EP in a VM's OS, and the EP files if force-unpacked won't do anything. The Guest Additions go inside the VMs.