vMotion of NSX EDGE gotcha

Hi,

Recently I was working on a brown field deployment of NSX and ran into an issue where we were not able to connect to the DHCP server from a Logical Switch (which means the VMs are not getting IP addresses from DHCP server) which was a key.

If we put the VM on a regular VDS dvportgroup it gets the DHCP IP correctly.

So we started looking in to the issue further and engage VMware GSS to look in to the issue.

During the troubleshooting we had to decide the location of Edge and try moving it to a different host to verify if its not hitting any uplink issue.

As we were using vCenter Web Client and as soon as we tried migrating (vMotion) it to another host and we were prompted with the NIC mapping page. Where we need to map each interface exists on the NSX Edge to a corresponding portgroup or dvportgroup. Now we have only limited number of portgroups/dvportgroups existed on the Cluster and we could not map all the internal interfaces (which gets created by default on the Edge appliance).

The source were listed as "None" so not sure where to map them.

So we ended up using the vSphere client to migrate the Edge appliance, and boom....it got migrated with no notification about mapping all the interfaces. Just select the destination ESXi host and hit "Finish", and we are done.

We were then moved into the next phase of troubleshooting but the above just put me in a dilemma that the behaviour of Web Client is a bug or is it by design.

Interested in getting the answer from VMware so that I can clarify that with the existing and future customers on why to use vSphere client and what is the alternate methods to use when the Fat/Thick client will completely got removed by VMware??

Please leave the comment and share this.

Thanks for your time.

Disable/Enable ABC for NFS Troubleshooting on NetApp

I was reading some issue with NetApp NFS troubleshooting and came across the KB from NetApp to disable flow Control on the Array.

This new Flow control setting is listed under a RFC 3465 which is described as ABC (Appropriate Byte Counting (ABC)).

Now this particular settings takes care of TCP Congestion Control with Appropriate Byte Counting (ABC) settings on the array.



As per this document  Storage Best Practice Document (TR-3749.PDF) page 25 Flow control means:


 FLOW CONTROL
Flow control is a low-level process for managing the rate of data transmission between two nodes to prevent a fast sender from overrunning a slow receiver. Flow control can be configured on ESX/ESXi servers, FAS storage arrays, and network switches. For modern network equipment, especially 10GbE equipment, NetApp recommends turning off flow control and allowing congestion management to be performed higher in the network stack. For older equipment, typically GbE with smaller buffers and weaker buffer management, NetApp recommends configuring the endpoints, ESX servers, and NetApp arrays with the flow control set to "send."

And further reading on the Congestion Management with Flow control - TR-3802.pdf page 23 , it mentioned other technologies to use such TCP windowing, increased switch buffering, and end-to-end QoS which may reduce the need for simple flow control throughout the network. Now I think along with that you can add the setting for ABC as per the RFC mentioned above. You can read the RFC to get more idea on how exactly it works on the TCP stack.

Fro ONTAP 8.1 Netapp has  released the guide with the following command:


ip.tcp.abc.enable

(Enables/disables the use of Appropriate Byte Counting in TCP Congestion Control following RFC
3465. Valid values for this option are on or off. The default value for this option is on.)


Now if you need further information on how to set this up on the affected Array and I would suggest to get in touch with the vendor.

Now this may or may not improve the overall situation but its worth giving a try.


Please share if you can.