Re: generating a Linux WWN?

[Luben Tuikov <ltuikov@yahoo.com>]

--- James Bottomley <James.Bottomley@SteelEye.com> wrote:
> 
> For the record, what the current in-kernel aic94xx driver does for this
> case is allow a parameter override to specify the WWN in the case where
> the card burned in one has gone missing or is corrupt.  I think this is
> the correctly balanced approach to the problem.
> 
> For the record, I pretty much agree completely with Luben's position on
> this:  I want to allow the user a method to correct any problem (i.e.
> supply a WWN override).  However, I also want them to think about the
> issue before they do this.  What I really don't want is the driver
> silently correcting what it thinks to be a defective WWN and generating
> its own replacement because that's a recipe for disaster on a SAN (SANs
> are a lot less robust than networks to duplicate MAC addresses: because
> of the way expander routing is done, you can possibly collapse the
> entire SAN with duplicate WWNs).
> 
> So, the procedure for a SAS card should be:
> 
>      1. Obtain the WWN from a device specific storage method (like
>         flash)
>      2. Replace this with a passed in command line parameter if one
>         exists
>      3. refuse to attach if there's still no valid WWN and give an
>         explicit method saying what the problem is (and possibly how to
>         fix it)

That is absolutely correct.

If a node in a SAN doesn't come up, the SAN admin will inspect
the kernel log and find out that the driver failed to attach
due to a missing WWN.  This is a grave condition.

In enterprise, if one component is compromised, then the whole
system should fail and be brought to admin's attention.

The admin may decide to replace this card with a working one,
or ask the Storage Manager to generate a temporary WWN (which could
be the next machine over), or if the admin themselves maintain
the SAN, they can generate a temporary WWN.

But it is imperative that the admin immediately knows
of the fact that a node in the SAN has experienced a problem
and cannot read its WWN.

Alternatively, if the SAN is zoned, then the _rogue_ node
who autogenerated its WWN will be rejected access to the SAN.
A node which autogenerates WWNs is considered a security
risk and a rogue node.

   Luben