Today, however, I am excited to publish a new architecture diagram that I have been working on for quite sometime. The VMware vCloud Suite 5.x.

Before we go any further into the details, I would like to echo the same disclaimer I have on my blog since I joined VMware. The architecture of this diagram, like any other content on my blog, is strictly mine. It’s my very own interpretation of this suite of products. There is probably 100 different ways on how to represent or architect this kind of diagram. How do I know, you ask. Well, I work as a consulting architect at VMware and this is what I do, day in and day out, in the company. Speaking of which, I followed real-world scenarios from my experience with customers when I designed this diagram. It’s like a mix of many scenarios and use cases that I came across with customers. I tried to make it as rich as possible, and yet in a very high level. This is an A2 size diagram, and I can tell you that even if I tried with A0 I wouldn’t be able to have all the details I want. That said, you can’t see in this diagram any technical deep-dives into the technologies like what you are used to in my traditional diagrams.

Back to the main point, and to make a long story short: Your mileage may vary.

http://www.hypervizor.com/wp-content/plugins/download-monitor/download.php?id=19

How to find your way around the diagram?

The diagram consists of three main areas. The first area is the huge architecture in the middle, which is flowing form the bottom of the page to the top. This is really the meat and potato of the diagram and the one we will spend most of this write-up describing.  The second area is the on the right, titled: “Software-defined Datacenter”. This is, as stated on the diagram, a bunch of examples and not a limitation of the SDDC concept (again, as I personally interpret it). I divided this into three main sections – Software-defined Network, Software-defined Storage and last but not least, Software-defined Security.  Now the last part of the overall diagram is the one on the top. These are the small gray boxes you can see with short descriptions of the vCS components. I know, it’s pure marketing and it is actually a copy and paste from the official VMware website. The reason why I included this is because I want any CxO standing in front of this busy diagram to understand (even in a very high-level) what is going on there.

The architecture

Now let’s dig dipper into the actual diagram architecture.

My preferred way to look into this is from bottom to top. You may have already noticed by now the layered-cake approach (if you will) that I followed in the diagram. These layers are starting from “IT” at the bottom of the diagram all the way up to “Public Clouds”. You can also see the dashed lines starting from each layer and fading into the actual diagram to indicate that anything that resides between those lines belong to the designated layer from left to right.

Now into each layer in details:

-       IT: these are basically the IT personnel at your organization. Be it management, operations or infrastructure teams. As you can imagine, this could significantly be different from one organization to another. What I have tried to illustrate here is some various role-based responsibilities and how would that map to the vCS products. For example, an Enterprise cloud admin would have access, of course, to the vCloud Automation Center and vCloud Director admin panels. That doesn’t mean that he/she shouldn’t access the vCenter Server/Web-Client. It all boils down to how your IT is structured.

-       Products: These are some (not necessarily all) the vCloud Suite products. Now one very, very important thing to note here is that these products are not explicit to the datacenter they are residing at. They are placed in this order for illustration purposes only. In fact, they could be common across datacenters. For example, you may have vCenter Operations running in the primary datacenter only but monitoring remotely all the infrastructure components in the secondary datacenter.

-       Physical/Virtual Infrastructure: that’s basically your server, storage and networking hardware along with your virtual infrastructure software including but not limited to: vSphere, Hyper-V, Xen, KVM and so forth. All these resources are endpoints managed and controlled by/through the vCloud Automation Center (vCAC). That’s why you see all these crazy arrows initiated from vCAC and terminated at each end-point.

