Home > Blogs > VMware Consulting Blog > Monthly Archives: May 2014

Monthly Archives: May 2014

Cloud Automation Requirements from the Field

By Jung Hwang, Enterprise Solutions Architect, VMware

Jung HwangIT organizations adopt private cloud solutions for two main reasons: to gain agility and to improve efficiency of the services they offer. VMware’s vCloud Automation Center (vCAC) solution offers workload lifecycle capabilities that help IT organizations automate and centrally manage IT tasks that were traditionally done manually. Although vCAC has robust out-of-the-box (OOTB) capabilities that address many of these manual processes, enabling business and IT logic on top of the OOTB capabilities has helped many of our customers to reach their goals and realize the true value of automation. Below we’ll explore three requirements we have seen enabled on top of the vCAC OOTB capabilities.

Generate Custom Host Names
Although this seems to be a straightforward process, maintaining consistent host names can be challenging, especially in the private cloud environment where the virtual machine provisioning is automated without any IT staff’s involvement.

Within vCAC, administrators have some ability to add a prefix and a suffix to host names, but many customers need more custom fields, such as the environment (Prod/Dev/QA), type (Application/Web/DB), location (NA/EMEA), and incremental numbers (00X). (For example, a host name could be PROD-SQL-NA-001.) Every customer has a unique naming standard – because of this, VM host name assignment should be automated in vCAC to further minimize the manual intervention.

Active Directory Organization Unit (OU) Placement
Related to the host names issue, vCAC can integrate with Active Directory and will place VMs in a default computer object container within Active Directory. Our customers often have complex Active Directory Organizational Unit (OU) structures. Based on the host name assigned by vCAC, customers want to place the VM in the specific Active Directory OU. This will minimize unnecessary steps required to associate automatically provisioned VMs by vCAC. Moving VMs from the default computer object container to other containers can be as easy as a drag and drop operation, but when 10s or even 100s of VMs are provisioned via a self-service portal, placing a VM to the right OU based on the host name becomes an important task.

Configuration Management Database (CMDB) Integration and Configuration Item (CI) Management
Another common requirement is integrating vCAC with CMDB. Traditionally, updating and maintaining CIs were manual tasks, but they would be extremely difficult to do manually in a private cloud environment when VMs are provisioned and decommissioned based on the policy. The consumer of the vCAC solution will also be able to make changes with VM specifications so the integration with CMDB is another important area. Since the VMs will be requested via vCAC, vCAC can capture the VM specifications to create and update CIs in CMDB. The integration and automation can be enabled during the provisioning (when VMs are initially deployed), management (when VM specifications are changed by the owner), and decommissioning (when VMs are deleted).

The key to success and further identifying automation opportunities is understanding the customer’s end-to-end processes and translating them to new, private cloud processes. As we listen to our customers we can bring them more of what they need.

Jung I. Hwang is an Enterprise Solutions Architect and a member of VMware’s Services organization. Jung is responsible for creating solution roadmaps and execution plans with VMware’s products and services portfolio to solve customers’ business and technology challenges and initiatives.

Practical Tools from VMware Consultants: Mobility Policy, Horizon + Lync Architecture, and vCOps Dashboard

Our goal on the VMware Consulting blog is to share best practices that have delivered results for our customers, in hopes that they will help others be successful with VMware offerings.  Once in a while we like to highlight past posts that our readers have found particularly valuable. Last month, we published three such pieces — with great, practical advice to help you in your daily work. Just in case you missed them, we hope you find them useful. And if you’re already putting them to use, be sure to leave comments for our consulting authors. Feedback helps us bring you more of what you want to read!

How to Set Up a BYOD/Mobility Policy
By TJ Vatsa, Principal Architect, VMware Americas Professional Services Organization

Architecture Overview: Microsoft Lync with VMware Horizon View
By Ray Heffer, VCDX #122, VMware EUC Architect

Create a vCOps One-Click Cluster Capacity Dashboard, Part 2
By Sunny Dua, Senior Technology Consultant, VMware

vCloud Automation Center 6 Certificates A to Z

By Eiad Al-Aqqad, Senior Consultant, VMware Professional Services

Eiad Al-AqqadWhile working on delivering vCAC 6 engagements, I have noticed that getting all the required certificates in place has always involved jumping across different information sources, from VMware documentation and blogs to other consultants’ work. I have created the following guide to make the process easier. This is the first of three posts that cover the certificates process for a new vCAC 6.x installation from A-Z, beginning with how to install your own CA and continuing through assigning the certificates to each component.

