VMware vCenter Site Recovery Manager service stops unexpectedly

[CRHP]

I've been building a Disaster Recovery Solution around VMware vSphere 5 and SRM 5. I'm using FalconStor IPStore NSS version 6.15 to provide array based replication between my two sites. I've been able to failover a set of virtual machines but I cannot get the "reprotect" process to complete successfully.

It completes the "Configure Storage to Reverse Direction" but gets no further. Having generated a log bundle I found the following in a file called VMware-dr-65:

Panic: Assert Failed: "ok" @ d:/build/ob/bora-633117/srm/src/replication/providers/storageProvider/reprotectGroup.cpp:1000

I have a feeling this might be an issue with the SRA provided by FalconStor but I've not had a response from their support team yet.

[vSitta]

We got same problem with SRM installed on same vCenter Server & SQL Server 2005 SP4 on a remote Microsoft Cluster Server Instance.

On the DR site the SRM 5.0.1 installed on DR vcenter server with SQL2008 R2 local instance works perfectly!!!

anyone got help

already tested odbc connection 32 bit with SQL Native Client 32bit (@SP4). User account for sql is SQL autentication & SYSADMIN dbo owner ecc... Setup works perfectlry and create the DB in SQL... but then SRM 5.0.1 starts and after a copiple of minute stops working!!!

HEEELPPPP

____

2012-09-07T15:15:18.681+02:00 [08036 verbose 'Storage'] XML validation succeeded
2012-09-07T15:15:18.681+02:00 [08036 info 'Storage'] Loaded an SRA from 'C:/Program Files (x86)/VMware/VMware vCenter Site Recovery Manager/storage/sra/ONTAP': c3554d24-7713-4086-88c8-39f20443c8c5
2012-09-07T15:15:18.697+02:00 [08036 info 'Locale'] Added locale path storage/locale/c3554d24-7713-4086-88c8-39f20443c8c5/ to locale map
2012-09-07T15:15:18.697+02:00 [08036 info 'Storage'] Update SRA from 'C:/Program Files (x86)/VMware/VMware vCenter Site Recovery Manager/storage/sra/ONTAP': c3554d24-7713-4086-88c8-39f20443c8c5
2012-09-07T15:15:18.760+02:00 [08036 verbose 'PropertyProvider'] RecordOp ASSIGN: reloadFault, storage-adapter-5002
2012-09-07T15:15:18.760+02:00 [08036 verbose 'PropertyProvider'] RecordOp ASSIGN: reloadTask, storage-adapter-5002
2012-09-07T15:15:18.760+02:00 [07192 verbose 'PropertyProvider'] RecordOp ASSIGN: reloadAdaptersTask, DrStorageManager
2012-09-07T15:15:18.760+02:00 [07192 verbose 'PropertyProvider'] RecordOp ASSIGN: info.progress, dr.storage.StorageManager.reloadAdapters0
2012-09-07T15:15:18.760+02:00 [07192 verbose 'Storage'] Polling storage started.
2012-09-07T15:15:18.760+02:00 [07192 verbose 'DrTask'] Task 'dr.storage.StorageManager.reloadAdapters0' completed (no result)
2012-09-07T15:15:18.760+02:00 [07192 info 'DrTask'] Work for task 'dr.storage.StorageManager.reloadAdapters0' completed - new state 'success'
2012-09-07T15:15:18.760+02:00 [07192 verbose 'PropertyProvider'] RecordOp ASSIGN: info.state, dr.storage.StorageManager.reloadAdapters0
2012-09-07T15:15:18.760+02:00 [07192 verbose 'PropertyProvider'] RecordOp ASSIGN: info.completeTime, dr.storage.StorageManager.reloadAdapters0
2012-09-07T15:15:18.760+02:00 [07192 info 'TopologyConfig'] Using drTaskCleanupTime '60'
2012-09-07T15:15:59.885+02:00 [06616 error 'authorize'] [Auth] Failed to initialize: <vmodl.fault.SystemError>
2012-09-07T15:15:59.885+02:00 [06616 error 'authorize'] Failed to initialize security
2012-09-07T15:15:59.900+02:00 [06616 info 'Default'] CoreDump: Writing minidump
2012-09-07T15:16:00.104+02:00 [06616 panic 'Default']
-->
--> Panic: Assert Failed: "rc" @ d:/build/ob/bora-633117/srm/src/authorization/authorize.cpp:135
--> Backtrace:
--> backtrace[00] rip 00f9a9ed (no symbol)
--> backtrace[01] rip 00eeaa84 (no symbol)
--> backtrace[02] rip 00eeaff7 (no symbol)
--> backtrace[03] rip 00fb6429 (no symbol)
--> backtrace[04] rip 00fb64dd (no symbol)
--> backtrace[05] rip 00ead7b4 (no symbol)
--> backtrace[06] rip 0505f9b6 (no symbol)
--> backtrace[07] rip 004535ad (no symbol)
--> backtrace[08] rip 05422db0 (no symbol)
--> backtrace[09] rip 05423d0c (no symbol)
--> backtrace[10] rip 73a834c7 (no symbol)
--> backtrace[11] rip 76553677 (no symbol)
--> backtrace[12] rip 77469f42 (no symbol)
--> backtrace[13] rip 77469f15 (no symbol)
-->

____

[vSitta]

Perhaps we have found a solution.

After several log analysis not only of the vCenter SRM, but also the vCenter Server (vpxd. .. log) in windows server with SQL Profiles and track the operations performed by the SRM, we have seen that when SRM starts, it executes a query looking all users with administrative rights on the vCenter server. If even one of them has a problem - typical a duplicated object n the db or something similar (this is proved by the fact that if you try to change the permissions for that user from vCenter server, you get an error), the SRM stops immediately.

So try to identify all the administrative logins permission in vcenter server and check if they work perfectly.

We solved the problem.

Bye

Davide Sitta

Sinergy Spa

www.sinergy.it