Re: [Xen-users] NPIV + Multipath

["Dr. Greg Wettstein" <greg@xxxxxxxxxxxxxxxxx>]

On Sep 22,  2:24pm, Nick Couchman wrote:
} Subject: Re: [Xen-users] NPIV + Multipath

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.

> ----- Original Message -----
> > From: "Etzion Bar-Noy" <etzion@xxxxxxxxxxxx>
> > To: "Nick Couchman" <nick.couchman@xxxxxxxxx>
> > Cc: eneal@xxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx
> > Sent: Monday, September 22, 2014 1:21:09 PM
> > Subject: Re: [Xen-users] NPIV + Multipath
> > 
> > Just a note - multipath does not use SCSI ID, but uses Word 83. I
> > hope it helps you with your search.
> > 
> > Etzion

> The multipath configuration I have by default uses the following
> binary as the "getuid_callout" for determining paths:
> /lib/udev/scsi_id
>
> Based on the name of that binary, I was guessing it uses scsi_id.
> In any case, I'm open to suggestions on what to replace the
> "getuid_callout" setting with that would work inside a Xen domU.  If
> there's something else that is able to reliably determine multiple
> paths to a disk other than the above scsi_id (whatever it uses), I
> would be interested to know.  I thought about using dd to input the X
> bytes of the disk, then run that through some sort checksum (shasum or
> something like that), but I'm not familiar enough to know if that
> would actually be reliable.

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.

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.

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.

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.

I've been meaning to incorporate 'layered block device' support in
Xen-SAN but haven't had the cycles to spend on a package upgrade since
I've been dealing with another higher priority project.

> Thanks,
> Nick

I hope the above information is helpful.

Have a good week.

}-- End of excerpt from Nick Couchman

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"According to the philosopher Ly Tin Wheedle, chaos is found in greatest
 abundance wherever order is being sought.  It always defeats order,
 because it is better organized."
                                -- Terry Pratchett
                                   Interesting Times

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