[libvirt] [PATCH v1 17/19] tests: Introduce basic vhost-scsi test
farman at linux.vnet.ibm.com
Tue Aug 9 15:16:45 UTC 2016
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:
>> <hostdev mode='subsystem' type='scsi' sgio='filtered' rawio='yes'>
>> <adapter name='scsi_host0'/>
>> <address bus='0' target='0' unit='0'/>
>> <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>> Could make it be "type='vhost_scsi'" or something else, if that clarifies
> 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
More information about the libvir-list