Failed to open session for Virtual machine: E_ACCESSDENIED

[RichardCranium]

I have installed VirtualBox 6.1 and created a Windows 10 VM with current upates. I have installed my development environment (Delphi RAD Server).
I have installed all the required Delphi patches and components I required and took snapshots after each major task.
The process involved many shutdowns and reboots as I spread the work over several days.
I am now ready to start doing productive work but am now getting the error shown in the attachment when attempting to start the VM from a shortcut:

screen shot of error message

Screenshot 2020-12-20 173434.jpg (26.94 KiB) Viewed 4285 times

Failed to open a session for the virtual machine.
The object functionality is limited.
Result Code: E_ACCESSDENIED 0x8007005
Component: MachineWrap
Interface: IMachine {85632c68-b5bb-4316-a900-5eb28d3413df}

If I try to start the VM from the Manager, I get the additional information:

Runtime error opening 'H:\VirtualMachines\Delphi 10.4 Development\Delphi 10.4 Development.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)).

I am hoping someone can tell me what/how I clobbered what ever got clobbered between shutting down in the evening and trying to start up the next morning.

And even more better - how do I fix it without wiping everything and starting over?

Thanks in advance.

[mpack]

Runtime error opening 'H:\VirtualMachines\Delphi 10.4 Development\Delphi 10.4 Development.vbox' for reading: -103 (Path not found.).

This should be very easy to diagnose. Can you demonstrate that this path and file exists?

Tip: if you are using a Windows host and trying to run a VM from an external USB drive, then that's usually a bad idea. VirtualBox has to remember the drive letter when the VM is registered, but unfortunately, Windows has a habit of changing the drive letters assigned to USB drives, especially if you plug in two drives at the same time.

[RichardCranium]

Runtime error opening 'H:\VirtualMachines\Delphi 10.4 Development\Delphi 10.4 Development.vbox' for reading: -103 (Path not found.).

This should be very easy to diagnose. Can you demonstrate that this path and file exists?

Tip: if you are using a Windows host and trying to run a VM from an external USB drive, then that's usually a bad idea. VirtualBox has to remember the drive letter when the VM is registered, but unfortunately, Windows has a habit of changing the drive letters assigned to USB drives, especially if you plug in two drives at the same time.

Thanks for your reply.

The VM is on an SSD currently mounted in a docking station connected via (external) SATA.
The drive letter has been assigned by me: it is H:\
I intend to move it into the case, but haven't got a Round Tuit yet.

As for the existence of the file:

Screenshot 2020-12-20 220831.jpg (37.69 KiB) Viewed 4266 times

Hmmm, I see '...vbox' is 0KB which is passingly odd.

So, if I rename '...vbox.prev' to '...vbox' I should be back in business?

I wonder if there is a known cause?

[mpack]

A 0KB .vbox file size is certainly odd if the VM was not running at the time, but doesn't necessarily explain the error message which is quite clear: no such path.

So if the path does exist then I guess maybe the session you are running VirtualBox in does not have permission to access it. E.g. wrong user or not logged in. You aren't trying to run this as a service are you?

And yes, ".vbox-prev" is a backup file, so renaming it to ".vbox" is one way of restoring a corrupted .vbox file.

I see you are using a raw VMDK, the type with the small descriptor file. There could also be a path error in the latter. Can you zip and attach it (the 1K "Development.vmdk" file) here?

[RichardCranium]

Attached is the zip.

I think my problem is that I'm out of space. So I need to merge/delete a bunch of snapshots. But I need space.

I'm in trouble here I think.

[mpack]

Snapshots? But you're using a fixed size disk! It doesn't make sense to have a big flat VMDK hogging 200GB of disk space when it's not even being used except as the base of a dynamically allocated chain of snapshots.

Other than describing a fixed size flat VMDK for some reason, I don't see anything wrong in the VMDK, i.e. no reference to a non-relative path.

[RichardCranium]

Yes - I admit it. I don't know WTF I'm doing - yet.

The snapshots were to ensure if I screwed something up I had a fallback to something good. It didn't occur that a snapshot would take up so much space. I haven't worked with VM's (VM/370 a type 1 VM not a type 2 like VirtualBox) since my IBM System Programming days, and of course backups went on tape and we kept a limited number of generations. Is it not possible to put these snapshots 'off line'? What is the point of 'chaining' them together - is this an incremental backup sort of affair - if so, why do they take up so dang much room?

