virtualbox.org

Under File=>Preferences=>General tab, I had change the "Default Machine Folder" from C:\home\vbox to E:\home\vbox and had
been running with this for a few months, closing the VM VirtualBox Manager, shutting down the machine and restarting just fine.

Today I shut down my box, rebooted and restarted and all of my VM's were invalidated. I checked the setting and it had changed back
to C:\home\vbox and now I have to go and re-add all my VM's again which will take about an hour.

Every VM has a red stop sign with a (-) in the middle and says "Inaccessible".

Is there anything I can do to prevent this from happening again? I took a look at every log file and they reference 'e:\home\vbox'
for the machine. I am not sure how it was reset from E:\ to C:\ or what caused it.

Is there a meta-data file I can go edit with a text editor so I do not have to spend an hour re-adding each vm?

thanks

J.V.

jvsrvcs wrote:Today I shut down my box, rebooted and restarted and all of my VM's were invalidated. I checked the setting and it had changed back
to C:\home\vbox and now I have to go and re-add all my VM's again which will take about an hour.

Nonsense. The "default machine folder" is the location where new VMs will be created. That setting has no effect on existing VMs.

From the symptoms it sounds more like the VirtualBox.xml configuration file got overwritten by an old version perhaps (from backup?). I agree that the default machine folder setting itself has no influence on existing VMs, so something else must have happened. It's not very clear what, though.

michaln wrote:From the symptoms it sounds more like the VirtualBox.xml configuration file got overwritten by an old version perhaps (from backup?).

Yes, and that didn't happen by magic, meaning that we are not getting the whole story.

But even leaving that aside: why would restoring an old version VirtualBox.xml result in VMs being still present, but inaccessible? The only way that works is if the VirtualBox.xml is old enough to contain a media registry.
[

Edit:  I'm used to "inaccessible" usually meaning missing media, but I guess missing settings xml would do it too. Which means I guess that the OP must somehow have restored the VirtualBox.xml from before the VM relocation saga described in his first posts on this site.] All in all, this is one very garbled problem description. The OP has a track record of providing insufficient info, even when asked to clarify, and then complaining bitterly if the best attempted answer is off target - so I'm not inclined to speculate until I'm sure I have the full facts.

I posted everything I had. shutdown normally, came back up and everything was pointing to the C:\ drive and not the E:\ drive. I am using the latest version of the software. I understand that sometimes a developer does not know what went wrong, can't explain it and shifts the causation back to the user. There is a bug in the software somewhere that caused this.

jvsrvcs wrote:There is a bug in the software somewhere that caused this.

No, there isn't. This is clearly pilot error.

If your description was accurate and complete to your knowledge then the cause of your symptoms is plain: weeks old VirtualBox.xml replacing the newer one. The only things I know that could cause this are (a) you copying the file yourself (or running some kind of system restore operation on the host which did it), (b) logging in as a different user, and thereby accessing a different VirtualBox.xml. One thing this can't be is a VirtualBox bug, because VBox has no mechanism that I know of - buggy or not - to restore old versions of any file. If you continue to deny the very very obvious then I see little point in discussing it further with you.

My first post here. I've just found this thread, & believe I have a similar thing: W7/64 with all latest fixes as host. VBox 4.1.14r.77440 with extension pack installed. Basically, I'm forced to put my VMs in the 'wrong' place; see below:

I created an Ubuntu VM, which was stored in my user folder C:\Users\TimS\VirtualBox VMs. This directory contains the VM folder (containing Ubuntu11-64.vbox, Ubuntu11-64.vbox.prev, Ubuntu11-64.vdi & a log dir), plus .VirtualBox, containing VirtualBox.xml). In the VirtualBox prefs, the Default Machine Folder is shown as C:\Users\TimS\VirtualBox VMs. This is all as expected.

However (and I don't know how this happened), Virtual Box seems to be trying to read its Default Machine Folder location FIRST from an alternative location: c:\chromiumtrunk (I build chromium on this machine). If chromiumtrunk exists, then a new set of .VirtualBox\virtualBox.xml gets created in chromiumtrunk. This new virtualbox.xml specifies that the VMs are in chromiumtrunk, & so virtualbox sees no VMs. In this case, the Default Machine Folder location in the preferences dialog is shown as C:\Users\TimS\VirtualBox VMs and not shown as c:\chromiumtrunk (even thought that is where it seems to be looking!).

If I rename chromiumtrunk to something else, the proper behavior occurs: the genuine VMs are picked up from C:\Users\TimS\VirtualBox. I've been through all the xml files that I can find, & there are no errors. I have uninstalled VirtualBox, searched all throught the registry for 'VirtualBox', reinstalled VirtualBox & the problem simply comes back.

I have used the ProcMon tool from Sysinternals, & have discovered that VBoxSVC.exe is accessing c:\chromiumtrunk. However I can find nothing in the registry, or any config files to tell it to do that. I have a %HOME% environment variable that is set to c:\chromiumtrunk

Does this make any sense? I'd like to stop VB from looking in chromiumtrink. No matter how many times I manually set the location in the prefs dialog, it simply reverts to chromiumtrunk.

Regards,
Tim.

VirtualBox.xml is not stored in the Default Machine Folder. Only machines are in the machine folder, it's the default parent directory for newly created machines. VirtualBox.xml is stored (by default) in <userdoc>\.VirtualBox.

Thanks. However this doesn't fix it. Looking at C:\Users\TimS\.VirtualBox\, there is the (correct) line:

<SystemProperties defaultMachineFolder="C:\Users\TimS\VirtualBox VMs" defaultHardDiskFormat="VDI" VRDEAuthLibrary="VBoxAuth" webServiceAuthLibrary="VBoxAuth" LogHistoryCount="3"/>

However, if c:\chromiumtrunk exists, then VBox always looks in there, finds no VMs. If I rename c:\chromiumtrunk to e.g. c:\chromiumtrunk0 then VB picks up my VM correctly from C:\Users\TimS\VirtualBox VMs.

Something is causing VB to look in c:\chromiumtrunk - I can find nothing in the XML, nor the registry, yet it's happening, sorry. I've tried invoking virtualbox as an admin (in case it couldn't write to C:\Users\TimS\VirtualBox VMs or something), but no joy.
Tim.

Look in your environment variables for something which sets the VBOX_USER_HOME path, or otherwise defines a path for user documents.

Thanks, but no fix, sorry. Currently there s a system env var VBOX_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\ . I then ensured VB was closed, created one: VBOX_USER_HOME=c:\users\TimS\VirtualBox VMs then restarted VB. No difference.

I tried 'reset' in the option for setting the home. Re-opened the settings to home (in VB) & it was back to chromiumtrunk. Whatever I do, I can't make VB forget this. It must be being persisted somewhere. It looks like I have three alternatives: (1) reinstall Windows, (2) accept that I must move my VMs into the chromiumtrunk directory, or (3) when I'm not working on chrome, I rename chromiumtrunk to chromiumtrunk0 so I can use VB, & when I need VB, rename chromiumtrunk0 to chromiumtrunk & not use VB!

Update Sorry about this, but it seems OK now. I've tried to be methodical about the changes, but it now seems to be correctly picking up the proper location. I deleted my %HOME% variable (which pointed to c:\chromiumtrunk) & I thought that fixed it. However putting the variable back in kept the fix. I can't be clear about whay happened, but it seems OK now. Mind you, I don't know what broke it either, so it may be back!

Thanks again.

Tim.

Here's what worked in my case:

Change the Default Machine Folder in the General Tab under FILE / PREFERENCES, then, go to the MACHINE menu and click on ADD

At that point, you should see the VMs located in the new Default Machine Folder

In my case, I actually use SOLARIS x86, and I moved a half-dozen VM's ( Windows 7, Red Hat, CentOS, etc. ) from one PC to another and changed the Default Machine Folder name. Once I clicked ADD and selected each VM from its new folder location, the VM's showed up in the main VirtualBox window.

If you use Machine|Add... then VirtualBox will accept VMs located anywhere, so the "Default machine folder" setting is irrelevant. The latter only matters when creating a new VM, not when finding existing ones.