Run the backup with -D5 added to the backup command and check the sso logs in /nsr/logs/sg/[group name]. This should give you more details on the reason for the unavailability of the SAN transport mode. There's an example in the below article:
I have a similar setup, although I'm running vSphere 5.5u1a and vCenter 5.5. For me, SAN transport mode works fine. What is the actual SAN storage array? Do you use FC, iSCSI?
you mean it crashes in debug mode, but doesn't crash without debug? You may need to open a Service Request with EMC Support in order to have the crash dump analysed. There isn't much we can tell from the above, so we'd need to look at the full stack trace with windbg. Alternatively, you can have a look at it yourself:
mansch79
4 Posts
0
June 25th, 2014 05:00
Thanks Bobby.
I'll try..
coganb
736 Posts
0
June 25th, 2014 05:00
Hi,
Run the backup with -D5 added to the backup command and check the sso logs in /nsr/logs/sg/[group name]. This should give you more details on the reason for the unavailability of the SAN transport mode. There's an example in the below article:
185186 : VADP backup fails indicating the "hotadd:san" transport modes are unavailable
https://support.emc.com/kb/185186
-Bobby
sechm
1 Rookie
•
79 Posts
0
June 25th, 2014 07:00
I have a similar setup, although I'm running vSphere 5.5u1a and vCenter 5.5. For me, SAN transport mode works fine. What is the actual SAN storage array? Do you use FC, iSCSI?
mansch79
4 Posts
0
June 27th, 2014 03:00
We have Fujitsu DX60 and HP p2000 as SAN storage arrays - they both have vmware datastores. All equipment is connected through FC.
mansch79
4 Posts
0
June 27th, 2014 03:00
Bobby,
I tried to start "nsrvadp_save" with -D5 option but after several seconds app crashes:
Problem signature:
Problem Event Name: APPCRASH
Application Name: nsrvadp_save.exe
Application Version: 8.1.1.2
Application Timestamp: 52e2d2b2
Fault Module Name: nsrvadp_save.exe
Fault Module Version: 8.1.1.2
Fault Module Timestamp: 52e2d2b2
Exception Code: c0000005
Exception Offset: 000000000001485b
OS Version: 6.1.7601.2.1.0.272.7
Locale ID: 1033
Additional Information 1: 1c13
Additional Information 2: 1c13b3433d73bfd02f3dd6aef15bb6e9
Additional Information 3: b169
Additional Information 4: b169fb4fb7594d3b44377c1f7ac75537
coganb
736 Posts
0
June 30th, 2014 05:00
Hi,
you mean it crashes in debug mode, but doesn't crash without debug? You may need to open a Service Request with EMC Support in order to have the crash dump analysed. There isn't much we can tell from the above, so we'd need to look at the full stack trace with windbg. Alternatively, you can have a look at it yourself:
windbg
file
open crash dump
!analyze -v
k
-Bobby