David, there is a bug 976387 where Paolo asked for tainting such domains. Maybe for iscsi it is just fine and domain should not be tainted. All in all, the log message is pretty harmless.

(In reply to Jaroslav Suchanek from comment #2)
> David, there is a bug 976387 where Paolo asked for tainting such domains.
> Maybe for iscsi it is just fine and domain should not be tainted. All in
> all, the log message is pretty harmless.

Right; I agree on tainting on host-cdrom, my only note is that the taint on iSCSI is probably unintended.

Hmm, true and we already don't send the message on any 'file' cdrom path. The current check is only limiting on is the device a block device as would anything libvirt is presenting as a block device. In this case, iSCSI, but I would assume LVM and Disk partitions could conceivably fall into this category.  

All we check is:

   if (disk->device == VIR_DOMAIN_DISK_DEVICE_CDROM &&
        virStorageSourceGetActualType(disk->src) == VIR_STORAGE_TYPE_BLOCK &&
        disk->src->path)

I can add a check if the path is a "known" /dev/cdrom or /dev/sr0 (or anything that resolves to those) type check. But beyond that it gets a bit more complex than is probably worth it.

Anyway, posted the patch:

https://www.redhat.com/archives/libvir-list/2017-September/msg00103.html

It's really a simplistic check.  Maybe someone will suggest something fancier.

After review, posted a v2 which handles things slightly differently, see:

https://www.redhat.com/archives/libvir-list/2017-September/msg00234.html

the patches there do work through the slight more complex logic, but there's also an option to just keep a much more simplistic check which essentially assumes that anyone not providing something that starts with "/dev/cdrom" or "/dev/sr" would then be providing a non physical device.  For extra credit, patches 2 and 3 will check the input path against the list of known cdrom devices on the host as determined by node device processing (just in case some other device by "/dev/XXN" path is used!

Pushed the "basic" patch for dealing with this. Although the extra credit patches were posted, there's no need to push them.

commit 4f95d52abac049186f924fb11266403e53364aa0
Author: John Ferlan <jferlan>
Date:   Mon Sep 11 08:35:05 2017 -0400

    qemu: Be more selective when determining cdrom for taint messaging
    
...
    
    Commit id '99a2d6af2' was a bit too aggressive with determining whether
    the provided path was a "physical" cd-rom in order to generate a taint
    message due to the possibility of some guest and host trying to control
    the tray. For cd-rom guest devices backed to some VIR_STORAGE_TYPE_FILE
    storage, this wouldn't be a problem and as such it shouldn't be a problem
    for guest devices using some sort of block device on the host such as
    iSCSI, LVM, or a Disk pool would present.
    
    So before issuing a taint message, let's check if the provided path of
    the VIR_STORAGE_TYPE_BLOCK backed device is a "known" physical cdrom name
    by comparing the beginning of the path w/ "/dev/cdrom" and "/dev/sr".
    Also since it's possible the provided path could resolve to some /dev/srN
    device, let's get that path as well and perform the same check.
    
    Signed-off-by: John Ferlan <jferlan>

$ git describe 4f95d52abac049186f924fb11266403e53364aa0
v3.7.0-139-g4f95d52ab
$

I am not quite sure what happened, but I noticed that the patch was missing from master... After checking various scrollbacks in my terminal screens, it seems even though I thought I had typed git push,  I hadn't so the commit id above was from my local branch.  Anyway, I just pushed for real this time...

Commit id ed2a741e483f65f2690e1c8aa340cd0c314ba34b

$ git describe ed2a741e483f65f2690e1c8aa340cd0c314ba34b
v3.7.0-153-ged2a741e4
$

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://access.redhat.com/errata/RHEA-2018:0704