How to use s390x pxelinux style network booting from qemu 3.0 in bionic
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
High
|
Unassigned | ||
qemu (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
* The netboot capability in qemu 2.11/2.12 are incomplete, they follow
an uncommon path of prebuilt binaries that bundle kernel/
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/
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. 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.
[1]: https:/
[2]: https:/
[3]: https:/
---
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.
Related branches
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 3448 lines (+3360/-0)14 files modifieddebian/changelog (+12/-0)
debian/patches/series (+12/-0)
debian/patches/ubuntu/lp-1790901-0001-ccw-update-libc.patch (+321/-0)
debian/patches/ubuntu/lp-1790901-0002-s390-ccw-move-auxiliary-IPL-data-to-separate-locatio.patch (+201/-0)
debian/patches/ubuntu/lp-1790901-0101-s390-Do-not-pass-inofficial-IPL-type-to-the-guest.patch (+80/-0)
debian/patches/ubuntu/lp-1790901-0102-s390-ccw-force-diag-308-subcode-to-unsigned-long.patch (+40/-0)
debian/patches/ubuntu/lp-1790901-0201-pc-bios-s390-ccw-net-Split-up-net_load-into-init-loa.patch (+184/-0)
debian/patches/ubuntu/lp-1790901-0202-pc-bios-s390-ccw-net-Use-diag308-to-reset-machine-be.patch (+299/-0)
debian/patches/ubuntu/lp-1790901-0203-pc-bios-s390-ccw-net-Add-support-for-.INS-config-fil.patch (+165/-0)
debian/patches/ubuntu/lp-1790901-0204-pc-bios-s390-ccw-net-Update-code-for-the-latest-chan.patch (+213/-0)
debian/patches/ubuntu/lp-1790901-0205-pc-bios-s390-ccw-net-Add-support-for-pxelinux-style-.patch (+200/-0)
debian/patches/ubuntu/lp-1790901-0206-pc-bios-s390-ccw-net-Try-to-load-pxelinux.cfg-file-a.patch (+106/-0)
debian/patches/ubuntu/lp-1790901-0207-pc-bios-s390-ccw-Optimize-the-s390-netboot.img-for-s.patch (+65/-0)
debian/patches/ubuntu/lp-1790901-partial-SLOF-for-s390x-netboot-2.11-to-3.0.patch (+1462/-0)
description: | updated |
tags: | added: s390x |
Changed in qemu (Ubuntu Bionic): | |
status: | New → Triaged |
Changed in ubuntu-z-systems: | |
status: | New → Triaged |
description: | updated |
description: | updated |
Changed in ubuntu-z-systems: | |
status: | Triaged → In Progress |
Changed in ubuntu-z-systems: | |
status: | In Progress → Fix Committed |
Changed in ubuntu-z-systems: | |
importance: | Undecided → High |
Changed in ubuntu-z-systems: | |
status: | Fix Committed → Fix Released |
Hi,
this would not only require a backport that seems hard (plenty of other cleanups/fixes to pc-bios/s390-ccw) but doable eventually with some extra work.
That part of it would be SRUable if we want to spend all the effort as it only fixes/improves the s390x netboot capabilities.
The initial netboot capabilities were only added in the 2.12 version (Cosmic) so we'd also need all the packaging changes.
That includes bringing back SLOF headers of the right version.
And with SLOF we have the biggest issue, for this to actually work we'd have to also bump SLOF quite a lot. Now that is a problem for many potential issues between the binary SLOF and ppc-qemu working against it vs the in-qemu-source SLOF that s390x needs to build the pxelinux.
Together the effort is high and the regression risk even higher, if I'd be SRU team I'd nack it so we might waste all the effort.