VBOX_USER_HOME var ignored once PEUL accepted

[bflong]

Once the main VirtualBox gui is run and the licence is accepted, creating and managing virtual machines with VBoxManage ignores the VBOX_USER_HOME var. Below I start with no .VirtualBox directory at all.

$ VBOX_USER_HOME=~/.VirtualBox-TEST VBoxManage createvm -name VMTEST1 -register VirtualBox Command Line Management Interface Version 3.0.12 (C) 2005-2009 Sun Microsystems, Inc. All rights reserved.

Virtual machine 'VMTEST1' is created and registered. UUID: ddbe8c75-1221-446c-8b9c-9df203321d45 Settings file: '/home/user/.VirtualBox-TEST/Machines/VMTEST1/VMTEST1.xml' <<< THIS IS CORRECT

$ VirtualBox << Run without the var and accept the license, which creates ~/.VirtualBox

$ VBOX_USER_HOME=~/.VirtualBox-TEST VBoxManage createvm -name VMTEST2 -register VirtualBox Command Line Management Interface Version 3.0.12 (C) 2005-2009 Sun Microsystems, Inc. All rights reserved.

Virtual machine 'VMTEST2' is created and registered. UUID: 901d2034-1f2e-47cd-8a16-ebdaddeb8ab1 Settings file: '/home/user/.VirtualBox/Machines/VMTEST2/VMTEST2.xml' <<< THIS IS WRONG

[Frank Mehnert]

That's not a bug. The correct usage is

export VBOX_USER_HOME=~/.VirtualBox-TEST
VBoxManage ...

[bflong]

Exporting the var before running VBoxManage makes no difference whatsoever. However, I did find the real cause of the problem. I was working so fast that the background VBoxSVC and VBoxXPCOMIPCD were still running when I went to run the 2nd VBoxManage command. If I let them die, or kill them specifically, it uses the VBOX_USER_HOME var.

[Henk]

This problem still exists in 3.1.4

Not sure why this was set to invalid, as the original example is valid use of passing environment variables to an application.

I have VBOX_USER_HOME in my environment variables (/etc/env.d/90virtualbox) and it shows up when running the export command. The problem still exists.

[Frank Mehnert]

Guys, this still works here and I've no idea what you are doing wrong. First, the export command will not show you the current state of an environment variable. Use echo $VBOX_USER_HOME from a command line. Second, a better check is to do the following:

$ pidof VBoxSVC
10843
$ cat /proc/10843/environ

This will show you the environment of the VBoxSVC process. And I'm quite sure that in your case it will not contain the VBOX_USER_HOME variable.

[Henk]

Frank, you're right. It technically works as you describes. In my case the problem was that the user's environment does have VBOX_USER_HOME set but the VBoxSVC process does not.

The expectation is that after changing this environment setting in the user's environment that it will take effect immediately when using VBoxManage. This is not unreasonable as it is how the majority of the software works.

What I missed is that the VBOX_USER_HOME value is read when VBoxSVC starts, which could even be another user's environment, something that is not visible to the user. Short of a reboot or a messy killall there is no easy way to get VBoxSVC to update its environment.

This is still a bug as once you get into this state you can't create or modify VM's any longer. For example, VBoxManage createvm does create the VM using the environment variable but list vms does not show it.

May I recommend some improvements:

1. Ideally VBoxManage uses the user's VBOX_USER_HOME environment variable, as this behaviour is in line with the majority of the software. This means passing it along in communication with VBoxSVC.
2. If the first option is not possible then VBoxManage could compare the VBOX_USER_HOME variable with that of VBoxSVC and issue a warning if they both exist and are different.
3. If these options are not possible then a big fat warning in the documentation might help.

Thanks for the reply Frank,

[Frank Mehnert]

I'm sorry, but I don't think this is a bug.

The .xml files are only read/written by VBoxSVC and there is only one VBoxSVC daemon per user at one time. So of course it makes only sense to set the environment variable for the VBoxSVC daemon. If already a VBoxSVC daemon is running there is no way to change it's mind about the location of the .xml files and this wouldn't make sense. If that would be really necessary then kill VBoxSVC. If this isn't possible because there is an open instance (either a VM running or a GUI is accessing the settings) then killing VBoxSVC would not be allowed.

Taking into account that changing VBOX_USER_HOME is only necessary in very rare cases I don't think that we will change anything. Ok, perhaps we should document that that environment variable applies only to the VBoxSVC daemon.

[Henk]

I can see your point but the fact remains that if you specify VBOX_USER_HOME after VBoxSVC is started, VirtualBox VM's are no longer working in either the old or new location. Don't you think that would be considered a bug?

[Frank Mehnert]

No, honestly.

[Frank Mehnert]

Because that is like environment variables work. Again, we will document this behavior but nothing more.

[Klaus Espenlaub]

Don't consider it a bug either, as there are ways to use this behavior to have multiple .VirtualBox directories (more environment variables needed).