I’m facing an issue while deploying an ONTAP Select cluster (2-node HA) using ONTAP Select Deploy 9.18.1 in a VMware environment. During the cluster creation, the Storage Pool dropdown is empty, even though I have available datastores that should meet the requirements. Environment details: ONTAP Select Deploy: 9.18.1 Deployment type: 2-node HA cluster License: Evaluation Mode VMware ESXi, 8.0.2, 23825572 Storage configuration: Tried Software RAID vCenter-managed ESXi hosts What I verified: I created new shared datastores (DS_SHARED_11 and DS_SHARED_12) Each datastore: 2 TB capacity 2 TB free space Datastores are visible and accessible in vCenter Both hosts are part of the same datacenter and see the same storage Minimum capacity requirement is met (UI shows ~1.9 TB required) Issue: Even with these datastores available, the “Select Storage Pool” dropdown does not list any options. Additional notes: I previously had smaller datastores (~1 TB free) that were not listed, which made sense due to requirements After adding larger datastores (2 TB free), the issue persists Software RAID is not an option (no qualified disks) Hosts are currently added via vCenter (not standalone) I’ve attached screenshots showing: The available datastores in vCenter The ONTAP Select Deploy UI where no storage pools appear Question: Is there any additional requirement or constraint (permissions, datastore type, host configuration, vCenter integration, etc.) that could prevent ONTAP Select Deploy from discovering these datastores?   ... View more

I need to revert these LIFs back to their home ports. However, several critical applications and clients are currently connected to them. In the past, I encountered issues when reverting LIFs without first considering the location of the associated volumes. To minimize risk and avoid any potential disruption, can the LIFs and their associated volumes remain on the same HA pair within the cluster during the revert process? We would appreciate any recommendations or best practices for performing the LIF revert safely before proceeding.   thanks, RT ... View more

Hi everyone!   NetApp's Multi-admin-verify (MAV) is a great tool for enforcing dual control on potentially dangerous commands  (or any command - it's up to you as an admin to decide!), so having a sandbox to play with in labondemand.netapp.com was something I've long thought would be handy.   However, it's one thing to play in a sandbox, and another thing to make it in the first place, and know what steps to follow to set it up in your production environment. We don't have a pre-defined lab for MAV that I could find, so I wrote the attached powershell script to build one from scratch.   The script does the following:   Creates AD OUs and groups for StorageAdmins and StorageOperators Provisions 9 accounts into each of them (storageadmX and storageopX), password: Netapp1! Creates an SVM on ONTAP cluster 1 (192.168.0.101) Domain joins SVM to demo.netapp.com Sets up domain tunnel through that SVM Sets up StorageAdmin and StorageOperator roles based on the admin role Assigns groups to roles Sets up MAV with StorageOperator requiring MAV approval, StorageAdmin not requiring approval Restricts vol delete and snap delete commands under MAV for StorageOperator I’ve tested it with 9.16.1 and 9.19.1 labs and it’s done what I expected with regards to setup - I haven’t done deep testing of MAV with it, the aim is to setup an environment where MAV can be tested.    To use it: Create a lab against https://labondemand.netapp.com/node/1078 (9.16.1X) or https://labondemand.netapp.com/node/1561 (9.19.1X), Drag the script into the lab window once the login is finished, Find it in the “Cloud storage” under “My Computer”, Copy it to the Desktop Open PowerShell, and run the command I hope people find this helpful!    Please note values are hardcoded for the demo environment on labondemand.netapp.com, but you are welcome to use it as a basis for your own environments too. This script is provided only as community supported - please do not call NetApp support for help with it. ... View more

We have developed an automation Ansible script which logs into the ONTAP System and fetch the details of the igroups whose initiators are not-logged in. This script logs into the ONTAP System multiple times, and in context to that please let us know if this can cause an issue on the Storage at any given time. Please highlight if this repeated login by the script on the ONTAP system can put the Storage in a non-ideal situation.   --> We also want to know the impact on ontap node i.e, CPU utilization on Ontap node to use the script to try login attempts to the storage after each 30 or 40 secs to fetch the requested information.  Please advice  --> What is the amount of CPU utilization may cause if the scripts attempts login for every 30s to Storage    Looking forward to your response.   Thank you! ... View more