Modify netapp SRA NOT to use iscsi??

[nsitps1976]

I am looking to see if there is a way to stop the netapp SRA from creating an iscsi igroup and mapping recovered luns to this igroup. I only want fc igroups created and luns mapped to this igroup.

The host cluster access both iscsi and fc storage (hence the SRA is creating iscsi igroups), although the iscsi storage is not on the netapp system (hence my recovery is failing)

[WEBSTERMORETTI]

Did you find an answer for this, i'm having the same problem

ESXi hosts with an FC Netapp and some VM's pointing to an ISCSI storage

Thanks

[nsitps1976 · Accepted solution]

Yes. Unfortunately this is an unsupported configuration. My customer was fortunate enough to be able to swap out the iscsi mezzanine adapters in the 3rd party storage for FC adapters, creating a single protocol SAN. Iscsi was then disabled on the hosts which ensures the SRA only creates iscsi igroups.

[WEBSTERMORETTI]

This is a surprise for me, do you know if it's a SRM unsupported configuration or the problem is in the SRA?

Unfortunately i don't have the option to change the adapter to FC, but i'm thinking if i can disable the iSCSI in the hosts and present through Microsoft iSCSI Initiator directly to the VM's

I know it's not recommended, but iSCSI is used only to store the cameras images.

Thanks a lot for your help

[nsitps1976]

This is a netapp SRA unsupported config. It is the SRA which talks to the filers to create igroups etc, not SRM. I did suggest to netapp could they modify the perl scrip to NOT create iscsi igroups, however, they said they could not do this for me. I can't recall the script name at the moment, however, you can can find it within the program files directories of the SRA install, you can clearly see both the FC and iSCSI igroups commands. If you can modify perl you could maybe do this yourself, however, you would no longer be supported.

If the host is enabled for iscsi then iscsi igroups will be created no matter what (this makes perfect sense of course) and as you have found the SRA will map luns to the iscsi igroups first. If you access directly from within the guest you will be fine, just ensure you disable iscsi on the hosts. 

[WEBSTERMORETTI]

ok, i understood

I think the only way is to point the LUN to the VM through iSCSI Initiator.

The problem is explain to the customer that the DR process will need some manual work because of the SRA

thanks a lot for your help

[DRussell]

Hi,

The information provided in this post is not strictly correct.

Yes SRA does issue the request to create IGroup for ISCSI and FC but this is due to the information obtained via SRM via host queries and submitted to be actioned by SRA.

I have a DR site that has ISCSI enabled and has ISCSI Adapters enabled in the Hosts but no mappings to them. The problem does not occur at the DR site.

However, at the Primary Site, I have an Enviroment with both NetApp (connected via FC only) and VSA (connected via ISCSI only). The ESX Hosts see both NetApp and VSA SANs.

However, when a test recovery is performed at this site, it fails due to the FC/ISCSI IGroup LUN Mapping conflict. When you inspect the SRM Logs, it clearly shows the queries of the Hosts/Datastores occurring well before SRM invokes the SRA scripts such that SRM requests ISCSI  Initiators to be created for these ESX Hosts.

Things are ok if the hosts have FC & ISCSI proocol enabled but have no ISCSI mappings associated with the Host. If there are no mappings, the ISCSI requirements are then ignored.

To me, this is a poor bit of programming by VMWare. The SRA carries out the request given to it by SRM. Garbage in equals garbage out! The SRM should be filtering the data received back from the Host queries so it could stop them being parsed to SRA if the Hosts do not have any ISCSI mappings back to the NetApp.

If your environment has both FC and ISCSI running on the NetApp, then this is an unsupported configuration as it is an either or but not both.

This problem still exists in SRM 6.x so really someone should be giving VMWare a perverbial kick.