Archive for August, 2013

VCAP-CIA objective 2.3 – Manage vSphere network resources

August 26th, 2013 No comments

The blueprint states the following skills needed to cover this objective.

  • Create and manage vSphere port groups
  • Configure vSphere network options including MTU and VLAN
  • Prepare vSphere cluster for VXLAN

The goal to manage and create vSphere port groups is done at the vSphere level. There are 2 different scenarios here, as vCloud Director could be combined with an Enterprise License instead of an Enterprise Plus license on the ESXi hosts backing the Provider vDCs we will go through the process of creating and managing port groups on both vSwitches and dvSwitches.

Let’s tackle vSwitches first. To add a part group consistently to a cluster you will need to complete the process on all of the hosts. The first step is to go to the host you want to create the new port group on, go the Configuration or Manage tab depending on the client you are using and click the “Add networking” button.


You will then be asked what kind of port group you want to add, select Virtual Machine port group. Select an existing vSwitch or create a new one. Select the appropriate uplink ports and finally assign a VLAN to the port group and name it.


You will now be able to choose this port group to create a port group backed network pool in vCloud Director.


This port group can now be managed through the Web Client. You will be able to edit the MTU on the vSwitch level of that port group. The VLAN can be changed by editing the port group directly.

Security features (promiscuous mode, MAC address changes, forged transmits), traffic shaping options and failover options can be configured on the switch level and propagated to the port group or be overridden on the port group level.


Creating a port group on a dvSwitch is actually very similar. Just click the “New Distributed Port Group” button, enter a name and configure the settings including VLAN.


To edit the port group or dvSwitch settings click on the appropriate buttons, the same principles as for a vSwitch apply (MTU on the dvSwitch and VLAN on the port group).


Information on why you would want to increase the standard MTU of 1500 can be found in the vCloud Architecture Toolkit (if the exam asks you to configure VXLAN or VCD-NI backed pools be sure to check out the MTU size of the dvSwitch you are creating).

Oddly enough the blueprint does not mention that you will need to create dvSwitches or vSwitches, the process also is rather easy. For a dvSwitch simply right click the datacenter in the Web Client and choose “New Distributed Switch”, a wizard will pop up which will ask for a name and some basic settings (Note that you cannot configure the MTU through that wizard, you will need to edit the dvSwitch settings after you created it).


The process to create a vSwitch has been explained in the top part of this post already. This leaves the task to prepare the vSphere cluster for VXLAN. This process is not described in the administrator’s guide or the installation guide. But there is a white paper and a blog post which describe the process.

VMware VXLAN Deployment Guide

To configure VXLAN the classic vSphere Client is needed as the required plugin for the configuration is not available in the Web Client.


Click the preparation link to start the configuration process.


Next click on “Edit” and choose all applicable clusters.


Choose the dvSwitch that will handle the traffic and assign the appropriate VLAN ID.


Select the correct Failerover Policy in the next wizard screen (depending on your hardware configuration) and configure the MTU to 1600.


After hitting finish the status should look like this.


If no DHCP is providing IP addresses to the Virtual Tunnel Endpoints they need to be configured manually. This can be done by using the Web Client.


Last up is setting up the segment ID and multicast address. The segment ID pool will define how many isolated networks can be created.


There should be no errors anymore after creating a provider VDC in vCloud Director now as the clusters are fully prepared for VXLAN.


Categories: Certification, VCAP Tags:

Why DNS is important … #2

August 26th, 2013 No comments

While writing up objective 2.3 I tried to enable VXLAN for my clusters and ran into the following issue.


Naively clicking on “Resolve” did not doing anything good to actually resolve it so I had a look at the tasks and events of the single hosts.


So it looks like it is failing to actually install the required agent on the host. I found this weird as the vCloud Agent could be pushed just fine, so I had a look at the esxupdate.log on one of the hosts.


