virtualbox.org

I suppose I should add conversion advice... Simplest way I know - and it only works if you avoid snapshots like the plague that they are - is to create a new v4 VM with a new drive, making all VM settings identical to those of the VM you want to convert; pay particular attention to IO APIC and VT-x settings, IDE and NIC controller types and MAC address. In short - pay attention to everything. When that's done you clone the hdd from its old location into the new VMs folder, then manually edit the media registry in the .vbox text file, where you correct both the filename and the UUID in the media registry entry - both need to be changed to that of the clone you just created (*). This procedure effectively clones the old VM: the clone has a v4 layout, the original continues to work using whatever layout it had. Once you are satified that the clone works ok, you can delete the original VM in its entirety, including xmls and VDIs.

Tidy up: when you created the new VM, a small new VDI was created as well - you can delete that VDI now.

If you have snapshots then conversion which preserves the snapshot structure is not practical, IMHO. You need to clone the current state to get a stand alone VDI, which you then treat as above.

(*) My CloneVDI tool can be used to determine the creation UUID of the clone.

Just my 2p worth, since I ran head first into the brickwall of migrating running v3 guests on v4.

I needed to move the machine and it's snapshots out of /home (50GB wasn't enough), and the split folder structure wouldn't allow that. However a solution was at hand.

Provided that you do not need the older snapshots, ensure that your guest is running its latest snapshot, then shut it down. Use the GUI 'Export Appliance', or the command line equivalent, to produce a .ova file (typically about 3GB for a 10GB drive with about 6.5GB used). Rename the original guest, adding say v3 to the name. Then use 'Import Appliance' to add the v4 guest. 'Rinse & Repeat' until satisfied

Though it's somewhat wasteful of disk space, the same technique could be used to create v4 versions of each snapshot, starting at the oldest, not forgetting that trying to run more than one at once will cause collisions, unless the v4 guests are individually tweaked to change things like the machine name.

Hope that helps someone else.

Using export/import carries its own risks, and also changes the hdd format from VDI to VMDK, which is not something everyone wants.

The important feature of your suggestion is that the snapshots are merged into a single file. There are more direct ways to do that. You can use my CloneVDI tool to clone the latest snapshot (read the release notes that come with it), or those who want a command line tool can use "VBoxManage clonehd" to do the same (read the VBox user manual). Either way you end up with a single VDI file which you then treat as per my last posting.

This issue is trivial if you are using VirtualBox 4.1 or greater. Simply "clone" an existing v3 machine and VirtualBox will convert to the new v4 format and include all snapshots.

brianafischer wrote:This issue is trivial if you are using VirtualBox 4.1 or greater. Simply "clone" an existing v3 machine and VirtualBox will convert to the new v4 format and include all snapshots.

Quite so. The only downside of that technique is that the VirtualBox clone feature unconditionally changes the UUIDs of all disks and the VM itself. This can cause boot problems in Linux or activation problems in Windows. However both problem have easy workarounds.

Actually, I'll amend that.

I've done a couple of v3 to v4 conversions before, just to test the concept, but yesterday I finally got around to converting all my remaining VMs to v4. At first I started off using the cloning method, but cloning is fairly slow... it was going to take a while. Eventually I settled on a copying routine that was quite simple and much faster :-

(Describing it step by step makes it seem lengthy, but in fact it's much faster than cloning).

1. Remove the selected v3 VM from the GUI, being careful to tell it to keep the physical files rather than delete them.
2. Shut down VirtualBox fully.
3. Move the v3 VM folder to its new preferred location (e.g. <userdoc>\"VirtualBox VMs").
4. Move the main VDI(s) into the same folder.
5. If I used snapshots I would also create a snapshots subfolder and copy all the snapshot vdi files there.
6. Rename the vmname.xml file to vmname.vbox.
7. Edit the vmname.vbox file:
7a. Change the settings version to "1.12-windows" from whatever it is at present (non Windows may need -linux etc).
7b. Paste in a skeleton media registry like that shown below, paste this right after the "<machine uuid=xxx" line, before <ExtraData>.
7c. Cut and paste (ie. move) the relevant hard disk definitions from VirtualBox.xml to the local VM registry.
7d. Remove the paths from hard disk filenames (they will all now assume the VM folder).
7e. Save changes to vmname.vbox and VirtualBox.xml then exit.
8. Finally double click the .vbox file to add it back to the GUI, it's now in v4 format.
9. Test this VM before repeating the procedure on the next one.

Obviously this involves manual edits to xml files. You should not attempt that unless you are confident, and even so I made a backup of VirtualBox.xml, and my first efforts were with VMs I could afford to lose and/or could easily recreate provided I didn't delete the VDI.

Once all of the VMs had been converted, the very last thing I did was to delete the .VirtualBox folder entirely (of course by now my VMs were stored elsewhere!). This forced VirtualBox to recreate VirtualBox.xml in the latest format. I then used Machine|Add... to add back each of my VMs. VirtualBox was now using the latest format everywhere, with no legacy baggage.

Sample skeleton local media registry. The example hard disk line would be deleted and replaced with your own lines.