[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy

[Frank Heimes]

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, Ready
  (I may have have missed some states in between.)
- Power Off, Ready is the final state at that point
  and on the console it's:
$ virsh list --all
 Id    Name                           State
----------------------------------------------------
 -     vm1                            shut off
- xml VM definition is:
$ virsh dumpxml vm1
<domain type='kvm'>
  <name>vm1</name>
  <uuid>0f7d1d61-9368-4bfe-8c65-c709e90e8780</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='s390x' machine='s390-ccw-virtio-bionic'>hvm</type>
    <boot dev='network'/>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source 
file='/var/lib/libvirt/maas-images/6addbfeb-ff2c-4350-b34d-11a56ea34f1d'/>
      <target dev='vda' bus='virtio'/>
      <serial>6addbfeb-ff2c-4350-b34d-11a56ea34f1d</serial>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0002'/>
    </disk>
    <interface type='network'>
      <mac address='52:54:00:ea:11:5f'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
    </interface>
    <console type='pty'>
      <log file='/var/log/libvirt/qemu/vm1-serial0.log' append='off'/>
      <target type='sclp' port='0'/>
    </console>
    <memballoon model='virtio'>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/>
    </memballoon>
    <panic model='s390'/>
  </devices>
</domain>

So it largely looks like assumed (after initially reading the bug),
PXE itself seems to work, but the boot issue it due to:
    <boot dev='network'/>
    <boot dev='hd'/>

That confirms the situation (on s390x and MAAS 2.6.2)m but it still
raises the question why it seem to have worked with 2.6.0?

-- 
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
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