Machines are being lost intermittently and replaced with debian6.vbox and test.vbox

[Glenn McDonald]

I'm running the latest version, Windows Server 2008R2 host, Windows 7 guest.

I launch from a desktop icon with the following command:

"C:\Program Files\Oracle\VirtualBox\VirtualBox.exe" --comment "Windows 7 x64" --startvm "Windows7x64" --fullscreen

Every now and then I get an error message stating:

There is no virtual machine named Windows7x64 Could not find a registered machine named 'Windows7x64' Details Result Code: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001) Component: VirtualBox Interface: IVirtualBox {c28be65f-1a8f-43b4-81f1eb60cb516e66}

After this occurs, if I launch the VirtualBox gui, I notice that my VM has disappeared and is replaced with two inaccessible vms:

debian6 (which it thinks is located at D:\VirtualBox\debian6\debian6.vbox) test (which it thinks is located at D:\VirtualBox\VM\test\test.vbox)

My VM is actually located at D:\VirtualMachines\Windows7x64

Every time this occurs I have to clone the VDI and re-build a virtual machine, which causes Windows to need to authenticate again.

I have no idea where it's getting this information from as my VirtualBox.xml file has the correct information in it.

[Frank Mehnert]

So you have no idea where this debian6 and test VMs come from, you never created them yourself?

[Glenn McDonald]

Correct. I never created them, and today I got a different one that I also never created:

Old machine

D:\VirtualBox\Old machine\Old machine.vbox

[Frank Mehnert]

Is your host a server which is used by other users? Your VirtualBox.xml file does not show any occurrence of 'debian' or 'test'. Please attach the correct VirtualBox.xml file together with the other spurious files (debian6.vbox and Old machine.vbox).

[Glenn McDonald]

No, it's not used by other users, but it is a server - and that's my point! Where are these mystery VM's coming from? Those files and subdirectories (like the \Old machine\ one) do not exist on my machine.

They must exist in the codebase somewhere as a debug fallback or something?

[Frank Mehnert]

Such files don't exist in the code base either. VirtualBox is open source and we build the packages from the source code which is included in the corresponding VirtualBox-x.y.z.tar.gz tarball which can be found on our Downloads page. You can check the tarball yourself. Did you install the official package from this web site or some package created by a third party?

I still want to see such spurious settings files attached to this ticket.

[Glenn McDonald]

Hmm OK I downloaded and grepped the sources myself and couldn't find any mention of 'debian6' or 'old machine'. I installed the official version from the above downloads page.

Can you tell me where the settings files would be stored? I got that VirtualBox.xml that I attached from the .VirtualBox folder on my machine (in my user folder).

The spurious files it complains about do not appear to exist in the above directory, or in the directory VirtualBox thinks they are stored in (probably as the directories do not exist).

I'm really stumped here. Thanks for your help so far.

[Frank Mehnert]

Your default VM machines folder is (according to the VirtualBox.xml file) "D:\VirtualMachines" so you would also find the settings files there.

[Glenn McDonald]

There weren't any settings files there. The next time it happens I'll post a screenshot of that directories contents...

[Glenn McDonald]

Proof that the directory does not exist

[Glenn McDonald]

It happened again - I have attached a screenshot :)

[Frank Mehnert]

Did you change anything yet? Do you still have the VirtualBox.xml file available?

[Glenn McDonald]

No, I haven't fixed it yet. Attaching it now, will name it VirtualBox1.xml

[Frank Mehnert]

That file still does not contain any sign of such a VM name. You said this is a server: Is there any global environment setting? Does the command 'set' show any environment variables containing 'VBOX'? If so, which values do they have?

[Glenn McDonald]

The only place VBOX comes up in the "set" command is:

VBOX_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\

[Glenn McDonald]

Happened again today, this time with "test.vbox". This time it was slightly different as the VM that I am using (the one that usually goes missing) is correctly displayed alongside it.

New screenshot !VirtualBox_Failure2.png is attached.

Perhaps you can send me a debug VBoxManage or something so that we can find out where it's trying to load the erroneous VM information from?

[Frank Mehnert]

I still have no idea how this can happen and I didn't saw any other reports here neither in the forums. There must be some specific action which you do to trigger this behavior.

[Klaus Espenlaub]

The symptoms you have hint that VBoxSVC was started with the wrong value of the HOME or VBOX_USER_HOME environment variable. This can happen if you use su/sudo incorrectly (e.g. in startup scripts). You should know what you did in this area, because this doesn't happen accidentally.

[Glenn McDonald]

klaus, you are almost correct! I don't start my VM's at boot time, however...

Our company requires that our HOME variable is set to a network drive so that our packaging tools work the same for everybody. It's set to "J:\CSH\BIN".

I had a look in the VBox.log and can see the following, which confirms VirtualBox is using it:

TFTPPrefix <string> = "J:\CSH\BIN/.VirtualBox\TFTP"

I took a peek inside J:\CSH\BIN\ and sure enough there is a .VirtualBox directory there, and this directory contains a VirtualBox.xml file that appears to be used by lots of other people in the company.

I found the test.vbox MachineEntry in that file so that explains where it's coming from:

<MachineEntry uuid="{fe049d1a-8436-4a46-b7ec-5d2a2c47112d}" src="D:/VirtualBox/VM/test/test.vbox"/>

So, given that we can't *not* use the HOME environment variable in our company - how can I get around this problem?

[Klaus Espenlaub]

You can use the VBOX_USER_HOME environment variable to put the .VirtualBox subdirectory in some place which is really local to your account, e.g. to H:\MyReallyPrivateHome\.VirtualBox

If this is set then VirtualBox won't look at HOME for finding a suitable default.

[Glenn McDonald]

I disagree that this is an invalid issue. You can handle this better by either:

1. Ensuring the VBOX_USER_HOME environment variable is set when VirtualBox is installed
2. Enforce a check on installation to determine whether the location of HOME is a local drive if it is set
3. During installation, if it is set, display the HOME directory to the user and inform them that this will be used by VirtualBox

It also doesn't explain why I have a copy of VirtualBox.xml in my true home directory that is used randomly.

[Frank Mehnert]

Regarding your suggestions:

1. VBOX_USER_HOME is normally not set but the user is free to set it to his own needs. So what should we check here?
2. The user is free to set the HOME environment variable to his own needs, even to non-local drives. But he has to ensure that the directory is not shared with other users. Keep in mind that strange things will happen with other applications as well if you share the HOME directory with other users. We can't do much there.
3. Well, perhaps we could display the HOME environment variable somewhere but surely not during the installation because the installation is normally done by the system administrator but it is up to the (restricted) user to run VirtualBox.

If there are environment variable overrides then we presume that the user knows what he is doing.

[Glenn McDonald]

Fair comments - what about a setting in the VirtualBox Manager -> Settings page that allows the user to set (override) the location of the VirtualBox home directory?

Alternatively, rather than using a hidden system folder under the user's profile, you could use the AppData directory to store the configurations etc. At least that's guaranteed to be applicable to the logged in user.

[Frank Mehnert]

As of VBox 4.3.22, HOME is no longer respected on Windows hosts.