Wasnt there something in the MediaMgr_DeviceConfig_Guilde in /usr/openv/volmgr about a system low on resaources may occasionally unload the st and sg drivers?
If unix i think you can put forceload: drv/st and forceload: drv/sg into /etc/system on separate lines. Just a thought Sebastian Schoenwetter wrote: > Tell us something about your SAN ... > > Are you in a fabric environment, or a loop environment ? Are the > drives fabric enabled drives in Point-to-point mode or are they Public > loops attached to your fabric (if you have one) ? > > If you are in loop mode, a LIP (loop initialization) or target reset > might cause your drives to get a new ALPA (= address on the loop) > effectively preventing your host from talking to the drive. > > Do you use persistent binding ? > > Bye > seb > > Quoting "Wilkinson, Alex" <[EMAIL PROTECTED]>: > > >> Hi all, >> >> We are consistently having to reboot our servers (both windows and >> unix) to get >> our LTO3 SSO drives back (after they mysteriously disappear). >> >> Scenario: >> >> For one reason or another we loose a drive and to get it back for example we >> powercycle our library and our NB master can now see the drive(s), >> however, our >> SAN Media servers cannot see the drives unless we reboot them. This >> is *bad* - >> _really_ bad. These are production servers and cannot be rebooted on a whim. >> >> So the question: >> =-=-=-=-=-=-=-= >> >> Can anyone recommend how to get SAN Media Servers to see their SSO >> drives again >> *without* having to reboot ? >> >> We are running NB-6.0-MP3 both Solaris and Windows 2003 Masters. >> >> Regards >> >> -aW >> >> _______________________________________________ >> Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu >> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu >> >> >> >> > > > > _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu