ecrypting image file breaks efi/boot of the guest/Ubuntu - ?

[lejeczek]

On 14/04/2023 13:57, Peter Krempa wrote:
> On Fri, Apr 14, 2023 at 13:39:17 +0200, lejeczek wrote:
>>
>> On 11/04/2023 09:13, Peter Krempa wrote:
>>> On Sat, Apr 08, 2023 at 11:25:18 +0200, lejeczek wrote:
>>>> Hi guys.
>>>>
>>>> I've have a guest and that guest differs from all other guest by:
>>>>
>>>>     <os>
>>>>       <type arch='x86_64' machine='pc-q35-rhel9.0.0'>hvm</type>
>>>>       <loader readonly='yes' secure='yes'
>>>> type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader>
>>>> <nvram>/var/lib/libvirt/qemu/nvram/ubusrv1_VARS.fd</nvram>
>>>>       <boot dev='hd'/>
>>>>       <bootmenu enable='yes'/>
>>>>     </os>
>>>>
>>>> whereas everything else has:
>>>>
>>>>     <os>
>>>>       <type arch='x86_64' machine='pc-q35-rhel9.0.0'>hvm</type>
>>>>       <boot dev='hd'/>
>>>>       <boot dev='cdrom'/>
>>>>       <bootmenu enable='yes'/>
>>>>     </os>
>>>>
>>>> Now, that different guest fails - as the only one - to start, to boot after
>>>> its qcow2 image was luks-encrypted.
>>>> Guest starts but says that:
>>>>
>>>> BdsDxe: failed to load Boot0001 "Uefi Misc Device" from PciRoot
>>>> (0x0)/Pci(0x2,0x3)/Pci(0x0,0x0): Not found
>>>>
>>>> revert back to original, non-encrypted qcow2 image and all works a ok.
>>> Please attach either the full XML or at least the disk part for *both*
>>> the case where it doesn't work and where it does work.
> [...]
>
>>    <devices>
>>      <emulator>/usr/libexec/qemu-kvm</emulator>
>>      <disk type='file' device='disk'>
>>        <driver name='qemu' type='qcow2' cache='none' discard='unmap'/>
>>        <source file='/00-VMs/ubusrv1.qcow2'/>
>>        <target dev='vda' bus='virtio'/>
>>        <address type='pci' domain='0x0000' bus='0x04' slot='0x00'
>> function='0x0'/>
>>      </disk>
>> ...
>>
>> When I add encryption to <disk> & use encrypted qcow2 then VM fails as I
>> described.
> I specifically asked for '*both*' XMLs. The working one. And the
> non-working one.
>
In case it might not be clear - which in my mind should not 
have been as it's simple, sure only in my mind - it is:
all guests use almost identical "template" with obvious 
differences, such as names/paths, hw adresses, now...

- tree guests have used 'pflash' in <os> from the beginning, 
always.

and I point to that as only those three guest fail to boot 
after their qcow2s were encrypted, just like all other VM's 
were, but those other VM's start & boot okey.
If in those three VMs I use original, non-encrypted qcow2 - 
without changing anything else in XML definition but 
'encryption' relevant in <disk> - then those VMs start & 
boot just fine.

thanks, L.