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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
