Hi Everyone, I have a quick design/technical question regarding running CDOT on a FAS2240 with a single 10Gb Cluster Interconnect/Switchless Cluster Cable...  I understand this is not best practice so please don't read me the riot act. However, technically will it work, and what are the downsides knowing if a port goes bad on either side we will have two nodes that can't communicate with each other in the cluster? I'm just trying to think if you only have 4 10Gb-E ports (2 on each controller), you could use just one from each controller for the cluster interconnect/switchless cluster and one on each controller to go up to the data network. That way you could get I/O into the controllers at 10Gb Speed from from the network on both sides and you can "vol move" over the cluster interconnect, as well as have the heart-beat over the interconnect for disk/controller takeover. I'm just trying to figure out how to make CDOT on a FAS2240 a practical option, because to me wasting your 2x 10Gb ports on each controller just for cluster interconnect/switchless cluster is just that.. a waste.  Again if someone can validate the design will work but the caveat is (whatever that may be) thats what I'm looking for. Thanks. It seems that when you go through the "cluster setup" command it says you need "at least one".. in my mind that means it should be possible. See bold below (I changed the font to call it out but this is what the message says in sequence): login: admin   (cluster setup) Welcome to the cluster setup wizard. You can enter the following commands at any time:   "help" or "?" - if you want to have a question clarified,   "back" - if you want to change previously answered questions, and   "exit" or "quit" - if you want to quit the cluster setup wizard.      Any changes you made before quitting will be saved. You can return to cluster setup at any time by typing "cluster setup". To accept a default or omit a question, do not enter a value. Do you want to create a new cluster or join an existing cluster? {create, join}: create Step 1 of 5: Create a Cluster You can type "back", "exit", or "help" at any question. List the private cluster network ports: At least one cluster port must be specified. The cluster network ports are the physical ports on the controller that connect it to the private cluster network. The controller routes cluster network traffic over these ports by using associated cluster logical interfaces (LIFS). Examples of cluster network ports in Data ONTAP are "e0a" and "e0b". You can type "back", "exit", or "help" at any question. List the private cluster network ports: ... View more

Hi Everyone, I have a question regarding connecting a V3220 to a Clariion CX4-120. The IMT says that direct connect is no longer supported. That much is understood. However, when I was originally researching this configuration the only document I could even find from NetApp about V-Series connecting to EMC is the: "V-Series Systems Implementation Guide for EMC Clariion Storage" which was written back in 2009. My question is; is there any reason direct connect technically wouldn't work with the latest DOT software (8.1.X/8.2.X)? In the "V-Series Systems Implementation Guide for EMC Clariion Storage" document, on P18 - 19, it clearly lays out how to direct connect a V-Series to a Clariion so I know at one time this was supported. To bolster support for my question: - The Flare version I'm using (04.30.000.5.524) is currently supported in the IMT. - On p4 of the "V-Series Systems Implementation Guide for EMC Clariion Storage" document. it says the CX4-120 is supported. So even though this document is older, direct attach was supported with this EMC model at the time the document was written. - The solution is a straight 4Gb FC (NetApp initiator) -to- 4Gb FC (EMC target) connection; meaning there will not be a speed mismatch issue. - How would the V-Series know it wasn't attached to a FC switch, and why would it care as long as it can see its targets? - Lastly, the CX4 will never be used for anything other than backend disk for the V-Series because we will have migrated all the data off to another FAS. Then we will rebuild the raid groups and LUNs (per NetApp best practices) just for the V-Series to be used as a DR/SnapMirror target. When I was architecting the solution I took my cues from this document (as it was the only thing I could find) and now I'm somewhat in a bind. My dilemma is we don't currently have an FC switch. The CX4 is running on iSCSI today. But we bought EMC FC cards to insert into the CX after the data migrations happen, so we could then rebuild the raid-groups/LUNs and present them over FC to the V-Series. I say "I'm somewhat in a bind" because I have a last resort option but I don't want to go there unless I have exhausted all other options. Any help would be greatly appreciated. Thanks. ... View more