-       Private Cloud(s): Here you can see the actual cloud(s) in the final presentation. In this example, I have showed three different clouds – the IaaS, the PaaS and the Test/Dev. Why three clouds not one, or four? As I mentioned earlier, this is just an example and your use case will vary. One VMware customer would be interested in having only one cloud for IT as a Service. Another customer, like the one here, would require a Platform as a Service, perhaps for rapid application development, and also a test cloud for application testing, evaluations or sandboxes. You can see that the IaaS cloud is consuming resources from a vCloud Director cluster. This could be in your case a native vSphere cluster. Everything is just an end-point for vCAC and it is your ultimate choice where you would want your workloads to run and how. Another very important component here is the vCloud Connector (vCC). The vCC has many great features and use cases. In this particular architecture, you can see that it is being leveraged to migrate workloads on-premise (across the IaaS and Pass clouds) and off-premise to public vCloud providers. It also facilitates a stretched deployment from the on-prem IaaS cloud to an off-prem vCloud provider. Another great feature that vCC has, and not shown here, is the catalog synchronization across clouds. For example, you could have another independent IaaS cloud running at your secondary datacenter but you would like to keep your catalogs across the two clouds in sync.

-       End-User Access: Moving up the stack you can see the end-users and how would they typically access the workloads on the various clouds. For example, in the IaaS cloud, an end-user could access his/her workloads either directly through RDP/SSH, or through the vCD portal (to manage his own networking, security..etc), or through the vCAC self-service portal for requesting workloads through workflows and corp governance. Again, you have the maximum flexibility here to design your cloud as you want. Mixing and matching different ways for different users are possible here to meet your business objectives and yet with the full control and governance per the corp guidelines.

-       Public Clouds: Last layer in our stack is the public clouds. As the diagram suggests, this could be a vCloud Datacenter Service Provider, the newly launched vCHS (available in the US only at the time of this writing), or a 3rd party public cloud like Amazon EC2. To give you few examples: the corp could have a policy to allow specific end-users to run some workloads on EC2, those users can instantiate workloads right from the corp vCAC portal and, of course, go through the relevant approval workflow. Another example would be related to an internal application that is growing faster than expected and no immediate resources are available on-prem to accommodate this growth. In this case, an enterprise cloud admin could extend this application to a public vCloud provider and yet keeping the same networking/security features enforced.

So there you have it. My latest and very humble attempt to picture the most powerful VMware suite of products to date!

First, let’s start with the holistic view.

Diagram

This is an overall illustration showing the products mentioned in the subject and how they relate to each other. In the next few sections I’ll talk briefly about my experience with each item and then wrap up with a conclusion on how I was able to benefit from this micro-project in the real world. Let’s get started!

Making the Wave

WaveMaker (WM) is one of the products that really impressed me from the first look. Coming from a web development background, I can tell you that a tool like this would have been instrumental for me when I used to build complex web apps in the old days. You literally drag and drop items here and there and voila! You have a fully functioning web application.

I used WM here to build the application interface and multi-tenancy (i.e. accounting and authorization) as a starting point. I didn’t write a single code in this part, everything is visually available for you to drag, drop and run. That’s it. As you can imagine, this was the easiest part of the whole project and I wouldn’t be exaggerating if I told you that it was done in a matter of minutes.

A sip of Java

Now to the tricky part. More than 15 years ago I used to call myself a programmer. I used Basic, Pascal, C, C++ and then figured that it’s not really my thing. Few years latter to that I found myself dragged by force into the WebDev and hence started learning PHP with mySQL. Again, it wasn’t my area of interest so I stopped and promised myself that it will be my last attempt to learn anything in the programming/scripting world. Of course I was wrong.

I started learning about Java about 2 weeks ago! It was really a very, very fresh start since it’s been years without practicing to write a code. Despite that, I was able to find my way through to build some java methods and use them in WM. Let me explain in a bit detail here.

WM comes with a quite rich “Services” that you can inject in your project and one of which is Java. All you need to do is to inset a new Java service in your project, write your own methods and then call them within the app. Since I was quite fresh with Java and was as good as a newbie to this world, I found the Java SDKs of vCloud Director to be all what I need! I used also here the SpringSource Tool Suite (STS) to test my Java code before porting to WM. Of course I could have used any other IDE like Eclipse or NetBeans but I just wanted to stick with the VMware tools here. Note that switching between WM and STS is quite easy and straight forward. You just need to create a new Java project in STS with the WM sources, do your java coding/testing and then go back to WM and “refresh” your service to pickup anything new you have applied.

