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.
Bug 1365823 - -device virtio-blk-pci,scsi=on no longer works
Summary: -device virtio-blk-pci,scsi=on no longer works
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Ján Tomko
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 1432057 (view as bug list)
Depends On: 1227354
Blocks: 1173757 1366991
TreeView+ depends on / blocked
 
Reported: 2016-08-10 09:41 UTC by Yang Yang
Modified: 2017-07-21 11:05 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-22 14:04:07 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Yang Yang 2016-08-10 09:41:33 UTC 
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:
Comment 2 Han Han 2016-08-24 02:55:30 UTC 
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.
Comment 3 Yang Yang 2016-09-09 05:07:27 UTC 
Hi,

Is there time to fix it in RHEL7.3
Comment 4 Ján Tomko 2016-09-09 11:55:14 UTC 
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.
Comment 5 Yang Yang 2016-09-12 02:16:25 UTC 
(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
Comment 6 Ademar Reis 2016-09-12 12:41:21 UTC 
(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?
Comment 10 Ademar Reis 2016-09-14 01:22:38 UTC 

*** This bug has been marked as a duplicate of bug 1245453 ***
Comment 11 Yang Yang 2016-09-14 02:28:39 UTC 
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
Comment 12 Han Han 2016-09-14 06:38:00 UTC 
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.
Comment 13 Xuesong Zhang 2016-09-14 06:50:35 UTC 
The virtio lun disk is working well in RHEL7.2, but do not working well in current RHEL7.3. So, I add regression keyword in this bug.
Comment 15 Paolo Bonzini 2016-09-14 11:18:02 UTC 
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.
Comment 20 Ján Tomko 2016-09-20 12:27:04 UTC 
Upstream proposal to add disable-modern=on and log a warning:
https://www.redhat.com/archives/libvir-list/2016-September/msg00787.html
Comment 21 Laine Stump 2016-09-20 20:50:34 UTC 
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 22 Jaroslav 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.
Comment 23 Ján Tomko 2017-03-14 13:46:30 UTC 
*** Bug 1432057 has been marked as a duplicate of this bug. ***
Comment 24 Andrew Jones 2017-03-14 14:11:05 UTC 
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?
Note You need to log in before you can comment on or make changes to this bug.