virtualbox.org

I am having a problem with adding a machine which is a backup of another machine. I copied the entire VM folder from one drive to an external hard drive. I get an error trying to add the VM.

The machine is a Navy NMCI Dell Latitude E6410. Its hard drive is encrypted using Guardian Edge. The external hard drive is a western Digital Elements USB 2.0 external hard drive. It is also encrypted using Guardian Edge with a different key.

The entire VM folder with all of the vbox, logs, vdi, and snapshots was copied to the external hard drive. I then started virtual box, "removed" the VM (without deleting files), and tried to add the VM from the new location.

Virtual box returned the following error message.

Failed to open virtual machine located in E:/_Program_Files_VFS/VirtualBox/CPVFS_SQL_2003-64/CPVFS_SQL_2003-64.vbox.

Cannot register the hard disk 'E:\_Program_Files_VFS\VirtualBox\CPVFS_SQL_2003-64\Snapshots/{0e7bb368-636d-4b18-9bab-0aba758a6b40}.vdi' {0e7bb368-636d-4b18-9bab-0aba758a6b40} because a hard disk 'C:\_Program_Files_VFS\VirtualBox\CPVFS_SQL_2003-64\Snapshots/{0e7bb368-636d-4b18-9bab-0aba758a6b40}.vdi' with UUID {0e7bb368-636d-4b18-9bab-0aba758a6b40} already exists.

Result Code: E_INVALIDARG (0x80070057)
Component: VirtualBox
Interface: IVirtualBox {c28be65f-1a8f-43b4-81f1-eb60cb516e66}

I was able to re-add the machine from the original location just fine. The message seems to be saying that Virtual box cannot add the machine using the copy because it sees the UUID of the original machine. But since the original machine was removed how does it know about the original vdi file with that UUID? I checked the vbox file and nowhere does it refer to this vdi file by other than a relative path from the vbox file. I searched the registry for this UUID and found it nowhere. So I am confused.

How does Virtual box know ever know that the other file even exists and how can I get around this to verify the successful copy of this VM. (There was already an issue where the vbox file got corrupted and had to be replaced. I need to ensure than no others got corrupted.)

Well of course. The purpose of a backup is to replace the original when necessary. You can't have both the backup and the original registered at the same time as their UUIDs would conflict.

Use the Machine|Clone feature when you want to make a copy of a VM.

If you desperately need access to the backed up VM - and don't want to lose the current VM - then one trick you might try is :-

1. Shut down VirtualBox (all VMs+GUI), rename the VirtualBox.xml file to something else, then run the VirtualBox GUI again.
2. Machine|Add... your backup VM, then use Machine|Clone... to clone it.
3. Shut down VirtualBox, delete VirtualBox.xml, rename old xml back to VirtualBox.xml, then run the VirtualBox GUI again.
4. Machine|Add... your clone VM.

<mod edit>Sorry, in the course of replying to this message of yours I accidentally invoked my magical moderatorial powers and zapped your message text. Feel free to edit this message again to restore a semblance of what you said.

To paraphrase what you said:

You pointed out that you had removed the original VM and questioned why there would be any conflict remaining.
You said that your client did not want to use clones for backup purposes.

joeller wrote:Are you saying that a Virtual machine is still registered with Virtual Box after it has been removed?

I didn't catch that you'd said you removed the original, but it fact yes - the background VBoxSVC process (last time I checked anyway) retains a memory of the media after it has been removed from the GUI, this memory persists as long as VBoxSVC runs. Which is of course only a problem if you try to reinstate media you removed in the same session. The workaround is to shut down all VirtualBox (meaning the GUI and all VMs) processes long enough for VBoxSVC to unload itself, then run VirtualBox again - now Machine|Add will work. I raised a formal bug ticket for this issue some time back, but it has received no response so far.

joeller wrote:The customer I am supporting does not want a clone. He wants the exact backup of the files that exist on the hard drive

That's fine, but he can't have his cake and eat it too. A backup is not intended to be registered alongside the original VM (only cloning allows that), so bear that in mind when testing backup/restore procedures. Also, whether or not the above behaviour can be considered a bug, IMHO it is anyway good practice to shut VirtualBox down before you start overwriting its config files! When restoring a backup with VBox shut down you simply overwrite the VM from the backup files - no need to mess with adding and removing VMs.

I didn't catch that you'd said you removed the original, but it fact yes - the background VBoxSVC process (last time I checked anyway) retains a memory of the media after it has been removed from the GUI, this memory persists as long as VBoxSVC runs. Which is of course only a problem if you try to reinstate media you removed in the same session. The workaround is to shut down all VirtualBox (meaning the GUI and all VMs) processes long enough for VBoxSVC to unload itself, then run VirtualBox again - now Machine|Add will work.

Great! I will try that.

A backup is not intended to be registered alongside the original VM

We don't need both registered at the same time. Just need the files available for when NMCI pulls one of their assinime stunts so we can put things back to the way they are supposed to be. (Which is why the external hard drive is disconnected every evening.)

Just wanted to follow up to let everyone know that Mpack's instructions worked excellently. Thanks a million Don.

Also wanted to let everyone know who are using Navy machines with Navy external hard drives that the vbox and xml files on these hard drive get corrupted once you reboot the machine, so if you are storing copies on one of these drives you have to maintain a CD or DVD with the original vbox and xml files to restore the backup.

Just a note that MPacks tip worked for me too.

Perhaps a few explanations for those other dummies like me.

The VirtualBox.xml MPack refers to is typically stored under your user profile in a Windows HOST OS, so \users\USERNAME\.Virtualbox for Windows 7 and \Documents and Settings\USERNAME\.Virtualbox for earlier OS's like XP.

Renaming the VirtualBox.xml basically removes all the references of the ALL guests you have in VB, so be sure to RENAME and not DELETE the file, don't worry, once you've cloned the OS and renamed the original VirtualBox.xml back again they will appear again in your VB list.

If you have moved the destination of your GUEST VM folders like I did then by renaming the VirtualBox.xml it will revert back to the STOCK location of VB guests, like C:\Users\USERNAME\VirtualBox VMs so the clone will end up THERE instead of your alternate location. Either change the location before creating the clone or MOVE the resultant clone to the new location once created.

Cloning will of course make a second copy of the guest you are trying to get to run, so of course oyu need enough disk space to support ANOTHER copy of the OS. Be sure to delete the ORIGINAL COPY of the guest that fails to add back in (NOT the one you just cloned) when done or it will just sit there taking up disk space.