Pushing to the Cloud

A working App without a solid foundation to run on is useless. There are many options/places to run my app in but what else would be better than the amazing Cloud Foundry? You literally need to type a “vmc push” command and your app will be in the cloud in a minute. Now, how cool is that?

Prior to pushing my app to CF, I wanted to have a taste of the MicroCloud as well. It’s a complete CF platform running in a VM! You just need to download it and run it in Workstation/Fusion and then test your application exactly as if you were pushing and running it on CF.com. After doing all my trials on the MicroCloud, I pushed my app to CF.com, created a couple of instances with another one-liner and that’s all. My app is running now in the cloud http://cloudwave.cloudfoundry.com

Putting it all together

When I first started creating this app, it was really just for fun. I call some Java methods in the app to go and grab specific information from a vCloud Director environment and return it back in a form of data grids. Now, these vCloud environments are actually real public clouds that I’ve built for customers and they were kind to keep an access for me to them. The application is multi-tenant as I explained earlier, so I can login either as an Admin to view all my clouds, or as a vCloud owner who can only see his/her own environment and call information from it. At the time of writing these lines, I have three public clouds and one private/home cloud registered in the app where I can live-grab information from them and show back in my UI. Here is a simple screenshot.

Conclusion

Now to my favorite part in the whole article. I was doing a vCloud engagement this week for one of my customers and while we were in the middle of the discussions they challenged me on how easy or hard it is to leverage the vCloud APIs for integrating with their own portal. In fact, I always get this question in my vCD engagements especially with Service Providers and I normally talk in high level since it’s not in the scope of the project. This time, I had a better story to tell my customer. In fact I didn’t even talk, I just fired-up my browser, opened my CloudWave application online, logged in, and then pulled live information from the customer cloud to the application. I then looked back at them and said “I built this app with no programming experience, and just during this week in my spare time!”

Every single thing you’ve seen in the diagram or read in the article is a VMware product or technology. Even better, it’s FREE! You can go ahead and download WM or STS for free and play with them, you can download the MicroCloud and run it for free on your PCs/Macs. You can register an account, again for free, on CloudFoundry.com and start pushing your apps to the cloud. You can download and use the vCloud SDKs (be it Java, PHP or .NET) and start coding your own apps leveraging the examples included in the kits.

Teaser

I took it up a notch this morning and decided to go crazy. I’ve built my own Cloud Foundry platform from the scratch on one the public vClouds that I’ve built for a customer. It’s up and running at the time of this writing and I’ve just pushed my very first app to it. Stay tuned for more details soon. http://www.myvcap.com/

So, that being said, those diagrams are far from being complete or perfect. Just accept them as they are and I will keep trying to adjust and complete the missing pieces.

Few notes on the diagrams:

• As you notice, there are two diagrams here covering the same topic but one is focusing on the private cloud and the other on the public side.
• There are many items that can overlap between the two diagrams. You can mix and match what you see relevant to your environment. The things are organized the way they are just to fit everything nicely in the limited A3 size.
• I focused in the Public Cloud diagram on the portal exposure to the Internet since it’s a (somewhat) complex topic and requires proper illustration (I blogged about it in details here).
• For the Private Cloud, I focused more on the management and monitoring aspect but make no mistake, these are as quite important for a Service Provider in a public cloud! Again, I’m just trying to fit so many things in so little space.

That’s it from me today.

Public Cloud Management Pod:

Private Cloud Management Pod:

I’ve tried to simulate this in one of my public vCloud accounts and I wanted to share with you these two methods in case they are of any interest to others.

Remote access from Windows machines:

