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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list