I used ubuntu 20.04 or something
First, I used this tutorial to convert the vdi image to qcow2. I then installed qemu and libvirt and co on my new vm host system, moved the files there and used some long command I no longer remember to create a new virtual machine using some libvirt thing? I had to activate “default” network for that command to work, IIRC.
virt-viewer helped me connect to the vm’s screen, and it showed “booting from hard disk” and got stuck there, turned out I had to add an UEFI image because that’s what VirtualBox also used or smth. I used “virsh edit” for that IIRC, opening an xml file that was unexpectedly easy to read and modify, and this snippet in the <os> section helped:
<loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE.fd</loader>
We did it, Reddit. This is all you need.
It’s tempting, but wrong, to add this too:
You absolutely should not add the <nvram> section, only the <loader> one. Seems like qemu will try to write into the <nvram>-located file, and if you give it the OVMF_VARS.fd file, virt-aa-helper will throw apparmor-looking errors. saying “error: skipped restricted file” and even “internal error: cannot load AppArmor profile”.
It might look like apparmor is shouting at you, but if you look at syslog and kernel.log messages carefully, it’s actually virt-aa-helper, an additional layer of defense and protection way before apparmor even gets a chance to react. Adding or editing apparmor profiles will do nothing!
Changing the virt-aa-helper’s behaviour requires recompiling libvirt, but you don’t have to – just don’t add any nvram store and let qemu/libvirt/whoever add its own store, it will appear on its own in the xml file next time you launch the machine, I think.
from there… don’t touch it, I guess? or touch it, I’m not a cop. Anyway, that’s how my 1h+ detour into apparmor finished, with “just remove the nvram section with the /usr/share default file”. Makes sense that each guest gets its own nvram that’s assigned automatically, tbf.