How come after I create a transport zone, I cannot disconnect a cluster . It seems I cannot select it or grayed out
If there are any VMs on any of the ESXi hosts member of the Cluster to be removed, and these VMs are connected to a Logical Switch that has this Transport Zone, then it is not possible to remove the Cluster from the Transport Zone. This may be because if otherwise the VM traffic on the Cluster could be affected. So first the VMs could be Vmotioned to another Cluster and on this Cluster no VXLAN based VMs about this Transport zone is left.
And if you just delete the transport zone ?
It seems like it is only attached to 1 cluster.
No need to have a transport zone without having it connected to a cluster.
So try deleting it.
Goto 'Action -> All nsx user interface plugin actions -> remove'
Hi man, you can use REST API for delete all what you want whitout vincle.
hi
question:
after I create a transport zone and then creating a logical switch, which in turns shows up as a port group in vcenter
what IP range is valid for this portgroup? What VMs can be put here? where do I define what IP range is valid for this Portgroup?
Theoretically, any IP Subnet is possible, since this Logical Switch or Port Group is a L2 Switch. It is similar to connecting a Physical Server to a physical switch, so in that part Logical switch and IP address assignment of the VMs are independent of each other. However if the VMs need to communicate to other VMs connected to other Logical switches, then the Default Gateway of these VMs should point to either an ESG (Edge Services Gateway) or a DLR(Distributed Logical Router). Again this can be thought as Physical Routers or the Vlan or SVI Interfaces on L3 switches that has IP addresses. Again, static or dynamic routing as Ospf or BGP may be needed if they are not connected to same DLR or ESG. So the DLR or ESG are needed for communication out of the Logical Switch to other Logical Switch or Physical networks.
If it is a new deployment, IP address and topology planning may be important. If there are already VMs working on Vlan backed distributed Portgroups on the DVS, then migrating those VMs or Portgroups to Vxlan backed Logical switchces may be needed, and this may be done as a portgroup basis, so no need to change the VM IP addressing during this change.
hi
ok I have created 3 portgroups - web/app/db
I have a vm on each portgroup
web - 192.168.10.10
app - 192.168.20.10
db - 192.168.30.10
on my physical network, if I have an identical vlan 192.168.10.x or 20.x or 30.x, how would my machines on the physical network access these vxlan servers and vice versa?
If these port groups are VXLAN based, then for each of the port groups a Logical Switch should exist. For each VXLAN there is a VNI Number similar to Vlan-Id on the physical switches.
VM web - 192.168.10.10 --> VNI 5010 - LS-Web
VM app - 192.168.20.10 -->VNI 5020 LS-App
VM db - 192.168.30.10 --> VNI 5030 LS-DB
Physical web - 192.168.10.11 --> Vlan 10 - Port Group PG-Web
Physical app - 192.168.20.11 -->Vlan 20 - Port Group PG-App
Physical db - 192.168.30.11--> Vlan 30 - Port Group PG-DB
Since both Physical Web and VM Web are on the same IP Subnet, there should be a bridge (similar to a virtual connection) between Vlan 10 and VNI 5010. NSX Uses DLR bridge Mode Feature for this Purpose. The ESXi host where the DLR Control VM exists act as a bridge between those VMs. If you try to ping 192.168.10.11 from the Web-VM the packet will:
1. Go th the ESXi host of the Bridge through a VXLAN Tunnel
2. --> pass through the bridge
3. --> Physical Uplink of ESXi host that DLR Control VM Resides
4. --> Pysical Switch(es) --> Physical Web Server.
These articles may be helpful for more detailed configuration and design:
http://www.routetocloud.com/2014/10/nsx-l2-bridging/
http://planetvm.net/blog/?p=2905
VLAN/VXLAN "bridging". To DLR or not?
( Bridged DLR may act as router and bridge at the same time)
http://chansblog.com/tag/nsx-l2-bridge/
In general Bridged DLR is used for cases such as P-V Conversion of Machines, and if there are devices such as Physical Firewall or a Physical Load Balancer that serves this Logical Switch, or a Server that is not possible (preferred to remain physical) to be virtualized, then it may be recommended to change the IP address for Physical or Virtual side and use bridge functionality as an intermediate solution. For L3 Underlay Physical Fabric Designs, each Vlan (since it may be considered as a failure domain due to STP) is considered to local only on the TOR switch. This is because the Vlans for each VM and Physical Machines exist on same subnet should be extended through the Data Center. So if not needed it may be better to use a routed design instead of bridging.