I recently installed Snapdrive 6.2 on my windows test VM running in a VMware ESX cluster. I am having a problem finding my existing igroup whenever I create a new disk or connect an existing disk from my NetApp storage. It keeps stating “No Igroups Found” and wants to create a new igroup with my ESX initiator that is hosting my test VM. My existing igroup that was previously defined has every ESX initiator in that group including the ESX server currently hosting my test VM. Why does snap drive not see this?? The only way I can get this to work using my existing igroup is to map the RDM LUN in filer, then within vCenter edit my test VM and add disk as a RDM. Once I boot the VM I add this using windows disk management. Once disk is added, snap drive will see the drive and I am able to manage. I am not sure if this is supposed to be the way. Any thought? TIA!
I have the same problem. It seems that snapdrive 6.2 don't recognize igroups already created (I've tried creating one manually and also with one created by rcu).
I had to make snapdrive create it's own igroup and then I've added the other vmware machines to that igroup to be able to vmotion switch the host where the machine run.
Does anyone know the difference between igroups created manually and igroups created by snapdirve? Also, is it safe to have two igroups with all esx servers in my cluster within both igroups? thanks!
I think SnapDrive follows certain naming convention when creating igroups. You can name the igroups anything you want when you create them manually. But they are essentially the same. As long as you only use one igroup to map a LUN, there shouldn't be any problem to have more than one igroups.
I have exactly the same issue. This has to be a bug. Have you found a resolution? When does one use type Windows for an igroup? I thought if I created an RDM within a Windows VM via snapdrive and needed to map that RDM to an igroup I'd need to create an igroup of type Windows? I know that the RDM is created as type Windows. Should the igroup also be of type Windows or VMware? This presents a dilema. Netapp states you cannot have the same initiators in different igroups of different types (i.e one igroup type Windows and the other type VMWare). I already map luns to ESX for datastores and those luns are mapped to an igroup of type VMware. If Snapdrive creates an RDM and needs an igroup of type Windows how can i use the same initiators when they are already part of another igroup of type VMware? Would I have to use NPIV - generate a new set of WWNN/WWPN for the Windows VM and put those into a different igroup.
I was pointed to this issue last night and to the posts here.
This issue was a Bug with SnapDrive v6.2 which has been fixed with 6.2D3
Hi Nick. Someone recently reported the issue was fixed in 6.2P1:
What's the difference between that version and the one you reported (6.2D3)?
The 6.2P1 version was released in March 12, 2010. It does not fix this specific issue. Among the issues it addresses, is a case where an ESX iSCSI RDM can not be created because an FCP license did not exist on the array. Clearly not the problem described here.
SWD 6.2D3 was Released April 28, 2010 and addressed the following issue:
408511 - Create/Connect LUN operation using ESX iSCSI RDM fails in VMWare Guest OS after VMotion or if the iGroup has first initiator from another ESX host. This is seen only for iGroups having ESX iSCSI initiators.
1. MMC does not see this iGroup during create/connect operations.
2. When used in SDCLI for create/connect operation it fails with below error.
"Error: igroup has initiators from other hosts. SnapDrive does not support this configuration
This is the issue described here
P releases contain multiple fixes for various bugs that have been discovered. These are scheduled releases.
D releases addresse a specific bug. D releases are emergency releases
Thans Nick. I had run into an issue with tryung to create a Windows cluster (virtual machines across ESX hosts). After creating the shared lun (qourum) I tried to "connect" to this lun with the 2nd node. Apart from Snapdrive not being able to find the existing igroups on the filer, the 2nd node displayed the following Snapdrive issue:
'Failed to create disk in vitual machine. Failed to map virtual disk :File [Netapp_FC2_DS]exch2/exch2_SD_scalar-cdc.scalar-labs.ca_W-DdV4WCi2kF_1.vmdk is larger than the maximum size supported by datastore'Netapp_FC2_DS'.
This error was also displayed on vCenter Server. The size of the datastore wasn't the issue.
I ended up upgrading Ontap from 22.214.171.124 to 7.3.2 and Snapdrive 6.2 to 6.2P1 and the issue disappeared.
The compatibility matrix stated 126.96.36.199 was supported with Snapdrive 6.2 that's why it was odd. Just wondering if you've seen this type of error?
BTW - The connectivity is FC between ESX and Netapp (i.e. FC RDM's in the virtual machines via Snapdrive)
The error you describe I have not seen. However, I have seen the behavior described by the initial post where SDW will not detect a manually created iGroup that contains multiple initiators in it. In fact, until last night in my lab I was using SDW 6.2 unpatched with ONTAP 7.3.2.
I have a single FCP igroup with all the ESX cluster initiators in it and an iSCSI igroup with all the ESX iSCSI IQNs. I also have individual igroups for each ESX host for both FC and iSCSI.
When I use SDW to create an RDM, select Manual mapping, it only allows me to map the LUN to the iGroup I had created for this particular ESX host only. In fact, there is no way from SDW to map the LUN to the iGroup that contains all the initiators simply because that iGroup is not even listed as an option by the SDW GUI.
After talking to engineering this am, i was told the fix is in 6.2D3. I installed it and it works for both. I did not upgrade ONTAP.
Unfortunately, 6.2D3 did not fix the issue for me. When I attempt to have snapdrive manually map an igroup i created it does not show me the igroup. It only allows me to map the LUN to the iGroup I had created for this particular ESX host only. I get the same issue you had and I upgraded to 6.2D3.
Let me make a suggestion. In fact, this how it'd implement this and this is how i recommend it.
1) Create a Single igroup (type VMware) that contains ALL of the WWPNs from all ESX Hosts in the Cluster
Then use this igroup from SnapDrive to map LUNs to. SDW will definately see this igroup. Previously SDW would not detect it. You can also use this igroup to map VMFS LUNs to
2) Then use the "1 igroup per ESX host" scheme for cases were you need to assign some tetmporary space/scratch to a particular host.
Still doesn't work. My customer went through all the steps and we even tried what you suggestd to no avail. It's definitely a bug that needs to be fixed asap.
We're running the 6.2D3 release for a couple of customers to resolve the issue with manually created igroups and it has resolved that particular issue. One thing we've noticed is that the snpdrvdbglog files in the SnapDrive folder appear to be created/filled much more rapidly than in SD6.2. Is this a configurable parameter at all (i.e. can we crank down logging somehow, e.g. in a .config file)?
Lower it from 100 to 1
Restart service and you are set. Of course you can delete the left over files not in use.
How did you solve the missing initiators problem. My customer has installed 6.2D3 and it doesn't matter if there are igroups already on the filer or we create new ones - Snapdrive sees absolutly zero initiators. Any help is appreciated.