VMware Solutions Discussions

ONTAP Tools, igroup and vSphere/SRM - side effects

Oli71
344 Views

Hello,

 

Today's logic with iGroup is way too strict and creates an unwanted situation. As documented in the following KB:  VSC and VASA_Provider/Why does Virtual Storage Console (VSC) create "rcu_generated_alua" iGroup and Storage Replication Adapter: What determines if a new initiator group or export policy is created during a failover operation? , we learn a new iGroup gets created if the system doesn't find an equivalent iGroup with all initiators. So far, nothing's wrong but the problem appears when you have an iGroup with all detected initiators but with extra initiators used by your backup system whose requirement is to connect on a LUN to backup or restore. Your only way to back to your original IGroup is to "force" unmap, map the LUN again and rediscover your system storage. It creates a system service disturbance which is a situation no one wants.

 

Now, you add your extra initiators to an automatically created iGroup by either VSC or SRM well next time you do a similar operation like creating a LUN/NFS or failOver, it will try to create a new iGroup or choose an iGroup with exact same list of initiators/export. 

 

Would it be possible to switch or leave the operator to decide to use minimal requirements (detected initiators) instead of strict requirements?

 

Regards,

Oli

 

2 REPLIES 2

bingen
311 Views

We can certainly look into it.

 

In the mean time, have you considered running a script to map the LUN to your backup host, rescan disks on the backup host, and run the backup? Then disconnect the LUN when finished and rescan again to clean up the device list?

Oli71
306 Views

Yes, it was my plan B to use pre and post-script. One adds and the other removes the backup machine initiators in the SVM iGroup.

 

Since all happens behind the scene,  I will welcome more of a change from the appliance side: like minimum requirements or leaving the choice in the appliance settings

 

Olivier

Public