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


\
 
 \ /
  Last update: 2011-07-01 08:43    [from the cache]
©2003-2011 Jasper Spaans