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