Community

Subscribe
Highlighted

Feature request - choose igroup when provisioning datastore

Environment:

Clustered Data ONTAP 8.1.2P3

vSphere + ESXi 5.1

VSC 4.1

When provisioning a new datastore VSC will create a new initiator group called "rcu_generated_alua" and add HBAs for each host to it, even if a suitable initiator group already exists. It would be nice if VSC either allowed you to specify an igroup or choose from a drop-down of suitable igroups if any are found. With the current method it means VSC can not be used to provision datastores if portsets are used.

Would it be possible to add this to a future release, similar to what is available in SnapDrive? I haven't tried the 4.2 beta yet so not sure if this is already an option.

Re: Feature request - choose igroup when provisioning datastore

I completely agree. It would be nice if this could be set as a preference.

Example: default creates the rcu_generated_alua, but you would have the option to select from existing igroups if already present.

Re: Feature request - choose igroup when provisioning datastore

Thanks for the suggestions!  We have these items on our roadmap.  No commitment, but they are there!

Re: Feature request - choose igroup when provisioning datastore

I'm sure that given the chance, the field would up-vote this feature request in a dramatic fashion.

In addition, I'd like to suggest adding the option to name the iGroup.

I have many customers who have naming conventions that they insist upon.

The current flow has them manually editing the iGroup name after provisioning storage with the VSC.

Thanks,

JP

Re: Feature request - choose igroup when provisioning datastore

Did i miss-use the tool at any Chance? I created a new datastore and it generated a new igroup with only the ESX in it on which i ran the Task. When I add all the other ESX, fine, but will it continue to use the rca_generated igroup for the next datastore?

Re: Feature request - choose igroup when provisioning datastore

I am using VSC 5.0 on vSphere 5.5, and still no way to avoid the catch-all igroup name ""rcu_generated_alua".