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.
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
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'.
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