Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Guest failed to start if using lun devices. Error like this
# virsh start vm1
error: Failed to start domain vm1
error: internal error: qemu unexpectedly closed the monitor: 2016-08-10T07:29:23.135463Z qemu-kvm: -device virtio-blk-pci,scsi=on,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Please set scsi=off for virtio-blk devices in order to use virtio 1.0
For now, qemu defaults to use virtio 1.0 as well as requires scsi=off, however, lun device has scsi=on. So libvirt needs to disallow this configuration
Version-Release number of selected component (if applicable):
libvirt-2.0.0-4.el7.x86_64
qemu-kvm-rhev-2.6.0-19.el7.x86_64
How reproducible:
100%
Steps to Reproduce:
1.configure lun device in domain xml
<disk type='block' device='lun'>
<driver name='qemu' type='qcow2'/>
<source dev='/dev/sdc'/>
<target dev='vda' bus='virtio'/>
<boot order='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</disk>
# virsh start vm1
error: Failed to start domain vm1
error: internal error: qemu unexpectedly closed the monitor: 2016-08-10T07:29:23.135463Z qemu-kvm: -device virtio-blk-pci,scsi=on,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Please set scsi=off for virtio-blk devices in order to use virtio 1.0
2.
3.
Actual results:
Guest starts failed
Expected results:
Libvirt need to disallow to configure lun device with virtio 1.0 together
Additional info:
The bug can be reproduced since qemu-kvm-rhev-2.6.0-19.el7.x86_64 due to the patches of https://bugzilla.redhat.com/show_bug.cgi?id=1360664 . We could add disable-modern=on when converting the xml to qemu command line.
This does not seem like something libvirt should fix.
If it worked with qemu-kvm-rhev before and it's supported, it should still work.
If it's not supported, I don't think printing a nicer error message is worth it at this point.
(In reply to Ján Tomko from comment #4)
> This does not seem like something libvirt should fix.
> If it worked with qemu-kvm-rhev before and it's supported, it should still
> work.
> If it's not supported, I don't think printing a nicer error message is worth
> it at this point.
It worked with qemu version prior to qemu-kvm-rhev-2.6.0-18.el7.x86_64. After BZ1360664 is fixed in qemu-kvm-rhev-2.6.0-19.el7, the default mode changes to disable-legacy=off and disable-modern=off. And virtio 1.0 needs scsi=off for virtio-blk devices. So -device virtio-blk-pci,scsi=on conflicts with virtio1.0 and does not work now
(In reply to Ján Tomko from comment #4)
> This does not seem like something libvirt should fix.
> If it worked with qemu-kvm-rhev before and it's supported, it should still
> work.
Apparently it's not supported anymore (Marcel?)
> If it's not supported, I don't think printing a nicer error message is worth
> it at this point.
What would be the alternative to an error message?
Jan,
Seems it is not a qemu issue, see comment #9. From POV of libvirt, it is indeed a critical bug. So I re-open it and move it to libvirt component.
The problem is that qemu bz#1360664 enabled virtio-1.0 by default and -device virtio-blk-pci,scsi=on conflicts with virtio1.0. Downstream libvirt does not provide an interface to disable virtio1.0 (or virtio-0.9) for user. So could libvirt add disable-modern=on when parsing the xml to qemu command line.
Thanks
I think libvirt should add disable-legacy=off,disable-modern=on when converting the virtio lun device xml to qemu cmdline, so that we make virtio lun devices available for users.
I think the reasoning in comment 11 makes sense (unfortunately).
virtio-blk lun has been deprecated for a long time, but probably has never been deprecated (formally(. I'm not sure what's the process for deprecating something in libvirt (tainting the domain?). Perhaps we could do the solution of comment 12 now (simple patch, downstream only, no need for backwards-compatibility to old QEMU I think) and work out a full deprecation strategy upstream.
I'm starting to wonder if anything can or should be done by libvirt about this:
https://www.redhat.com/archives/libvir-list/2016-September/msg00825.html
existing configs should continue to work due to their machinetype version, and new configs can use virtio-scsi. I suppose this might be a problem if OpenStack or RHV (see, I used the new name!!) can't do virtio-scsi...
Comment 22Jaroslav Suchanek
2016-09-22 14:04:07 UTC
This issue has been discussed a lot and various attempts were made including upstream and downstream only patch. None of it was accepted and as Laine pointed out in comment 21 of this bug it is actually not a issue for current configurations. For rhel-7.3 configuration the virtio-scsi is recommended.
Just to be clear, what is the expected result of this command
virsh attach-disk --domain $DOM --source /dev/sdb --target vdb --driver qemu \
--type lun
when run on a guest that does not support legacy virtio and chooses not to have a virtio-scsi controller? Failure is fine, as it's not supported, but how graceful/informative will that failure be? IOW, how can we avoid getting more bug reports?
Description of problem: Guest failed to start if using lun devices. Error like this # virsh start vm1 error: Failed to start domain vm1 error: internal error: qemu unexpectedly closed the monitor: 2016-08-10T07:29:23.135463Z qemu-kvm: -device virtio-blk-pci,scsi=on,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Please set scsi=off for virtio-blk devices in order to use virtio 1.0 For now, qemu defaults to use virtio 1.0 as well as requires scsi=off, however, lun device has scsi=on. So libvirt needs to disallow this configuration Version-Release number of selected component (if applicable): libvirt-2.0.0-4.el7.x86_64 qemu-kvm-rhev-2.6.0-19.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.configure lun device in domain xml <disk type='block' device='lun'> <driver name='qemu' type='qcow2'/> <source dev='/dev/sdc'/> <target dev='vda' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> # virsh start vm1 error: Failed to start domain vm1 error: internal error: qemu unexpectedly closed the monitor: 2016-08-10T07:29:23.135463Z qemu-kvm: -device virtio-blk-pci,scsi=on,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Please set scsi=off for virtio-blk devices in order to use virtio 1.0 2. 3. Actual results: Guest starts failed Expected results: Libvirt need to disallow to configure lun device with virtio 1.0 together Additional info: