2

I'm on Ubuntu focal and trying to start

VBoxManage list vms

using a different config directory. This can be achived by changing (or setting) VBOX_USER_HOME and works quite well in terminal if simply I type:

export VBOX_USER_HOME="/new/config/path"
VBoxManage list vms

However when I try the same code from a bash script :

#!/bin/bash
export VBOX_USER_HOME="/new/config/path"
echo "$VBOX_USER_HOME"
env | grep VBOX_USER_HOME
VBoxManage list vms

the variable is not "seen" by VBoxManage so that it lists the VMs configured at the default location even though the variable was apparently successfully exported to env. Here is how the output looks like:

/new/config/path
VBOX_USER_HOME=/new/config/path
lists the machines from default config

I know that /usr/bin/vboxmanage is a link to a script which calls eventually the real application $INSTALL_DIR/VBoxManage. Just to make sure the VBox scripts do not clean the environment I tried calling the binary directly. However, this made no difference.

So, how comes the exported variable is visible to $INSTALL_DIR/VBoxManage when I do the export from the terminal but is invisible when I do it from a script?

Amendment: I just found out that this is some kind of race condition issue with Virtual Box. If I do the export in the terminal and directly run $INSTALL_DIR/VBoxManage list vms afterwards, it erroneously shows the VMs from the default config just like the script. Subsequent calls then always return the old list Subsequent calls show after 5 to 10 seconds the new list. If I do the export and wait a little longer, the list is correctly updated to the VMs configured at the new location. Subsequent calls now always return the new list. So the solution to my problem is to insert a sleep into the script. Anyway, I will reward answers that can explain this unexpected behaviour.

9
  • 1
    Are you saying there's both /usr/bin/vboxmanage, /usr/bin/VBoxManage and a third $INSTALL_DIR/VBoxManage? Which of these are you running in the first two command blocks? – muru Feb 25 at 11:29
  • According to the manual, the variable is XDG_CONFIG_HOME on Linux. – Kusalananda Feb 25 at 11:39
  • @muru Well spotted. Both versions reside in /usr/bin and link to the same script /usr/share/virtualbox/VBox.sh . This script is eventually calling the third VBoxManage which is the actual binary and resides in /usr/lib/virtualbox . But as I stated, I have this issue even if I call /usr/lib/virtualbox/VBoxManage directly. – cuffel Feb 26 at 13:52
  • @Kusalananda Thanks for pointing this out. However, it's working very well with the VBOX_USER_HOME variable if I use the terminal. My question was how it is possible that the exported variable is "seen" by VBoxManage when I'm using a terminal but not if the export and call is within a script. – cuffel Feb 26 at 13:57
  • @Kusalananda : XDG_CONFIG_HOME configures where any user configuration is written to (usually ~/.config). So this is not specific for VirtualBox. – cuffel Feb 26 at 14:05
1
+50

I used to have the exact same problem here as I have 2 disks on my machine - a small SSD disk for / (now upgraded to 1 TB so not so small anymore) and a big HDD for data. Due to insufficient space on the SSD disk I kept all my virtual machines on the huge HDD. I found that after running vboxmanage list vms 2 Virtualbox-related processes show up:

$ ps aux | grep -i '[V]irt'
ja       29172  0.0  0.1  36084 11240 ?        S    21:17   0:00 /usr/lib64/virtualbox/VBoxXPCOMIPCD
ja       29178  1.0  0.2 523564 21256 ?        Sl   21:17   0:00 /usr/lib64/virtualbox/VBoxSVC --auto-shutdown

They are terminated after some time, about 20 seconds. These processes are described in Virtualbox manual:

5.7.6. VBoxSVC IPC Issues

On Linux, Oracle VM VirtualBox makes use of a custom version of Mozilla XPCOM (cross platform component object model) for interprocess and intraprocess communication (IPC). The process VBoxSVC serves as a communication hub between different Oracle VM VirtualBox processes and maintains the global configuration, such as the XML database. When starting an Oracle VM VirtualBox component, the processes VBoxSVC and VBoxXPCOMIPCD are started automatically. They are only accessible from the user account they are running under. VBoxSVC owns the Oracle VM VirtualBox configuration database which normally resides in ~/.config/VirtualBox, or the appropriate configuration directory for your operating system. While it is running, the configuration files are locked. Communication between the various Oracle VM VirtualBox components and VBoxSVC is performed through a local domain socket residing in /tmp/.vbox-username-ipc. In case there are communication problems, such as an Oracle VM VirtualBox application cannot communicate with VBoxSVC, terminate the daemons and remove the local domain socket directory.

And indeed, cat /tmp/.vbox-$(whoami)-ipc/lock shows PID of VBoxXPCOMIPCD process. That's the root cause of the problem.

Now, I haven't found any mention of this in vboxmanage --help so I don't think you can easily bypass it. You might always want to kill VBoxXPCOMIPCD before using vboxmanage and it would very easy to do because the PID is always saved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.