Skip to main content

Convert Parallels Disk to VirtualBox VDI

I used to use the free Parallels Desktop Lite on the Mac App Store to host various Linux virtual machines for software testing purposes. Although I'd heard things about the company's business practices, I thought it was a pretty fair deal allowing people to run free OS's for free - you only had to pay to run Windows.

However about a year ago they introduced a mandatory subscription (at £74 per annum) even to run Linux, in the guise of a normal software update. None of this was mentioned in the update info - Nice 😡

No worries I thought (this is the polite version) - I'll just restore the previous version from Time Machine and Bob was indeed my uncle.

This plan worked fine until I upgraded to Catalina and sure enough Parallels would no longer run. Rather than pay the Parallels ransom, I decided to investigate the alternatives.

After some research I settled on VirtualBox, a free open-source VM from Oracle.

VirtualBox was surprisingly easy (for an open-source product) to install and make work on the Mac, the only problem was how to convert my existing VM disks to VirtualBox format. I had a large number of these and didn't fancy recreating them from scratch.

Unfortunately I couldn't find any information on how to do this conversion for Parallels expandable disks (only for the old fixed-disks). I figured out how to do it after some trial and error and here are the steps:

Step 1: Convert Parallels Disk to a format VirtualBox can read

  • Remove Parallels Tools from within VM (otherwise it won’t boot in VirtualBox):
$ sudo /usr/lib/parallels-tools/install -r

As my copy of Parallels Desktop Lite would no longer run, I had to download a trial copy of the full Parallels Desktop. Happily this also helped with the prl_disk_tool step, which isn't installed with the Lite version.
  • Show Package contents of Parallels .pvm file.
  • Copy .hdd file to a temp directory.
  • Convert .hdd from the expandable to the fixed format .hds with the Parallels prl_disk_tool:
$ /Applications/Parallels\ Desktop.app/Contents/MacOS/prl_disk_tool convert --hdd <your disk>.hdd --plain
  • Rename .hds to .hdd and copy to VirtualBox VM directory
  • Uninstall all version of Parallels when you're done 😉

Step 2: Add .hdd to virtual machine using the GUI

  • The VM can now be started from this disk.
  • The only problem is this is a fixed-size disk (in my case 64Gb).
  • The following steps convert the fixed disk to an expandable .vdi disk.

Step 3: Convert Fixed-size Disk to expandable VDI

  • Find out the identity & guid of the existing disk:
$ vboxmanage list hdd
  • Convert to dynamic VDI:
$ vboxmanage clonemedium disk <your disk>.vdi  --format VDI --variant Standard
  • Remove old disk from VM (using the GUI).
  • Delete the original fixed-size disk:
$ vboxmanage closemedium  <guid from above> --delete
  • Attach new disk to VM (using the GUI).
  • Start the VM and enjoy!

Comments

Popular posts from this blog

Emacs and MacOS Catalina

Catalina introduced a lot of security changes and the most intrusive is probably all the popups asking to give permission for apps to access directories under Home, like Documents. Worse still, apps which weren't written to handle the new security measures might just fail silently with no clues for the user. A solution is to give apps like Emacs "Full Disk Access" under "Security & Privacy" in Preferences, to give unfettered access to your files and avoid all the popups and silent failures. Sounds good, but that doesn't actually work for Emacs because "Emacs" in the app bundle is actually a Ruby script which decides which flavour of Emacs executable to run. This never mattered before, but it does under Catalina because MacOS thinks the executable is /usr/bin/ruby . Conventional wisdom is therefore to give "Full Disk Access" to Ruby. While this does work, I've always been uncomfortable giving all Ruby scripts full access...

Merging Git Repositories

No project of significant size that I've ever seen has retained its initial structure. Restructuring projects is a fact of life, but unfortunately Git doesn't make it easy. Fundamentally this stems from the way Git works, treating changes as a succession of snapshots and not storing any other metadata. Of course this is part of what makes Git fast and efficient, but at the expense of making some common operations more difficult for users. Git really is a perfect 21st century illustration of the classic  "Worse Is Better"  paradigm of successful software 😀 Previously I discussed how to split a Git project apart into separate repositories . Now I'm going to discuss how to do the opposite and merge separate repositories into one. On the face of it, this would seem a simpler task as Git has powerful support for merging... Let's take the opposite example to my splitting apart article - say you have a main Git repo (ProjA) and a second repo (ProjB) in...

Setting Environment Variables and the PATH on MacOS

Time Was setting environment variables and the PATH on a Mac running OSX was just like any other *IX.  However with successive OS releases Apple have changed how this works (more than once) and generally made it more difficult 😢  This article discusses how I go about setting environment variables on Mojave and Catalina. Why does this matter? MacOS doesn't add  /usr/local/bin to the PATH by default, which is unfortunate as most *IX-style programs you build yourself will be installed in there. If you only ever launch stuff from Terminal, all you have to do is set environment variables and the path from Shell startup files in the time immemorial fashion. However, this doesn't help with native Mac Apps like Emacs, which aren't launched from a shell and where you may still want to access custom environment variables and programs in /usr/local/bin . Setting the PATH In the past you could add to the path via /etc/paths (or paths.d ), however this no longer works...