Bug 1715608

To start
- The engine configuration to understand how the disks are configured at the engine
- the vm xml to understand what libvirt is getting
- the qemu command line from /var/log/libvirt/qemu/vmname.log

(Originally by Nir Soffer)

Current XML produced by vdsm, uses scsi-generic:

    <hostdev mode='subsystem' type='scsi' managed='no' rawio='yes'>
      <source>
        <adapter name='scsi_host0'/>
        <address bus='0' target='6' unit='0'/>
      </source>
      <alias name='hostdev0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </hostdev>


1) Desired XML for scsi-block (faster/fixed SCSI passthrough):

    <disk type='block' device='lun' rawio='yes'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/sdd'/>
      <alias name='hostdev0'/>
      <target bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>


2) Desired XML for scsi-hd (SCSI, not passthrough): same as above, except 

    <disk type='block' device='lun' rawio='yes'>

becomes

    <disk type='block' device='disk'>



In a hook, to get the new source, you can pick the host source address from

      <source>
        <adapter name='scsi_host0'/>
        <address bus='0' target='6' unit='0'/>
      </source>

combine the host:bus:target:unit into 0:0:6:0, then do:

    $ ls /sys/bus/scsi/devices/0:0:6:0/block
    sdd

I guess a shell script would use something like "(cd /sys/bus/scsi/devices/0:0:6:0/block && echo sd*)".


This can be done through either a hook or RHV-M UI.

More food for thought and for separate BZs:

1) in the UI this could be made configurable among scsi-block (passthrough), scsi-hd (emulated), virtio-blk-pci, since each of them has its place.  Many users are going to use SCSI host devices for passthrough (e.g. persistent reservations), others only need pinning.

2) likewise, when passing through an NVMe PCI device we could offer the choice between PCI passthrough, scsi-hd (emulated SCSI device pinned to the host device), virtio-blk-pci (also pinned to the host device).

(Originally by Paolo Bonzini)

> > - Disks defined as "host devices" should not use scsi-generic at all
>
> Are we sure there's no use case for it? TAPE devices or what not?

Tapes and media changers, yes.

> We do not plan (ATM) to further integrate it into the
> UI - as it's the first time we were asked about it.

Even though it's the first time that you heard about it, I would be surprised if no customer has ever wanted it.  Both AWS and GCE have been offering local SSDs (they are actually transient in their case) for years, and (even though that usecase is closer to OpenStack) I expect that database users will want the same even for "pet" VMs.

> I'm wondering if our default should not be changed, though
> (from scsi-generic to something else). 

I think the default should be scsi-block, yes.

(Originally by Paolo Bonzini)

Seems the GUI configuration for FC is generating a scsi-block configuration, so hopefully no hook needed for scsi-block.
scsi-hd would need a change, but not sure it's worth it, perhaps we just want to hide/remove the scsi-generic hostdev option

(Originally by michal.skrivanek)

> the GUI configuration for FC is generating a scsi-block configuration, so
> hopefully no hook needed for scsi-block.

The FC GUI does not guarantee pinning to the host, does it?

The usecase for storage hostdev should be pinning to the host.  The actual device shown to the guest can be configured on top; even if the default is passthrough for backwards compatibility reasons, it makes sense to allow emulated devices (scsi-hd, virtio-blk) for SCSI direct access or PCI NVMe hostdevs.

(Originally by Paolo Bonzini)

Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

(Originally by Ryan Barry)

This has been open for over a year without a clear use case. Closing. Please re-open if this changes

(Originally by Ryan Barry)

The hook itself works as designed, however it doesn't work together with the rest of the system and as such is not really usable for the intended use case.
Closing the bug, as the hook made it in and will be in 4.3.5. 
A complete solution will need one of: bug 1718852, bug 1718851, bug 1718818

(In reply to Michal Skrivanek from comment #14)
> The hook itself works as designed, however it doesn't work together with the
> rest of the system and as such is not really usable for the intended use
> case.
> Closing the bug, as the hook made it in and will be in 4.3.5. 
> A complete solution will need one of: bug 1718852, bug 1718851, bug 1718818

No need for QE?

no reason to test a (currently) pointless hook. Once we got it working by solving one (or all) those bugs above the testing of this functionality should happen there. Especially since 1718818 means "no hook" thre's not much point in doing a QE right now....