On Tue, Jul 09, 2024 at 08:41:17AM GMT, mirlos--- via Devel wrote: > My reply by email has not arrived by now, hence I'll post it via > the archive site. Sorry for the potential double post. No double post as far as I can tell :) > Older bootloaders were not split into separate _CODE.fd and _VARS.fd, > i.e. there was no separate nvram for the latter file to create. The guest > could write to the single bootloader, which then must not be shared. > > You mark such bootloaders readonly=no and make a copy of the pflash, > e.g. next to the VM's disk files, as you did in your TEST ONLY run. > > It is a mode of operation supported by the formatdomain documentation > on the loader element and intended to work as described. This patch > makes such combination of parameters actually succeed on Ubuntu, > which I find should be useful to the project. > > In the VMs we use this for, they do not actually write anything to the loader. > This meant that we never noticed the bug, which was present in focal and > configured qemu to open the loader read-only anyway. But it failed on AA > in noble since the bug is now fixed in newer libvirt. So the behavior changed between libvirt 6.0.0 in Ubuntu 20.04 and libvirt 10.0.0 in Ubuntu 24.04. That's not surprising, since I've done a lot of work to fix and improve firmware handling around the 9.2.0 timeframe. You seem to identify the change of behavior as a bug fix, which matches my understanding too. > As a workaround, we've in the mean time switched to marking the loader > stateless and read-only, which is now allowed in libvirt, and also works > without requiring a separate nvram. Of course, this only works because > the VM does not make any writes and would fail in case it needed to. Right, that ought to do the trick. As far as I'm concerned, I'm satisfied with the explanation you've provided so the patch gets my Reviewed-by: Andrea Bolognani <abologna@xxxxxxxxxx> Christian, any objection to pushing it? -- Andrea Bolognani / Red Hat / Virtualization
