[SunHELP] Veritas VM help connecting to an ESS? - update

[Tim Bingham]

A while back, before going on vacation, I'd posted an email asking 
about some problems with Veritas Volume Manager connecting to an IBM 
ESS. Since it's been a while, and the issue is still a problem, I'll 
summarize the ongoing problem so far.

I have Veritas Volume Manager 3.5 on a 420R running Solaris 7. I'm 
trying to connect two disks defined on an IBM ESS Shark through an 
Emulex LP8000 HBA. I can see the disks correctly and configure them 
in VM without a problem.

At boot time though, the polling of the disks takes quite a while and 
Veritas VM starts before the second LUN is discovered. VM declares 
the second disk is missing and starts the process of moving data 
around to recreate the mirrors on the lost device. Once the system is 
booted to where I can login, I can issue a "vxdctl enable" and that 
rediscovers the disk and I can add it back into the disk group but 
it's too late.

Richard Markham suggested checking sd.conf to make sure it contained 
the necessary lun entries for lun>0 and keeping all of the extra lpfc 
entries that the lpfc installation put in. Andrew Hay suggested 
putting in a sleep process to delay the VM startup scripts in init.d. 
Emulex support suggested removing any unnecessary lpfc entries in 
sd.conf to shorten polling time. Miguel Demaerel suggested setting up 
persistent binding in lpfc.conf. The Emulex instruction manual also 
suggested using a target number greater than 15 to avoid any possible 
SCSI conflicts.

In short, I've tried all suggestions and nothing changes the outcome.

I set up persistent bindings in lpfc.conf to bind the disks to target 
17, and made sure entries of:

name="sd" parent="lpfc" target=17 lun=0;
name="sd" parent="lpfc" target=17 lun=1;

were in sd.conf.

Still, the second lun is not probed until after VXVM starts up and 
decides the second disk is missing. I tried writing sleep processes 
in init.d to slow down the boot process, but it just slows down 
everything, including polling of the HBA. Everything still happens in 
the same order, just later.

Sun support said there wasn't really a way to slow down the Veritas 
VM boot process and referred me to Emulex to ask what drivers needed 
to be forceloaded. Emulex says lpfc is all that is needed and said 
that there wasn't a way to affect the disk polling speed or order 
from the HBA's point of view.

At this point, I will probably replace the LP8000 HBA with a spare 
LP9002L I have in the hopes that the new hardware speeds something up.

Thanks to all those who have helped so far. Any more suggestions 
would be appreciated.

Regards,
Tim

-- 
ooooooooooooooooooooooooooooooooooo

Tim Bingham
SUNY Upstate Medical University
Syracuse, NY  13210
binghamt at upstate.edu