Unable to manage a VM if started from rc.local

proci · Post by **proci** » 24. Jul 2008, 22:48

Hi,
I start a VM from rc.local using /usr/bin/VBoxManage startvm WXP -type vrdp >/home/vboxstart.log. After the VM startup is completed I'm unable to verify if the VM is running or not using VBoxManage list runningvms (I'm logged as root)...
If the VM is started from the console using the same command, I'm able to view the VM status. Why?
(Fedora Core 9, VBox 1.6.2)

bundabrg · Post by **bundabrg** » 27. Jul 2008, 05:02

I've noticed this as well. When I run VirtualBox using VBoxHeadless or VBoxSDL, it does not show as running using "VBoxManage list runningvms".

I've not investigated it enough yet.

- Brendan

brandonheat · Post by **brandonheat** » 27. Jul 2008, 07:40

try run the VBoxManage in rc.local as below

su - root -c " /usr/bin/VBoxManage startvm WXP -type vrdp >/home/vboxstart.log"

You have to specify which user (above is root) to start the because it look for ".VirtualBox" at the home directory. --brandon

Post by **TerryE** » 27. Jul 2008, 12:33

Alternatively create a startVMs script which you can su -<user> -c and this can handle setting VBOX_USER_HOME appending to log files etc.

Also note that in general leaving the RDP port to default is not a good idea, since this means that you can only start one VM per host.

proci · Post by **proci** » 28. Jul 2008, 18:11

Thanks Brandon: IT WORKS!

Mesmerism · Post by **Mesmerism** » 15. Aug 2008, 21:11

Is there any good solution to this problem other than running everything as root?

I have tried "VBOX_USER_HOME=/usershome/.VirtualBox/ VBoxManage list runningvms" but that doesnt seem to help if the users doesnt match. I think it has something to do with the user-named lock files created in /tmp, eg .vbox-user-ipc

This kind of defeats the purpose of "rc.vboxdrv stop" if root cant manipulate user vms. It isnt possible to send acpipowerbutton signals to the vms before the system shuts down.

Kind of a serious flaw I think.

---------------

Actually on second look while writing this post.. it might be related to the mysterious loss of state I keep getting, eg:
$ VBoxManage list vms
..
State: powered off (since ...
- or -
State: aborted

when the vm is running just fine (Im logged into it with windows remote desktop).

The VM is started with "VBOX_USER_HOME=/usershome/.VirtualBox/ VBOX_LOG_DIST=nofile DISPLAY=asdf nohup VBoxHeadless -s testXP &"

This is ver 1.6.4 on Slackware 10.2

thanks

Post by **TerryE** » 16. Aug 2008, 00:24

As long as you get your ownership and protections correct (including umasks) then you can use sudo to start the VM in any account and group. You just need to remember that you need to export the correct context before starting up any VBoxManage commands to manage this. You may want to wrap this all up in a shell script. You can also allow unprivileged accounts to do this if you you set up sudoers correctly. It's just a matter of getting all the details correct.

Post by **greenpossum** » 16. Aug 2008, 00:58

I don't know if this is your problem but I encountered something similar when starting a VM from an init script using Debian/Ubuntu's start-stop-server (probably the same with startproc in RPM based distros). The problem is that even though you may set the uid of the VBoxHeadless process right, it cannot determine the username. By trial and error I found that VBoxHeadless looks at $LOGNAME to get the username, so if you set this before the call, IPC will work correctly. IPC is needed for some VBoxManage calls.

Have a look in /tmp. If you see a socket with the name /tmp/.vbox--ipc, then this is the problem. The TRAC ticket is:

http://www.virtualbox.org/ticket/1890

Unable to manage a VM if started from rc.local

Unable to manage a VM if started from rc.local

Re: Unable to manage a VM if started from rc.local