On 11/30/21 06:33, Nathan Vander Wilt wrote: > On Fri, Nov 26, 2021 at 11:08 PM Michal Prívozník <mprivozn@xxxxxxxxxx> wrote: >> Since you are providing the path to both UEFI image and varstore you can >> drop this 'firmware="efi"' attribute. It's what's causing troubles here. > > Thank you, yes! > >> A short trip into not so distant past. UEFI was introduced to QEMU, so >> libvirt came up with <loader type="pflash>/path/to/uefi</loader> and >> <nvram/> combo. This was suboptimal, because now users had to guess >> which FW to select (because it depends on guest arch, secure boot >> enabled, SMM mode, ...). So QEMU started shipping small, machine >> readable files to each BIOS/UEFI image, which libvirt would parse and >> pick the best one for given domain XML. And this is what firmware='efi' >> controls. IOW, using firmware='efi' is incompatible with specifying >> paths in <loader/> and <nvram/> and if you define this XML you'd see >> that the paths are not formatted back (e.g. in virsh dumpxml). > > Okay, yes this was unclear. It's not in the documentation afaict and I > saw some threads making it sound like it was the mere presence of the > JSON config files that made libvirt ignore any loader/nvram > configuration. But dropping the firmware attribute on the os element > was indeed the trick to get rid of the EFI error. Thanks for the > clarification! Yeah, writing documentation is hard. When doing so I tend to put myself into shoes of an user, but in fact I can never escape my developer mindset. What is obvious to me is not obvious to users, but at the same time - I'm unable to realize that. Having said that, if you have any suggestion, I'm more than happy to work it in. Michal