Hi Everyone, I just thought I would share the results of my hard work in hopes it will make others lives easier. I've been working on creating a VMWare SRM 5.1 with NetApp demo environment for over four weeks now. Most of my time has been spent learning SRM and some of the basics of VMware clustering and NFS mounting etc. I finally got to the point where I had: - 3x VMWare ESXi 5.1 hosts installed - 2x VCenter Servers 5.1 created with NetApp VSC Plugin Installed - ESXi Hosts clustered with VMotion working through VCenter - NFS volumes created and NFS export permissions configured on the NetApp(s) - NFS Exports mounted as ESXi Datastores - Win 2008 DC, Exchange 2007 and OCS 2007 VMs installed with 2 Win7 client VMs to prove it was a fully functional demo environment - NetApp's NFS Volumes SnapMirrored - SRM installed (ODBC connections to SQL, etc.) - SRM configured Moment of truth.. I ran the recovery test plan and it failed with this Error - Failed to create snapshots of replica devices. Failed to create snapshot of replica device /vol/NetApp_Datastore1. SRA command 'testFailoverStart' failed for device '/vol/NetApp_Datastore1'. Unable to export the NAS device Ensure that the correct export rules are specified in the ontap_config.txt file. (See the SRM Failures.doc in the attachment) I was at this point on Monday. I scoured the internet for this error and found very limited information. I also obsessed over the ontap_config.txt file on the VCenter/SRM server to no avail. What I did find is when configuring NFS every Volume/Export must be explicitly configured with r/w & root privileges. RO must be removed along with Anonymous access. The export should look like the "Permissions.jpg" in the attachment. From the command line the permissions should look like this: ONTAP-SRM-2> exportfs /vol/vol0/home  -sec=sys,rw,nosuid /vol/vol0       -sec=sys,rw,anon=0,nosuid /vol/SRM_Placeholder    -sec=sys,rw=10.18.202.31,root=10.18.202.31 /vol/NetApp_Datastore1  -sec=sys,rw=10.18.201.31,root=10.18.201.31 /vol/NetApp_Datastore2  -sec=sys,rw=10.18.202.31,root=10.18.202.31 That being said. How SRM works when you execute the recovery test plan is it creates a FlexClone of the SnapMirrored volume. When I executed the test plan and it failed I started looking at the NetApp on the recovery site. I noticed it created the FlexClone but it obviously didn't mount it as a datastore and start up the VMs. Funny thing is that when I manually mounted the FlexClone I could start up the VMs. Thinking that NFS is all about permissions... look what I found on the permissions of the FlexClone when I ran the "exportfs" command on the recovery side NetApp ONTAP-SRM-2> exportfs /vol/testfailoverClone_nss_v10745371_NetApp_Datastore1  -sec=sys,rw=10.18.18.31:10.18.201.31:10.18.202.31:10.18.203.31:fe80::20c:29ff:fea5:ac48:fe80::250:56ff:fe63:7152:fe80::250:56ff:fe66:28d7:fe80::250:56ff:fe66:fd86,root=10.18.18.31:10.18.201.31:10.18.202.31:10.18.203.31:fe80::20c:29ff:fea5:ac48:fe80::250:56ff:fe63:7152:fe80::250:56ff:fe66:28d7:fe80::250:56ff:fe66:fd86 /vol/testfailoverClone_nss_v10745371_NetApp_Datastore2  -sec=sys,rw=10.18.18.31:10.18.201.31:10.18.202.31:10.18.203.31:fe80::20c:29ff:fea5:ac48:fe80::250:56ff:fe63:7152:fe80::250:56ff:fe66:28d7:fe80::250:56ff:fe66:fd86,root=10.18.18.31:10.18.201.31:10.18.202.31:10.18.203.31:fe80::20c:29ff:fea5:ac48:fe80::250:56ff:fe63:7152:fe80::250:56ff:fe66:28d7:fe80::250:56ff:fe66:fd86 /vol/vol0/home  -sec=sys,rw,nosuid /vol/vol0       -sec=sys,rw,anon=0,nosuid /vol/SRM_Placeholder    -sec=sys,rw=10.18.202.31,root=10.18.202.31 /vol/NetApp_Datastore1  -sec=sys,rw=10.18.201.31,root=10.18.201.31 /vol/NetApp_Datastore2  -sec=sys,rw=10.18.202.31,root=10.18.202.31 Look at all of that junk in there.. for anyone who doesn't recognize this.. This is IPv6 and I am pretty sure SRM 5.1 doesn't work with IPv6. SOLUTION - on the ESXi hosts: To view whether IPv6 is currently enabled, run the following ESXCLI command: esxcli system module parameters list -m tcpip3 You will see, ipv6 property is set to 1 which means it is enabled. To disable IPv6, you just need to set the property to 0, run the following ESXCLI command: esxcli system module parameters set -m tcpip3 -p ipv6=0 We can now reconfirm by re-running our list operation to ensure the changes were made successfully. All that is left is to perform a system reboot, you can either type in "reboot" or use the new ESXCLI 5.1 command: esxcli system shutdown reboot -d 60 -r "making IPv6 config changes" After the ESXi host reboots see the FlexClone permissions: ONTAP-SRM-2> exportfs /vol/testfailoverClone_nss_v10745371_NetApp_Datastore1  -sec=sys,rw=10.18.18.31:10.18.201.31:10.18.202.31:10.18.203.31,root=10.18.18.31:10.18.201.31:10.18.202.31:10.18.203.31 /vol/testfailoverClone_nss_v10745371_NetApp_Datastore2  -sec=sys,rw=10.18.18.31:10.18.201.31:10.18.202.31:10.18.203.31,root=10.18.18.31:10.18.201.31:10.18.202.31:10.18.203.31 /vol/vol0/home  -sec=sys,rw,nosuid /vol/vol0       -sec=sys,rw,anon=0,nosuid /vol/SRM_Placeholder    -sec=sys,rw=10.18.202.31,root=10.18.202.31 /vol/NetApp_Datastore1  -sec=sys,rw=10.18.201.31,root=10.18.201.31 /vol/NetApp_Datastore2  -sec=sys,rw=10.18.202.31,root=10.18.202.31 ONTAP-SRM-2> Note IPv6 permissions are now gone = Success! SRM Test Recover Plan works! Enjoy. ... View more