MPxIO with VxVM is only supported with Sun storage. If you run into problems
with MPxIO and SF on XP24K then support will not be able to help you. I would
recommend using DMP with XP24K.
Ashish
--
Sent using BlackBerry
- Original Message -
From: veritas-vx-boun...@mailman.eng.auburn.edu
veritas-vx-boun...@mailman.eng.auburn.edu
To: Sebastien DAUBIGNE sebastien.daubi...@atosorigin.com;
undisclosed-recipients undisclosed-recipients:;@mailman.eng.auburn.edu
Cc: Veritas-vx@mailman.eng.auburn.edu Veritas-vx@mailman.eng.auburn.edu
Sent: Wed Oct 06 10:08:08 2010
Subject: Re: [Veritas-vx] Solaris-SFS / MPxIO / VxVM failover issue
Hi Sebastien,
In the first mail you mentioned that you are using mpxio to control the XP24K
array. Why are you using mpxio here?
Thanks,
Venkata Sreenivasarao Nagineni,
Symantec
-Original Message-
From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-
boun...@mailman.eng.auburn.edu] On Behalf Of Sebastien DAUBIGNE
Sent: Wednesday, October 06, 2010 9:32 AM
To: undisclosed-recipients
Cc: Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Solaris-SFS / MPxIO / VxVM failover issue
Hi,
I come back with my dmp_fast_recovery issue (VxDMP fails the path
before
MPxIO gets a chance to failover on alternate path).
As stated previously, I am running 5.0GA, and this tunable is not
supported in this release. However I still don't know if VxVM 5.0GA
silently bypasses the MPxIO stack for error recovery.
Now I try to determine if upgrading to MP3 will resolve this issue
(which rarely occured).
Could anyone (maybe Joshua ?) explain if the behaviour of 5.0GA without
tunable is functionally identical to dmp_fast_recovery=0 or
dmp_fast_recovery=1 ? Maybe the mechanism has been implemented in 5.0
without the option to disable it (this could explain my issue) ?
Joshua, you mentioned another tuneable for 5.0 but looking at the list
I
can't identify the corresponding tunable :
vxdmpadm gettune all
Tunable Current Value Default Value
--- -
dmp_failed_io_threshold 5760057600
dmp_retry_count 55
dmp_pathswitch_blks_shift11 11
dmp_queue_depth 32 32
dmp_cache_open on on
dmp_daemon_count 10 10
dmp_scsi_timeout 30 30
dmp_delayq_interval 15 15
dmp_path_age 0 300
dmp_stat_interval 11
dmp_health_time 0 60
dmp_probe_idle_lun on on
dmp_log_level 41
Cheers.
Le 16/09/2010 16:50, Joshua Fielden a écrit :
dmp_fast_recovery is a mechanism by which we bypass the sd/scsi stack
and send path inquiry/status CDBs directly from the HBA in order to
bypass long SCSI queues and recover paths faster. With a TPD (third-
party driver) such as MPxIO, bypassing the stack means we bypass the
TPD completely, and interactions such as this can happen. The vxesd
(event-source daemon) is another 5.0/MP2 backport addition that's moot
in the presence of a TPD.
From your modinfo, you're not actually running MP3. This technote
(http://seer.entsupport.symantec.com/docs/327057.htm) isn't exactly
your scenario, but looking for partially-installed pkgs is a good start
to getting your server correctly installed, then the tuneable should
work -- very early 5.0 versions had a differently-named tuneable I
can't find in my mail archive ATM.
Cheers,
Jf
-Original Message-
From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-
boun...@mailman.eng.auburn.edu] On Behalf Of Sebastien DAUBIGNE
Sent: Thursday, September 16, 2010 7:41 AM
To: Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Solaris-SFS / MPxIO / VxVM failover issue
Thank you Victor and William, it seems to be a very good lead.
Unfortunately, this tunable seems not to be supported in the VxVM
version installed on my system :
vxdmpadm gettune dmp_fast_recovery
VxVM vxdmpadm ERROR V-5-1-12015 Incorrect tunable
vxdmpadm gettune [tunable name]
Note - Tunable name can be dmp_failed_io_threshold, dmp_retry_count,
dmp_pathswitch_blks_shift, dmp_queue_depth, dmp_cache_open,
dmp_daemon_count, dmp_scsi_timeout, dmp_delayq_interval,
dmp_path_age,
or dmp_stat_interval
Something odd because my version is 5.0 MP3 Solaris SPARC, and
according
to http://seer.entsupport.symantec.com/docs/316981.htm this tunable
should be available.
modinfo | grep -i vx
38 7846a000 3800e 288 1 vxdmp (VxVM