You are suggesting I should tear it down and start over? What file structure should I use? What do you recommend as a beginners primer?

[RichardCranium]

I'm back up and running.

I created a bigger partition on a spinning disk, cloned the SSD to that partition, futzed around undoing the crap I tried to get it working that didn't work, and it finally started.

I deleted all but two of my snapshots (the initial snapshot with Windows installed, activated, and updated, and my 'final installed configuration') and it seems to start much faster now

In the process, reality hit me like a ton of bricks: I kept thinking the 'virtual disk' is what was out of space, but of course it was the 'real disk' that the virtual disk was on. Dumb, I know better than that - really! I also think I figured out how the snapshot system works.

Anyway, next steps:

1) Get a clean backup of my final VM
2) Delete the leaf snapshot and restore the Windows Installed snapshot
3) Get a clean backup of the Windows Installed VM
4) Restore the final VM Backup
5) Delete/Merge the Windows Installed (Root) Snapshot
6) Delete/Merge the Final Config (Root=Leaf) Snapshot
7) Clean backup of the now Snapshot-less VM
8) The VM at step 7 is my final configuration with out snapshots.
9) Install the SSD into the workstation and load the VM to it.
10) I can now return to my development tasks that were interupted by getting the VM to work.

Does that all look right?

[mpack]

This discussion has actually been about the host, so does not belong in "Windows Guests". I'll move the topic to "Windows Hosts".

Getting rid of snapshots is always a good move: they do not work as backups, in fact they increase the odds of catastrophic data loss. You were lucky to get away with your data this time. If you have proper backups then there's no reason to have snapshots at all: important states that you might want to return to? You can get that too from a backup, except the real backup is more flexible and can be moved to offline storage until needed. And all it costs is a few seconds more, to attach an external drive and drop to the host for folder copying.

I'd also like to see mention of ditching that 200GB fixed disk (*). Hogging that much space on the host is not usually welcome and there's absolutely no good reason for it to be there. Fixed size does NOT give you better performance (thought that assumption is less dumb now that the snapshot overlays are gone).

(*) Easiest way to do convert fixed to dynamic is to clone it with CloneVDI and check the "Keep UUID" option. CloneVDI exclusively creates dynamic VDI, as there's really no need for anything else (nor does it give you the full functionality) in VirtualBox. If you want to move to a different platform in the future then export it to an OVA at that time. In the meantime you'll need to do some minor juggling to replace a .VMDK with a .VDI in the VM.

[RichardCranium]

Thank you for that. I will do the VDI thing. I did not realize that a VDI was 'dynamic' compared to a VDMK.

I really don't need a lot of space in the virtual disk - just space for Windows installation and a few apps, paging space, and a small development database - or maybe a pair for different versioning. Not much growth is expected over that, so dynamic growth when necessary should probably be just fine.

In the meantime you'll need to do some minor juggling to replace a .VMDK with a .VDI in the VM.

I'm not 100% sure what you are saying here.

Would I not 'just' CloneVDI, add the clone to the VM Manager and start using it? The old VM could then be deleted?
- hmm, no I guess that wouldn't work since the UUID cannot be duplicated
- I'd have to delete the old VM first, then add the Cloned version

This is of course all very different from my old VM/370 days (now z/VM I guess) but the issues are all very familiar.

[mpack]

In the meantime you'll need to do some minor juggling to replace a .VMDK with a .VDI in the VM.

I'm not 100% sure what you are saying here.

Would I not 'just' CloneVDI, add the clone to the VM Manager and start using it? The old VM could then be deleted?

CloneVDI does not clone the VM, just the hard disk. If you cloned the VM then it would lose activation because the "motherboard" UUID had changed. The motherboard UUID is distinct from individual hard disk UUIDs, which are a less serious problem.

However, if you clone just the hard disk, using CloneVDI (not VirtualBox) with the "Keep UUID" option checked, then no UUIDs will change and the guest OS will not lose activation. However VirtualBox does not allow conflicting disk UUIDs, and you don't want two disks in one VM anyway, so after cloning you need to go (in the manager UI) into File|Virtual Media Manager and Release and then Remove the old VMDK. The go to the VM settings, Storage panel, and add the VDI as an attached to the SATA controller. Double check that the snapshots are really gone before you do any of that: snapshots make this practically impossible.