topic SMSQL 5.1 and cloning on SnapMirror destination volumes in ONTAP Discussions

SMSQL 5.1 and cloning on SnapMirror destination volumes

radek_kubka — Thu, 05 Jun 2025 06:53:55 GMT

Hi All,

There is a thread about this within Partner & Field Community (http://communities.netapp.com/message/54863#54863), but due to lack of responses I've decided to give it a bit more visibility here.

Basically I am trying to use SMSQL cloning wizard to clone a SQL 2008 database off SnapMirror destination volumes. This is a fully virtualised environment, utilising:

- vSphere 4.1

- VSC 2.0.1P1 (build 2.0.10246.1006)

- SDW 6.3P2 (build 6.3.0.4813)

- SMSQL 5.1 with SQL 2008 databases on NFS VMDK files.

This is what happens:

There is a check box within cloning wizard: "Clone on available SnapMirror destination volume". I check it, run the wizard, get no errors & can see a nice info in the clone report window: "Clone on available SnapMirror destination volume: Yes"

Yet the actual cloning happens definitely off primary, not target volumes / filer.

Am I missing something or is the check box in question merely an anticipation of a future functionality?

Regards,
Radek

SMSQL 5.1 and cloning on SnapMirror destination volumes

curtish — Fri, 27 May 2011 13:45:58 GMT

Unfortunately, I am doing NFS from ESX to NetApp creating VMDK for my VM, then attaching the database from the VM via iSCSI.

I have not gotten around to setting up VMDK support for the database yet.

Thanks,

Tom

SMSQL 5.1 and cloning on SnapMirror destination volumes

radek_kubka — Fri, 27 May 2011 13:48:37 GMT

OK, fair enough.

I'll experiment with iSCSI LUNs & report back whether it changes anything.

Regards,
Radek

SMSQL 5.1 and cloning on SnapMirror destination volumes

qzhang — Fri, 27 May 2011 14:02:43 GMT

You may want to check SMSQL 5.1 IAG for information on how to clone on SnapMirror destination volume with VMDK configuration.

Thanks, Qing

SMSQL 5.1 and cloning on SnapMirror destination volumes

radek_kubka — Fri, 27 May 2011 16:06:51 GMT

Hi Qing,

Thanks for the reply.

I don't want to be too lazy , but can you reveal whether there is anything unusual re setup for cloning off target VMDKs?

Most of stuff seems to work fine in my environemnt, SDW sees all the NFS VMDKs, backup & verification works, etc.

Regards,
Radek

Re: SMSQL 5.1 and cloning on SnapMirror destination volumes

radek_kubka — Fri, 27 May 2011 16:25:12 GMT

Actually the backup verification also does not happen off the destination volumes - despite ticking the relevant box in the backup wizard.

No error message is displayed, SnapMirror gets updated, job ends successfully, yet clones for verification are taken off the source volumes.

It looks like things haven't changed in this respect since beta:

http://communities.netapp.com/message/37692#37692

(I am attaching backup report)

SMSQL 5.1 and cloning on SnapMirror destination volumes

qzhang — Fri, 27 May 2011 19:32:04 GMT

There are a couple of extra steps that you need to implement in order to clone from SnapMirror destination volume if you are running VMDK/VMFS in SMSQL. Due to limitation of SMVI, a script installed along with SMSQL needs to be run to replicate SMVI metadata to a remote server where another SMVI instance is installed. 5.1 IAG has detailed information on how to implement those extra steps.

Thanks, Qing

Re: SMSQL 5.1 and cloning on SnapMirror destination volumes

radek_kubka — Tue, 31 May 2011 10:33:27 GMT

Thanks again - did my homework this time & eventually got to the right info on page 271 of the SMSQL IAG (http://now.netapp.com/knowledge/docs/SnapManager/relsmsql51/pdfs/install.pdf)

One thing though I have discovered first on page 31 is a tad awkward:

If you are running verification on a SnapMirror destination volume, or cloning a database on SnapMirror destination volume, the remote virtual machine should not reside on the same vCenter as the original SQL Server virtual machine.

But looking into the detailed howto guide I can see why it is the case - 2 instances of SMVI replicating info to each other do require two vCenter instances.

Regards,

Radek