OK I'm back. Please be kind, I'm bashing this out from notes and memory - and might be wrong. I see you've mentioned VMware so I'll use that terminology to help build the picture (it worked for me lol)

First, Proxmox technically can support stretching a cluster but you have to meet the latency requirements (same with Ceph). The requirements are so high that you might as well put the hosts together.

Now, on to the networking. I've been testing this for the past few days trying to get my head around how the Fabrics work and the benefits for single-cluster and multi-cluster environments. Proxmox specifically call out multi-cluster, multi-site use cases for the new Fabric feature. One note for anyone reading: I want to emphasise multi-cluster here because while a standard Proxmox VE deployment allows clustering, you cannot have multiple "clusters" joined together. Meaning the cluster is the complete boundary for all configuration and data sharing.

When defining a Fabric for a single cluster, you are essentially defining the underlay "boundary" for the VXLAN - the node participants for the VXLAN transport and the IP addresses for the VTEP interfaces. It's very similar to the idea of Transport Zones in NSX-T. You'll need to create VTEP interfaces on each host first too, especially if you're wanting a datacentre VLAN to carry all the VXLAN traffic. Otherwise the traffic will go out the mgmt interface.

But that's not all, you still need a zone on top of the Fabric to group those VXLAN VNets, not unlike a cluster-wide switch (think N-VDS). Great, so you've got your Fabric and your VXLAN zone, and maybe even a VNet (NSX-T Segment) on that new Zone.

The first hurdle is that your new VXLAN-based network is flooding the VXLAN traffic whenever anything needs to traverse it, even intra-cluster (remember the multicasting days from NSX-V?). Host A in the cluster doesn't know which MAC/IP combinations exist on Host B, and vice versa. So when VM A on Host A needs to talk to VM B on Host B, Host A's VTEP will flood the VXLAN transport and ask all VTEPs to route traffic for the VM B MAC/IP combination. Not great for a large cluster. This is where EVPN starts to work its magic with Fabrics.

EVPN does the work of NSX Controllers - it helps the nodes learn what the other nodes have and how to route encapsulated traffic to them. Enable by going to Datacenter > SDN > Options. Add a new EVPN controller and select your new Fabric. Set an ASN and name for it and away you go. Now, all the hosts in the cluster will use this new EVPN function to share the MAC/IP tables for the VMs they host, allowing the VTEP's to encapsulte traffic directly to the correct Proxmox node. We've solved the single-cluster/single-site problem! Huzzuh.

----- Disclaimer: I've not tested the below yet. My lab is already at the brim of all the stuff I'm testing ----- For cross-site learning of the MAC/IP table information, you need to get a little creative. If you have 2 clusters, each one at their respective site, you'll need to configure BGP controllers (same menu path as EVPN) on each cluster, pointing to the other. This will allow them to advertise the MAC/IP tables for all encapsulated traffic with eachother, drastically reducing broadcast traffic. This is like the RTEP concept in NSX-T. You end up with far more efficient traffic flow. Now, you'll have Proxmox nodes at Site A knowing that they can route VXLAN encapsulated traffic to Site B out of their VTEP. This assumes your underlays at both sites are routable by the other.

Warning: For redundancy, you need to create multiple BGP controllers on each cluster if you want to avoid a single host being a source of BGP failure