2015-12-09 08:34 AM - edited 2015-12-18 01:01 AM
I wonder if anyone could point me in the right direction.
NetApp Release 8.1.4P1 7-Mode
Our environment consists of multiple SQL servers with datastores stored on VMDKs (mixture of NFS and FC). VSC is installed and along with SnapDrive and SnapManager for SQL we reqularly clone database snapshots from one SQL server to another, with good results.
We have a second environment which uses the same NetApp system but prestents to a separate vCenter with its own VSC install. The servers are in the same active directory. This environment is behind a firewall. We seem to be unable to mount a clone from a server within here to a server in the first environment. We have opened all of the ports we think are required between the source and destination servers. The clone fails with ....
Snapshot mount failed.
Remote clone operation failed: Error code: 0x80004005, Error Code: 0x80004005 Object reference not set to an instance of an object.
We suspect this is a firewall issue?
Questions that I am trying to find answers to are what in the flow of traffic in a clone mount operation to a remote server. Is all the communication SQL server to SQL server or does the server communicate with the VSC of the destination server? or even the vCenter server?
2015-12-14 02:19 AM
I remember a similiar case being closed by "Adding the destination snapdrive's user account to source's local admin group". Sounds like a clue? Any observations around this point?
2015-12-14 03:16 PM
Thanks for responding and thinking about this. I have checked and we are using the same account for both Snapdrives which is in both local admin groups. I was wondering if it was at least possible i.e. one A VM in one VCentre to a VM in another VCentre. I have taken the support ticket route and logged a case with Netapp. They state that it is possible but I'm still waiting on a response to my last email requesting that, yes, help from a product specialist would be most welcome. I'll update this post if I find a solution.
2015-12-22 12:25 AM - edited 2015-12-22 12:29 AM
Cloning a database from a local or archived backup is possible, if ports are open, however the pre-requisites are quite complex and we are planning to fully document those in the Admin guide of the next release of SMSQL. (for ports usage, please check for example https://kb.netapp.com/support/index?page=content&id=3011242 , https://library.netapp.com/ecmdocs/ECMP1400523/html/GUID-115A0CD6-4C90-4D32-8395-D4D1EEE573D9.html , https://kb.netapp.com/support/index?page=content&id=3012060&locale=en_US and https://kb.netapp.com/support/index?page=content&id=3012698&locale=en_US&access=s )
here is a draft of what the Prerequisites for VMDK verification or cloning on SnapMirror destination volumes are, but please note that those steps are not fully tested and you should treat them as guideline and test them yourself before relying on them:
You can verify backup sets on SnapMirror destination volumes and you can clone databases from
SnapMirror destination volumes. If the databases that you want to verify or clone are hosted on
VMDKs, you must meet several prerequisites before you can perform either of those operations.
You can verify and clone from destination volumes when the database hosted on the VMDKs is
replicated to a site by SnapMirror and the configuration meets the following requirements:
repository folder where the backup metadata file resides.
and modify permissions at the share on the secondary site.
destination volume and the name of the destination datastore must be specified in the change list
values must be defined in HKEY_LOCAL_MACHINE\SOFTWARE\Network Appliance
\SnapManager for SQL Server\Server:
destination SMVI server name
\\source SMVI server name\SMVI repository share name\backups.xml
\\destination SMVI server name\SMVI repository share name
change list file name
Requirements for the change list file
The change list file is a text file that contains information about source and destination volumes. The
contents of the file must be in the following format with fields separated by a space and each
datastore beginning on a new line:
DatastoreType SourceDatastoreName DestinationDatastoreName
SourceStorageName DestinationStorageName SourceVolumeName
DestinationVolumeName [SourceDatastoreUUID DestinationDatastoreUUID]
In this format, Datastore Type is either NFS or VMFS and Datastore UUID is not required for
an NFS volume.
Note: For NFS datastores residing on clustered Data ONTAP, SourceStorageName and
DestinationStorageName must be the IP addresses of the source and destination NFS data
The following example shows the contents of a change list file:
NFS ds-nfs1 ds-nfs1-dest snapmgr-05-vm2 snapmgr-54-vm1 4211945a-124a-b7c9-
ae63-cacc07f3f4f8 420f010b-7e5a-e66e-7ed1-7bef6a357cca snapmgr-05-vm1
snapmgr-54-vm1 172.17.233.24 172.17.232.74 snapmgr05_vmw1
Finding the UUID for VMFS datastore
To find the UUID for VMFS datastore, follow the steps below:
datastore on the secondary ESX server.
Note: When you add the storage from the destination, select the option “Resignature the
that you noted in the changelist file.