Upgrading vCloud Networking & Security to NSX including vCloud Director

This morning I gave an internal presentation to my colleagues about upgrading vCloud Networking & Security (vCNS) to NSX including vCloud Director (vCD), as there’s still quite some customers that need to follow up on this. In this article, you can find my remarks and key takeaways that might assist you in performing the upgrade without any hassle.

Continue reading

vCloud Director: Unable to verify the following cells share the transfer spooling area

Today I encountered an issue where, in a multi-cell vCloud Director environment, warnings were popping up in the /opt/vmware/vcloud-director/logs/cell.log:

Warning: unable to verify the following cells share the transfer spooling area.

This article describes what this means and how to fix it.

Continue reading

vCloud Director Design 0.3

Good morning everyone,

While implementing my first vCloud Director environment for testing purposes, I have created a high level design that I would like to share with the community. Hopefully this will help people understand some of the ways you can use vCloud Director to provide cloud functionality to your datacenter.

Currently my design is at version 0.3. If there would be any major adjustments, I will publish a new blog posting.

The first drawing shows the way vCloud Director uses a management cluster for the vCloud management VMs and have a separate resource cluster to deploy your VDC (Virtual Data Center) in. Next it shows how authentication is flexible for each organization you create and assign resources according to the needs of your customers.

This slideshow requires JavaScript.

The drawing below shows the communication lines from vApp inside vCloud Director to the physical networks you might have.
Internal organization traffic will be transported over the VXLAN network. The VXLAN network is, in my situation, VLAN25 and is transporting more then one organization. Because VXLAN adds extra information to the VLAN packet, it will not be possible to communicate between organizations without passing through the vCloud Edge.

Addresses used on the internal and external NICs do not have to be unique inside your infrastructure, because all of that traffic is VXLAN traffic. Communication to the external networks will always happen using the physical IP address(es) you assign to the vCloud Edge. The example I always give here is: “You have a customer that wants to move his virtual infrastructure to your vCloud environment. The customer has his own IP subnets and does not want to re-number all of his VMs. Because only IP addresses inside an VDC have to be unique, the customer can keep using his own IP addresses and use the NAT functionality of the vCloud Edge to provide physical network ‘talk’.”

External traffic also flows thru the vCloud Edge and gets NAT’ed to an IP address on the physical network and is therefor routable to the corporate network or the internet (and backwards).

This slideshow requires JavaScript.