Technology Tales

Converting QEMU disk images to VirtualBox images on Linux Mint 21

30^th October 2022

Recently, VirtualBox gained fuller support for Windows 11 and I successively set up a new Windows 11 virtual machine that, I hope, will supplant a Windows 10 counterpart in time. While the setup itself was streamlined, I ran into such stability issues that I set the new VM aside until a new version of VirtualBox got released. That has happened with the appearance of version 7.0.2, but Windows 11 remains prone to freezing on my Linux Mint machine. Thankfully, that now is much less frequent, yet the need for added stability remains outstanding.

While I was thinking about trying out VirtualBox 7.0.0, I remembered a QEMU machine that I had running Windows 11. Though QEMU proved more limited than VirtualBox when it came to having easy availability of functionality like moving data in and out of the virtual machine or support for sound, there was no problem with TPM support or system stability. Since it did contain some useful data, I wondered about converting its virtual hard disk to VirtualBox format, and it is easy to do. First, you need to install qemu-img and other utilities as follows:

sudo apt-get install qemu-utils

With that in place, executing a command like the following performs the required conversion. Here, the -O switch specifies the required file type of vdi in this case.

qemu-img convert -O vdi [virtual hard disk].qcow2 [virtual hard disk].vdi

While I have yet to mount it on the new VirtualBox Windows 11 virtual machine, it is good to have the old virtual hard disk available for doing so. The thought of using it as a boot drive in VirtualBox did enter my mind, but the required change of drivers and other incompatibilities dissuaded me from doing so.

Disk corruption can be virtual too

16^th July 2008

It's the sort of sight that causes you to fear the worst, an unchanging black screen with a flashing cursor. That was what started to greet me recently when I tried to fire up a Windows XP guest in VMware Workstation. The cause was the corruption of a virtual disk, an ominous thing that affected a supplemental virtual hard drive that I had added to the virtual machine rather than its main one. Though there might have been some data on there, it was nothing that I didn't have elsewhere anyway. Removing the broken disk from the XP VM returned the situation to fuller health, and I simply tried creating a new one again. So far, this seems to be working fine, yet I'll be keeping a watchful eye on things.

So far, I have no idea why the corruption happened, but the broken disk files were created without a VMDK extension, which might indicate that something was amiss with the process that created them. While it would be better if VMware highlighted the state of its virtual disks, it was when I tried opening the trashed disk with VirtualBox that a warning was given and VMware did the same when I tried it with that afterwards (opening VMware virtual disks with VirtualBox is possible, but you need to ensure that no attempt at importation is made, or you could end up with a breakage). While I may have discovered the fault in a roundabout manner, it's better to know what's gone wrong than not to know at all.