CDI problem 1

[Shuegli]

Hi

We had alway CDI on "SCSI Commands" now we upgrade a Falconstor VTL with RHEL5.1 from 4.0 to 5.1

Since then the couldn't Backup anymor your Red Hat Linux und Solaris but the Windows still worked normal.

The error message was:

Nov 11 09:57:14 bwbckse1zhh logger: NetWorker media: (alert) device "/dev/nst3": serial number mismatch, check system device ordering. Expected "Serial Numbers:WWNN=500630323142AAAA:ATNN=HP Ultrium 3-SCSI 8AU5S0021B:8AU5S0021B", found ":WWNN=4850202020202020:8AU6400238"

Then we disabled CDI on all Drives.

Now the Backup is working again normal and we haven't seen this errors anymore in the Logs.


For what is CDI?

Is there any disadvantage because we disabled CDI?

What are the recommendet settings for CDI: "SCSI Commands" or "Not used"

What are you using?


Thansk for your help


Stephan

 

[605]

CDI is nothing but a kind of hardware interface - how NW controls the backup device. You should use it (leave the default "SCSI Commands" on).

It sounds strange to me that you cannot backup a fileystem just due to the fact that you changed the backup hardware. This would only make sense if you only backup your Linux and Solaris clients to this storage node.

 

[Shuegli]

Hi 605

We use Networker 7.4.4 our Backup Server is a Red Hat 3 Server.

Befor Yesterday the CDI was on all Drives on "SCSI Commands" and it worked normal.
Then we upgrade one of our two Falconstor VTL from RH4 with VTl Software 4.0 to RH5.1 with VTl Software 5.1
Since then we had the problem.
When i mount a Tape in the Networker GUI to a Drive from a Windows Server it worked no problem. Backup is running.
BUT if i mount a Tape to a Drive from a Red Hat Linux or Solaris the i get the Error message you can read on the first post.
When i Disable CDI on a Drive the i can mount a Tape normal without error and run a Backup.
The next Strage thing is since the upgrade if i execute the inquire command on a Server that get the Drive from this VTL i have a new WW2N Number. What is that? See my Post "WWNN number missmatch inquire"

You wroud i should use CDI. But what can be happend if i leave it Disabled?
We dont change the Backup Hardware we just upgrade the Software and we ONLY upgrade the VTL NOT the Backup Server or a Storage Node.
Thanks
Stephan

 

[605]

As i do not have your equipment, i can not verify the problem.

Be aware that NW only uses what the OS or the underlaying structures provides - it does not generate the WWNNs.

Strange enough:
- you updated the VTL software
- you got a problem
- but now you blame NetWorker which was obviously running fine before.

Would you mind thinking about Falconstor causing the trouble and the 'new' version probably being incompatible with your NW version ?

 

[Shuegli]

Hi 605

I didnt blame NW. After the upgrade we had this problem. With CDI chageing to "not used" solved the problem so i would like to know that CDI is. (I know it now Thanks for that)
I opened a Ticket at Falconstor. Maybe the Supported CDI with the old Version but didnt support it with the new one. That would explain allot.

And the inquire missmatch WWNN Number IS a inquire problem.
Example:
My VTL has a HBA with a WWNN number.
SAN Switch (Brocade 5100) see's the SAME WWNN Number.
HBanyware on the Windos Dedicated Storage Node see's the SAME WWNN number.
Inquire see's complet diverent WWNN number and it shows a WW2N Number.
What is that WW2N number? i never hired of a WW2N number in SAN.

Stephan

 

[605]

I googled for the term, WW2N which is also new to me. Maybe it is just another (inofficial) abbreviation for WWNN (due to the two 'N'). But then the numbers should be identical, correct?

Inquire just returns parameters from the device's firmware. Unless a software (driver) on the way to the user interface (mis)translates the output due to whatever reason, i do not know where the difference should come from.

BTW - you will find more information about CDI in the NW Admin Guide.

 

[Shuegli]

Hi 605

The Example with the Windows Server:
C:\Program Files\Support Tools>inquire
scsidev@0.0.0:TEAC DV-28E-N C.6B|CD-ROM
scsidev@2.0.0:COMPAQ SCSI COMMUNICATECISS|Unknown Device Type
scsidev@2.4.0:HP LOGICAL VOLUME 2.84|Disk, \\.\PHYSICALDRIVE0
WWNN=600508B10018443953533730474C0009
scsidev@2.5.0:HP LOGICAL VOLUME 2.84|Disk, \\.\PHYSICALDRIVE1
WWNN=600508B10018443953533730474C000A
scsidev@8.0.0:HP Ultrium 3-SCSI G27D|Tape, \\.\Tape0
S/N: 8AU5S0020K
ATNN=HP Ultrium 3-SCSI 8AU5S0020K
WWNN=50063032304BAAAA
WW2N=50060B000029AAAA
scsidev@8.0.1:HP Ultrium 3-SCSI G27D|Tape, \\.\Tape1
S/N: 8AU5S0020L
ATNN=HP Ultrium 3-SCSI 8AU5S0020L
WWNN=50063032304CAAAA
WW2N=50060B000029AAAA
scsidev@8.0.2:HP Ultrium 3-SCSI G27D|Tape, \\.\Tape2
S/N: 8AU5S0021O
ATNN=HP Ultrium 3-SCSI 8AU5S0021O
WWNN=50063032314FAAAA
WW2N=50060B000029AAAA
scsidev@8.0.3:HP Ultrium 3-SCSI G27D|Tape, \\.\Tape3
S/N: 8AU5S0021P
ATNN=HP Ultrium 3-SCSI 8AU5S0021P
WWNN=500630323150AAAA
WW2N=50060B000029AAAA

You can see WWNN and WW2N are different.
All 4 Drives are present true the SAME HBA from the VTL Server. So all WWNN should be the same.Diverent is only the LUN.
The WWNN number from ALL my Servers is different then the real HBA WWNN number.

Stephan

 

[605]

Thanks for the info. As i said, i do not know what the WW2N stands for. As you mentioned it is always the same. This in fact could point to the FC HBA number.

However, i am not surprised as i expect the WWNN to be different - it is a unique representation. The LUN is just an old ID coming from the SCSI history. As far as i remember, it allows only to address 8 logical subdevices below the SCSI ID.

Although the abbreviation points to a node name it can also represent a device number. And it makes sense, if you look at

http://en.wikipedia.org/wiki/World_Wide_Name

and

http://en.wikipedia.org/wiki/World_Wide_Node_Name.

For example, the WWNNs represent ...
500630 32 30 4B AAAA
2 0 K

500630 32 30 4C AAAA
2 0 L

500630 32 31 4F AAAA
2 1 O

500630 32 31 50 AAAA
2 1 P <---- Compare the substring with the device's SN