[…or how I learned to enable vApp Network Fencing]
In this example I want to tinker with the “Fenced Network” concept. This allows VMs with the SAME IP and HOSTNAME/COMPUTER name to reside on the same network without a conflict. I imagine the big use case here is checking out vApps from a development catalog where you don’t want to re-IP the guest operating system – mainly because that would break all the communication between those VMs. I thought I would start by trying to create conflict, and seeing in Fenced Networking would resolve it. So I created two vApps (imaginatively called FencedvApp1 and FencedvApp2 – each using the same manually assigned address of 172.168.7.100 within my Test/Dev Virtual Datacenter directly on the Development Isolated Organization Network.
Then I tried to power on both vApps at the same time – vCloud Director sensibly wouldn’t let me – and gave me a useful hint on how to resolve the problem!
To enabled fenced networking for vApp, you merely put a tick on the box under the Networking tab:
This has the affect putting each vApp on its own network, together with its own vCNS Edge Gateway to broker its connection on to that network.
That allows my two vApps with the same IP address to reside on the same network – as they are isolated from each via the Edge Gateway. The only downside I see is that the naming of these DvSwitch Portgroups and vCNS Edge Gateways do not correspond directly to the name of the vApp. So whereas a vApp with its own vApp Network gets dvs.VCDVvApp – Web appended to it – each Fenced vApp just gets the standard name of the Organization Network.
Of course my two vApps with same IP address (172.168.7.100) cannot ping each other directly, but as they each sit behind a NAT – each VM is assigned an external address which is unique.
