I recently moved my NSS objects to an iSCSI SAN. The SAN has some built-in
replication, which provides snapshots of the pool/volume objects so I can
back them up to tape on a separate Netware system or perform a manual DR
failover if I ever lose the main data center.
I have been experiencing period pool deactivations (seems random for timing
and which pool). The common error shown during deactivation is:

3-19-2007 4:14:02 am: COMN-3.25-1092 Severity = 4 Locus = 3 Class = 0
NSS-3.00-5001: Pool <server>/<poolname> is being deactivated. An I/O error
(36(zlssMSAP.c[1796])) at block 0(file block 0)(ZID 0) has compromised pool

I have performed pool rebuilds and pool "MSAPrebuild"s and yet the periodic
deactivations continue. I am thinking of turning off MSAP (nss
/noMSAPserver) in order to stop this from happening. Instead, I will
utilize protection built into my SAN to ensure that no other server can see
these LUNs. Other servers will have read-only access to recent snapshots of
these LUNS, but not the actual production copies.

Other info: Server is NW 6.5 SP6, fully patched per Novell support. I have
9 volumes in 9 NSS pools, but SYS is on a local disk, and is therefore
immune to these deactivation events. Server is not part of a cluster. I
have not enabled multipath support or jumbo frames for this system yet, but
I do intend on doing this as soon as the server is stable.

Question1: Am I missing something - is there some other way to stabilize
this server?

Question2: Any ideas why these volumes are deactivating? No other servers
are trying to activate the pool, so why am I getting the MSAP errors?

Question3: What are the implications of disabling MSAP in this scenario.
Other than the obvious where another NW server activates the pool it will
kill it.

Question4: Has anyone else had to disable MSAP for a similar situation? Is
this common for running on an iSCSI SAN?

Thanks very much for your help.

Paul Peterson
Boise Idaho