| 2018-09-05 16:01:38 |
Andres Rodriguez |
bug |
|
|
added bug |
| 2018-09-05 16:17:43 |
Andres Rodriguez |
description |
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. |
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 |
|
| 2018-09-06 06:42:57 |
Frank Heimes |
bug |
|
|
added subscriber Frank Heimes |
| 2018-09-06 06:43:56 |
Frank Heimes |
tags |
|
s390x |
|
| 2018-09-06 07:33:58 |
Andrew Cloke |
bug |
|
|
added subscriber Andrew Cloke |
| 2018-09-10 14:31:01 |
Christian Ehrhardt |
summary |
Backporting s390x pxelinux style network booting from qemu 3.0 to bionic |
How to use s390x pxelinux style network booting from qemu 3.0 in bionic |
|
| 2018-09-10 14:32:21 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
Invalid |
|
| 2018-09-26 18:39:29 |
Joshua Powers |
bug |
|
|
added subscriber Joshua Powers |
| 2018-09-27 05:51:38 |
Christian Ehrhardt |
qemu (Ubuntu): status |
Invalid |
Triaged |
|
| 2018-09-27 18:00:24 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-09-27 18:00:24 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Cosmic) |
|
| 2018-09-27 18:00:24 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-09-27 18:00:24 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Bionic) |
|
| 2018-09-27 18:00:55 |
Christian Ehrhardt |
qemu (Ubuntu Bionic): status |
New |
Triaged |
|
| 2018-09-27 18:14:39 |
Frank Heimes |
bug task added |
|
ubuntu-z-systems |
|
| 2018-09-27 18:14:52 |
Frank Heimes |
ubuntu-z-systems: status |
New |
Triaged |
|
| 2018-09-28 05:45:54 |
Christian Ehrhardt |
description |
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 |
[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 |
|
| 2018-09-28 05:48:45 |
Christian Ehrhardt |
description |
[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 |
[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. 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://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 |
|
| 2018-10-02 16:52:57 |
Launchpad Janitor |
qemu (Ubuntu Cosmic): status |
Triaged |
Fix Released |
|
| 2018-10-04 06:39:46 |
Frank Heimes |
ubuntu-z-systems: status |
Triaged |
In Progress |
|
| 2018-10-10 12:49:59 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/356406 |
|
| 2018-10-10 12:50:38 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/356407 |
|
| 2018-10-19 09:45:38 |
Robie Basak |
qemu (Ubuntu Bionic): status |
Triaged |
Fix Committed |
|
| 2018-10-19 09:45:39 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-10-19 09:45:40 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2018-10-19 09:45:42 |
Robie Basak |
tags |
s390x |
s390x verification-needed verification-needed-bionic |
|
| 2018-10-19 10:06:09 |
Frank Heimes |
ubuntu-z-systems: status |
In Progress |
Fix Committed |
|
| 2018-10-22 05:06:55 |
Christian Ehrhardt |
tags |
s390x verification-needed verification-needed-bionic |
s390x verification-done verification-done-bionic |
|
| 2018-10-25 12:16:03 |
Frank Heimes |
ubuntu-z-systems: importance |
Undecided |
High |
|
| 2018-10-29 09:17:01 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-10-29 09:27:06 |
Launchpad Janitor |
qemu (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-10-29 09:28:31 |
Frank Heimes |
ubuntu-z-systems: status |
Fix Committed |
Fix Released |
|
