«

»

vCloud Director Organization Virtual Datacenter Network Sharing

A customer of mine called me a few weeks ago with a design question regarding the vCloud Director (vCD), version 5.1.2, Organization Virtual Datacenter (Org VDC) network sharing (Share this network with other VDCs in the organization) feature.

Just wanted to share the problem and solutions discussed even though the solution used by my customer might not fit your vCD design and setup. However the problem described can easily happen to pretty much any vCD setup if not taken into account at an early stage in the vCD design process.

When sharing an Org VDC Network with all other Org VDCs within the organization there is no need to create multiple networks serving the same purpose within one organization. All Org VDCs can use the shared networks as long as resources are available.
This is a nice feature but you can run into some administrative issues if you plan and perform things incorrectly.

During my customers vCD proof of concept (POC) he used the following setup.

  • 3 Org VDCs to verify the functionality of the different vCD allocation models.
    Screen Shot 2013-07-30 at 17.27.15
  • All Org VDC networks were created in the Org-VDC-01 and shared to the other Org VDCs within the organization.
    Screen Shot 2013-07-30 at 17.31.27

My customer encountered a problem when trying to delete the Org-VDC-01. When you delete an Org VDC you must delete all the objects included in the Org VDC e.g.

  • Edge Gateways
  • Networks
  • vApp
  • vApp Templates

In this case he could not delete the Org vDC since the other Org VDCs used the Org VDC networks created and shared by Org-VDC-01.
My customer received the following error message for 3 of the 4 Org VDC networks when trying to delete them even though he had deleted the vApps and vApp Templates in the Org-VDC-01
Screen Shot 2013-07-30 at 17.50.35
The fourth Org VDC network, the routed one, was not in use by any other Org VDC and that’s why it was successfully deleted.

So my customers question was obviously how he can avoid this potential administrative challenge in the future.

Well, i think we have basically 3 ways of dealing with this:

  1. Do nothing and if it happens it happens. Maybe you do not use vCD in the way so you need/take advantage of the Org VDC network sharing feature. If running into the problem you can:
    1. Create Org VDC networks in another Org VDC/Org VDCs.
    2. Change network configuration for all the vApps pointing to the Org VDC networks belonging to the Org vDC you want to delete.
    3. Using the following sequence and recreate the vApp Templates using the Org VDC network belonging to the Org vDC you want to delete:
      1. Add/create a vApp from the vApp Template.
      2. Change network configuration for the vApp making sure it does not use any Org VDC networks belonging to the Org VDC you want to delete.
      3. Add the vApp to the catalog creating a vApp Template.
  2. Create an Org VDC, using the Pay-As-You-Go allocation model, with the purpose of creating the objects you would like to share within the Organization such as:
    1. Org VDC Networks
    2. Edge Devices
  3. Do not share the Org VDC network within the organization. Create the Org VDC networks you need per Org VDC. If you need a routed Org VDC network for e.g. 2 Org VDCs you’ll have to create:
    1. 2 Edge devices instead of 1 Edge device if using the sharing feature.
    2. 2 routed Org VDC networks instead of 1 if using the sharing feature.

My customer liked the second option so we created a new Org VDC (Org-VDC-04) and set up the shared Org VDC networks and an Edge device. The Org VDC uses the Pay-As-You-Go allocation model with the below compute resource configuration.
Screen Shot 2013-07-30 at 18.14.57

I’m not saying you should use this option all the time but it was the best choice available for my customer to avoid the administrative challenge he faced during his vCD POC.

If and when to use the Org VDC network sharing feature must be addressed during the vCD design session to avoid the problem described in this blog post.