libvirt users - May 2020 - Firmware auto-select limitation

Hi everyone and Martin 

I would like to confirm the conversation we had in regard the possible
limitation of firmware auto-select feature that’s been released since v5.20.  I
recall you saying that there were a lot of issues with auto select and later
they shipped it into a Json file , it  still didn’t solve all the problems, did
it?

Is it better to explicitly specify the loader and nvram path than using
auto-select ?

Just today, I encountered the issue of using firmware=“efi” on libvirt 5.4.0 

I am running Ubuntu eoan 19.10, I am wondering how did it happen.

Detailed error 
Error starting domain: internal error: process exited while connecting to
monitor: 2020-05-15T14:19:06.033267Z qemu-system-x86_64: -drive
file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on:
Failed to lock byte 100

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in
cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in
tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py",
line 66, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line
1279, in startup
    self._backend.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1080, in
create
    if ret == -1: raise libvirtError ('virDomainCreate() failed',
dom=self)
libvirt.libvirtError: internal error: process exited while connecting to
monitor: 2020-05-15T14:19:06.033267Z qemu-system-x86_64: -drive
file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on:
Failed to lock byte 100

On 5/15/20 4:40 PM, GUOQING LI wrote:
> Hi everyone and Martin
> 
> I would like to confirm the conversation we had in regard the possible 
> limitation of firmware auto-select feature that’s been released since 
> v5.20.  I recall you saying that there were a lot of issues with auto 
> select and later they shipped it into a Json file , it  still didn’t 
> solve all the problems, did it?
I'm not aware of any pending fw autoselection bug/problem.
> 
> Is it better to explicitly specify the loader and nvram path than using 
> auto-select ?
No.
> 
> Just today, I encountered the issue of using firmware=“efi” on libvirt 
> 5.4.0
If you specify the FW and NVRAM explicitly in the domain XML does this 
not reproduce?
> 
> I am running Ubuntu eoan 19.10, I am wondering how did it happen.
> 
> *Detailed error *
> Error starting domain: internal error: process exited while connecting 
> to monitor: 2020-05-15T14:19:06.033267Z qemu-system-x86_64: -drive 
> file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on: 
> Failed to lock byte 100
> 
This error message comes from QEMU. Unfortunately, it doesn't say why 
locking the file failed. Is there perhaps some additional info in the 
audit log?

I don't think this is related to FW autoselection (those bugs 
demonstrate in libvirt picking wrong FW image) and what you are facing 
is different.

Michal

On Fri, May 15, 2020 at 17:16:57 +0200, Michal Privoznik
wrote:
> On 5/15/20 4:40 PM, GUOQING LI wrote:
[...]
> > *Detailed error *
> > Error starting domain: internal error: process exited while connecting
> > to monitor: 2020-05-15T14:19:06.033267Z qemu-system-x86_64: -drive
> >
file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on:
> > Failed to lock byte 100
> > 
> 
> This error message comes from QEMU. Unfortunately, it doesn't say why
> locking the file failed. Is there perhaps some additional info in the audit
> log?
IMO there's another qemu where the 'readonly=on' command line
property
or thus the <readonly> property in the XML is missing and thus it's
opened in write mode. Readers are forbidden then.