I can't seem to find anyone talking about doing only the distributed firewall running NSX-T. We currently have a small VDI pod with NSX-V and use the distributed firewall only. Our VDI team is going to build two new pods and not put any of them in linked mode. So my understanding is NSX-V I will have to have a manger for each vcenter and the rules won't really be in sync between the managers I will have to export/import or some other process to keep them in sync, where with NSX-T I can have one manager connected to many vcenters. Is the architecture the same if only doing the distributed firewall piece (meaning I still need the manger plus 3 controllers and i can skip the edges?) or should i just stick with NSX-V if only using the distributed firewall?
We are looking to do the DFW as our first foray into NSX. Original plan was to do it with NSX-V but dithering over licensing has put us back so far that we are being told to do it with NSX-T.
With NSX-T you have to establish the Manager/Controller cluster and then define your ESXi Hosts as NSX-T Transport Nodes from within the NSX-T GUI. My understanding from the way things are plumbed together is that you have to go whole hog and put your Hosts into an NSX-T Transport Zone, implementing networking either as "VLAN Backed" or "Overlay" in order to be able to apply Security Policy.
You don't get to deploy the DFW VIB in isolation on your hosts. From the NSX-T GUI you ready a Host for NSX-T and that will push firewall, switching and routing software out to the Host.
So, I think the answer is that you can't do the DFW and retain the VMware Virtual Distributed Switch networking. You can reproduce that networking in NSX-T.
As to the details of making the transition from VMware DVS to NSX-T DVS, I am not clear. My plan is to establish a new clean cluster, set up VLAN backed NSX-T network and move workloads to it, and then pull Hosts over into this new cluster as I move the workloads.
I am certainly not the expert here but nobody else has answered so that's my two cents.
I've been researching the exact same issue and so far, this is what I've learned...
First of all, like you already mentioned, nobody is really talking about just doing microsegmentation using NSX-T. It's pretty much always about network virtualization, with some microsegnmentation built on top of that. But in NSX-v this is one of the main use cases and there is a lot of information about this specific topic (microsegmentation for VDI deployments). And as we all know you only need an NSX Manager and Host Preparation to do that. No NSX Controllers are required. You don't even need to have a VDS, a VSS will work just fine, because microsegmentation is performed on the vNIC level and this all works because NSX-v is tightly coupled to / integrated with the vCenter Server Appliance.
Now it would be quite troublesome if VMware were to say that you MUST virtualize your (VDI) network in order to be able to perform microsegmentation. Because that implies that you need to deploy Edge Nodes, T0 (and maybe also T1) routers, etc. And that would mean that all of these resources cannot be used to deploy additional VDI desktops. Well then, is VMware going to buy additional servers for us and provide free licensing for them? So in my mind, there had to be a way to do just the microsegmentation part, without using network virtualization. But then when you read the NSX-T Installation Guide, one of the first steps you need to perform is to deploy one or more Edge Nodes. And as far as I can tell it doesn't say anywhere in the document that this is an optional step. This made me quite sad 😞
But then I found this:
So in the end you really only need to use the NSX-T N-VDS. And N-VDS supports both Overlay and VLAN backed Segments (or Logical Switches). Now you do need to deploy three NSX Managers / Controllers. First of all because NSX Controller functionality has been merged with the NSX Manager. And you always need to deploy NSX Controllers to use N-VDS switches.
Now, depending on the number of pNICs in your servers (which most of the time will be two times 10G or 25G), you have a couple of options. You could of course keep using VSS or VDS for management, vMotion, etc. But you can also migrate your VMkernel interfaces to N-VDS (this is fully supported). Then you would only need 2 pNICs and assign both of them to the N-VDS. Otherwise you would assign one to the VDS/VSS and one to the N-VDS, or you need to add additional pNICs so that both switches have full redundancy. My advice would be to just use the N-VDS.
As for migrating from NSX-v to NSX-T, HamishMcCann makes a good point. Simply deploy a new Cluster and build your NSX-T deployment on top of that. Migrating VMkernel intefaces to N-VDS is fully documented and there are tons of blogposts about doing this as well, so that shouldn't be a problem. Then the old Cluster would still run on NSX-v and the new Cluster on NSX-T (this should work fine). When the old Cluster is empty you can perform the uninstallation of NSX-v (also fully documented and it's really not so hard to do). Deploying a new vCenter Server Appliance would also work of course, maybe even better 🙂
Regarding your other question, I'm not really sure if you can use the same Distributed Firewall on ESXi hosts in different vCenters. But in theory this should work. You can add multiple Compute Managers (vCenters) to NSX-T and then perform the Host Preparation. The way I see it you would then have multiple vCenters, each with their own ESXi hosts, all using the same Distributed Firewall rules. But don't quote me on that 🙂 Maybe someone else could provide us with a bit more information about this specific topic.
Definitely don't keep using NSX-v. You will have to move from NSX-v to NSX-T at some point (before January 2022), otherwise you will end up with a production environment that isn't supported (or maintained) anymore.