Thanks - that is a helpful article. In this scenario, one of the goals is to be able to have a group of esx hosts, clusters and vms, all on the same physical subnet, and all with IP's on that ...
See more...
Thanks - that is a helpful article. In this scenario, one of the goals is to be able to have a group of esx hosts, clusters and vms, all on the same physical subnet, and all with IP's on that subnet - and then from this larger group of VMs, to separate groups of VM's and allow them to only talk to VM's in their group. For example, suppose there are 200 vm's on the 192.168.1.0/24 subnet. They are all going to keep their IP addresses. Suppose 20 of those vm's are in "group A" and 20 are in "group B". Group A vm's should be able to talk to other group a Vm's only. Group B vm's should be able to talk only to other Group B vm's. However, there could be group A vm's spread out among different esx hosts and clusters. But whatever management tool is controlling the isolation still keeps track of where the Group A vm's are even if they are spread out among separate ESX hosts and ESX clusters. Amidst all of this it is happening without requiring the creation of a separate subnet and and keeping all IP's on the 192.168.1.0/24 subnet. The management piece that is administering the (vshield zones/vshield edge or whatever the solution is) for example, can from one place manage the vm's that are in these separate groups and keep their traffic separate. Although the article discussed some of these topics from a high-level perspective, I'm not completely clear on the distinctions between products and what they can and can't do to understand which product if any will actually do just this. Can this be done with Vshield Zones? The next commenter talked about vshield Edge "separating layer 2 traffic" Is Vshield edge dealing with separating traffic between VM's on separate logical subnets as a router would or on the same subnet? (In this scenario all the vm's would be created on and stay on the 192.168.1.0/24 subnet)