Ticket #10565 (closed defect: invalid)

Opened 6 years ago

Last modified 3 years ago

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

Reported by: testworks Owned by:
Priority: blocker Component: other
Version: VirtualBox 4.1.14 Keywords:
Cc: Guest type: Windows
Host type: Windows


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.


VirtualBox.xml Download (3.1 KB) - added by testworks 6 years ago.
VirtualBox_Failure.png Download (181.9 KB) - added by testworks 6 years ago.
Proof that the directory does not exist
VirtualBox1.xml Download (3.1 KB) - added by testworks 6 years ago.
VirtualBox_Failure2.png Download (117.7 KB) - added by testworks 6 years ago.

Change History

Changed 6 years ago by testworks

comment:1 Changed 6 years ago by frank

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

comment:2 Changed 6 years ago by testworks

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

comment:3 Changed 6 years ago by frank

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).

comment:4 Changed 6 years ago by testworks

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?

comment:5 Changed 6 years ago by frank

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.

comment:6 Changed 6 years ago by testworks

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.

comment:7 Changed 6 years ago by frank

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

comment:8 Changed 6 years ago by testworks

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

Changed 6 years ago by testworks

Proof that the directory does not exist

comment:9 Changed 6 years ago by testworks

It happened again - I have attached a screenshot :)

comment:10 Changed 6 years ago by frank

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

comment:11 Changed 6 years ago by testworks

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

Changed 6 years ago by testworks

comment:12 Changed 6 years ago by frank

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?

comment:13 Changed 6 years ago by testworks

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

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

comment:14 Changed 6 years ago by testworks

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?

Changed 6 years ago by testworks

comment:15 Changed 6 years ago by frank

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.

comment:16 Changed 6 years ago by klaus

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.

Version 0, edited 6 years ago by klaus (next)

comment:17 Changed 6 years ago by testworks

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?

comment:18 Changed 6 years ago by klaus

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.

comment:19 Changed 6 years ago by frank

  • Status changed from new to closed
  • Resolution set to invalid

comment:20 Changed 6 years ago by testworks

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.

comment:21 Changed 6 years ago by frank

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.

comment:22 Changed 6 years ago by testworks

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.

comment:23 Changed 3 years ago by frank

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

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use