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?
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:
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?)
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.
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.. 😞
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.
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.
okay, I was finally able to confirm system behavior.
Source system: two physical Windows 2008r2 Datacenter servers in a failover cluster, SQL Server 2008r2 Enterprise Ed.
Created two SQL databases, one on a ISCSI LUN, one on a FC LUN, both "shared" for clustering. Each DB consisted of two files (MDF and LDF): iSCSI -- W:\SQLData\clone_test_iscsi.MDF, W:\SQLDATA\clone_test_iscsi.LDF FC -- Y:\SQLData\clone_test_FC.MDF, Y:\SQLData\clone_test_FC.MDF
Destination: Virtual machine (VSphere 5.1ud3) "VSql", Windows 2008r2, SQL Server 2008r2 EE. Created VMware datastore (ISCSI-based) and assigned to 4 VSphere 5.1 hosts in a VMware cluster. Added a VMDK on this datastore to the destination VM as drive Z: and created a folder \SMSqlMtPt for use as the mount point.
Cloned the Clone_Test_ISCSI DB to \\VSQL
Attempted to Migrate \\VSQL after the clone, and could successfully migrate to any other host in the cluster.
Deleted the clone_test_ISCSI DB from \\VSQL
Clone the Clone_Test_FC DB to \\VSQL
Attempted to migrate \\VSQL after the clone. Validation failed with the error: "Virtual disk 'Hard disk 2' is a mapped direct-access LUN that is not accessible..."
Even if the FC initiators for the other hosts in the destination VM cluster are added to the cloned LUN manually, it is still not possible to use VMotion to move the machine to another host.
Thus, it appears the ability to migrate a VM hosting a cloned DB from a non-VM SQL server is indeed dependent on the host database storage being ISCSI-protocol. The clone process for ISCSI-based storage does not create RDMs, whereas a DB hosted on FC storage does create RDMs.
The location of the mount point on the destination VM does not seem to make a difference. I acheived the same results with mount points on both FC- and iSCSI-protocol datastore LUNs on the destination VM.
The good news is that we do at least have confirmation that it is possible to migrate a VM hosting a SnapManager cloned SQL DB from a physical server; however, the source server's storage must be iSCSI based to accomplish this. Since our DB storage is all FC, we have some work to do, but it's less work than trying to come up with another method of quickly replicating our production DB server.
this has nothing to do with the test you described. you won't be able to migrate that VM regardless of whether that SQL clone exists or not, as long as you have iscsi RDM lun on that vmware guest.
If the only iscsi rdm lun is the one created per effect of the clone, then you are not applying my workaround correctly. I specifically asked you to use the guest iscsi initiator from Microsoft and not the one from the esx server (which will create an iscsi RDM lun). In case you are creating the clone with guest iscsi, then the vmware kb above should be applied.
I'm trying to use a FC-based SQL instance as a clone source. You keep referring me to the MS ISCSI initiator.
Your quote: "this has nothing to do with the test you described. you won't be able to migrate that VM regardless of whether that SQL clone exists or not, as long as you have iscsi RDM lun on that vmware guest." -- please understand, the RDM LUN is being created by the SMSQL clone process, when the source SQL DB is hosted on FC storage. There is no RDM of any kind on the destination VM until the clone process completes. The VM can be migrated via vMotion with impunity until the cloned DB is created from a FC host.
If the host storage for the SQL DB is iSCSI, a RDM is not created on the clone destination VM; SnapDrive connects the DB snapshot via the MS iSCSI initiator.
In the SMSQL Clone Wizard, there is no way that I know of to tell SnapDrive to use any particular set of initiators to connect the cloned instance on the destination device. Nor does it appear to be possible to specify this as parameters within a CL request via PS.
The VMware KB you referenced is telling me something that I already know. The problem is with the creation of the SnapDrive cloned LUNs on the destination VM. When the source LUNs are hosted on iSCSI storage, there are no RDMs created, hence, there is no issue. When the source LUNs are FC, SMSQL creates the RDM, which can't then invoke VMotion because of that known issue you referred me to.
I have opened a NetApp case regarding this issue, which has been closed, so please feel free to refer to this. Case# 2005587856
I have come to the conclusion that this can be resolved by moving my SQL host storage to iSCSI from FC. I'd prefer not to do this, but I can't afford to lose the SMSQL clone capabilities, and I need to move the destination SQL server to a VM while maintaining something resembling HA.
You say you were able to successfully implement my "test 2" -- please confirm:
your source system's SQL storage was on FC in a physical cluster,
you used SMSQL to clone the SQL DB to a VM, and
you were then able to use VMotion to relocate said VM to another host?
If this is indeed the case, please reply with more specifics regarding your setup so I can learn what I'm doing wrong here. Because the other support tech at NA that I worked with on this case was not able to do this.
I'm not trying to spread misinformation regarding SMSQL's capabilities. I'm only trying to get this process to work in my situation.