** Description changed: + [Impact] + + * The netboot capability in qemu 2.11/2.12 are incomplete, they follow + an uncommon path of prebuilt binaries that bundle kernel/initrd/config + into one image and that can be booted. + To fully exploit the new (virtial) HW capability as it was planned for + 18.04 initially we'd need more. + + * In qemu 3.0 the code finalized implementing real "standard" PXE boot + capabilities. That is of a high demand to now be available back to at + least 18.04. Not limited to, but for example for solutions like MAAS + that rely on PXE. + + * This is IMHO checking multiple boxes of the "safe cases" of the SRU + policy [1]. To some extend it touches: + 1. "affect an application rather than critical infrastructure" by + modifying only the s390x netboot feature + 2. "For Long Term Support releases we regularly want to enable new + hardware" while here it is virtual hardware that we want to enable. + But the closest match of these rules is: + 3. "Long Term Support releases we sometimes want to introduce new + features". It qualifies for the statements there of being + unintrusive, tested and not changing other parts. + + [Test Case] + + * Follow this blog that we wrote for the old version [2], but requiring + much less steps. + Follow steps: + "Prepare a tftp server" (install and configure tftp) + "Prepare libvirt network to provide PXE" (tftp and bootp entries) + "Prepare guest definition" (<boot dev='network'/>) + Then create a pxlinux.cfg entry matching the ID of the guest (if u + $ cat /tftpboot/pxelinux.cfg/b785659a-a351-490b-a0b7-d4bf6610419d + kernel kernel.ubuntu + initrd initrd.ubuntu + append testparm1=foo testparm2=bar + If you don't know the ID you can use MAC, UUID or other things - just + boot the guest without config and you will see the ID + + Finally boot the guest with a console attached immediately to see PXE + in action. + $ virsh start --console <guestname> + + * these should allow someone who is not familiar with the affected + package to reproduce the bug and verify that the updated package fixes + the problem. + + [Regression Potential] + + * There are three ways to look at that in regard to regression potential. + 1. What should it affect + It affects the netboot capabilities of qemu for s390x. + 2. What it could affect + Due to the fact which code changed and what is build from it (only + s390x ROMs) the one things that might regress in case we missed + something in backport and tests is the local boot from s390-ccw.img + We checked multiple times in review and tested it to ensure that + there should be nothing that breaks/changes in there. + 3. What it should not affect + Everything else that "could" be built from the modified source + is not built (as it is split to src:slof), therefore no influence + there. + + [Other Info] + + * I filed no FFE [3] as the rules for an SRU are harder and it qualifies + for that. Also since without an FFE we'd most likely "just SRU it + later" IMHO there is no point in an FF-Block on this bug. + + [1]: https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases + [2]: https://blog.ubuntu.com/2017/12/20/early-experiences-with-pxe-net-boot-of-kvm-vms-on-ubuntu-for-s390x + [3]: https://wiki.ubuntu.com/FreezeExceptionProcess + + --- + QEMU 3.0 has recently released with support for pxelinux style network booting from s390x. As part of the MAAS roadmap, we have an item to enable s390x as a supported architecture for deployment of KVM image. Since QEMU now includes that support upstream, we would like an evaluation of whether it would be possible to backport this feature back to Bionic's QEMU to avoid having to create a work around in MAAS that are not supported upstream. Note that the MAAS team has not tested this feature. https://wiki.qemu.org/ChangeLog/3.0#s390_firmware
** Description changed: [Impact] - * The netboot capability in qemu 2.11/2.12 are incomplete, they follow - an uncommon path of prebuilt binaries that bundle kernel/initrd/config - into one image and that can be booted. - To fully exploit the new (virtial) HW capability as it was planned for - 18.04 initially we'd need more. + * The netboot capability in qemu 2.11/2.12 are incomplete, they follow + an uncommon path of prebuilt binaries that bundle kernel/initrd/config + into one image and that can be booted. + To fully exploit the new (virtial) HW capability as it was planned for + 18.04 initially we'd need more. - * In qemu 3.0 the code finalized implementing real "standard" PXE boot - capabilities. That is of a high demand to now be available back to at - least 18.04. Not limited to, but for example for solutions like MAAS - that rely on PXE. + * In qemu 3.0 the code finalized implementing real "standard" PXE boot + capabilities. That is of a high demand to now be available back to at + least 18.04. Not limited to, but for example for solutions like MAAS + that rely on PXE. - * This is IMHO checking multiple boxes of the "safe cases" of the SRU - policy [1]. To some extend it touches: - 1. "affect an application rather than critical infrastructure" by - modifying only the s390x netboot feature - 2. "For Long Term Support releases we regularly want to enable new - hardware" while here it is virtual hardware that we want to enable. - But the closest match of these rules is: - 3. "Long Term Support releases we sometimes want to introduce new - features". It qualifies for the statements there of being - unintrusive, tested and not changing other parts. + * This is IMHO checking multiple boxes of the "safe cases" of the SRU + policy [1]. To some extend it touches: + 1. "affect an application rather than critical infrastructure" by + modifying only the s390x netboot feature + 2. "For Long Term Support releases we regularly want to enable new + hardware" while here it is virtual hardware that we want to enable. + But the closest match of these rules is: + 3. "Long Term Support releases we sometimes want to introduce new + features". It qualifies for the statements there of being + unintrusive, tested and not changing other parts. [Test Case] - * Follow this blog that we wrote for the old version [2], but requiring - much less steps. - Follow steps: - "Prepare a tftp server" (install and configure tftp) - "Prepare libvirt network to provide PXE" (tftp and bootp entries) - "Prepare guest definition" (<boot dev='network'/>) - Then create a pxlinux.cfg entry matching the ID of the guest (if u - $ cat /tftpboot/pxelinux.cfg/b785659a-a351-490b-a0b7-d4bf6610419d - kernel kernel.ubuntu - initrd initrd.ubuntu - append testparm1=foo testparm2=bar - If you don't know the ID you can use MAC, UUID or other things - just - boot the guest without config and you will see the ID + * Follow this blog that we wrote for the old version [2], but requiring + much less steps. + Follow steps: + "Prepare a tftp server" (install and configure tftp) + "Prepare libvirt network to provide PXE" (tftp and bootp entries) + "Prepare guest definition" (<boot dev='network'/>) + Then create a pxlinux.cfg entry matching the ID of the guest (if u + $ cat /tftpboot/pxelinux.cfg/b785659a-a351-490b-a0b7-d4bf6610419d + kernel kernel.ubuntu + initrd initrd.ubuntu + append testparm1=foo testparm2=bar + If you don't know the ID you can use MAC, UUID or other things - just + boot the guest without config and you will see the ID - Finally boot the guest with a console attached immediately to see PXE - in action. - $ virsh start --console <guestname> + Finally boot the guest with a console attached immediately to see PXE + in action. + $ virsh start --console <guestname> - * these should allow someone who is not familiar with the affected - package to reproduce the bug and verify that the updated package fixes - the problem. + * these should allow someone who is not familiar with the affected + package to reproduce the bug and verify that the updated package fixes + the problem. [Regression Potential] - * There are three ways to look at that in regard to regression potential. - 1. What should it affect - It affects the netboot capabilities of qemu for s390x. - 2. What it could affect - Due to the fact which code changed and what is build from it (only - s390x ROMs) the one things that might regress in case we missed - something in backport and tests is the local boot from s390-ccw.img - We checked multiple times in review and tested it to ensure that - there should be nothing that breaks/changes in there. - 3. What it should not affect - Everything else that "could" be built from the modified source - is not built (as it is split to src:slof), therefore no influence - there. + * There are three ways to look at that in regard to regression potential. + 1. What should it affect + It affects the netboot capabilities of qemu for s390x. There are no + known users of the feature as it is today due to it's current + limitations. Even with the change it could still boot the squashed + binary that it can today, although being so "uncomfortable" we + expect no one to do so. + There could be cases where former PXE setups using the old technique + would have to be slightly adapted to work with the new one. But all + partners and peers related to this expressed that the current one is + almost unusable and they'd want the new one. + Therefor this potential regression is minor and worth to take for + the benefits to make the feature really usable. + 2. What it could affect + Due to the fact which code changed and what is build from it (only + s390x ROMs) the one things that might regress in case we missed + something in backport and tests is the local boot from s390-ccw.img + We checked multiple times in review and tested it to ensure that + there should be nothing that breaks/changes in there. + 3. What it should not affect + Everything else that "could" be built from the modified source + is not built (as it is split to src:slof), therefore no influence + there. [Other Info] - - * I filed no FFE [3] as the rules for an SRU are harder and it qualifies - for that. Also since without an FFE we'd most likely "just SRU it - later" IMHO there is no point in an FF-Block on this bug. + + * I filed no FFE [3] as the rules for an SRU are harder and it qualifies + for that. Also since without an FFE we'd most likely "just SRU it + later" IMHO there is no point in an FF-Block on this bug. [1]: https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases [2]: https://blog.ubuntu.com/2017/12/20/early-experiences-with-pxe-net-boot-of-kvm-vms-on-ubuntu-for-s390x [3]: https://wiki.ubuntu.com/FreezeExceptionProcess --- QEMU 3.0 has recently released with support for pxelinux style network booting from s390x. As part of the MAAS roadmap, we have an item to enable s390x as a supported architecture for deployment of KVM image. Since QEMU now includes that support upstream, we would like an evaluation of whether it would be possible to backport this feature back to Bionic's QEMU to avoid having to create a work around in MAAS that are not supported upstream. Note that the MAAS team has not tested this feature. https://wiki.qemu.org/ChangeLog/3.0#s390_firmware -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1790901 Title: How to use s390x pxelinux style network booting from qemu 3.0 in bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790901/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
