Bull micro partitioning AIX and virtual scsi cause create lus failed 1

[smielvaque]

Hi,

this is my environnement :
server Networker 7.3.2
server storage node 7.3.2 on AIX 5.3.5 with (1,5 To to backup)

The server Netwoker is a Bull PL6450 with XX partition.
This will cause not to have scsi dev in AIX system only virtual scsi driver : lsdev -C | grep scsi =>
vscsi0 Available Virtual SCSI Client Adapter
vscsi1 Available Virtual SCSI Client Adapter
vscsi2 Available Virtual SCSI Client Adapter
vscsi3 Available Virtual SCSI Client Adapter

So the script /usr/lib/methods/startlus don't create Lus device ( it's based on scsi device : mkdev -c port -s scsi -t lus )


This cause inquiry failed because there is not lus in the system

Networker client work successfully.

My question is :
Can i modify the script "startlus" to use virtual scsi device ? (vscsi)
Is there a solution other than re-partionning without virtual scsi ?


Thanks for all response

 

[Chapter11]

I had a related problem with versions of Networker prior to 7.3.2 - I'm still at 7.2.2 with migration to 7.3.2 later this year.

My new Networker server was a micropartitioned AIX LPAR on a P5, that was purely fiber SCSI, with virtual SCSIs providing my rootvg, so absolutely no traditional "real" SCSI devices.

My system exhibited pretty much the same problem: LUS wouldn't start, and so I could not run inquire or jbconfig to add my fiber-scsi library. I was told that this was resolved in 7.3.2 but if you're seeing it in that version, you just blew my hopes out of the water.

As a workaround, I had to move the robot control of my library to another system that had a physical SCSI card so LUS and inquire/jbconfig would scan the SCSI busses. The SCSI card in that machine isn't attached to anything, it's just there to give LUS a starting point - once it has a physical SCSI adapter, it sees the rest of my vscsi and fscsi hardware just fine.

This has the downside that for my library, I have to configure the remote server as a storage node, but that was going to be the case for me anyway, so I didn't have to buy a useless license.

 

[smielvaque]

Thanks Chapter11,

did you try or Could you try to edit the file /usr/lib/methods/startlus and change the line :
mkdev -c port -s scsi -t lus to
=> mkdev -c port -s vscsi -t lus
?
and simply execute /usr/lib/methods/startlus it will perhaps launch lus driver!

I can't do this at this time because my server is already in critical way.
Have you call Legato for this ?
Thanks

 

[Chapter11]

I think I tried that when I first encountered the problem a long, long time ago.

Since it'll do no harm to my current server:

grumpy:/usr/lib/methods# mkdev -c port -s vscsi -t lus
mkdev: 0514-520 Cannot find information in the predefined device
        configuration database for the following:
        type = 'lus' AND subclass = 'vscsi' AND class = 'port'

Giving it the correct "scsi" subclass, I get an error about not enough information to uniquely identify the device.

I am certainly not qualified to start hacking the ODM, so I'll leave it at that.

 

[smielvaque]

thanks for trying this !

I'm trying to found a solution with Legato support. If I find I will tell you

Bye