Description of problem: QEMU's virtio-scsi's direct LUN implementation directly passes SCSI commands to the target device, so it currently has no mechanism to filter non-read-only commands. QEMU's virtio-scsi implementation does support an emulated SCSI mode which does support read-only but the virtio-scsi device needs to be set to a "disk" device and not a "lun" device. VDSM currently supports the ability to change the virtio-scsi driver between a 'lun' device (passthrough) an 'disk' device (emulation); however, ovirt-engine is hardcoded to set the disk device to 'lun' for all virtio-scsi direct LUN connections. This realistically prevents using a CFME appliance to conduct smart-state analysis of RHEV 3.4 data storage domains backed by a large number of LUNs. Version-Release number of selected component (if applicable): RHEV 3.4 How reproducible: Every time. Steps to Reproduce: 1. Configure a direct LUN virtio-SCSI disk for a CFME 3.x VM appliance using one or more LUNs backing a RHEV data storage domain. Set the direct LUN to read-only for the CFME VM appliance. 2. Note that the virtio-SCSI direct LUN is actually R/W instead of read only. Actual results: virtio-SCSI Direct LUNs presented to RHEV 3.4 VM are read/write instead of read-only due to a QEMU limitation with handling virtio-SCSI labaled "lun" as read-only. Expected results: A simple solution to this issue could be to have ovirt-engine set the disk device to 'disk' for virtio-scsi direct LUN connections when the read-only option is enabled. That would avoid a potential UI change and fix the missing read-only support for virtio-scsi. Additional info: One important use case for direct LUN read-only with virtio-SCSI disks is CloudForms smart-state analysis, which requires the presentation of all LUNs backing a RHEV 3.4 storage domain to the CloudForms appliance via the Direct LUN read-only functionality that is native to RHEV 3.4. It is not uncommon for RHEV storage domains in large deployments to be backed by large numbers of smaller LUNs. In the CloudForms smart-state analysis scenario which requires presenting the backing LUNs to the CloudForms appliance via direct LUN read-only it is very easy to exceed the QEMU PCI device limit of the CloudForms appliance VM if you are constrained to using virtio-blk. Presenting direct LUNs read-only to the CloudForms appliance as virtio-scsi devices is a natural way to get around the QEMU PCI device limitation problem, as now the CloudForms appliance can conduct smart-state analysis of RHEV VMs across hundreds of storage domain backing LUNs. Because of the scope of access that CloudForms has to RHEV VM data across the enterprise it is essential that it be confined to read-only access for the VM disks that it is analyzing. If the direct LUN presentation of storage domain backing LUNs is the only mechanism for conducting smart-state analysis of RHEV VMs and if virtio-SCSI is a necessity for deploying CloudForms on large RHEV environments that RHEV’s direct LUN read-only functionality needs to work with virtio-SCSI disks.
See BZ1082673 and BZ1110396 as background on the issue.
This may be related to change I7ceffe36e1145d4783c94f62043dfad694fdd290. Daniel, please take a look?
moving to 3.4.2, build for 3.4.1 is already closed for accepting new bugs.
Quoting my reply on the upstream gerrit, I think this approach is not a good one. If you change 'lun' to 'disk' (or vice versa) the /dev/disk stable paths to the disks change, and the guest might be relying on them. Similarly, Windows might think the disk is a new one and it may not bring it online or it may assign a different disk letter. To provide full flexibility there should be two choices: - emulated/passthrough ('disk' vs. 'lun') - if emulated, read-only/read-write When QEMU adds support, passthrough read-only can be supported too.
(In reply to Paolo Bonzini from comment #4) > Quoting my reply on the upstream gerrit, I think this approach is not a good > one. If you change 'lun' to 'disk' (or vice versa) the /dev/disk stable > paths to the disks change, and the guest might be relying on them. > Similarly, Windows might think the disk is a new one and it may not bring it > online or it may assign a different disk letter. > > To provide full flexibility there should be two choices: > > - emulated/passthrough ('disk' vs. 'lun') > - if emulated, read-only/read-write > > When QEMU adds support, passthrough read-only can be supported too. I agree with you completely - this would necessitate a UX change at the ovirt-engine level to ensure that the user can pick and choose their desired virtio-scsi device flags. The current ovirt-engine UX only allows virtio-scsi "lun" device types (implicitly) for virtio-scsi direct LUNs presented to VMs.
Attaching a direct LUN connected by virt-IO-SCSI as RO is greyed out in webadmin. Re-opening. Checked with ovirt-3.5 RC1
When attaching a direct LUN connected to a VM by virt-IO-SCSI, the device is set to 'disk' <disk device="disk" snapshot="no" type= "block"> <address bus="0" controller="0" target="0" type="drive" unit="1"/> <source dev="/dev/mapper/3514f0c5462600003"/> <target bus="scsi" dev="sda"/> <readonly/> <serial></serial> <driver cache="none" error_policy="stop" io="native" name="qemu" type="raw"/> </disk> Verified that the disk is write protected by the OS. Verified using ovirt-3.5-RC1.1 oVirt Engine Version: 3.5.0-0.0.master.20140821064931.gitb794d66.el6
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html