vCloud Director Management Structure

Ok, I know that I keep writing about vCD but there is so much to talk about, I feel compelled to post more and more information about the intricacies of this product – so I thought I would do a little write-up on the basic components that comprise it and what needs to be setup prior to handing it out to anyone in (or outside) of your organization.

First off, you must create an Organization for each business unit or logical group of people that access a specific subset of your infrastructure. Think of this as the framework that each unit operates within and authenticates to. Granular control can be shoveled out from here to administrators that function within each org.

On that note, the next component(s) are the actual users and groups that each organization has. These account can either exist within vCD or imported from an LDAP directory service (such as Microsoft’s Active Directory). All permissions within the organization are derived from these users and groups assignments.

Virtual Datacenter (or vDC’s for short), is the container of resources that each and every organization is assigned to. This is how much of the vSphere environment an organization is entitled to.  There are two types of vDC’s

  • Provider vDC’s – Under a single vCenter server, this combines the RAM & CPU resources under a single resource pool. Storage can be derived from any storage path in the cluster.
  • Organization vDC’s – This is where those resources mentioned in the previous bullet point are separated out and provided to organizations. This includes resources such as CPU, Memory, SAN and/or NAS storage, CD images and virtual media to name a few. One important thing to remember about vDC’s is that they can belong to multiple organizations.

To separate everything within vCloud Director, Organization Networks are formed when templates are deployed and create vApps (which are basically a collection of virtual machines). Its these Organization Networks that enable all vApps within the Organization to communicate with one another. They can also be setup to communicate externally as well for access to persistent environments. Permissions are a bit granular here and only system administrators can create these networks with organization administrators managing them.

A subset of the Organization Networks are vApp Networks that are encompassed within the vApp itself and enables virtual machines within them to communicate with each other and can be setup to talk to systems outside of the vApp or even to an external network.

The final component are the Catalogs that organizations utilize to store templates that can be deployed by the users. These templates are preconfigured (complete) environments that can be deployed very quickly and allow multiple instances of them to be deployed at once since they are isolated. As stated in the organization networks section, these templates from the catalog can also be configured to talk to external networks as well.



VMware Auto Deploy: A Closer Look

One of the best new deployment features to come out from VMware is the Auto Deploy method introduced with the release of vSphere 5. There was a similar product that was released on the site a while back that had similar features to it, but almost all “Flings” that are posted on the VMware Labs site are unsupported since they are not official release products from VMware.

VMware Auto Deploy is a feature rich automated process to deploy 100’s if not 1000’s of hosts in a very short timeframe and without intervention. What makes this product unique is the fact that it leverages a true definition of Stateless Computing whereas the ESXi nodes themselves can run completely in memory and there is no need for magnetic or solid state storage in the server. This is not to say that you cannot deploy hosts to local storage (you certainly can) but generally this type of deployment method is geared towards larger scale environments when stateless computing is preferred giving you the ability to scale your environment in a very short period of time. The unique configuration of each cluster node is handled by a Host Profile that is applied prior to the node becoming an active participant in the cluster.

Image creation starts at the MS PowerShell and vSphere PowerCLI level with the creation of custom image builds that are specific to your hardware and can be tailored to only include the necessary VIB’s (Software Packages) that are pertinent to your hardware. This helps with boot times as well as having a bloated image that contains drivers for hardware you don’t even have.

These image profiles are stored in what are called “Software Depots” and are usually stored on the server that is handing out the images to the hosts which generally happens on the vCenter server.

There are two methods to creating these images; one from the PowerShell command line and the other is to use PowerGUI (My personal favorite and the method I will be talking about in this post).

As for the infrastructure that supports this deployment method, there are a number of key services that need to be in place and configured for VMware Auto Deploy service to work. This includes a DNS server that will have DHCP reservation addresses in it and have the associated host names as static entires, a DHCP Server that will serve as a target for the gPXE booting hosts with a custom scope that has a pointer to the TFTP server that will deliver the custom ESXi image, installation of the VMware Auto Deploy server on the vCenter server (where you obtain the TFTP boot zip file from, this file needs to be placed in the TFTP_Root directory of your TFTP server in unzipped format), a custom ESXi image (as stated above), a host profile attached to the install process and proper answer files for them.

