qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Christian Ehrhardt " <1859656@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
Date: Tue, 21 Jan 2020 15:24:09 -0000	[thread overview]
Message-ID: <157962024941.4516.8390070990072713909.malone@soybean.canonical.com> (raw)
In-Reply-To: 157902669328.14768.4315907500950527119.malonedeb@wampee.canonical.com

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 needs to change the
XML to boot fro disk in this case. (BTW that is the case since the
beginnign the comment is from libvirt 3.5 somewhere around zesty I
think).

P.S. if this ever worked it was a bug that is not to be relied upon (but
I'd wonder)

But that doesn't mean it won't work, just not with that XML format.
I've never tested it but I think you might be able to get away with a proper bootorder config.
An example can be found here [1] that you might try (do not implement it directly, give it a test please)

[1]:
https://libvirt.org/git/?p=libvirt.git;a=blob;f=tests/qemuxml2xmloutdata
/machine-loadparm-multiple-disks-
nets-s390.xml;h=c4e08fd4401bf5bf448ee45ab8890b3e44057f97;hb=HEAD

** Changed in: qemu
       Status: New => Incomplete

-- 
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 in QEMU:
  Incomplete
Status in Ubuntu on IBM z Systems:
  Triaged

Bug description:
  MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1)
  Arch: S390x

  Appears that MAAS can not find the s390x bootloader to boot from the
  disk, not sure how maas determines this.  However this was working in
  the past. I had originally thought that if the maas machine was
  deployed then it defaulted to boot from disk.

  If I force the VM to book from disk, the VM starts up as expected.

  Reproduce:

  - Deploy Disco on S390x KVM instance
  - Reboot it

  on the KVM console...

  Connected to domain s2lp6g001
  Escape character is ^]
  done
    Using IPv4 address: 10.246.75.160
    Using TFTP server: 10.246.72.3
    Bootfile name: 'boots390x.bin'
    Receiving data:  0 KBytes
    TFTP error: file not found: boots390x.bin
  Trying pxelinux.cfg files...
    Receiving data:  0 KBytes
    Receiving data:  0 KBytes
  Failed to load OS from network

  ==> /var/log/maas/rackd.log <==
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] boots390x.bin requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64BA0 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64BA requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64B requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 requested by 10.246.75.160
  2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/default requested by 10.246.75.160

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1859656/+subscriptions


  parent reply	other threads:[~2020-01-21 15:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <157902669328.14768.4315907500950527119.malonedeb@wampee.canonical.com>
2020-01-21 14:54 ` [Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy Christian Ehrhardt 
2020-01-21 14:54 ` [Bug 1859656] [NEW] " Launchpad Bug Tracker
2020-01-21 15:24 ` Christian Ehrhardt  [this message]
2020-01-21 17:35 ` [Bug 1859656] " Sean Feole
2020-01-21 19:01 ` Sean Feole
2020-01-22 11:14 ` Frank Heimes
2020-01-23  6:17 ` Frank Heimes
2020-01-23  9:52 ` Christian Ehrhardt 
2020-01-23  9:55 ` Christian Ehrhardt 
2020-01-23 11:34 ` Frank Heimes
2020-01-23 11:49 ` Frank Heimes
2020-01-23 12:36 ` Christian Ehrhardt 
2020-01-23 17:02 ` Lee Trager
2020-01-28 10:58 ` Frank Heimes
2020-01-28 16:19 ` Frank Heimes
2020-01-30 15:43 ` Frank Heimes
2020-02-10 10:52 ` Frank Heimes
2020-02-10 14:12 ` Christian Ehrhardt 
2020-02-10 14:13 ` Christian Ehrhardt 
2020-02-10 14:14 ` Christian Ehrhardt 
2020-02-10 14:26 ` Christian Ehrhardt 
2020-02-10 14:31 ` Christian Ehrhardt 
2020-02-10 14:33 ` Christian Ehrhardt 
2020-02-10 14:33 ` Christian Ehrhardt 
2020-02-10 15:05 ` Christian Ehrhardt 
2020-02-10 17:09 ` Andrew Cloke
2020-02-10 21:49 ` Sean Feole
2020-02-10 21:53 ` Sean Feole
2020-02-10 22:04 ` Sean Feole
2020-02-10 22:11 ` Sean Feole
2020-02-11 17:53 ` Adam Collard
2020-02-12 11:27 ` Andrew Cloke
2020-04-09 14:34 ` Sean Feole
2020-04-09 14:37 ` Sean Feole
2020-04-09 16:18 ` Frank Heimes
2020-06-25 16:48 ` Frank Heimes
2020-07-18 14:33 ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=157962024941.4516.8390070990072713909.malone@soybean.canonical.com \
    --to=1859656@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).