Specify initiator group for SnapManager SQL clone destination [ Edited ]

[#1]

We are cloning a SQL database from a physical server to a VMware virtual server. 

The clone process creates a RDM on the virtual server, a VMDK with a semi-random name each time it runs.

The problem is that when the RDM is created, it is only assigned the initiators for the VMware host server the VM is assigned to. This makes it impossible to use VMotion to relocate the virtual SQL server if there's a problem with the host. So, high availability is not possible.

Is there a way during the clone process to specify an initiator group for the new cloned LUN? 

Or, is it possible through a Powershell script to, after the clone, modify the cloned LUN so it includes an initiator group or a list of the other initiators in the VMware cluster?

[#2]

I doubt there is a registry key which forces Snapdrive to chose a specific igroup when snap mounting or cloning.

I agree that it would be desireble.

I do know there is a registry key to force SnapDrive use the MS sofware initiators for clones created by SnapManager. I think that will resolve your requirement with vmotion too, as long as you are happy with clones going through the guest MS iSCSI initiator...

in case you want to go for it, here is what you need to do:

the following key needs to be manually created and it allows administrators to pre-select the initiator to be used for snap mounts (during verifications) or clones initiated y SnapManager:

HKLM\System\CurrentControlSet\Services\SWSvc\Parameters\SetOfInitiatorsPerFiler

Here is how you set it up:

1. From within the Guest VM (target for your clones) create the iSCSI sessions to the storage system containing the production lun.
2. Create a registry key HKLM\System\CurrentControlSet\\Services\\SWSvc\\Parameters\\SetOfInitiatorsPerFiler
3. Under this key create a string key with storage system name and then insesrt the MSiSCSI initiator name as its value.

it will look like this:

hope that helps,

Domenico.

[#3]

Hi. The NetApp tech that I worked with also suggested this registry key. And we tested it. But it only seems to work when the source system is also a VM. 

When we try to use this key with the physical SQL instance as source, the clone process only grabs the *last* initiator listed in the key string value. If the key doesn't exist, it uses the initiators of the host that was assigned.

It's also possible that this key is iSCSI-specific (we are FC for SQL storage).

(Also, your image is a broken icon -- I would like to see what the key looks like, though; can you paste it in as text?)

[#4]

Hi,

here is the picture as attachment. Sorry, not sure why picture was not showing with copy paste.

the idea of this key was to (temporarily) avoid or workaround problems existing with RDM (FC or iSCSI) LUN's by forcing SnapDrive in the guest to use Microsoft Software Initiator, just like in the picture.

for the string value, replace storage system name and iqn of guest.

hope that helps,

Domenico

[#5]

So it looks like that registry key allows you to assign one specific initiator.

Problem here is that the VM is in a cluster with four servers, and thus, eight FC initiators. I wasn't able to get the process to recognize anything in that registry key beyond the last one entered in the string.

So, unless there was something wrong in the way the key was populated, it's not helping. And it's hard to find anyone at NetApp who understands the key in the first place..

[#6]

Like I mentioned, the key was designed to force snapdrive in guest to use ms iscsi, if you have troubles understanding that, perhaps you can call support and we explain it to you.
Feel free to ask for me during CEST normal working hours.
Domenico.

[#7]

I understand the concept well, thank you for your offer. The NetApp tech I was working with on this case suggested the registry key as a possible option (even though it wasn't indicated in our specific situation, we thought maybe it would work; no such luck.)

I'll just have to accept that it's apparently not possible to VMotion a VM that's hosting a cloned DB from a physical SQL server. It's disappointing.

[#8]

it's been a while I haven't played around with a physical SQL server, but I can try to set it up and test a clone on a target VM.

If I succeed today, I will let you know by posting a reply here...

Domenico.

[#9]

My SA found this link, which might apply:

http://community.netapp.com/t5/Microsoft-Cloud-and-Virtualization-Discussions/Mirroring-Igroups-Initiators-and-Lun-Mappings/td-p/55514

It's VMware, not MS Cloud, but it looks like there are some PS commands to manage Igroups and initiators?

[#10]

I completed my test:

production SQL server: Physical windows 2008 R2 SP1

target of clone SQL server: Virtual Machine on ESX with windows 2008 R2 SP1

Storage system: a fas 3160 with FC and iscsi with Ontap 8.2.3 7mode

SnapDrive 7.1.1 (on both servers)

SMSQL 7.2 (on both servers)

SQL prod db are FC connected to Storage (no RDM).

Clone server only has RDM and MS iSCSI lun's.

once both windows server (in same AD domain) had dns connection to the storage system and credentials were set from both of the windows servers,

I could succesfully clone a production SQL db into the target server. the clone was mounted on clone server with MSiscsi.

This was achieved even without the registry key, since my esx host which hosts the VM whcih is the target of the clone does not have FC connection to that specific storage server.

This shows you that if you force SDW to use Msiscsi, it will use it.

So unless you are doing something different, this should work and there is no disappointing limitation.

please work with your support engineering to insist on the correct implementation of the reg key and restart your snapdrive service.

hope that helps,

Domenico