It looks like the shortname of the vCenter server could not be resolved, a quick check with nslookup on the host confirmed this, only the FQDN of my vCenter could be resolved. So I went ahead and added the appropriate search domain to my ESXi configuration which actually fixed the issue as the “Resolve” button was working just fine now.


Categories: Homelab Tags:

New VCAP-CIA blueprint released

August 8th, 2013 No comments

It seems there was an update to the VCAP-CIA blueprint. Be sure to download version 2.4 from the following link.

VCAP-CIA Exam Blueprint Version 2.4

Categories: Certification, VCAP Tags:

VCAP-CIA objective 3.1 – Manage Provider VDCs

August 7th, 2013 No comments

The blueprint states the following skills needed to cover this objective.

  • Create and Provider VDCs
  • Merge or Expand Provider VDCs
  • Manage Provider VDC options

Creating a Provider vDC is described on pages 21 and 22 in the English version of the vCloud Director Administrator’s Guide. There is also a video showing the process in the kb noted below.

Creating a Provider Virtual Data Center in VMware vCloud Director

Let’s go through creating a Provider VDC step by step.

On the landing page click option 2 to open the wizard. Enter a descriptive name and choose the maximum supported hardware version which is affected by the build of the hosts in your cluster. Make sure the Provider VDC is enabled.


The next step is selecting the compute resources, namely choosing a vCenter Server and according Resource Pool to supply these CPU, memory and network resources from the vSphere layer to the actual vCloud workloads.


You will then need to add storage resources to the Provider VDC, be careful when choosing the * (Any) profile as this also includes the local datastores of the hosts which can cause problems. You can find more information on this profile in the following kb article.

About the *(Any) Storage Profile


The last step is to provide the root credentials to prepare the hosts for the use for vCloud Director.


After you click okay on the final summary page you can see the creation process in the Manage and Monitor tab.


The next 2 goals are described on the pages 45 – 51 in the English version of the vCloud Administrator’s Guide. Let’s start with merging 2 Provider VDCs. This is a very simple process you can start by going to the Manage and Monitor tab, choosing the Provider VDC option and right clicking the Provider VDC that should be the merge destination.


A wizard will pop up where you can choose which Provider VDC to merge with the selcted one.


To actually expand a Provider VDC you will need to either add compute resources which can be done by adding another Resource Pool, or additional storage which can be done by adding Storage Profiles to the Provider VDC. For both options a wizard is going to pop up and guide you through selecting the additional resources.



The last goal is to manage Provider VDC options. The vCloud Administrator’s Guide lists the following options and procedures that can be edited for a Provider VDC.

  • Enable or Disable a Provider vDC
  • Delete a Provider vDC
  • Modify a Provider vDC Name and Description
  • Merge Provider vDCs
  • Enable or Disable a Provider vDC Host
  • Prepare or Unprepare a Provider vDC Host
  • Upgrade an ESX/ESXi Host Agent for a Provider vDC Host
  • Repair a Provider vDC ESX/ESXi Host
  • Enable vSphere VXLAN on an Upgraded Provider vDC
  • Provider vDC Datastores
  • Add a Storage Profile to a Provider vDC
  • Edit the Metadata for a Storage Profile on a Provider vDC
  • Add a Resource Pool to a Provider vDC
  • Enable or Disable a Provider vDC Resource Pool
  • Detach a Resource Pool From a Provider vDC
  • Migrate Virtual Machines Between Resource Pools on a Provider vDC
  • Configure Low Disk Space Warnings for a Provider vDC Datastore
  • Send an Email Notification to Provider vDC Users

Some of these tasks or procedures are prerequisites to be able to edit other options so I will only show a few examples here. Some have even already been described above.

We will start by modifying the name and description of a Provider VDC. Simply right click a Provider VDC in the Manage and Monitor tab when selecting the Provider VDC option. Click on properties and change the settings to your new requirements.


Note that you can also change the highest supported hardware version in the renaming wizard. You will not be able to assign new storage or compute resources though.


You can disable and delete a Provider VDC by right clicking it in this view, as well as enabling VXLAN. The option to send an email notification to all Provider VDC user can also be found here by clicking the Notify… option.


