lkml.org 
[lkml]   [2011]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: virtio scsi host draft specification, v3
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


\
 
 \ /
  Last update: 2011-06-29 10:37    [from the cache]
©2003-2011 Jasper Spaans