Bug 1118847

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.