Bug 1118847 - ovirt-engine currently sets the disk device to "lun" for all virtio-scsi direct LUN connections and disables read-only for these devices
Summary: ovirt-engine currently sets the disk device to "lun" for all virtio-scsi dire...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.4.0
Hardware: x86_64
OS: All
unspecified
high
Target Milestone: ---
: 3.5.0
Assignee: Daniel Erez
QA Contact: Elad
URL:
Whiteboard: storage
Depends On:
Blocks: 1125373 rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-07-11 16:52 UTC by Rob Washburn
Modified: 2019-05-20 11:16 UTC (History)
14 users (show)

Fixed In Version: ovirt-engine-3.5.0_rc1.1
Doc Type: Enhancement
Doc Text:
Previously, the Red Hat Enterprise Virtualization Manager was configured to set all virtio-SCSI direct LUN devices to the "LUN" device type. This device type does not support direct LUN read-only capability. Now, the Manager sets virtio-SCSI direct LUNs to the "disk" device type when the read-only option is enabled, which enables read-only functionality via SCSI emulation. This functionality is important, in particular, for Cloud Forms Management Engine appliances attempting to run smart-state analysis against Red Hat Enterprise Virtualization data storage domains with a large number of backing LUNs.
Clone Of:
: 1125373 (view as bug list)
Environment:
Last Closed: 2015-02-11 18:05:46 UTC
oVirt Team: Storage


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0158 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.5.0 2015-02-11 22:38:50 UTC
oVirt gerrit 30123 master MERGED core: allow read-only for VirtIO-SCSI DirectLUN disks Never
oVirt gerrit 30885 ovirt-engine-3.5 MERGED core: allow read-only for VirtIO-SCSI DirectLUN disks Never
oVirt gerrit 31333 master MERGED webadmin: attach disk - allow read-only for passthrough Never
oVirt gerrit 31340 ovirt-engine-3.5 MERGED webadmin: attach disk - allow read-only for DirectLUN Never
oVirt gerrit 31343 ovirt-engine-3.4 MERGED webadmin: attach disk - allow read-only for DirectLUN Never

Description Rob Washburn 2014-07-11 16:52:17 UTC
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.

Comment 1 Rob Washburn 2014-07-11 16:58:26 UTC
See BZ1082673 and BZ1110396 as background on the issue.

Comment 2 Allon Mureinik 2014-07-12 07:16:44 UTC
This may be related to change I7ceffe36e1145d4783c94f62043dfad694fdd290.
Daniel, please take a look?

Comment 3 Eyal Edri 2014-07-13 10:09:26 UTC
moving to 3.4.2, build for 3.4.1 is already closed for accepting new bugs.

Comment 4 Paolo Bonzini 2014-07-17 13:38:29 UTC
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.

Comment 5 Rob Washburn 2014-07-17 17:21:51 UTC
(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.

Comment 7 Elad 2014-08-11 10:56:49 UTC
Attaching a direct LUN connected by virt-IO-SCSI as RO is greyed out in webadmin.

Re-opening.

Checked with ovirt-3.5 RC1

Comment 8 Elad 2014-08-25 07:51:36 UTC
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

Comment 10 errata-xmlrpc 2015-02-11 18:05:46 UTC
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


Note You need to log in before you can comment on or make changes to this bug.