By default, VMware Cloud Foundation (VCF) 9.0 will use the optimized Enhanced Data Path (EDP) Standard switch mode when configuring NSX, which will require you to have an EDP capable network adaptor. One way to check whether your network adaptor supports EDP is by using the Broadcom Compatibility Guide (BCG) and ensuring "Enhanced Data Path - Interrupt mode" feature
Alternatively, if you already have ESXi running, you can quickly check by running the following command: esxcfg-nics -e
If you are planning to deploy VMware Cloud Foundation (VCF) 9.0 on an AMD Ryzen processor (consumer CPU), make sure you are aware of the required workaround to get the NSX Edge node to function properly, which I had shared the solution back in 2020.
Fortunately or unfortunately, the workaround is still applicable with VCF 9.0 due to lack of support for Data Plane Development Kit (DPDK) with Ryzen processors. One of the challenges you could face depending on where you deploy the NSX Edge, since there is a new workflow that is built right into vCenter Server 9.0 and SSH is not enabled by default, which means you would need to go to VM Console of the NSX Edge VM to apply the workaround.
To make this even less fun, during this time the NSX Edge is going through its initialization process and because it fails to detect DPDK support, the required NSX services can not start and keeps re-trying which is not a bad thing. The reason the looping is a problem is because the workaround requires editing a configuration file and depending on how fast you can type, the initialization process will restart and cause your session to end and you now need to log back in, thus causing a less than ideal experience.
As you can probably guess, I got hit by this re-initialization loop and I just got tired of trying to be faster than the computer 😅
Since vSphere 7.0, it has been much simpler to correlate between an NSX network segment defined in NSX Manager and its representation as a vSphere Distributed Virtual Portgroup (DVG) in vCenter Server as demonstrated in screenshot below using the vSphere UI.
With the additional NSX information such as NSX Transport Zone ID, Transport Zone ID Name, Logical Switch ID, Segment Name and VNI (Virtual Network Identifier), users can streamline debugging and troubleshooting issues with their network team by quickly providing this relevant information.
I recently had a user ask about retrieving the VNI information for a given NSX segment in vCenter Server using PowerCLI, so here is a quick snippet including other NSX information for those interested.