Here is our setup, all on vmdk's:
C: has the OS, SQL install and system DB's
E: has the Database files
L: and S: are on the same volume and has the Log files and SnapInfo files respectively.
The C: was being snapped by SMVI with the other drives removed from the job. The other drives were snapped by SMSQL. Our over simplified intent was to have the staff at the remote site simply be able to break the mirror, repoint the drive mappings in vCenter and fire up the VM. Most of our expertise is at the main data center and should a disaster occur while we are in the office, we wanted it to be a simple as possible for those in our DR site.
We will need to rework our vCenter implementation as it's database is on one of the SQL servers we are trying to recover. If we can't bring vCenter up in the DR site, we can't have SMSQL restore from the snapshot...or am I incorrect that it is a dependancy? That begs another question though, if we go to a SQL Express on the vCenter server, will that be snapped consistently so we can mirror that VM to the DR site?
In reading through the article you referenced, it seems that our simplified process is unattainable due to the cross over between the two SnapManager products. Maybe a feature request could come from this forum post to have a version of SMVI that is SMSQL aware to acheive the higher level / simplification of DR recovery.
Thanks for your help welch!