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 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.
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 188.8.131.52 to 7.3.2 and Snapdrive 6.2 to 6.2P1 and the issue disappeared.
The compatibility matrix stated 184.108.40.206 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.