diskless virtio-scsi-ccw controller triggers an error
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
Medium
|
bugproxy | ||
qemu (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
The example starts with a basic call to run an image (it doesn't matter which image)
$ sudo qemu-system-s390x -enable-kvm -cpu host -nographic -m 512 -hda ubuntu-
LOADPARM=[........]
Using virtio-blk.
Using SCSI scheme.
....
[ 0.451611] Linux version 4.15.0-42-generic (buildd@
[ 0.451617] setup.289988: Linux is running under KVM in 64-bit mode
Adding an empty virtio-scsi-ccw breaks it (different than x86)
$ sudo qemu-system-s390x -enable-kvm -cpu host -nographic -m 512 -hda ubuntu-
LOADPARM=[........]
Using virtio-scsi.
! Cannot locate virtio-scsi device !
It seems to be the bootloader code insisting on a device to scan, since skipping bootloader makes it work
$ sudo qemu-system-s390x -enable-kvm -cpu host -nographic -m 512 -hda ubuntu-
[ 0.475643] Linux version 4.15.0-42-generic (buildd@
[ 0.475649] setup.289988: Linux is running under KVM in 64-bit mode
Those are just examples, but it seems you can add a disk-less virtio-scsi-ccw to any to make it break.
We wondered about two things:
- the behavior is different than with virtio-scsi-pci
- one use case could want add a virtio-scsi-ccw with some explicit config to later hot-add devices right?
All of this could as well be intentional, but I wanted to report it in case it is a bug for you as well.
Thanks @Rharper for finding and mentioning it
Changed in ubuntu-z-systems: | |
assignee: | nobody → bugproxy (bugproxy) |
tags: | added: reverse-proxy-bugzilla s390x |
Changed in ubuntu-z-systems: | |
status: | New → Triaged |
tags: | added: architecture-s39064 bugnameltc-173834 severity-high targetmilestone-inin1804 |
Changed in ubuntu-z-systems: | |
importance: | Undecided → Medium |
Changed in ubuntu-z-systems: | |
status: | Triaged → Confirmed |
tags: | added: qemu-21.04 |
Changed in ubuntu-z-systems: | |
status: | Incomplete → Fix Released |
------- Comment From <email address hidden> 2019-01-09 04:03 EDT-------
This is certainly something where we can improve the heuristics to guess the right boot device, but it is low priority and severity. It will not happen with libivrt and it will not happen when the user specifies a boot priority.
Reducing severity.