Re: [Xen-users] NPIV + Multipath

[Nick Couchman <nick.couchman@xxxxxxxxx>]

> 
> Hi, I hope the week is going well for everyone.
> 
> We designed and wrote the Xen-SAN package so I thought I would pop in
> with a few quick comments.
> 
> 
> The scsi_id command uses the generic (SG) sub-system to issue an
> INQUIRY command to a SCSI device for mode page 80, 83 or the
> pre-SCSI-spc3 variant of mode page 83.  It uses various pieces of
> information out of the mode page to synthesize a 'serial number' for
> a
> SCSI disk which uniquely defines the disk.  SCSI block devices which
> return idential 'serial numbers' are considered to represent multiple
> paths to a common storage device by the multipath sub-system.
> 
> The XEN blkback driver which is used to export physical block devices
> from a Dom0 instance to DomU guests is a ring buffer/event based
> system which provides nothing more then a flat LBA representation of
> a
> block device.  Since it does not support a protocol such as
> SCSI/SAS/ATA there is no concept of INQUIRY commands and scsi_id will
> not be able to synthesize a serial number.

The makes sense, though it would be nice if something akin to INQUIRY worked so 
that you could do things like multipath, but I understand that the goal of the 
Xen block devices was not to build SCSI-compatible devices.

> 
> You could use something like dd to synthesize your own serial number
> but you will need to find something on the block device/filesystem
> which is invariant.  The obvious candidate would be a filesystem UUID
> so such a solution is going to be filesystem dependent and thus not a
> generic block device multipathing solution.

Filesystem level might be good enough, but seems a little tenuous, and, in at 
least one case (Oracle ASM), that wouldn't work.

> 
> The other alternative is to take a look at the pvSCSI support which I
> see there is now movement on.  Presumably the SCSI pass-through
> support would be done with sufficient fidelity in order to support
> INQUIRY commands which would thus allow scsi_id to be called from
> within a guest to identify degenerate representations of a block
> device.

Hmmm...does pvSCSI support NPIV, or would that be similar to presenting the 
devices to the Host O/S, then just passing them through?  I know NPIV is really 
kind of similar to that, just masks things so that it looks like the VM has the 
devices, but, with my SAN in my environment, I'd really prefer to have the 
separation, even if it is just a semantic thing.  It gives me a little bit 
better visibility into when certain domUs are having problems (get alerts from 
the SAN, etc.), and a little more control over which domUs can see which LUNs.

> 
> Quite frankly the best place to handle all of this is at the Xen-SAN
> level or equivalent block hotplug layer.  In this model DOM0 handles
> the multi-pathing and passes a fault tolerant block device via
> blkback
> to the guest.  Multi-pathing is a notoriously finicky beast and as
> with other SAN modalities such as NPIV/iSCSI is far easier to debug
> from DOM0 then from within a guest.

This would be fine, but, again, it'd be nice to do it in such a way where, like 
NPIV, the WWPN/WWN gets assigned to the VM and not the entire dom0.

Thanks,
Nick

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users