IMPORTANT: Some of my examples use View Connection and View Security Servers as an example. Remember at the moment such a configuration is not supported in production. As this is a lab environment I’m kind of free to do what I like, which is one of the benefits of a lab environment.
So far my focus has been been on External Networks and Organization Networks – I’ve made the occasional sojourn into other areas such as Secure LDAP, vApp Templates, Uploading and so on. But I haven’t yet really touch upon vApp Networks – so to this point my vApps have sat directly on the Organization Network like so:
My master plan (and this a bold idea I know) is to try and configure every type of network configuration possible in vCloud Director. That’s quite a tall order because there are many – and so far I’ve skipped some of the possibilities already. For example I’ve yet to setup a Organization Network that is directly connected to the External Network. I’ve good excuse there because I think most people would see that as insecure – it would mean one organization would be on the same network as another with nothing (potentially) to stop them seeing each others traffic. So the possibilities are almost endless – but initially I think I should focus on the most common configurations rather than every possible one. The joke I’ve repeatedly made about vCD networking is that often sounds like the “Dem Bones” song – you know the vApp Network connects to the Organization Network, the Organization Network connects to the External Network. Now here the word of the Lord! 
So initially I want to focus on the most popular configurations, and then look at getting A to speak to B – even that has a number of permutations. Like how do you get one vApp to speak to another vApp on the same Organization each within their own vApp Network – and how do you configure that between two vApps in different Organizations. Before I begin on that I’m going to remind myself of the rules that govern what is (and isn’t possible) with vApp Networks.
1. Although each VM can have multiple NICs only one NIC at anyone time can be connected to a given network. This rule is actually very simple. Think of it like a physical cable. One end goes into the back of the VM, the other end can only plug into one UTP port at the other end. I actually got this from the official courseware – perhaps its bit odd to state something as obivious as this…
2. A single vApp could have more than one vApp Network. This is kind of requirement for no 1 to be possible. For example its possible for VM-A to have vApp connection to VM-B. VM-B could have two NICs one connected to vApp Network1 and the other connected to vApp Network2. That would require two vApp Networks.
3. You can have multiple Organization Networks connected to mulitiple vApp Networks – so packet come into VM-B from OrgNetworkB, on one of its NICs and then that traffic to be moved to second NIC configured for vApp Network1, the pack to picked up by VM-A on the same vApp Network1 and then transfered to its 2nd NIC to OrgNetworkA. Yes, VM in a vApp Network behind a vCNS could use GoS routing to bridge to different networks. It strikes me that reason for a VM to have more than one network is merely to bridge on network to another. I think the chances of someone actually in this day & age introduce the complexity of GoS routing is slim. Nonetheless the option is exists and good luck to you finding a compelling use case.
4. As the example indicates above – a VM with two NICs could be plugged into a vApp network and Organization Network at the same time.
5. Even if a VM has two NICs, those individual NICs can be plugged into the same network
Like a lot of rules in life – its stuff you cannot do that really matters. Here are my top 3:
- You cannot directly connect one vApp Network to another vApp Network. The only way to achieve this is if you have a VM that acts a router between the two networks. This means you can have two developers working on the same set of VMs in their own little networks if you so wish…
- You cannot directly connect one Organization Network to another Organization Network, again to do that you would need a VM with multiple NIC bridging the two networks
- Although a vApp Network can be patched to an Organization Network (which I think would be very common) its not possible for one vApp network to be connected to multiple Organization Networks.
There’s another layer of functionality within vApps which control if the connection is NAT/Firewall or Fenced. Mixed it up all those options together you have an awful of lot of choice at your disposal. There’s two main ways of creating a vApp Network – when you deploy the vApp itself or by adding it to an existing vApp that’s there. Personally, I think things are “neater” to do it at the point of creation – that’s because if you have a vApp with 6 VMs, and you introduce a new network (the vApp Nework) each VM within the vApp will need (potentially) reconfiguring for that network.
Adding a vApp at creation time:
1. Login as vApp Author
2. Select Add new vApp from Catalog
3. Select either an image from either the Gold Master or Templates view
4. Set the vApp Name and Description
5. Select a Virtual Datacenter, VM name and Storage Profile
6. In the “Configure Networking” wizard set the hostname/computername for the VM, and from the NIC0 pull-down list select Add Network
Note: This should open a second dialog box labeled “New vApp Network Wizard”
7. These IP ranges are auto-magically completed by vCloud Director. It’s entirely up to you what you set here. You might find the dialog box very similar to when you create a NAT/Routed Organization Network. That’s because they are very similar except the scope is different. Whereas Organization Networks are visible to Organization Virtual Datacenters (and other Organization vDC if they are “shared”) the vApp network appears just to the VMs configured for it. You can re-configure the IP as you see fit. It’s at this point that I wish my External Network was on 10.x.x.x, Organization Network on 172.x.x.x and the vApp Network on 192.x.x.x. However, IP is IP where ever it is used so I won’t worry about this now. But if I EVER write a book on vCloud Director a RE-IP is on the cards for my lab environment!
As far as my “tenant” is aware the only networks that exists is their Organization Network (172.168.x.x) and their own vApp Network (192.168.10.x). They have no idea what my External Network IP range (which happens to be 192.168.3.x – I wish it was something like 10.10.10.x). So guess if you were the same position as me – you quickly forget about the IP range on the External Networks (except when you do networking from one Organization to another).
8. Finally, set a name and description for the new vApp Network
9. Once the vApp Network has been configured you can control how IP address are assigned by enabling the “Switch to the advanced networking workflow” option – IPs can either statically from the pool, manually from the pool or using the vCNS DHCP Service.
Note: If you do configure the option for DHCP – then the Static IP Pool created previously is ignored. The vCNS does not by default enable the DHCP service – that is something that the vApp Author, Organization Admin or System Admin would have to do on the properties of vApp Network.
10. The “Advanced Networking” actually defaults to creating no connection to from the vApp Network to any wider network in the system. Is it is possible for a vApp Network to be a network in its own right with no relationship to any wider network at at. You could say it lives in a “bubble” of its own. If you select a Organization Network from the pull-down list (in my case the Test/Dev Virtual Datacenter only has one network) – you will also see the option to deploy vCNS for the vApp Network with NAT and Firewall functionality as well.
When subsequent VMs are added into the vApp you will see the option to patch the VM to the vApp Network. As the vApp Network was requested with NAT/Firewall the icon you see here shows the “wall” icon. If you think about it there are number of layers of firewall-ing. First there’s my external physical juniper firewall, then behind it is the Edge Gate way for the Organizational Network – then there is an Edge Gateway for the vApp Network.
The settings that back the vApp Network’s vCNS Edge Gateway are configurable by the creator/owner of the vApp itself. That would allow them to let their vApps properly access the Organizational Network (and potentially be accessible) from elsewhere. That’s done by selecting the vApp, Select the Networking Tab and right-clicking the vApp Network and choosing “Configure Services”
I find vApp Networks Edge Gateways interesting because thier default settings are subtly different defaults. For example whereas Organization Network Edge Gateway will have the firewall enabled, but no rules defined (thus blocking all traffic), the vApp Network version has the firewall enabled, but with one rule that allows for all outbound traffic (but nothing inbound). That to me make sense – that vApp within Organization would have a less restrictive policy for communication. After all they should be trusted entities if they reside within our network. Whether those same VMs should be allowed to communicate OUTSIDE of the organization on to the External Network where they maybe able to access either the Corporate backbone or the Internet is more serious decision.
The other thing that I worry about in my lab environment is if every vApp I create – also creates a vCNS Edge Gateway – that’s going to consumme resources pretty quickly. In contrast a vApp that just stuck behind the Organizational Network vCNS Edge Gateway shares that gateway with a whole host of VMs. As I worked on this section posts I eventually wound-up with two “types” of vApp within each Organization Virtual Datacenter – one without a vApp Network and one with. That way I could test communications between two Organization. I also took advantage of the fact that powered down vApp shutdown the vCNS Edge Gateway and deletes it. This frees up resources considerably. The lesson learned is to only power on what you need, when you need it your lab environment – and to try and limit the number of vApps you need for each example/type of communication.
Adding a vApp at after the fact:
Adding vApp Network to vApp after the vApp has been created involves a number of tasks. Firstly, creating the vApp Network itself within the “Networking Tab” of the vApp which kicks off the vApp Network wizard we saw just above.
Once add it you decide if the vApp Network should be connected to the Organization network, and if it should support NAT/Firewall as well.
Finally, all the VMs within the vApp will need to be reconfigured for new vApp Network, once completed the reference to the CorpHQ-DevelopmentOrgNetwork can be removed.
So to summarize – that leaves me with two vApps – one using a vApp Network of 192.168.11.x and another using 192.168.10.x. Currently neither of them can communicate to each other despite being uplinked to the CorpHQ Development Organization Network – because there’s a no route to each of them, and their reside behind their own personal vApp firewall. There’s isn’t a really view that shows the relationship between vApps on the same organization network. But through the magic that is SnagIT I concocted one!
…and Finally… when you power off the vApp what you’ll find it is also powers off the vCNS Edge Gateway – and deletes its from vSphere. This is VERY important if you go about making STATIC IP references within the vApp vCNS Edge Gateway. That’s something I will be doing in the next part on vApp Networks… But for the moment you might notice that every vApp Network has this option called “Retain IP/Mac Resources”. There’s also handy explanation down of the bottom of the vApp’s Networking tab
Retain IP/ MAC Resources: By default, when a vApp is stopped, public IP and MAC addresses for the network are relinquished to pool. Select this option if you intend to retain IP and MAC addresses of the edge gateway across deployments.