Re: virtio scsi host draft specification, v3

[Paolo Bonzini <pbonzini@redhat.com>]

On 06/14/2011 10:39 AM, Hannes Reinecke wrote:
> If, however, we decide to expose some details about the backend, we
> could be using the values from the backend directly.
> EG we could be forwarding the SCSI target port identifier here
> (if backed by real hardware) or creating our own SAS-type
> identifier when backed by qemu block. Then we could just query
> the backend via a new command on the controlq
> (eg 'list target ports') and wouldn't have to worry about any protocol
> specific details here.

Besides the controlq command, which I can certainly add, this is 
actually quite similar to what I had in mind (though my plan likely 
would not have worked because I was expecting hierarchical LUNs used 
uniformly).  So, "list target ports" would return a set of LUN values to 
which you can send REPORT LUNS, or something like that?  I suppose that 
if you're using real hardware as the backing storage the in-kernel 
target can provide that.

For the QEMU backend I'd keep hierarchical LUNs, though of course one 
could add a FC or SAS bus to QEMU, each implementing its own identifier 
scheme.

If I understand it correctly, it should remain possible to use a single 
host for both pass-through and emulated targets.

Would you draft the command structure, so I can incorporate it into the 
spec?

> Of course, when doing so we would be lose the ability to freely remap
> LUNs. But then remapping LUNs doesn't gain you much imho.
> Plus you could always use qemu block backend here if you want
> to hide the details.

And you could always use the QEMU block backend with scsi-generic if you 
want to remap LUNs, instead of true passthrough via the kernel target.

Paolo