[libvirt] What to do about the qemu "-boot strict" option

[Laine Stump]

On 11/28/2013 01:56 AM, Amos Kong wrote:
> On Wed, Nov 27, 2013 at 02:37:02PM +0200, Laine Stump wrote:
>> Awhile back a bug was filed against libvirt about the inability to completely
>> exclude a disk from the boot order:
>>
>>    https://bugzilla.redhat.com/show_bug.cgi?id=888635
>>
>> In short, you can't have a domain that used PXE to boot, but also has an
>> un-bootable disk device *even if that disk isn't listed in the boot order*,
>> because if PXE times out (e.g. due to the bridge forwarding delay), the BIOS
>> will move on to the next target, which will be the unbootable disk device
>> (again - even though it wasn't given a boot order), and get stuck at a "BOOT
>> DISK FAILURE, PRESS ANY KEY" message until a user intervenes.
>> It was obviously beyond the ability of libvirt to fix this (although it can be
>> worked around by creating a very small disk image with a bootloader that merely
>> instructs the system to reboot, and placing *that* disk in the boot order just
>> after the PXE device), so the BZ was closed as CANTFIX.
> We have a reboot-timeout boot parameter to reboot guest if not found
> bootable device.

Yes. libvirt supports that parameter. The problem was that the disk was
"bootable", but just happened to boot into an "operating system" whose
only function was to print out

    BOOT DISK FAILURE, PRESS ANY KEY

then wait indefinitely for a key to be pressed :-)

>> A couple days ago I noticed that Amos Kong had later actually fixed this
>> problem in seabios and qemu:
>>
>>    https://bugzilla.redhat.com/show_bug.cgi?id=888633
>>    https://bugzilla.redhat.com/show_bug.cgi?id=903204
>>
>> Existing behavior is preserved though, and the new behavior only comes about if
>> "-boot strict" is specified on the qemu commandline.
>  
>> It definitely seems desirable to have this ability in libvirt, but I'm almost
>> of the opinion that this should *always* be the behavior (if you want all
>> devices to be in the boot order, you can just give all of them (or none of
>> them, if you're feeling adventurous) a boot order ranking).
> We leave the default as off just for compatibility with old qemu.
> For libvirt code, you can always use "strict=on"

Right. The fact that it's configurable in qemu raises the question of
whether there may be legitimate cases for libvirt where someone would
expect/demand the old behavior, and the new behavior would cause
breakage of existing setups. If there are, I don't want to prevent them
by making it unconfigurable, but if there aren't, I don't want to
clutter up config with yet another unnecessary knob.