What's the recommended way to move a VirtualBox VM to another computer?

Question

I use VirtualBox 4.1.x on my Ubuntu machine and I’ve set up several virtual machines. Since there are several ways one can move a virtual machine in VirtualBox to another computer, I was wondering which one is the recommended way:

1. Use the “Import/Export utility.”
2. Copy the entire virtual machine folder, containing the .vdi and .vbox files.
3. Clone the VDI using “Virtual Media Manager” and then recreate a VM on the target machine but using the cloned VDI as the hard disk.

I have successfully used the 1st method several times and it has always worked. The problem is that after exporting and importing, the disk image is transformed into VMDK and not VDI anymore!

The 2nd method is probably the easiest but I’m not sure that simply copying the files will work or not on the target machine. When searching about this method, I found some people had problems in which they had to edit the VirtualBox.xml file to solve it!

At last, there’s the 3rd method, but it requires the extra work of creating a VM similar to the original VM configuration, which is not desirable.

It’s clear from the above explanation that my desired method is the 2nd one, but I need expert advice on this if it works or not. I don't want any XML editing getting in my way!

What’s the best method of safely transferring my VM’s to another computer with VirtualBox?

Answer 1

Well done for doing your research. I regularly use all three options.

1. (Use the “Import/Export utility”). This is the easiest because it combines the whole VM into a single file and transfers it over without issue pretty much every time. However, in my experience when creating the OVA or OVF file for export it throws away all snapshots and if done incorrectly can result in a VMDK file. When you re-import the VM you should be able to select what type of HDD file you want created, VDI or VMDK.

2. (Copy the entire virtual machine folder, containing the .vdi and .vbox files). This is my preferred option and although I have had to edit the XML file a few times it's been my own fault for messing something up. Make sure that when you copy the VM, you get ALL the files associated with it. The issues I ran into were when certain snapshots and secondary VDI files were in the wrong directory and weren't copied properly. If you copy all the files (and permissions) you should not have any problems whatsoever.

3. (Clone the VDI using “Virtual Media Manager” and then recreate a VM on the target machine but using the cloned VDI as the hard disk). This is less desirable because then you have 2 copies of a VM, and it can cause licensing issues, network issues, etc, depending on how you clone the VDI file.

In summary, I would definitely recommend option 2, just make sure you get all the needed files when you move it over.

Answer 2

Method 2 works well now (with VirtualBox 4.0 and higher), without any XML modification required:

1. Stop your Virtual Machine
2. Exit VirtualBox
3. Copy the VM folder to the new location
4. Restart VirtualBox, and delete the old VM.
5. Go to Machine menu ≥ Add and browse to your old folder.

That's it!

ps: I have VirtualBox 4.3.20 on OSX 10.10

See this VirtualBox forum post for more details.

Answer 3

My preferred option is option 2 as well:

2. Copy the entire VM folder, containing the .vdi and .vbox files.

But sometimes a UUID mismatch will happen. Often this happens if you just copy the VDI disk image of one machine into another machine but I have had it happen during straight copies of full directories as well.

So, if this is the message you get after moving the virtual machine and trying to start it up in the new setup:

Failed to open the hard disk .

Cannot register the hard disk becuase a hard disk with UUID already exists.

Just go into the directory of your virtual machine; of course change the actual path to match the actual path you are going into:

cd /full/path/to/virtualbox/virtualmachine/Sandbox

And run this command to assign the disk a new UUID:

VBoxManage internalcommands sethduuid Sandbox.vdi

Answer 4

In case anyone else is looking for an answer to this I successfully moved 5 Virtual Box VMs to another Win7 install on a new hard drive on the same machine (essentially a move from one guest OS to another on the same PC). I realise that drivers on a completely new machine would probably vary and potentially have a negative effect on the move but I've documented the process below in the hope that it may help someone.

• There was no requirement to clone VMs or alter the xml file. VB version was fairly current: 4.3.12r93773.
• New copies of VMs were created in a new folder/shared drive to retain existing/old VMs intact. I can still boot from the old hard drive which I've retained for redundancy/issue resolution until I'm happy with my new setup; so I can access the old VMs in their former state if necessary.
• Drive letters will vary/may not be necessary depending on your setup.

On Old Win7 Host:

1. Ensure all VMs are powered off.

On New Win7 Host:

1. Create new folder called X:\NewVMs\VirtualBox VMs (from New Win7 machine to ensure permissions OK)
2. Copy/Paste (don’t drag) all VMs and related folder contents from the old folder to this folder (uses new permissions)
3. Uninstall VirtualBox (if installed)
4. Delete .virtualbox folder and all contents (if existing)
5. REBOOT to confirm no program files or registry entries remaining (if uninstalling old VirtualBox).
6. Install/Re-install VirtualBox (ensure you’re using the same version as the VirtualBox on which VMs were created on old host/machine (in my case ver. 4.3.12r93773))
   IMPORTANT: (Don’t select tickbox to open/run VirtualBox at end of installation)