I’ve used here two free tools in order to access the Linux GUI remotely. The first one is my favorite SSH client, Putty. This is to initiate the ssh connection to your VM in the cloud. The second tool is called Xming and we will use it here to forward the X-Window traffic. You need to download and install both the Xming and Xming-fonts utilities.

After the installation is done, all what you need is to fire-up your putty client, and set your SSH connection as follows:

in the Connection -> SSH -> X11 panel click on the “Enable X11 forwarding” check box and put “localhost:0″ in your X display location. Now start the SSH connection and when you are there in the Linux shell you can either launch the GUI application directly (e.g. firefox as shown in the screen shot below) or launch a complete Gnome / KDE session by issuing the commands gnome-session / kdestart respectively.

Remote access from an iOS device (iPhone or iPad):

In this method i used a paid App called “iSSH” since i already have it installed in my iPhone/iPad. You simple need to download the App to your iOS device and setup your SSH connection. once you are at the Linux shell, you also need to run your GUI app and then click to the “X” icon to see the display. Make sure to enable the X-Window in the App after you install it since it is switched off my default.

The iPhone Screenshots:

The iPad Screenshots:

So what is the catch here?

As you may have already noticed, you can only use these two methods if your VMs are connected to an external network (direct or routed). If your VMs are isolated, there is no way to access them remotely. Your only option will be the native VMRC through the vCloud portal.

In this post I will cover both the architecture considerations as well as the technical configuration from my experience in a real-world implementation. You have to keep in mind though that there is no one solution that fits all requirements, however, there are always some common guidelines and that’s what I will try to cover here.

Quick introduction

As you already know, a vCloud Director cell provides two services for end users to self-provision and access VMs in a cloud. We will refer to the first service here as “HTTP” and the second one as “VMRC”. The former is obviously responsible for providing the web portal and the latter for accessing the remote console of the VM running on the ESX host even if it doesn’t have any networking set for it.

Architecting your solution

There are two approaches here for publishing the vCD portal on the internet. The first one by connecting your HTTP and Console Proxy interfaces to the DMZ, and the second one by putting a reverse proxy in front of the Cells to handle the https requests back and forth (but not the VMRC). I intend to blog about the reverse proxy solution in a future post so we will focus here only on the first approach.

First thing first, you need to have at least three network interfaces on the vCloud Director cells:

• the first one for the HTTP service
• the second one for the Console Proxy service.
• the third one for the back end communications with the management network e.g. vCenter Server, ESX hosts, NFS shared mount and so forth.

This is a diagram showing you in details the complete architecture that we will talk about throughout this article.

As you see, we have the first and second network adapters connected to the DMZ network which is typically a port-group set on your Management Pod ESX hosts and either segmented with a VLAN or dedicated network cards depending of course on your network and security infrastructure.

As we mentioned above, the third network card on the vCD cell will be communicating with the management network. You have another two options here:

• The first option is to connect this to the same management network port-group in your ESX host, the one that is also serving the vCenter Server, database, NFS ..etc.
• The second option is to connect this interface to a new port-group/VLAN that is being routed through a Firewall to your management network.

The reason being for the second option is that if your vCD cell is compromised on the Internet, the intruder will be still facing another firewall to access your internal management network. In my article here I will adopt the second option since it is the most secured architecture.

Here are an examples on how the networking would look like on a Management Pod ESX host.

The Linux Routing

As illustrated in the diagram (and the vSS/vDS screenshots), we have three different networks for routing the traffic. The first one is the external perimeter network (typically the DMZ), the second network is the internal perimeter network, and the third one is the management network for the vSphere substrate. The common question or confusion here is around the routing. How would the Linux OS decide on the routing paths to the upstream DMZ and the downstream management traffic? And the answer to that is just some basic static routing. Let’s have a closer look.

