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

[lejeczek]

On 17/04/2023 12:46, Peter Krempa wrote:
> On Fri, Apr 14, 2023 at 14:26:53 +0200, lejeczek wrote:
>>
>> 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.
> Well, your problem is then most likely with the guest image or the way
> how you've created/converted them.
>
> I've ran a few experiments and my machines that I've converted to
> encrypted qcows run properly with uefi.
>
>> BdsDxe: failed to load Boot0001 "Uefi Misc Device" from PciRoot
>> (0x0)/Pci(0x2,0x3)/Pci(0x0,0x0): Not found
> The error seems to indicate that the boot entry was not found, but the
> disk encryption is transparent when the disk is decrypted by qemu, so
> there should be no difference between an encrypted and unencrypted
> image.
>
> Thus why I suspect that the guest image is somehow not properly
> converted.
>
> Specifically I've managed to get this error when I had an empty
> encrypted image used with a VM.
>
I thought it was bit strange - but in the end, as almost 
everything, it turned out to be a human typo.
In my case - so if you see such errors check those - it was 
confused, by me, formats raw/qcow2.

many! thanks, L.