List of Required Software & Hardware:

  • vCenter 5 (with datacenter, clusters & folders properly configured)
  • Minimum 4GB RAM & a separate volume recommended
  • SAN Storage (with a list of target IP’s and volumes for iSCSI or NFS)
  • NIC MAC Addresses of the targeted hosts for deployment
  • FQDN’s (fully qualified domain names) and IP Addresses for each of the targeted hosts
    • Network Mask
    • Routing Address
    • Primary & Secondary DNS Servers
    • IP Address and NetMasks for the VMkernel management network as well as for storage, FT & vMotion
  • vSphere Install Image
  • VMware PowerCLI & Microsoft PowerShell
  • TFTP Server (Not Windows 2008 TFTP)
  • DHCP Server (Windows DHCP OK)
Auto Deploy Points to Remember:
  • The TFTP Server that is included with Windows 2008 is not recommended to use with VMware Auto Deploy
  • If you a using VMware Auto Deploy to install on a DAS (Direct Attached Storage) vSphere will do a check on each system for local storage devices and existing partitions and will not create partitions if the DAS:
    • Has remote storage
    • Contains a GPT partition map
    • Has a MBR table that has any partitions defined within it
  • The network segment that you are deploying on must have total control of the broadcast domain. No other DNS, DHCP or TFTP server can exist on the subnet!
*Note about unknown partitions to vSphere: Auto Deploy will overwrite these partitions and create a new one. Linux LVM is one such partition type that vSphere does not recognize.

*Note about EFI hosts: These MUST be set in BIOS compatibility mode.

Using PowerGUI to Create Custom Images:

I started using PowerGUI a while back and ever since they released a PowerPack for VMware, I’ve been a big fan. During the installation, you have the option to install the VMware PowerPack and you will need to install the Windows Management Framework Core Package (Windows PowerShell 2.0 and WinRM 2.0) along with VMware vSphere PowerCLI 4.1 or later (I recommend version 5.0). After the install, launch PowerGUI and go to the administrative console. Click on tools and then select “Find PowerPacks Online” and search for “Auto Deploy”. There you will find Alan Renouf’s PowerPack (image 1) that you will download and install into your PowerGUI console. It should look something like (Image 2) when installed.

Image 1

Image 2

There are a number of things to discuss regarding the VMware PowerPack, but that is beyond the scope of this post and information that I will be writing about in the very near future.

After installation, you will need to connect to your vCenter server through the “Connect/Disconnect” item under the Image Builder & Auto Deploy section. The next step will be to connect to the VMware “host update” site to when connecting to the Software Depot within the tool. This is constantly being updated by VMware so when you point your PowerGUI client to the depot, you are always obtaining the latest and greatest from them.

This is located at this address:

After you connect your client to the VMware Software Depot, you can then look at the Image Profiles that are contained within the depot. Under the name column, they are easily identified with build numbers and the type of install they are.

Software Packages (next item below Image Profiles), lists the various drivers and tools that come with the selected Image Profile.


Cloning a profile is the next logical step in creating your own customized image within PowerGUI. One way is to clone from the “Actions” menu on the righthand side and the other way is to right-click the Image Profile that you want cloned, select Image Profiles and then click on “Clone Profile”. This brings up a window where you enter the name of your custom profile.

When your clone is complete, you can then start the process of removing or adding software packages to the image. When you have this file compiled to match your hardware, you can then export the image as either an ISO or a Zip file to be added to the Auto Deploy server to be handed out in the designated segment discussed earlier.

Creating an Answer File for host uniqueness:

Now that the image is ready to be used on your massive VMware virtual infrastructure, you must now create an Answer File that is to be applied to each host that receives the ESXi image. This is done by creating a Answer File from a reference host (much like we do with existing profiles).

Maintaining your Answer Files for Auto Deploy:

  • Checking the Answer File Status
    • Complete – Valid Answer File
    • Incomplete – Missing necessary answers
    • Missing – Not found
    • Unknown – Status of the answer file is unknown
      • This will occur upon the creation of the first answer file
  • Update the Answer File
    • Simple right-click on it to update values
  • Import & Export Answer Files
    • The Imported answer file must be linked to one of the hosts in the cluster.
  • Syslog Configuration of the Answer File
    • Remote log shipping for each host since they have no local storage
    • Logs can be sent to the new VMware SysLog Collector (new in vSphere 5).

Things to remember about Answer Files:

  • Answer Files are not stored in a format or location that administrators can access. You must use the UI in the VIC (vSphere Interface Client) to edit them.
  • When the profiles are executed, you must place a value in each and every field that is presented or the profile will fail to apply to the host.
  • The host must be in maintenance mode to apply a answer file to.

Thanks for reading,