I have a PS6210 group connected to 3 esxi hosts over a private LAN, all set up to use multipath. In EQ group manager, the 2 older hosts show duplicate iscsi connections for each nic (the ones with IPs ending with 21, 28, 29 and 30. The newer host (with the .31 and .32 IPs) doesn't have the duplicate connections.
I've scoured my host network configurations to see if I can find a difference, but no luck yet. Any ideas on what I can check?
Hmmmm - just now noticed that VM LUNs with EQ snapshots don't have the duplicates, while LUNs with no snapshots do have them. I'm in the middle of setting up snapshot space for all my VMs, so maybe the duplicates will disappear after the snapshots are created?
Snapshots do not affect iSCSI connections at all. So that is not your issue.
ESXi maintains iSCSI connections in a small database. That is likely where the duplicate entries are coming from. You will likely seem them in the "Static Mappings" tab in the iSCSI initiator.
They aren't likely causing harm but I would suggest opening a case with either you VMware support or Dell Support to take a closer look and clear them out safely.
I would also suggest you make sure that all the best practices for EQL with ESXi are followed. This tech report will show you how to do that.
Social Media and Community Professional#IWork4DellGet Support on Twitter - @dellcarespro
OK, thanks, Donald.
You are very welcome. Also, if you haven't set things like Delayed ACK, the Login and NOOP timeouts per our best practice, the process to correct that will require nodes to be in maint mode and rebooted. You can do them one at a time to prevent downtime. But when it's all done, it will likely also resolve this issue. As the old entries have to be removed so that the new settings can be implemented.
Great, thanks. I'm glad you mentioned those. Delayed ack and iscsi login timeout were set correctly on the older servers but not the newest one, and the noop needs to be changed on all, so I'll schedule after I verify any other changes per the best practices doc.
re iSCSI NOOP. Just an FYI, that is most critical with VMware Virtual Volumes. (VVOLs). The way VVOLs work, especially in multiple member pools makes the setting very important. It still should be done regardless but just wanted to let you know that.
If you not already doing so, you might want to consider using CHAP for your volume ACLs. Makes it very easy to add / remove nodes and or move them to a new cluster for example.
OK. We aren't using VVOLs yet, but I do have chap configured for the group. For data volumes, we are restricting access by IQN of the Windows server that hosts them.
Sounds great! Yeah, nice thing about setting the NOOP now is you'll be ready for VVOLs day one. :)
Re: CHAP. Nice. I manage multiple clusters and at different versions so I found this really helps. Especially when I migrate one to a newer ESX version as older ones are phased out. I migrated an ESXi v4.1 cluster to 5.0, 5.1 and now 5.5. :) SSH shell still says "MIgrated to 5.0.0" when I log in.
Also, if you're running newer EQL firmware I find using the Folders with Volumes really helps too. Makes it easier to manage ESX volumes, data volumes, etc...
Cool. I had 2 clusters for a while, one of them being a test cluster with older hardware, so the CHAP was really nice for that. Another test cluster is on the list since we refreshed our hardware, but I just have to find the time.
We're running 8.1 now, so I've been loving the folders. On the vm client side, I have resource groups and vm folders, but I tend to use the view with the resource groups more because I'm looking at hosts as much as I'm looking at VMs.
I like resource groups as well. Since my lab is kind of wild wild west of sorts, not production. But I like that the few important VMs I have I can protect and make sure they always have resources!
All the best.