Well, that is probably due to my (sometimes a bit too) kind way of writing. I've rephrased it now in a more precise, specific and clear way.
** Description changed: [ Impact ] * KVM virtual machines do not currently attempt booting from multiple targets, as defined by the targets' boot order properties. * Therefore, users cannot utilize existing management frameworks to control their boot order on CCW devices for multi device boot. * This SRU backports and utilizes the "virtio-ccw.loadparm" QEMU capabilities detection, so that if the QEMU version (detected at runtime) supports multi boot device, it makes use of it instead of using the single boot device machine parameter. [ Test Plan ] * Testing needs a specialized setup with virtualized CCW devices on s390x, an IBM z13 or LinuxONE system, running noble or newer. - * The (modified) qemu version of LP#2049698 is needed - and the libvirt version of this bug LP#2051239 is needed, - since this libvirt depends on the modified qemu. + * The (modified) qemu version of LP#2049698 is needed + and the libvirt version of this bug LP#2051239 is needed, + since this libvirt depends on the modified qemu. - * The test itself would require at least two (ideally more) - bootable devices listed in the boot order (virsh xml file), like: - <os> - <type arch='s390x' machine='s390-ccw-virtio-noble'>hvm</type> - <boot dev='cdrom'/> - <boot dev='hd1'/> - <boot dev='hd2'/> - </os> - and proper detailed device section for the dev atrributes. - - * Then several cases should be tested: - - booting from the first (bootable) device, - if the second device is also bootable. - (regression test) - - booting from a (bootable) second device, - with having a first device that is not bootable. - (So that an attempt is made to boot from the second) - (test of new functionality) - - booting from a third (or later) (bootable) device, - when two (or more) devices earlier in the order are not bootable. - (So than more than one attempt is made to boot from a device). - (test of new functionality) - For achieving this the boot order needs to be adjusted, - and devices accordingly added that are bootable and non-bootable - to catch the above cases. - Different devices should be used as well, like CDROM and harddisks - of different types. + * The test itself requires at least two (ideally more) + bootable devices listed in the boot order, like (virsh xml file): + <os> + <type arch='s390x' machine='s390-ccw-virtio-noble'>hvm</type> + <boot dev='cdrom'/> + <boot dev='hd1'/> + <boot dev='hd2'/> + </os> + and obviously proper detailed device section for the dev attributes + are needed in the xml definition on top. + + * The following test cases provide a coverage that is sufficient: + 1) booting from the first (bootable) device, + if the second device is also bootable. + (regression test) + 2) booting from a (bootable) second device, + with having a first device that is not bootable. + (So that an attempt is made to boot from the second) + (test of new functionality) + 3) booting from a third (or later) (bootable) device, + when two (or more) devices earlier in the order are not bootable. + (So that more than one attempt is made to boot from a device). + (test of new functionality) + Whereas 1) and 2) are mandatory and 3) is strongly suggested. + For achieving this, the boot order needs to be adjusted, + and devices added accordingly, so that bootable and non-bootable + device are available to catch the above cases. + Different devices (at least two) need to be in place and used, + and also different type of devices, at least CDROM and harddisk. * The original bug reporter is supposed to help on the verification. [ Where problems could occur ] * This change touches the QEMU feature-flag/capabilities detection (for QEMU_CAPS_VIRTIO_CCW_DEVICE_LOADPARM). It is mostly isolated to virtualized s390x CCW devices, but if anything goes wrong, it could affect the overall capabilities detection of libvirt, leading to invalid control commands being generated for QEMU and therefore a change in behavior. * For the potential change in behavior, please also see [ Other Info ], 's390x KVM: Full Boot Order considerations' details. [ Other Info ] * This enablement work is targeted to virtualized CCW devices on s390x * QEMU part of this enablement work is tracked in bug #2049698 - this modified qemu is needed for the overall test of libvirt, - but also vice-versa. + this modified qemu is needed for the overall test of libvirt, + but also vice-versa. * s390x KVM: Full Boot Order considerations I want to leave some more details and explanation about a potential risk due to a potential change in behavior (thanks to Boris F. for the discussion - here is the summary): There is already a "boot order" before this 'full boot order patch set' that is in discussion here, but so far libvirt handed over only the first device of the boot order as boot device to qemu. Since this is a known limitation to qemu on s390x users, there is usually just only one device specified in the boot order (aka list) - on s390x. Means a guest boots from the first (and usually only) boot device, or it does not boot at all. But one could define one or more devices in the domain XML - also on s390x, but this didn't change anything - the boot device was always the first one. Let’s go into some more details and distinguish the following two cases, where multiple boot devices are configured (which again is unlikely, since this was not supported, didn't work, hence wouldn’t change anything, but nevertheless let us play it through to consider the regression risk for this change): 1) the first device is bootable 2) the first device is NOT bootable This leads to the following results with and without the full boot order patch set: 1) a) without patch set: guest starts from first device b) with patch set: guest starts from first device 2) a) without patch set: guest does not start at all as the first device fails b) with patch set: guest does not start from first device AND an attempt is made to boot from the next device in the boot order So there is a potential change in behavior in case 2) b). But if a system is configured today, it is obviously configured to work, that usually means it has only one bootable device - or in case it has multiple ones (which is unlikely, since it was never supported), the first one will be bootable. So case 1) can strongly be assumed. Case 2) can be considered as an extreme (and useless) edge case, since: i) a user would need to have a guest configured with a device that it cannot boot from (which provides no function and with that no value) ii) a user would need to have multiple devices configured in the boot order and one other than the first one is bootable (which was not supported until now and never work) And only if both cases (i) and ii)) would apply, a change in the behavior would be noticeable. ----- Original bug report ----- Allow KVM virtual machines to attempt booting from multiple targets, as defined by the targets' boot order properties. Customers will benefit from simplified installation, and can reuse existing management frameworks. (This is the libvirt part of the feature) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2051239 Title: [25.04 FEAT] [VS1807] KVM: Full boot order support - libvirt part To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2051239/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
