QA » openQA Project

Motivation¶

The initial problem I observed is that PXEBOOT=once no longer works properly: it does a PXE boot every time the VM boots, not just the first time. I believe this was caused by https://github.com/os-autoinst/os-autoinst/commit/bb95579ddd226e3aac93fdaf4339b1037dd1915e , because it sets bootindex for the network device any time PXEBOOT is set, even if it's set to "once", and you cannot define "once" behaviour using bootindex (I've filed that as a missing qemu feature - https://gitlab.com/qemu-project/qemu/-/issues/1995 ).

When I went to look at fixing this, though, I struggled, because our behaviour here is pretty...messy. The qemu docs specifically say "Note that it does not make sense to use the bootindex property together with the -boot order=... (or -boot once=...) parameter. The guest firmware implementations normally either support the one or the other, but not both parameters at the same time. Mixing them will result in undefined behavior, and thus the guest firmware will likely not boot from the expected devices.", but we are definitely doing this. Even before bb95579 , I'm pretty sure there are cases in which we will set both -boot order and some bootindex values (e.g. any time we set BOOTFROM=disk on x86_64 BIOS, I think). The more I look at all the code that handles the BOOTFROM variable, the messier it seems and the harder it seems to resolve this sensibly.

I think conceptually it'd be simplest to just always use bootindex and drop the code to set -boot order and -boot once, but then we'd lose the "PXEBOOT=once" support where it works (only x86_64 BIOS, I think), and we'd have to check x86_64 BIOS actually supports/respects bootindex and it works the way we want in all the cases we support...

The interaction between BOOTFROM and PXEBOOT and USBBOOT seems pretty confused conceptually, too. Quick! If I set "BOOTFROM=disk PXEBOOT=1", what does that mean? What should it mean? What does it do?

Acceptance criteria¶

• AC1: Backwards compatibility has been preserved
• AC2: Common use cases of boot configurations are well-known and documented (e.g. in backend_vars.asciidoc or backend.md)
• AC3: The use cases identified via AC2 are supported

Suggestions¶

• Confirm best practice for boot options
• Consider if https://gitlab.com/qemu-project/qemu/-/issues/1995 is necessary or more "nice to have"
• Add documentation for how to use the settings correctly or link to upstream qemu docs
• Maybe revert the change that led to this problem (https://github.com/os-autoinst/os-autoinst/commit/bb95579ddd226e3aac93fdaf4339b1037dd1915e)
• Brainstorm on AC2 in a workshop session