Firstly, you need to set the IP addresses facing the DMZ with a default gateway. In our case here the IPs for the two cells are (192.168.25.11 / 12 / 21 /22). The default gateway for them is (192.168.25.1). Secondly, for the management network, you need to set the IP address without a default gateway and then set a static route for that network. You have to note here that we will need to have a persistent entry for that route in order to retain the configuration should the cell be rebooted or shutdown for any reason. To do that, you need to add the following entry to the /etc/sysconfig/networking-scripts/route-eth2 file:

GATEWAY0=192.168.20.1
NETMASK0=255.255.255.0
ADDRESS0=198.18.5.0

Let’s quickly explain that. First of all, the file name mentioned above may be different in your case if you are using another order for the vNIC assignment (also note that we are using here a RHEL distribution). In my case, the eth0 and eth1 are assigned to the HTTP and Console Proxy services respectively. The third vNIC, eth2, is set for the management network which we are setting the static route for here. The other entries are self explanatory. The Gateway0 is the firewall IP address that will route our traffic from the Internal perimeter network to the management network. The Address0 and Netmask0 are for the destination management network we are routing the traffic to.

After setting these entries, you will need to restart the networking service and then test the connectivity like pinging the vCenter Server IP address from the Cell shell (sounds like a biology lesson!). After that I recommend to reboot the cell and see if your configuration is still persistent to avoid any issues in the future.

Okay, so now that we have the network all set for our traffic flow, you will need to install the vCloud Director software. When you run the configuration script, you will be asked which NICs you would like to assign to which service (HTTP and VMRC). Just make sure you set that properly.

The SSL Certificates

Depending on your case, you might be using a signed or self-signed certificates for your vCD portal. Each has a slightly different configuration approach the I intend to blog about in details in the future. Meanwhile, I’d highly recommend that you checkout this excellent blog post by Chris Colotti for the high level considerations on the Certificates as well as some great tips on the cell Load balancing.

The Load balancer

First of all, you will need to have two public IPs assigned to you and set on your public DNS servers to resolve to the relevant host names. For example, I’m using these two entries in my diagram:

• vcloud.provider.com -> 11.11.11.11
• vmrc.provider.com -> 22.22.22.22

Of course these are fictitious IP addresses just to show a real-world configuration example end to end. Now it’s time to set your load balancer to point each IP address to distribute the load across the cells as illustrated in the diagram. If we look at a simple traffic flow for the HTTP service it would be as follows:

• The end-user fires-up his browser and point the URL to vcloud.provider.com
• The hostname gets resolved into the public IP 11.11.11.11 and hits the Load balancer external interface.
• The LB then distribute the traffic through its internal interface to the cells IPs (192.168.25.11 and 192.168.25.21).

Note that in our example here we are using a path-through SSL traffic example for the LB.

If you are wondering about the VMRC traffic flow and how it is different from the HTTP service, you can have a look into this great two-part blog post by Michael Hines.

Setting the public address fields in the vCD admin panel

Now to the important part that most of us forget to set. You will have to configure the relevant host names in your “Public Addresses” section in your vCloud Director Administration panel.

As shown in the above screenshot, there are three URLs:

• The vCD Public URL: this will be reflected in the Organization URLs set for your customers access to your cloud.
• vCD public console proxy address: this will be used when the customer clicks on the VM console to access his VM on the web. If this is not set, the cell will use the private IP address which will obviously fail for the user accessing the portal on the Internet.
• vCD public REST API base URL: this will be used for all the functions depending on the APIs. One of which is the end-user uploads of ISOs/templates to the cloud. This one gave me a bit of a grief where I didn’t set that entry properly and had all my uploads failing (again because the cell will use the private IP if this field is empty).

The Network Ports

Last but not least, you have to understand the right network ports that is used in your entire vCloud environment. I have published a detailed KB Diagram earlier that you can grab from here: http://kb.vmware.com/kb/1030816/

You will need to work with your network/security team to open the ports between your different zones. Please note that (at the time of writing this post) there is a small mistake in the ports listed in the diagram. The vCD and ESX hosts do not communicate on port 22 and port 80. Also vCD talks to vSM on port 443 and vSM talks to ESX on port 443. This will be updated very soon on the KB.

