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
