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:
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):
- Take note of the list of all machines (order, grouping, etc)
- Take note of the first one on the list (all its configuration)
- Take note of all properties of machines i want to move to another host
- Copy the .vbox files as .txt files (the one on the top of the list + all machines i want to migrate)
- Recreate all machines (and have a special one on the top of the list) inside VirtualBox on new host
- Close VirtualBox on new host
- 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
- Open VirtualBox and attach all VDIs in correct order
- Again Close VirtualBox on new host
- 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).