I recently switched over from Hyper-V to Qemu (KVM), and in migrating my VM’s unpleasantly discovered that I had neglected to use the Hyper-V tools to merge one of my Ubuntu VM’s disks containing several hundred gigabytes of data I’d like back.
Worse, I’d first checkpointed it immediately after install (a common practice for me to get a baseline) and had never previously merged, so the .avhdx file contains all the data I’m interested in; the .vhdx (which I have successfully copied then converted using qemu-img to poke at under Linux) has nothing but a base install plus locale/root password/ssh public keys/networking setup—just what you get from going through initial install.
Some sources suggest simply renaming the .avhdx file to have a .vhdx suffix, and I tried that (on a copy!) but qemu-img refused to work on the resulting file. Are there any other Linux-based tools that can help me here?
Alternately, if Windows Hyper-V tools are my only option, can I
- build a free trial Windows VM, since I don’t have a spare Windows license and
- get Hyper-V disk tools to merge the checkpoint without enabling the Hyper-V feature, which I believe the ordinary way to get those tools onto your system?
I ask the latter because my Qemu hypervisor is doing lots of virt-io and iommu passthrough (including raw disks for openZFS and a GPU), and I’ve heard that nested hypervisors can cause performance and device havoc on other preexisting VMs (and even that these issues don’t necessarily go away by stopping/deleting the nested hypervisor VM).
I don’t need Windows to be a hypervisor to merge the checkpoints—I just don’t know how else to get the tools installed. (I can’t recall if Windows requires a reboot immediately after turning on the Hyper-V feature, but if not, perhaps that’s my out—turn on the feature so the tools are available, use them to merge the checkpoint, then turn off the feature/shut down the VM for good.)
A colleague suggested that getting an Azure virt-on-virt (which supports nested Hyper-V) would be the easiest way to deal with this, but I’ve never done that before and as I mentioned the total size of the a?vhdx files is several hundred gigabytes, so not ideal for adding an upload/download step.
From what I can see on Gitlab it looks like some work has been done (as of this writing in May 2022) on qemu-img and .avhdx, just not enough for it to just work. I’m hoping someone has a workaround.