First, I have to give credit where it is due. This document includes information from the following sources:

While I have used a lot of material from the above sources, I have also applied these steps at various customer sites, and carried out the full process in my lab. I hope you will find it useful.

Before You Begin
There are some important recommendations and requirements before you get started.

  1. VMware recommends a domain certificate or a wildcard domain certificate for a distributed installation.
  2. The certificate must be in PFX (for Windows) and PEM (for Appliances and Load Balancer) formats. (See table below.)

Certificates needed

While this post focuses on generating and using certificates for a new vCAC 6 installation, if you have an existing installation and vCAC 6 setup and you want to replace your self-signed certificates with signed certificates, you need to consider the following:

  1. Update components certificates in the following order:
    1. Identity Appliance
    2. vCloud Automation vCenter Appliance
    3. IaaS components

Note: With one exception, changes to later components do not affect earlier ones. For example, if you import a new certificate to a vCloud Automation Center Appliance, you must register this change with the IaaS server, but not with the Identity Appliance. The exception is that an updated certificate for IaaS components must be registered with vCloud Automation Center Appliance.

The table below shows registration requirements when you update a certificate.

Registration requirements

Step 1: Installing Domain CA
This section documents how to create the Domain Certificate Authority that you will later use to generate your certificates.

      1. In the Select Server Roles screen, click to select Install Active Directory Certificate Services.Select Server Roles screen
      2. In the Select Role Services screen, click to select both Certification Authority and Certifications Authority Web Enrollment.
        Select Role Services screen
      3. In the Specify Setup Type screen, click to select Enterprise.
        Specify Setup Type screen
      4. If this is your first CA, in the Specify CA Type screen, click to select Root CA.
        Specify CA Type screen
      5. In the Set Up Private Key screen, click to select Create a new private key.
        Set Up Private Key screen
      6. In the Configure Cryptography for CA screen, make the selections as shown in the below screenshot.
        Configure Cryptography for CA screen
      7. In the Configure CA Name screen, type in the name of your CA.
        Configure CA Name screen
      8. In the Set Validity Period screen, use the drop-down menu to select the appropriate period for the certificate generated by this CA.
        Set Validity Period screen

Step 2: Creating vCAC Certificate Templates
To allow for export of the certificate key, you need to create a non-standard certificate template, which is a modified copy of the standard web server template. In addition, the Microsoft CA will be updated to allow for Subject Alternative Names (SANs) as specified in the attributes.

To create a new, non-standard default template:

      1. Connect to the Root CA server or Subordinate CA server via RDP.
      2. Click Start > Run, type certtmpl.msc, and click OK. The Certificate Template Console opens.
      3. In the middle pane, under Template Display Name, locate Web Server.
      4. Right-click Web Server and click Duplicate Template.
      5. In the Duplicate Template window, select Windows Server 2003 Enterprise for backward compatibility.
      6. Click the General tab.
      7. In the Template Display Name field, enter vCAC Certificate as the name of the new template.
      8. Click the Extensions tab.
      9. Select Key Usage and click Edit.
      10. Select the Signature is proof of origin (nonrepudiation) option.
      11. Select the Allow encryption of user data option.
      12. Click OK.
      13. Select Application Policies and click Edit.
      14. Click Add.
      15. Select Client Authentication.
      16. Click OK.
      17. Click OK again.
      18. Click the Subject Name tab.
      19. Ensure that the Supply in the request option is selected.
      20. Click the Request Handling tab
      21. Ensure that the Allow private key to be exported option is selected
      22. Click OK to save the template.


To add a new template to certificate templates:

      1. Connect to the Root CA server or Subordinate CA server via RDP.
        Note: Connect to the CA server in which you intend to perform your certificate generation.
      2. Click Start > Run, type certsrv.msc, and click OK. The Certificate Server console opens.
      3. In the left pane, if collapsed, expand the node by clicking the [+] icon.
      4. Right-click Certificate Templates and click New > Certificate Template to Issue.
      5. Locate vCAC Certificate under the Name column.
      6. Click OK.

A new template option is now created in your Active Directory Certificate Services node. This new template can be used in the place of Web Server for the vSphere 5.x CA certificate.

Step 3: Installing OpenSSL version 0.9.8.
Use the following steps to install OpenSSL, which will be used to request the required certificates.

Important: Ensure that you are using OpenSSL version 0.9.8. If you do not use this version, the SSL implementation will fail.

