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)
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. fallthrough on s390x.
There is no fallback/
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/ qemuxml2xmloutd ata/machine- loadparm- multiple- disks-nets- s390.xml; h=c4e08fd4401bf 5bf448ee45ab889 0b3e44057f97; hb=HEAD