PVLANs is one of those features that everyone should have in their mental “toolbox”. We were looking for a way to fence off portions of a network with minimal effort, but they didn’t really require a whole separate subnet. For example, maybe to enhance security, or for pre-production VMs. (Obviously, this is assuming properly configured switches) For those that are unfamiliar with PVLANs, check out VMware’s KB on the subject. Essentially, it allows you to further segment a VLAN using different groups (promiscuous, isolated, community)
The promiscuous group can talk to all other groups. The community group can talk among itself and the promiscuous group, and isolated can only talk with promiscuous (not even other members in the isolated group!)
Traditionally, if I had two servers in the the same subnet and same vlan, I may have had to create firewall rules to stop traffic or some other means. Maybe reconfigure the network or addressing. Maybe not such a big deal, but what if I added 10 more servers. 50 more servers? Rules and firewall configuration could get kinda hairy.
Using PVLANs in vSphere, I would create the PVLAN, PVLAN groups, and then create the port group associated with the PVLAN groups. Then, assign the VM to the required port group. In our case, infrastructure servers like the Domain controller were set to the promiscuous group. But, we wanted to restrict traffic between all RDS servers, which were assigned to the Isolated group.
I will note that the behavior of PVLANs can be achieved through other means, depending on what exactly your trying to accomplish. Also, they are not a replacement for firewall rules in most cases, you will still want to restrict traffic as needed to those VMs in the promiscuous group. However, PVLANs seem to be a great broad solution and should be considered to augment such designs.