** 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 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 - --- Original bug report --- + * 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
