VB Manager does not 'see' active VM

[LesD]

I wanted to ensure that whenever the server is restarted that my VM starts automatically (headless).

So I set up a Windows Task to run when the server starts.

Now, when I run the VB Manager GUI it shows the VM as Powered Off and when I try and start it I get an error

Failed to open image ... for writing due to wrong permissions (VERR_VD_IMAGE_READ_ONLY).

This got me all bothered for a while but after some loss of sleep I have discovered that the VM is running happily in the bowels of the server, it is just the VB Manager that is not seeing it.

I can actually see three vboxheadless.exe processes running (two sized 2.8 M and one 86 M) - not sure what the other two are.

All three processes are running under the same Windows user name as I am logged on as.

So I am guessing that a fresh set of XML control files have been created for the VM that starts via the Task Manager.

Bottom line, is there a way to get the VB Manager GUI to interact with the running VM so I can shut it down in a controlled manner?

[noteirak]

VirtualBox relies on a per-user security context communication channel to see which VMs are running or not. You need to use the same user for your scheduled task and launching the manager.

[LesD]

Thank you.

I suspected that it was user based (though I do not really understand the need for it).

However, I set the Task to run under user 'xxadmin' and I can see that VBoxHeadless.exe is running under xxadmin and I am logged in as user xxadmin and still the Manager shows the VM as powered off.

I am logging into the server using RDP as user xxadmin. I have tried logging in both with 'Console' ticked and not ticked and it makes no difference.

I think you are on the right track about this being a 'user' issue in so far as if I open Task Manager while logged in as xxadmin I still do not see the VBoxHeadless.exe task listed. I have to click "Show processes from all users" for it to appear even though the task is running under my user name.

So there must be something special about a task started using Task Manager.

[noteirak]

I suspected that it was user based (though I do not really understand the need for it).

It's only a design choice, there is no need per say.

However, I set the Task to run under user 'xxadmin' and I can see that VBoxHeadless.exe is running under xxadmin and I am logged in as user xxadmin and still the Manager shows the VM as powered off.
I am logging into the server using RDP as user xxadmin. I have tried logging in both with 'Console' ticked and not ticked and it makes no difference.
I think you are on the right track about this being a 'user' issue in so far as if I open Task Manager while logged in as xxadmin I still do not see the VBoxHeadless.exe task listed. I have to click "Show processes from all users" for it to appear even though the task is running under my user name.

So this is the security context I am talking about. While you may be running under the same user, you may not be under the same security context. This would typically be the case for the Task scheduler which runs into a different mode than regular GUI applications.
Another example of such behaviour (even tho it doesn't apply to you) is running VirtualBox as a normal admin user with UAC enabled, and then asking to run it with admin priviledges.
While you would be under the same username, the security context is different (you'll effectively be running under Administrator from a process point of view).

The issue here is how Windows segments all that, and the impact on VirtualBox. Even tho you ask the Task Manager to run the task under a specified user, you might inherit the system user profile or something like that.
I never use Windows to run headless VMs, Linux is far more adapted for that, so I can't advise further on what are the right steps to make this work, but this is the general direction you need to look into.

[LesD]

Thank you for the pointers where to start looking.

Now that you have 'woken up' this thread maybe someone will jump in. I will also do some more research.