I wrote a test script to run the migrations you suggested in a reproducible manner, (sorry for taking so long, it took me quite a while to deal with all libvirt/QEMU/OVMF quirks)
Notes:
The reason why focal (upgraded) -> focal migration fails in the default "--boot uefi" scenario is; the upgraded host creates the guest with the new "_4M" images (because fw descriptors are now pointing to the 4M images), and the non-upgraded focal simply doesn't have them, hence the migration fails. VM stays on the source host, untouched.
You can find the test script and test reports in the following attachment.
Hello Christian,
I wrote a test script to run the migrations you suggested in a reproducible manner, (sorry for taking so long, it took me quite a while to deal with all libvirt/QEMU/OVMF quirks)
Here is the summary:
Migration of default "--boot uefi" guests:
focal -> focal(upgraded) [OK]
focal (upgraded) -> focal [FAIL] (see notes)
bionic -> focal [OK]
bionic -> focal (upgraded) [OK]
focal -> jammy [OK]
focal (upgraded) -> jammy [OK]
bionic -> focal -> jammy [OK]
bionic -> focal (upgraded) -> jammy [OK]
Migration of "--boot loader= OVMF_CODE. fd/OVMF_ VARS.fd" guests (simulates created guests before the update):
focal -> focal(upgraded) [OK]
focal (upgraded) -> focal [OK]
bionic -> focal [OK]
bionic -> focal (upgraded) [OK]
focal -> jammy [OK]
focal (upgraded) -> jammy [OK]
bionic -> focal -> jammy [OK]
bionic -> focal (upgraded) -> jammy [OK]
Notes:
The reason why focal (upgraded) -> focal migration fails in the default "--boot uefi" scenario is; the upgraded host creates the guest with the new "_4M" images (because fw descriptors are now pointing to the 4M images), and the non-upgraded focal simply doesn't have them, hence the migration fails. VM stays on the source host, untouched.
You can find the test script and test reports in the following attachment.