When you left click on one of the Provider VDCs you get a new screen with tabs on the top. All hosts options can be seen by selecting the Hosts tab and right clicking the host. You will be able to enable or disable hosts, prepare or unprepare hosts, redeploy all VMs off from a host, upgrade the host agent or repair the host.


To edit the meta data of a Storage Profile select the Storage Profiles tab, right click the according profile and select properties. You can also enable and disable Storage Profiles that way.


You will not be able to set storage warnings in the Datastores tab, you need to choose the Datastores option on the left pane to do that as these alarms are valid for all Provider VDCs that have access to these datastores.

You can enable, disable and detach Resource Pools by right clicking them in the Resource Pools tab.


To migrate VMs to another Resource Pool choose the Open option, CTRL click all the VMs in the Resource Pool which need to be moved and choose the Migrate to option. You will have the choice to automatically select a destination Resource Pool or do a manual selection.

Categories: Certification, VCAP Tags:

VCAP-CIA objective 5.1 – Manage vCloud Director SSL Certificates

August 1st, 2013 No comments

The blueprint states the following skills needed to cover this objective.

  • Create and process certificate requests
  • Replace default certificates

SSL certificates are an absolute requirement for vCloud Director to work. You will need 2 different certificates, one for the vCloud Director Web Interface and one for the Console Proxy. There are 2 options for SSL certificates, self-signed and CA signed. The process to create the certificate requests and generate the certificates is described in the vCloud Director Installation and Upgrade Guide on pages 17 – 20 in the English version. There is also the following kb article describing the process in detail.

Generating SSL certificates for VMware vCloud Director

To create untrusted self-signed certificates simply run the following 2 commands on the vCD cell.

keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey –keyalg RSA -alias http
keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey –keyalg RSA -alias consoleproxy

This generates the certificates which are valid for 90 days by default (use the -validity parameter to set a different value).


You can list the contents of the keystore using the following command.

keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -list

You should expect to see both certificates in there.


To actually replace the certificates now you can follow the guidelines in the English version of the vCloud Director Administrator’s Guide on page 16. It is basically a 3 step process.

  1. Stop the vCD cell
  2. Run the configuration script again
  3. Provide the path to the new keystore file and passwords for the keystore and certificates


After a restart of the cell the new certificates should be loaded and accessible.


The process to create CA signed certificates is slightly different. Instead of creating the certificate itself we are going to use the key tool to create requests which have to be handed over to a CA which will provide back the actual certificate files. These will be imported to a keystore again like the self-signed certificates. The procedure to actually replace the certificates for the cell stays the same.

The requests can be creating by using the following 2 commands.

keytool -keystore certificates.ks -storetype JCEKS -storepass passwd –certreq -alias http -file http.csr
keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -certreq –alias consoleproxy -file consoleproxy.csr

You will need an existing certificates.ks keystore with self-signed certificates for the consoleproxy and http interface in it for these commands to work.


Upload these files to your CA and request the certificates. You will need to get back the 2 requested certificates, the root certificate for the CA and any intermediate CA certs if they exist. These need to be imported into the keystore using the following commands.

keytool -storetype JCEKS -storepass passwd-keystore certificates.ks -import -alias root -file root.cer
(optional) keytool -storetype JCEKS -storepass passwd-keystore certificates.ks -import -alias intermediate -file intermediate.cer
keytool -storetype JCEKS -storepass passwd-keystore certificates.ks -import -alias http -file http.cer
keytool -storetype JCEKS -storepass passwd-keystore certificates.ks -import -alias consoleproxy -file consoleproxy.cer

When the complete chain is imported you should list the contents of the keystore to make sure everything is in there.

keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -list


When everything is in place you can run the configure script as described above to actually replace the certificates. You should also import the root certificate into the trusted certificates store of the clients actually using vCloud Director to get rid of the security warnings.


Categories: Certification, SSL, VCAP Tags: