This is something I came up against several years ago but never got around to posting it, the workaround is to deploy a Nexus1000v, the PVLANs will be defined within the Nexus and will never traverse the upstream network.
Here’s the response from Cisco
“In a nutshell in End Host mode on the Fabric Interconnects have no unknown unicast flooding functionality and does not learn Mac addresses on the uplinks.
Because the Vmware DVS cannot terminate the PVLANs they will need to extend into the external LAN switching infrastructure.
Therefore, all community/isolated VLANs have to be defined on UCS and on the external LAN switch(es) as well.
This is fine if no communication is required between the isolated PVLAN and any external host on the Primary VLAN.
Where the design requires an external promiscuous port then you need to set the UCS Fabric Interconnects in switch mode. That is traffic that enters the promiscuous port is classified in the primary VLAN. Therefore from a UCS perspective there are no server-side MAC-table entries in the primary VLAN because servers are in an isolated PVLAN. So no communication is possible.
As such, switch mode is a must for bi-directional communication. Here the fabric interconnects will do Mac-Learning on the uplink ports as well as the server ports.”