Default shared configuration has incorrect assumptions

[pevogam]

The setting in

avocado-vt/virttest/shared/cfg/guest-hw.cfg

Line 88 in 80ca89f

image_boot~=yes

has preceding comment

        # Add -drive ...boot=yes unless qemu-kvm is 0.12.1.2 or newer
        # then kvm_vm will ignore this option.

but on most recent Qemu 8.2 it is not ignored and rather has a dramatic effect on our VT tests where the image will be strictly booted in cases of UEFI reinstallation and USB installation tests that previously relied on alternative boot order configuration using Avocado VT. Is this default really intended to be set? If not I would recommend

-         image_boot~=yes
+         # image_boot~=yes

which used to be the case long ago. Is there any other purpose behind this parameter and its meaning different then the above-mentioned comment?

@luckyh @YongxueHong Do you happen to know more about this choice?

[luckyh]

@pevogam sorry, I cannot recall on that since it was introduced too long ago (more than 10 years)... anyway, I'd like to prefer to drop the setting as well due to

• we don't apply such a setting to other kind of virtual block devices, that means we seems to be safe for dealing with boot orders in the case that image_boot not being present
• nowadays, qemu don't even have the option (-drive ...,boot=) documented in the manual page
• -blockdev was recommended to be the replacement of -drive from several years ago and the former don't support the boot option

does it sounds good to you?

[pevogam]

@pevogam sorry, I cannot recall on that since it was introduced too long ago (more than 10 years)...

Indeed, the difference is that back then it was commented out and later through the years it got uncommented and now ended up affecting out test suite as it was still making use of -drive options via the virttest parameter qemu_force_use_drive_expression. The ~= must have only affected users that defined the image_boot parameter on the first place but in our case it seems it somehow comes up and as a result this setting completely modifies our previous behavior when we switched to virtio storage.

anyway, I'd like to prefer to drop the setting as well due to

* we don't apply such a setting to other kind of virtual block devices, that means we seems to be safe for dealing with boot orders in the case that `image_boot` not being present

* nowadays, qemu don't even have the option (`-drive ...,boot=`) documented in the manual page

* `-blockdev` was recommended to be the replacement of `-drive` from several years ago and the former don't support the `boot` option

does it sounds good to you?

Perhaps it is worth keeping it a while longer for backwards compatibility. My main point and worry was that it introduces unexpected behavior in comparison to other storage hardware variants since we were using -drives there and didn't end up forced to always boot the same image (e.g. when wanting to boot from a CD or USB instead). And I definitely can't find image_boot anywhere in our configs but it got triggered by this line when switching to virtio storage hardware variant.