** Project changed: qemu => qemu (Ubuntu)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM machine after initial deploy
Status in MAAS:
Triaged
Statu
Maybe this will 'automagically' get fixed and change if MAAS got rebased on LXD.
LXD 4.2 comes with KVM support for s390x and the MAAS version that is going to
be based on LXD is (iirc) 2.9?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
I still think that #29 could be a viable fix for this.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM machine after initial deploy
Status in MAAS:
It would appear that this bug is once again causing problems with some of our
automated testing.
S390x KVM deployments are failing for Focal. When attempting to investigate a
big I found that it is indeed this bug.
Our MAAS Server is Version:
maas:
Installed: 2.7.0-8232-g.6e1dba4ab-0ubuntu
Also, please note that the libvirt version did not change on the s390x
Virtual Machine Host.
On S390x VM Host
ii libvirt-clients 4.0.0-1ubuntu8.14
s390xPrograms for the libvirt library
ii libvirt-daemon4.0.0-1ubuntu8.14
After discussing, I realise I had a misunderstanding in comment #30 that
I'd like to correct.
I had incorrectly assumed that feeding the PXEBooting KVM guest a zero
length pxelinux.cfg file *instructed* it to boot from the local disk.
I now realise that is incorrect. Feeding the PXEBooting KVM gu
** Changed in: maas
Status: New => Triaged
** Changed in: maas
Importance: Undecided => Low
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM
After looking at the original description it does appear that I upgraded
maas since originally filing this bug, that upgrade was done to
workaround a different issue which was resolved since 2.6.1
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
Here is my pkg versions as things are now.
maas:
Installed: 2.6.2-7841-ga10625be3-0ubuntu1~18.04.1
Candidate: 2.6.2-7841-ga10625be3-0ubuntu1~18.04.1
On the s390x Lpar, Bionic, Linux s2lp6 4.15.0-74-generic #84-Ubuntu SMP
Thu Dec 19 08:05:42 UTC 2019 s390x s390x s390x GNU/Linux
ubuntu@s2lp6
To add to this discussion today, I noticed that some of the maas
deployments for s390x are working. I took a look and I was able to
successfully deploy 19.10/18.04/20.04
I have not changed anything on the MAAS host, I have not upgraded / altered
any packages.
I have not upgraded libvirt,
The on
@paelzer, Aye and thanks for your comment #27 , I was already aware of
that, and yes that does work. However, it's a shoddy workaround at best
and if this is going to be a solution to be presented to a customer MAAS
would be scoffed at.
I'm aware of the issue at hand here, I think the problem ex
My understanding from the MAAS design was that the suggestion in comment
#29 "Maas can boot from network (always) and if not deploying just issue
a "reboot from disk" command" was the intended design.
...and the "reboot from disk" command was the supply of an empty (zero
byte?) pxelinux.cfg.
But
OR
Maas can boot from network (always) and if not deploying just issue a "reboot
from disk" command
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM ma
The assumption from here was that this only appeared to be working due
to:
a) Deploy = netboot + reboot from disk = working
but at the same time
b) Start = netboot (fail) + no fallback = fail
To get that from Maas UI we stopped the guest (it went down as expected).
Then from Maas we said "powe
@sfeole - after initial deployment just do the change to your guest XMLs
you see in comment #27
@maas - as I said in comment #26 (and before) this needs coding in maas
to switch the XML content (or waiting a long time on IBM)
--
You received this bug notification because you are a member of qemu
I flipped
to
And JFH started it from the MAAS UI again.
Now things work (obviously as expected)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to
Here are the interesting bits from the log:
1 LOADPARM=[]^M
2 Network boot device detected^M
3 ^M
** Attachment added: "Guest XML "as it was once working""
https://bugs.launchpad.net/maas/+bug/1859656/+attachment/5327027/+files/vm1-as-deployed-by-maas.xml
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.n
The one that currently is deployed is using the same "list network and hd"
which should not work.
It will boot network but should not internally fall back to disk.
10
11 hvm
12
** Attachment added: "Serial log "as it was once working""
https://bugs.launchpad.net/maas/+bug/1859656/+attachment/5327028/+files/working-guest-serial.log
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net
In between I found the time to setup an env. build upon older releases:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename: bionic
$ dpkg -l | grep -i qemu
ii qemu-block-extra:s390x1:2.11+d
@Lee, do you think that the boot log from comment #18 looks fine?
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1859656/+attachment/5323507/+files/boot_console.txt
What would be the usual next step for MAAS KVM on s390x if the above is
successful (me not really knowing the exact internal flow)
I doubled check today again with sfeole and he confirmed that it worked
for him as well (and not only for me) when he just started using MAAS
KVM on s390x and had his initial setup...
Anyway, I'm now sure on how much effort we should spent on recreating the old
situation (I may try some old qemu/
It took some time (due to travel), but I was now able to do a setup
based on the old 2.6.0 version [2.6.0 (7803-g6fc5f26eb-
0ubuntu1~18.04.1)] for testing.
And with the combination:
$ apt-cache policy maas
maas:
Installed: 2.6.0-7803-g6fc5f26eb-0ubuntu1~18.04.1
Candidate: 2.6.0-7803-g6fc5f26e
The S390X KVM boot driver in MAAS really hasn't changed since it was
committed in 2018[1]. I doubt changing the version of MAAS will show it
working. I would try using older versions of qemu.
[1]
https://git.launchpad.net/maas/log/src/provisioningserver/boot/s390x.py
--
You received this bug not
I asked around a bit without going into the "why" and got confirmation from IBM
that fallthrough from netboot never existed.
In addition a RH engineer jumped in and said that they have this bug as well
and would appreciate if IBM would implement it (that is the RH ticket I added
to the other bug
The general issue with multiple boot elements on s390x was indeed already
identified back in 2017, and a ticket was opened and reverse mirrored to IBM
(so it should never have worked that way):
LP 1736511 (and btw. RH ticket is referenced there as well)
--
You received this bug notification bec
I took the time and recreated a MAAS setup (latest stable 2.2) on s390x and it
looks like this:
- I could start a deployment and ran through the states:
- Power On, Commissioning (Performing PXE boot)
- Power On, Commissioning (Gathering Information)
- Power On, Ready
- Power Off, Read
First check - as assumed - the old style config always failed.
It went into netboot, netboot fails and then it bails out.
root@testkvm-bionic-from:~# virsh start netboot --console
Domain netboot started
Connected to domain netboot
Escape character is ^]
done
Using IPv4 address: 192.168.122.33
TBH I'd really want to see how this worked as we didn't push anything to
Bionic that would have changed this recently.
I checked and the only change in that regard is really old.
It was for bug 1790901 which was a prereq for real IPXE on s390x.
So I doubt that MAAS could have worked before that.
N
** Tags added: s390x
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM machine after initial deploy
Status in MAAS:
New
Status in QEMU:
Incomplete
S
** Changed in: maas
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM machine after initial deploy
Status in MAAS:
Ne
Please note# https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1790901
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM machine after initial deploy
I tried the above workaround mentioned by Christian last week also, I
did not mention that in comment #6.
I tried using the boot order configuration as outlined in the
example(comment #9)
After the machine deploys, the same symptom occurs. So we are sort of
stuck again still.
Domain s2lp6g001 s
qemu-kvm doesn't exist for years, I have marked it for qemu instead.
Thanks Frank for making me aware.
Sean got everything right in comment #6, it can only boot one and that is the
first boot entry.
There is no fallback/fallthrough on s390x.
If you stick with global boot options the host would n
** Project changed: qemu-kvm => qemu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM machine after initial deploy
Status in MAAS:
Incomplete
Status
36 matches
Mail list logo
