[…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 within my Test/Dev Virtual Datacenter directly on the Development Isolated Organization Network.

Screen Shot 2012-12-19 at 12.18.07.png

Screen Shot 2012-12-19 at 12.18.18.png

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!

Screen Shot 2012-12-19 at 12.21.31.png

To enabled fenced networking for vApp, you merely put a tick on the box under the Networking tab:

Screen Shot 2012-12-19 at 12.42.26.png

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.

Screen Shot 2012-12-19 at 12.58.31.png

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 ( cannot ping each other directly, but as they each sit behind a NAT – each VM is assigned an external address which is unique.

Screen Shot 2012-12-19 at 13.08.23.png