virtualbox.org

It seems as though VBoxManage and other command line utils look for `%HOME%/.VirtualBox/VirtualBox.xml`. Can anyone confirm this is the precise behavior on Windows hosts? What happens if the HOME environment variable isn't configured? Is `%USERPROFILE%` used instead?

I've been trying to execute these tools from within a cygwin shell, and setting HOME to the path containing my `.VirtualBox` directory makes things work.. sometimes. If HOME points to the wrong directory, the utils run, but don't use the existing config (usually this means no VMs are found). If HOME is the empty string or undefined, something else happens and the config is located.

AFAIK, Windows doesn't use the %HOME% variable, but %USERPROFILE%. Doesn't cygwin have access to the system variables? Maybe you can set it to add them, so you don't need to set some manually.
Also, VB can use the variable VBOX_USER_HOME to change the default location for the config files and VMs. This isn't set by default, or set for the default location %USERPROFILE%\.VirtualBox.

Thanks for the reply, Sasquatch!

Sasquatch wrote:AFAIK, Windows doesn't use the %HOME% variable, but %USERPROFILE%.

Right, but it seems that VBoxManage and other utilities do pay attention to it, therefore, when using things like cygwin which update the environment to include HOME, you have to be careful..

Sasquatch wrote:Doesn't cygwin have access to the system variables? Maybe you can set it to add them, so you don't need to set some manually.

Yup! I've been trying to get this just right, but I thought it would be easier if I knew just which variables these utilities pay attention to. It seems that HOME does play a part on Windows hosts.

Sasquatch wrote:Also, VB can use the variable VBOX_USER_HOME to change the default location for the config files and VMs. This isn't set by default, or set for the default location %USERPROFILE%\.VirtualBox.

Great! I'll try this one out and see if it doesn't override any value in HOME.

If HOME is set, VBoxManage will look for "%HOME%/.VirtualBox/VirtualBox.xml". However, if VBOX_USER_HOME is set, then VBoxManage looks for "%VBOX_USER_HOME%/VirtualBox.xml". In either case, if the file or path does not exist, it's all created with default settings.

Unfortunately, I'm still not done.. I would like to be able to execute VBoxManage from the Windows Task Scheduler. This is oddly difficult as task user credentials and privileges are controlled in special (and to me, very magical) ways. I created a special cmd shell script which exec's "VBoxManage list vms" with all appropriate environment configuration (i.e. VBOX_USER_HOME is set, my VirtualBox.xml has absolute paths to vms and vdis). I then created a task which runs the script with Administrator level privileges. The task successfully exec's VBoxManage, but VBoxManage doesn't get the right config and lists zero configured vms. However, when I start up a cmd shell with Admin rights and run the script, it works just fine-- the config is found and I see the expected list of vms.

What I would really love is to be able to make VBoxManage print out to the console the path it is using for VirtualBox.xml on exec. Then perhaps I could learn more about this issue...

Even though you set the variables, it's still not a good idea to run the schedule as administrator. Your normal username should be used.

After an egregious waste of time I figured out how to get the SYSTEM user to exec VBox* utils without missing the config. The critical element was VBOX_USER_HOME + the "allow service to interact with desktop" setting in Windows service config. Without it, you see the mystifying behavior I mentioned earlier. See my other post for further details on using cygrunsrv to manage Windows services to control vbox vms.