I hope you found this article useful in planning and publishing your portals. Happy vCloud’ing!

I’ve blogged already about NetFlow with VI3.5 in this blog post, and I explained how you can configure it form the command line on an ESX host to push the Netflow data to an external collector/analyzer.

The cool thing is that now it is fully supported in vSphere 5.0 and it can be configured also right from the GUI. Let’s have a quick look first on this.

Configuring NetFlow on the vNetwork Distributed Switch

1 – You will need to go to your networking panel in vSphere 5.0 and choose the vNetwork Distributed Switch (vDS) you want, and then right click and choose “Edit Settings”

2 – Go to the “NetFlow” tab and then fill the required fields as shown in the screenshot below.

3 – The first field is the NetFlow collector/analyzer IP address and the relevant port it will be listening to. The second field is the vDS IP which I must say can cause a lot of confusion. This doesn’t have to be a real IP address, it’s more of an identifier, if you will. This IP address will *not* be attached to any ESX vNIC. Think of it as if you are sending an email to someone with “your name” in the sender field so that the recipient knows from where it’s coming from. It’s important in our case here because you will probably have many ESX hosts in the cluster, each sending the data to the same collector. The unified IP address here is meant to tell that collector that all these data are coming from the same source/router rather than different ones.

4 – The rest of the settings are self explanatory and aimed to tweak the NetFlow exporting settings. Just keep in mind that if you set the “Sampling rate” to “0″ the sampling will be disabled and you will be pushing all the traffic stats. This is of course the most accurate results you will have but in the same time it may require more resources from the ESX hosts in a busy network environment.

5 – In our case here, we are typically selecting the “External Networks” vDS which will have the external traffic of the customers/tenants in the SP (typically out to the Internet or their Site-to-Site VPN)

6 – Last step is to enable the NetFlow monitoring on the designated ports, up-links or port-groups. In our case here, I enabled the monitoring on a port-group which is in effect an external network for a pool of customers.

Use cases for a vCloud Service Provider

I’ll list below some of the use cases for a Service Provider applying this in their vCloud environment:

• Traffic Reporting: Some end-customers would like to have a “live” traffic statistics for their cloud. With something like “NetFlow Analyzer” from ManageEngine (one of my all-time-favorites) , the SP can facilitate that to its customers. A scheduled reports can also be set to push the traffic statistics to each tenant based on his Organization Network.
• Bandwidth Utilization: a customer may want to have a capped bandwidth for his/her cloud external networking or at least a notification if they exceeded a specific quota. With NetFlow (and again NF Analyzer) you can set specific thresholds so that the customer get notified if they exceeded a certain bandwidth per day/week/month ..etc.
• Security: Through the NetFlow properties like (Protocol, Source and Destinations ports), a Service Provider can generate some security related reports like suspicious virus traffic. If you want to have a more accurate results, you can also leverage the Port-Mirroring feature in vSphere 5.0 (will talk about it in a future post)

  

• DoS attacks: With NetFlow, a Service Provider can easily identify internal DoS attacks that may be launched between a tenant and another across Organization Networks or shared External Networks.

What about the Enterprises and Private Clouds?

Similar use cases can be also considered in an enterprise or a private cloud. For example, a developer may want to analyze the internal or external traffic of his applications in the cloud. A Networking/Security team may want to have a visibility into a cloud environment for troubleshooting, security, auditing (you name it) and with a tool like this, it’s quite easy and very effective to achieve that.

Conclusion

Leveraging the NetFlow support in vSphere 5.0 with 3rd-party collectors/analyzers can be a of a great benefit to any Service Provider. I’ve personally managed various ISPs in the old days and I know for a fact that with a simple protocol like NetFlow I was able to not only have the required visibility in my environment, but also have a very effective tool to monitor and troubleshoot any problems. Of course you can still leverage expensive and high-end solutions like IPSs or traffic-shapers with a lot of administration and redesigning of your network infrastructure to have the inter-VM traffic visibility, but everything has its limit at the end of the day.

