I have a VirtualBox VM that has a project I'm working on. I'd like to be able to use this VM on two separate computers, so I can work on it where I happen to be at that time. I've seen answers on transferring, cloning, and backing up VMs, but nothing on having two copies and keeping them in sync.

What's the easiest (fewest or simplest steps) or best (lowest risk of problems) way to maintain a single VM image on multiple computers?

Ideally, I'd rather not run the VM from a USB drive as one of the two computers has very few USB ports, but if that's going to be best, then I'll take it (I'm actually not sure if there are any problems with running a VM from a USB drive). I would, however, plan on using a USB drive to transfer any files between computers.

9 Answers 9


I think that you have two options here: the first one is to set (in the installations of Virtualbox on both computers) the folder where the VMs are stored on some kind of portable or remote hard drive; if the computers that you will be using are linked together on a network, you can use a shared folder, if not, I fear that the only solution is a USB pendrive or an external harddrive. To set the folder, go to File > Preferences > General > Default Machine Folder. The speed of the USB key could be a limit on the overall performance.

The second solution, that also require a pendrive or something similar (but just to carry around your VM files), is to manually export and import the desired VM every time that you need to carry it away. You can do this by selecting the VM and go with File > Export Appliance and File > Import Appliance. By exporting, a file with the .ova format will be created, it is an archive that contains all the files needed to use the VM, by importing it in another installation, you will have the same VM on the second computer. This way you are using the pendrive to simply carry around your files, that when reimported will be stored and accessed from your computer, thus the USB speed is not a concern.


Faced with exactly the same problem and I think I solved it.

Say you have two machines, A and B. Create/prepare your vm in A. After that take a snapshot or create a linked clone (both works, but further steps differ, will give one, you can resolve the other)

Now, make sure that you have a freshly installed Virtualbox in B. Copy ~/.VirtualBox and ~/VirtualBox VMs from A to B with a USB (considering that they are in far away sites)

Now, if you chose the snapshot way, then sync ~/VirtualBox VMs/YourVM/Snapshots folder until it gets big enough. If it gets larger, then create another snapshot in A and copy the YourVM folder to B for once and only sync this new snapshot file in Snapshots folder.

If you take a snapshot or make a linked clone in either A or B, this ritual will be broken, be warned.

Tested in 5.0.20

  • very intriguinig answer. would you do this still today or is there a better way? May 2, 2018 at 14:54

I know this thread is a year old, but it is a top search result on google for the issue of sharing one VM between two locations.

VirtualBox allows you to remotely connect to a running VM using RDP. If you don't want the VM running continuously, rig some way to launch it remotely.

There is an option for "Allow Multiple Connections", so you wouldn't even have to disconnect from one location before connecting from another.

If you are not able to host your own VM, a quick google search found providers that will host your VirtulaBox images for you.

I've never tried all of this...


I think Sekhemty's answer is the only way to do what you want.

But why does your virtual machine need to be moved? Why not just move your project(s)? Set up your project in a private git and just push and pull as you need it.

Another method to try, if you need to maintain machine consistency and you're changing a lot, would be to use a vagrant and chef/puppet setup. This works by using either a chef(which is a ruby gem) and puppet(I haven't used puppet) to tell vagrant what you want your VM to include and install.

It works by using a script, using chef or puppet, and vagrant reads this script when starting up the VM. If you want anything to be installed just add it to the script and if it's not already there it will be installed when you "vagrant up"! It took me a while to get used to it, steep enough learning curve, but it's very efficient once you get used to it and it will mean you just have to move around a script file instead of a whole VM.


  • 2
    It's not just about the code (which does go into a repository) and configuration; it's because the VM is my development environment. I started using VirtualBox so I could work in Ubuntu on a computer running Windows. This would give me a consistent development environment when it's less convenient to move the environment than it would be to move a copy of it.
    – rsgoheen
    Apr 29, 2013 at 15:59
  • Well then vagrant and chef/puppet seems like it's the best. That way if you need to change something in your dev environment, there's no need to export and import your VM, you just add what you installed to your script and vagrant will build it into your VM on start up. It's very handy for having different instances of dev builds as well, as vagrant works off a "base-box(OS)" and builds on top of that what the script tells it too, so you could have multiple testing environments but only using the space of one. Apr 29, 2013 at 16:29

Following the KISS principle, after the VMs are registered and settings are adjusted, just rsync the *.vdi file across while both sides are powered down.

rsync -aPh <path-to-vm>/<diskname>.vdi <remote>:<path-to-vm>/

There will be no way to "merge" conflicts, of course, so you have to be disciplined about how you make changes to the VM and to mirror these changes.

Meanwhile, you could put most of your personal data on a NAS so it is always up to date and accessible from all machines. Furthermore you could mount additional .vdi disks to contain the swap partition or other temporary storage so as to not increase the size of your system .vdi.

If you are on windows, you should install cygwin (or msys2) for the ssh and rsync program.


You could rsync the virtual machine images between your two computers.

  • 2
    A bit more detail would make this a better answer. Can you elaborate?
    – Dave M
    Sep 20, 2013 at 20:20

One possible solution, depending on your use case, is a variation on cjpembo's answer.

If the two separate computers are both on the same LAN at the same location, then it might be possible to run one VM on an ESXi server or similar, and just use the remote console function of the management tools (or even SSH) to access it from both other computers.

Obviously, if one of the computers you want to use the VM with is a laptop that will move around, then this is possibly not a solution, especially if you have to share a large amount of data between the "host" and "guest" environments.

If the VM is relatively self contained, VMware's remote console capabilities are pretty efficient, so unless you need video playback in the VM, it may work well enough even remotely to be good enough.


I achieved this by using an external ssd on usb c disk. VM will be located in the ssd disk, and referenced in my virtualbox setup on both laptops. I took an USB 3.1 Gen2 Type-C (10Gbps), 540MB/s model, and performance are fine.


I have the same story, but my solution is using Google Remote. My main PC is alway turned on. So when I use my laptop, it uses the main PC process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.