[libvirt] [PATCH v1 17/19] tests: Introduce basic vhost-scsi test

[Eric Farman]

On 08/09/2016 10:54 AM, Daniel P. Berrange wrote:
> On Tue, Aug 09, 2016 at 10:44:44AM -0400, Eric Farman wrote:
>>
>> On 08/09/2016 08:22 AM, Daniel P. Berrange wrote:
>>>>> +    <hostdev mode='subsystem' type='scsi'>
>>>>> +      <source protocol='vhost' wwpn='naa.5123456789abcde0'/>
>>>>> +    </hostdev>
>>> I'm not sure this syntax really makes sense.
>>>
>>> IIRC, currently <hostdev type="scsi"> is used to passthrough an individual
>>> SCSI LUNs from the host to the guest.
>>>
>>> With vhost-scsi, IIUC, you are passing through an entire (virtual) SCSI HBA
>>> to the guest. So I think it better for us to not reuse type="scsi" for that
>>> purpose. Instead it feels like we should be adding a type="scsi_host" for
>>> passthrough of entire HBAs
>> Would that cause confusion amongst an existing type='scsi' hostdev, since a
>> "scsi_hostX" turns up in the source tag?  Example from the libvirt doc:
>>
>>    <devices>
>>      <hostdev mode='subsystem' type='scsi' sgio='filtered' rawio='yes'>
>>        <source>
>>          <adapter name='scsi_host0'/>
>>          <address bus='0' target='0' unit='0'/>
>>        </source>
>>        <readonly/>
>>        <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>>      </hostdev>
>>    </devices>
>>
>>
>> Could make it be "type='vhost_scsi'" or something else, if that clarifies
>> things.
> No, it should be type=scsi_host, so that in the future if we want to
> pass through entire SCSI or iSCSI HBAs without vhost-scsi, then we
> can do it.

Ok.  I'll keep the "type='vhost'" in the protocol to distinguish that in 
the future, rather than dropping it as an implicit "if hostdev 
type='scsi_host' then it's a SCSI HBA with vhost-scsi"

>
>> (Question from my own ignorance; does an iSCSI target with more than one LUN
>> behind it get rejected if specified here, instead of using a <pool> tag?)
> The IQN name has to include the LUN in it - if that's left out, QEMU would
> complain that no LUN was specified.

Thanks for the clarification.  Haven't played with that configuration yet.

>
>>> Obviously this has major implications for almost all patches in this series
>> Splitting this out as a new hostdev type would mean it's not being
>> shoehorned into the existing SCSI parts.  That would probably make the
>> entire series less unwieldy by dropping the separate protocol that exists
>> herein.
> Regards,
> Daniel