It’s been like what, six months now without blogging?! Now that’s something not cool and I really need to do something about it. The thing is, I’ve been involved in a lot of cool stuff internally at VMware and a lot more projects that I’ve learned so much from. It will all come back and reflect on my future blog posts in a way or another, so I can’t really complain!

But I’m not here to talk about that. I’ve just came across something really cool and I wanted to share with you right away.

Out of the blue, and while I was doing some geeky stuff with WAMP, ColdFusion and the vCloud PHP APIs, I’ve received a ping back from another blog with a title called: “Drawing Network Diagrams like Hany Michael”

What!! Are you kidding me?!! Am I really that famous!!

Ok, jokes aside. The blog post is so insightful that I really liked it a lot. I don’t necessary call then “Rules” as the author described them, but I agree with the vast majority of them. For example, in rule number 3 I personally think that the “right-angle” lines are so ugly in 99% of the cases, but everything has a use case. I just haven’t came across that one yet.

Anyways, I highly recommend reading that article and don’t forget to grab the .VSS stencils file provided by the author. As a matter of fact, I’ve learned a new trick from the “Cloud” shape! I just enhanced it a bit to look like that:

P.S. thank you Jake, you just made my day

I did some trial and error experiments in my lab until I reached some good results that I thought I’d share with you through this blog post. So, with all that being said, I’d highly recommend trying this in your lab thoroughly before applying in production. To the best of my knowledge, everything you will see here is supported, however, you have to use with caution.

A high level overview.

I won’t go into the detailed benefits of vShield Edge/App and how they are two solid networking and security solutions. I just want to give you a glimpse on what you can achieve/expect from integrating them with vCloud Director:

