Re: virtio scsi host draft specification, v3

[Paolo Bonzini]

On 06/29/2011 11:39 AM, Stefan Hajnoczi wrote:
> > >  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.
>
> IIUC the in-kernel target always does remapping.  It passes through
> individual LUNs rather than entire targets and you pick LU Numbers to
> map to the backing storage (which may or may not be a SCSI
> pass-through device).  Nicholas Bellinger can confirm whether this is
> correct.

But then I don't understand.  If you pick LU numbers both with the 
in-kernel target and with QEMU, you do not need to use e.g. WWPNs with 
fiber channel, because we are not passing through the details of the 
transport protocol (one day we might have virtio-fc, but more likely 
not).  So the LUNs you use might as well be represented by hierarchical 
LUNs.

Using NPIV with KVM would be done by mapping the same virtual N_Port ID 
in the host(s) to the same LU number in the guest.  You might already do 
this now with virtio-blk, in fact.

Put in another way: the virtio-scsi device is itself a SCSI target, so 
yes, there is a single target port identifier in virtio-scsi.  But this 
SCSI target just passes requests down to multiple real targets, and so 
will let you do ALUA and all that.

Of course if I am dead wrong please correct me.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/