To set up OpenSSL:

      1. Ensure that the Microsoft Visual C++ 2008 Redistributable Package (x86) is installed on the system on which you want to generate the requests. To download the package, see the Microsoft Download Center.
      2. Download the Shining Light Productions installer for OpenSSL x86 version 0.98r or later at http://www.slproweb.com/products/Win32OpenSSL.html. This software was developed by the OpenSSL Project.
      3. Launch the installer, proceed through the installation, and note the appropriate directory for later use. By default, it is located at c:\OpenSSL-Win32.

This tutorial includes two additional posts, which you can find on my blog at the following links:

Post 2: Generating Certificates for the identity Appliance/vCAC Appliance
Post 3: Generating Certificates for vCAC 6 IaaS Web Server & Manager Service

Eiad Al-Aqqad is a Senior Consultant within the SDDC Professional Services practice. He has been an active consultant using VMware technologies since 2006. He is VMware Certified Design Expert (VCDX#89), as well as an expert in VMware vCloud, vSphere, and SRM. Read more from Eiad at his blog, Virtualization Team, and follow him on Twitter @VirtualizationT.

Using Secondary Management Network for vSphere Replication

By Sunny Dua, Enterprise Solution Architect, VMware Professional Services

Sunny DuaI have written a lot about vSphere Replication best practices. This time, I want to share an experience of implementing SRM and vSphere Replication in a brownfield virtual infrastructure.

As we all know, vSphere Replication uses the management interface for the ESXi servers to send the replication traffic to the DR site vSphere Replication Appliance. It is important that we understand the network flow clearly before diving deeply into configuration of the networks. The diagram below illustrates how the data flows.

Understanding Network Flow
Let’s see how the traffic flows in generic sense before we add IP addressing to it:

Network Flow

  1. Changed blocks are captured by the VR Filter on the ESXi server in the primary site.
  2. This data is sent to DR Site VR Appliance using the primary management interface of the ESXi server.
  3. The VR Appliance in the DR Site passes the data to the ESXi servers in the DR Site using the NFC Service.
  4. This data is then written on to the designated DR Site data store.

Note: Just reverse this sequence to do a reverse replication while doing re-protect in SRM.

A Real-Life Scenario
Let’s look at a real life setup and see how this replication will flow. Here’s a quick view of my setup, along with the IP addresses:

vSphere setup


Let’s look at each component one by one:

  1. This is the IP address of the vCenter Server. Notice that the IP sub-nets are different in the Primary Site and DR Site.
  2. This is the IP address of the SRM Server. Notice that the IP sub-nets are different in the Primary Site and DR Site, similar to vCenter Server.
  3. The IP address of the VRA server is not in the same range, because you do not want to use same IP segment as the management network. In this case I have a point-to-point connectivity between the site and the IP configured is on the 10.12.12.x sub-net. This is configured on both sites, as the VRA server will receive the traffic from the ESXi servers on this interface. Remember, this appliance will connect on a virtual machine port group.The default gateway for this sub-net is at the Primary Site and at the DR Site.
  4. VMK0 is the primary management network interface. This is used to manage the ESXi servers in the primary site. Notice that ESXi and vCenter are on the same sub-net.
  5. VMK1 is configured for vMotion on a non-routable VLAN, which is why I have a completely different IP segment here.
  6. VMK2 is the third VMKernel interface I have configured. This is to use the point-to-point connectivity for vSphere Replication. I want the vSphere Replication traffic to go out of this VMK interface and reach the vSphere Replication appliance on the DR Site.
  7. One of the most important things to note that in case of ESXi, the Default Gateway will always be defined with VMK0. Hence, all the VMKernel port-groups will have the same default gateway.

The last point is the problem for me. I do not want the vSphere Replication traffic to hit the gateway ( in the DR site when the traffic is sent to the vSphere Replication appliance in that site. I want it to hit the gateway configured for 10.11.12.x sub-net. To be precise, the default gateway is

Define a Static Route
This is not possible until you define a static route to force the vSphere Replication Traffic to go through the vSphere Replication Interface (VMK2) and then hit the vSphere Replication appliance on the DR Site with the default gateway. Remember, you will have to just reverse this action and add a static route on the ESXi servers in the DR site for ( default gateway in the primary site.

Here are the commands to do define a static route:

~ # esxcli network ip route ipv4 add –gateway <Gateway for vSphere Replication Subnet> –network <IP range for vSphere Replication Network in DR Site>

So in my case I would run the following command:

~ # esxcli network ip route ipv4 add –gateway –network

You also need to add this line to the rc.local to make this setting consistent across reboots.

~ # vi /etc/rc.local.d/local.sh

Add the following line just before the exit command in the script:

~ # esxcli network ip route ipv4 add –gateway –network

Save and exit from this file and you are done on the primary site. You need to do the same on the ESXi servers in the DR site for reverse replication to work. The command for DR site ESXi servers is:

~ # esxcli network ip route ipv4 add –gateway –network

Note: Remember to add this to the local.sh script as you did in the primary site.

Now let’s see how the traffic flows in this case:

vSphere Traffic Flow 2


Here is a KB article from VMware that might help you with this setup:

Configuring static routes for vmkernel ports on an ESXi host (2001426)

Hope this makes things easy for you and allows you to setup vSphere Replication on your preferred network interface.

Sunny Dua is an Enterprise Solution Architect for VMware’s Professional Services Organization, focused on India and SAARC countries. He holds several certifications including VCP, VCAP-DCA, and VCAP-DCD and the VMware vExpert award. Sunny also speaks regularly at VMware User Groups conferences. Most of his ramblings on virtualization and cloud computing can be found on his personal blog: vxpresss.blogspot.com. He tweets as @sunny_dua.

Quick Tip: vSphere Auto Deploy Reverse Web Proxy Caching

By Ryan Johnson, Staff Technical Account Manager, VMware Professional Services
Ryan JohnsonLately, I’ve been working with a customer on a vSphere 5.1 and 5.5 Auto Deploy environment. The environment is rather large, and each pod of compute/storage requires localized access to the ESXi VIBs during the boot process. This falls in line with the best practice outlined in the VMware vSphere Installation and Setup Guide.

Auto Deploy Load Management Best Practice
Simultaneously booting large numbers of hosts places a significant load on the Auto Deploy server. Because Auto Deploy is a web server at its core, you can use existing web server scaling technologies to help distribute the load. For example, one or more caching reverse proxies can be used with Auto Deploy to serve up the static files that make up the majority of an ESXi boot image. Configure the reverse proxy to cache static content and pass requests through to the Auto Deployserver.

Configure the hosts to boot off the reverse proxy by modifying the Trivial FTP tramp file. When you click Download Trivial FTP ZIP in the vSphere Client, the system downloads the ZIP file that contains the tramp file. See Prepare Your System and Install the Auto Deploy Server. Change the URLs in that file to refer to the address of the reverse proxy.

Kyle Gleed has written a terrific article on how to set up an Apache HTTP reverse web proxy to cache the content from the Auto Deploy server. However, I noticed that he mistakenly did not mention that some additional Apache modules are needed to enable the disk caching directives within Apache HTTP Server. Otherwise, Apache will not cache the content from the Auto Deploy server and the reverse web proxy will only act as a web proxy – with no caching.

Load the Necessary Modules
Specifically, the mod_cache and mod_disk_cache Apache modules need to be loaded to enable these caching directives. Kyle covers these directives in the article.

You might be wondering where the proxy stores the cached content. This is defined in the CacheRoot directive in the Apache HTTP Serverhttpd.conf.

For example: CacheRoot /var/cache/AutoDeploy/

Set Cache Timing
In addition, the CacheDefaultExpire directive specifies a default time, in seconds, to cache a piece of content (“document”) if neither an expiry date nor last-modified date is provided with the document. The value specified with the CacheMaxExpire directive does not override this setting.

For example: CacheDefaultExpire 86400

NOTE: The CacheMaxExpire directive specifies the maximum number of seconds for which cachable HTTP documents will be retained without checking the origin server. Thus, documents cached from the Auto Deploy server will be out of date in, at most, this number of seconds. This maximum value is enforced even if an expiry date was supplied.

Verify VIBs are Loading
Lastly, if you need to verify that an ESXi host is loading VIBs from a reverse web proxy, you will need to either review the Apache logs (eg. /var/log/httpd/access_log) on the reverse web proxy for “Get” requests from the ESXi host IP address or quickly catch the address during the boot process (which moves pretty fast).

By following these steps at setup, you’ll ensure caching will work as expected.

Ryan Johnson, an avid husband, father, runner and technologist, is based in Orlando, Florida USA. Ryan is also a Staff Technical Account Manager in the Professional Services Organization at VMware. As an accomplished enterprise architect and technologist, he enables VMware’s largest customers and VMUG community members in Central and North Florida to accelerate and simplify their infrastructures services and organizations through VMware’s software defined data center and hybrid cloud solutions.
Follow him on Twitter at @tenthirtyam. This post originally appeared on his blog, tenthirtyam.org.