• By adding the Load Balancing functionality of Edge, you can have simple (yet very powerful) load balancing for web applications in your cloud. The LB is currently limited to http but you can expect more protocols to show up in future releases (Hey, don’t qoute me on that . I will show you in details how to configure this in vCD/vSE later in the post.
• By adding the VPN functionality of Edge, you can do things like site-to-site VPN tunneling using IPsec. I will have a detailed blog post on this interesting subject soon.
• Adding the vShield App functionalities will give you another great tools like traffic visibility that you won’t normally have in these sophisticated inter-VM-networking. Think of it like NetFlow but with new ways to reach very deep levels of Org/vApp networks. You can also do some application level firewalling or even apply them on the vCD External Networks level to enforce some global security policies across all of your tenants. (I will talk about that as well in details in future posts).

First thing first. Licensing.

Before you can test anything here, you must have the appropriate licenses for vShield Manager. Remember, I’m referring here explicitly to the Edge and App (Endpoint is out of my scope here). You will need to get your licenses and apply them first in vCenter Server. This can be done like any other vSphere licenses. You have to note though that these licenses can be applied only after you associate your vCenter Server with the vCloud Director.

Preparing vShield Manager.

After applying the required licenses, you need to go to your vSM web portal and login with your user/pass (admin/default). Once you are there, click on Setting & Reports on the left panel, and then press on the Register button on the right side to register your vSM as an extension in vCenter Server. (Screenshot below)

After registering the vSM extension in vCenter, you will find a new icon in the “Solutions and Applications” tab. In addition to that, and in fact what interest us here, you will find two new tabs called “vShield Edge” and “vShield App” as shown in the screenshot below.

Installing and configuring vShield App

Although you can see the “vShield App” tab present in vCenter, you won’t be able to use anything there until you install the vShield Zones component in vSM. You do that but returning back to the vSM web portal (or now in the vCenter Solutions and Applications section), and selecting your ESX hosts that are present in the “Datacenter” list. On the right side, you will find the link to install the vShield App on the designated host. The setup is pretty straight forward, you just need to enter the IP settings and choose the appropriate datastore and network for storing/managing the appliance. (screenshot below).

Now to the real fun!

Okay, so now that we’ve taken care of all these pre-requisites to license and install the Edge/App components, it’s time to put them in action. I’ve tried to continue using screenshots for the procedures, but I found that really hard. I compiled instead this video (kind of quick and dirty) to make it easier and better to follow.

You can right-click on the image to save the high-resolution video. You can also view the video on You Tube or Vimeo.

And this is a quick illustration showing the setup in the video. We have an Organization called “ITDev” with an organization network which we created under the name “OrgNet-ITDev-Routed_LB”. This OrgNet is routed to an external network with the subnet 172.30.0.0/23.

Important notes

These are some of the notes that I’ve taken throughout the process of testing this integration:

• It is very important to note that you should *NOT* mess with the Firewall and NAT tabs of the vSphere/vShield Edge panels. Anything you can do inside vCloud Director, keep it there. The moment you start to mix things with each others, you will end up with a huge mess, and probably a broken configuration. Remember, the only objective of this post is to empower your cloud with added features that are not currently there in the vCD GUI. We are not trying here to replace the vCD portal with the vSphere Client!
• Make sure you have Abobe Flash Player installed and configured properly with your IE browser. I used here a remote lab to test and configure all that, and while in my initial phase, i had a quite hard time working with the vShield Edge screens. Nothing seemed to work and things used to freeze. After a lot of looking here and there i figured that Adobe was not installed on IE (i use Firefox to access the vCD). Once the Flash Player was installed and configured with IE, everything worked just fine.
• I mentioned earlier that you need to associate you vCenter Server first with vCloud Director in order to be able to apply the vShield Licenses. Make sure also after that to apply the full licenses of Edge in vCenter as it might be still using the basic vSE licensed features.
• DNS, DNS, DNS and D.N.S.

That’s all folks. I will come back with more posts on this subject when I have the time to touch on the vShield App use cases, as well as the VPN features inside vCD.

Although there is no way to renew this SSL certificates from the vCD GUI, the process is fairly easy using the command line. Here is the steps I’ve taken to renew the certs on my lab:

1) First thing you need to stop the vCD cell service. The command for that, using root account, is “service vmware-vcd stop”.

2) Next, you need to run the configuration script once again. The command is “/opt/vmware/cloud-director/bin/configure”

3) Once the script starts, it will ask you for the SSL certificate. You have to identify the name of the file and then enter the required passwords.

4) You accept the question asking you if you want to start the vCD service again and you are done.

The easiest way to check on you new certificate renewal is to fire up your web browser and go to the vCD portal. Once there, you should have the security warning asking you to accept the new cert. In my case this is how the new cert looked like:

It’s important to note here that you need to apply the same changes on all your cells if you are running a multi-cell vCD setup. You may have noticed also that this certificate changes will require a minor downtime, so you have to plan for that as well.

While playing with VMware vCloud Director during the beta phase, I came across some interesting points that I documented in my OneNote. One of these points that always confused me is the required DNS field when you create a new Organization Network. Have a look on the screenshot below.

If you look at it from a “Private Cloud” perspective, it makes perfect sense to have this field as a requirement. Why? because your cloud admin will be more or less involved in the infrastructure services. As I always like to say, the cloud admin doesn’t live in his own island isolated from anything else in the enterprise.

Now, if you look at the same thing but from a “Public Cloud” perspective, this can make you scratch your head. Why would the service provider be involved in the internal services of an organization like DNS? How can a SP even know the IP address of the DNS for an Org that is just getting it’s cloud up and running? Furthermore, what if the Organization want to change this IP for any reason in the future?

I researched our internal mailing lists on this point, and I did find that one of my colleagues brought this topic up. The response was simple, this is a small bug that will be fixed in a future update of vCD.