Bug 1801206

Summary: Possible missing block path for a SCSI host device needs to be handled in the UI
Product: Red Hat Enterprise Virtualization Manager Reporter: Tomasz Barański <tbaransk>
Component: ovirt-engineAssignee: Shmuel Melamud <smelamud>
Status: CLOSED ERRATA QA Contact: Nisim Simsolo <nsimsolo>
Severity: high Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: ahadas, nsimsolo, pelauter
Target Milestone: ovirt-4.4.2Keywords: ZStream
Target Release: 4.4.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.4.2.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-23 16:11:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomasz Barański 2020-02-10 12:14:44 UTC
This is a followup to bug #1718818.


VDSM sends a new piece of data from VDSM: a path to block device for a hostdev SCSI disk. It is be non-null in most cases, but it is not hard to imagine a situation, where it's not. In current implementation this would cause building a Libvirt XML that won't be accepted by libvirt. However, preventing it is not as simple as adding an 'if ( ... != null)'. If the path to block device is not there (i.e. is null), a device cannot be used with a scsi driver other that scsi_generic. The block device path, assigned by the host OS, is needed for libvirt to use other drivers.

The engine needs to correlate three pieces of information: the device, the path to block device in the host OS, and the chosen driver. This needs to be handled in the UI.

Expected result:

If the VM has:
1. SCSI host device(s) added
2. The block_path in the host_device table (and thus in the HostDevice) is null
3. The custom property scsi_hostdev has a value different than scsi_generic

THEN an error should be shown and the VM should not be able to be run.

Comment 1 Ryan Barry 2020-02-11 01:27:49 UTC
We'll need to check against this either at launch, or add validations when custom properties are set. I'd suggest the former with audit messages so it's visible in the engine

Comment 5 Nisim Simsolo 2020-08-13 07:00:14 UTC
Verified:
ovirt-engine-4.4.2.1-0.15.el8ev
vdsm-4.40.24-1.el8ev.x86_64
libvirt-daemon-6.0.0-25.module+el8.2.1+7154+47ffd890.x86_64
qemu-kvm-4.2.0-29.module+el8.2.1+7297+a825794d.x86_64

Verification scenario:
1. Attach SCSI hostdev to VM.
2. From host CLI shell, logout SCSI connection. 
   Refresh host capabilities from host tab in WebAdmin
3. Try to run VM. 

The next error listed in engine.log:
 Failed to run VM 1_rhel8_virtio_blk_pci due to a failed validation: [Cannot run VM. The path to a host SCSI disk is empty and 'scsi_hostdev' custom property is not 'scsi_generic'.] (User: admin@internal-authz).

The next operation canceled popup message appears in WebAdmin:
Cannot run VM. The path to host SCSI disk is empty and 'scsi_hostdev' custom property is no 'scsi_generic'.

Comment 9 errata-xmlrpc 2020-09-23 16:11:04 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 (Moderate: Red Hat Virtualization security, bug fix, and enhancement update), 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://access.redhat.com/errata/RHSA-2020:3807