7. Copy/paste (don’t drag) .virtualbox folder and contents from Old Win7 Host (usually C:\Users[username].VirtualBox
8. Now open VirtualBox
9. Set preferences for new Default VM creation folder to the same file path as the newly created VirtualBox VMs folder: X:\NewVMs\VirtualBox VMs
10. Test status of VMs

Good luck.

Answer 5

For the special case where:

• you only have a single VM (or want to move all of your VMs),
• and the host is the same hardware with same OS version (or reinstalling same OS to same machine)

If you are in this case, then things are easy:

1. Shut down VirtualBox on both hosts.
2. Copy the .config/VirtualBox and VirtualBox VMs folders from the source host.
3. Copy these folders to the destination host.
4. Start VirtualBox on the destination host

Answer 6

The 4th Way

In VirtualBOX:

1. Power off the VM
2. Right click and remove the VM (don't delete files)
3. Go to file>Virtual Media Manager and remove the .vdi
4. Go to File>Preferences>General and set the default machine folder to the new location
5. Create a new VM use expert mode to create the VM without a harddrive

In File Explorer:

6. Locate the .vdi file and copy it
7. Go to the new default machine folder, there will be a VM folder inside
8. Paste the .vdi file in the new VM folder

Back In VirtualBOX:

9. Right click the VM and open settings
10. Go to Storage>Controller: SATA and add a harddisk, click choose an existing disk 11.choose the .vdi file in the new VM folder

Note: If method 2 breaks your installation of VirtualBOX go to C:\Users\.VirtualBox and delete VirtualBox.xml and rename VirtualBox.xml-prev to VirtualBox.xml

Answer 7

I used method 2 as well to move my virtual machine and I didn't have to make any change in any XML file but got couple of errors with USB and file sharing and below is how I fixed them along with process:

1. Copy the virtual machine from old to new pc. The virtual machine files are different from the Oracle Virtual machine itself. These files are typically at c:\users\\VirtualBox VMs\. I picked up the whole VirtualBox VMs\ part and copied it to similar location on new PC. This copies all virtual machines I had on original PC.

2. Now on new PC, run virtual box and go to Menu > Machine > Add and select .vbox file from the folder copied. That's it.

3. Now when I run virtual machine on new PC, I got error when it was booting up:

4. I don't know why USB controller was not working because the same worked on original computer. I went ahead and installed VirtualBox Extension Pack

5. This installation was a little weird because the install download was not an executable file. I clicked on Oracle_VM_VirtualBox_Extension_Pack-5.1.4-110228.vbox-extpack and selected 'Select a program from a list of Installed programs' and than selected Oracel virtualbox and it installed the extension. That fixed the problem, but another less desirable solution is you can disable the usb.

6. If you had shared folders in the original VM, they may differ and you will get error. Review those in Settings >> Shared Folder and delete the ones which are broken. An error message will look like

.

That's all.

Answer 8

zar, first thing first... never ever move a machine that is in saved state, prior to move you must shut down the guest, not just save the state.

Also ensure you use the same version of VirtualBOX on both host, but not only VirtualBOX version, also the extension pack vesion... or at least the new host have a higher version, but never ever a lower version on any of thoose two.

And finally, i learned it the hard way, delete SHARED folder configuration on VirtualBOX prior to move the machine, then re-create it in a correct way... very important when host are different OS (Windows / Linux hosts).

And just as a side note... i allways, allways use inmutable hard disk VDI files for OS as well as for data VDIs (that way the same DATA VDI can be used for more than guest), specially trick for 4GiB pagefile.sys

That last part, re-use an inmutable VDI file makes things go a little harder, VirtualBOX has a BIG BUG.

To see the Bug in action:

• Create one inmutable VDI (like the one i use for pagefile.sys)
• Create Two or Three VM's on VirtualBOX
• Move one of them to the top of the list (just to avoid get damaged any one of yours)
• BackUp the .vbox files of each of thoose machines you created (for comparing it after the BUG happens)
• Attach that inmutable VDI to more than one of that machines (except the one on the top of the list)
• Now see the .vbox of the machine that is on the top of the list

That machine has been edited, it has references to the other machines inmutable VDI.

So the BUG is: Edit one machine adding a inmutable VDI that is used by another one affects the machine on the top of the list.

Why on the hell i re-use the same 4GiB VDI on all Windows machines? Easy, it is a MBR disk with a FAT32 partition where i put pagefile.sys, since it is inmutable all virtual machines will create a file on their snapshot folder where they store the changes, and that get lost on next boot, so i do not need 4GiB for each guest stored on the host disk, just only one... that way i save a lot of GiB since i have more than 20 different windows for testing apps i develop for my own, all combinations of (XP, Vista, 7, 8, 8.1, 10)*(32Bits, 64Bits) * (Just as is on first install, after each ServicePack, after full windows update), i get a lot, lot of guest... so on all of them i share the inmutable 4GiB VDI for the virtual ram (pagefile.sys).

And if you let the BUG go further, try to move one of thoose machines to another VirtualBOX host (remember they are only virtual machine with a configuration on them and no guest yet installed on them), you will see VirtualBox does not let you to add them since some VDIs are missing (it is FALSE and TRUE, it is that such first machine holds the references to such VDIs insteed of beeing on the correct machine).

Now compare the .VBOX files of all them with previos BackUp... note how one is modified wrongly?... yes, it is the one on the top of the list.

Well, this BUG was informed to VirtualBOX some years ago, they still can not fix it... and it is causing a lot, lot of problems.

Also more, if you move the top one on the virtual machines to a lower position, close VirtualBox and re-launch it... will tell you some machines are damaged and can not be started... yes the first one on the list must be treated in a different form if you do not want to get a lot of trouble.

It is a really bad BUG that took me a lot of days to discoverd (some years ago) i learn it the hard way!

I had overcome it by having a machine i had called:

• Common Inmutable Disks

It has an empty configuration and only one VDI, yes, you are right, you have guess it, the inmutable VDI i share for all the rest virtual machines.

Well when i open the .VBOX file i see inside it a lot of lines on the <MediaRegistry> <HardDisks> section, one per each machine where i use that inmutable VDI... just as a sample (i remove private data):

<MediaRegistry>
  <HardDisks>
    <HardDisk uuid="...UUID..." location="D:\VDIs\_Virtual_Memory_.vdi" format="VDI" type="Immutable">
      <HardDisk uuid="{...UUID...}" location="Snapshots\{...UUID...}.vdi" format="VDI" autoReset="true"/>
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows001 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows002 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows003 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows004 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows005 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows006 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows007 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows008 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows009 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows010 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows011 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows012 ... // This belongs to other virtual Machine
      <HardDisk uuid="{...UUID...}" location="D:\VMs\Windows013 ... // This belongs to other virtual Machine
      ... and so on ...  // This belongs to other virtual Machine
    </HardDisk>
  </HardDisks>
</MediaRegistry>

Pretty BUG, not solved since years.

Well, to move such machines... you must manually edit the .VBOX files, to put all such disks references on the new host on the first machine (the one that is on the top of the list) prior to add the .VBOX files to the list, so when adding them VirtualBOX has the references to the missing VDIs (missing caused by the big BUG).

The thing occurs because each time you connect a VDI that is used on another machine VirtualBOX update two machines .VBOX files (the one that belongs to the machine you are using) and to the first one on the list.

I am not totally sure what would happen when on the list, the first one does not have such common VDI attached to it... better not to try it, seen what i see.

So migrating to another HOST is much more complicated than what it seems to be becuase of a very bad implementation on .VBOX files internal structure and because of really big BUGs when VirtualBOX edits them.

Fails:

• Internal structure (XML) depends on the HOST (Windows or Linux)
• Edit one machine can alter another one, not only the one beeing edited
• ... what more ?

Need more... i allways migrate machines doing this (and had no problem, never ever):

1. Take note of the list of all machines (order, grouping, etc)
2. Take note of the first one on the list (all its configuration)
3. Take note of all properties of machines i want to move to another host
4. Copy the .vbox files as .txt files (the one on the top of the list + all machines i want to migrate)
5. Recreate all machines (and have a special one on the top of the list) inside VirtualBox on new host
6. Close VirtualBox on new host
7. Diff compare the old .txt with the new .vbox files and copy from .txt to .vbox some parts in human way, not just Copy&Paste
8. Open VirtualBox and attach all VDIs in correct order
9. Again Close VirtualBox on new host
10. Diff compare the old .txt with the new .vbox files and 'fix' from .txt to .vbox some parts in human way, not just Copy&Paste

All the rest (snapshots folder and VDI files) i copy them in the normal way (File System Copy&Paste).

All that hard manual work is caused by the Big BUG VirtualBox: It edits / alters a machine not been modified when you attach a inmutable VDI that are used on more than one machine, else a simple Copy&Paste the .VBOX file would be enough (after fixing shared folders paths, etc).

Answer 9

Copy the folder containing the machine to destination, then from the menu: "Machine" ---> "Add", and then choose the vbox file, NOT the vdi file. For me this went flawlessly. Not sure if I was lucky, or if it is supposed to work this way.