Building the lab 4: Stand up vCloud Director

First, I would like to declare: “vCloud Director is NOT dead!” I can say emphatically, this product did not die, never died, and I don’t believe that it is going to die! It is still actively being developed by VMware.

With this clarified, let’s move on to getting vCD stood up. Again, I followed along with the wonderful guide from Sysadmin Tutorial.

This guide has a very good walk-through for standing up vCloud Director 8.0 for a Proof of Concept (it also works well for 9.0). There are multiple steps that break out each milestone of the installation/deployment. You could follow along each part, as I did. Along the way, I will point out the various things that I did or changed for my environment.

Part One is self explanatory. The walkthrough shows you how to set up a SQL database. Yes, MS SQL is still supported with vCD 9.0. While you may want to migrate or move to a PostGreSQL Database, this guide sets you up for MS SQL. (I will cover how to setup PostGreSQL and migrate the database sometime in the future. You may need or want this down the road when you get ready to upgrade.)

Part Two – setting up a RabbitMQ server, I skipped. Why do you ask? Well, the answer is selfish. My environment is small and is designed for one thing – quick deployment and stand up of an SDDC environment for play and discovery. Unlike many vCD environments that can be found in the wild, I will not be interfacing or integrating with any outside services. Nor will I be standing up mulitple cells. So I have no need of a RabbitMQ server at this time. You and your environment may very well need one.

Part Three of this guide is very good. I like how they dig into the certificate creation and the details of what to do with them. This portion of the walkthrough also includes how to create the cert with a Microsoft CA server. These are details that I would like to see VMware include in their documentation. This is one area that plagues many installations as certificates always seem to be problematic and having a good walkthrough would really go a long way.

Once you complete these steps, you are ready to configure vCloud Director for consumption. Like all VMware products, you should have a good idea of how or what you want to do. Setting this up to play with is one thing. But if you are trying to utilize it beyond “how do I install it?”, then you need to have an idea of what you are trying to accomplish. If you haven’t taken the time to do this, you should.

For me, as I said previously – I want to stand up vCloud Director to be a mechanism where I can quickly deploy full SDDC environments to manipulate and play with. I want to utilize these environments to learn, discover, and grow my skillset. I do not want to destroy and rebuild my lab environment every time I have a different scenario I want to test. My goal is to ‘mimic’ the Hands On Lab environment. Ambitious? Yes.

I’m going to stop here as the next Part of the SysAdmin Tutorial walkthrough was already covered when I stood up NSX in “Building the lab 3: NSX”. Before I continue with the SysAdmin Tutorial on and kick off Part 5, I want to set up more storage.


The only thing constant is change. Change is the backbone of any IT organization. New widgets, software, and hardware seem to come out daily. Our job as IT professionals is to try and stay aware of these new products. However, while we try and stay ‘cutting-edge’ and ahead of all this change, we always seem to fall behind at some point. What we ought to try and do though, is not fall so far behind that we lose sight of the pack. Thus, we become obsolete and are expendable.

Recently, I went to a vCloud Director 9.x Design Workshop. Yes, my friends — vCloud Director is not DEAD. While the software is primarily for Service Providers, it is still a mighty tool that allows many IT groups the ability to rapidly deploy internal, isolated, “pods”. This training got me to thinking, ‘why am I not using vCD in my lab?’

That’s why, once again, I am updating my homelab. Over the last few years, I’ve torn down and rebuilt my lab numerous times. This has wound up taking weeks and months of time to reset back up — just to test something. It seems most often, the rebuild wastes so much time. This time around, I’m going to explore rebuilding my lab around vCloud Director 9.x.

Home Lab

Over the years, I have gone from a full 42U rack with Dell PowerEdge servers that consume massive amount of power, cooling, and my personal manpower to maintain. This hurt my wallet (as well as my time) — a lot, which also caused numerous problems with finance (aka: the wife). A while ago, I replaced the Dell PowerEdge servers with a Supermicro Super Server. This has been working out great for me. As a matter of fact, this past year I have made a few hardware modifications to the lab. I wound up running out of space and had to upgrade the hard drives in my synology box from (5) 2TB drives to (5) 3TB Drives. To expand the capabilities, additional hardware was acquired: A new Intel NUC was added as a payload target, and another Supermicro Super Server was obtained at the end of the year (Merry Christmas, right?).

Further blog posts will detail my rebuild journey. I fully intend on sharing what I learn.

Project: Home Lab v4.0 – The Home Lab goes MOBILE!!

Woot! Ok, that was cheesy, I know. However, my home lab has undergone significant improvement, redirection, and an overall evolution. And that calls for celebration! So Woot it up!

SuperMicro Super Server X10SDV-TLN4F
SuperMicro Super Server X10SDV-TLN4F
Over the last two years, I went from individual rack mounted Dell PowerEdge 1950s and Synology storage, to a four blade Dell c6100 Cloud Server chassis, to rented COLO Space from OVH, and now to the all new mobile lab. You are probably asking yourself “why all the changes?” Well, it grew from a need to be more energy efficient, to a random act of god (lightning strike), and eventually to money.

While the Dell Cloud Server averaged approx 700Watts fully loaded keeping my electric bill down, my new Mobile Lab will average less than 120Watts. (I’m not exactly sure how much lower as I haven’t put the meter on it yet.) OVH was a very good colo – especially for the price. I just don’t want to pay them rent any longer. The Synology will remain the in-home media server/backup location for the family and no longer used by the lab.

Why mobile?
It doesn’t have to be. I have a VPN to my home, so I can connect to it remotely. Plus, the new server has the ability for remote control, so I can power it on/off – if needed, without the need of the “break/fix” wife. But with the size of the server, I can take this bad boy on the road. The downside to that is TSA, theft, and potential travel damage. The upside to it is being able to plug it up and demo on the spot. In addition, when there are power or internet outages preventing me from connecting to my home from the hotel or the customer’s workplace; I could still work in the lab — without that dependency.

What makes up this mobile lab?
Over the last year, several co-workers and I have been discussing building small labs. We had several ideas for what we wanted to use, but we were also very particular in what we wanted. We pinned requirements and started searching. One friend decided to run an Intel NUC, another is utilizing a Gigabit server, and one more suggested the hardware I am using now.

Our requirements (or I should say, my requirements) were the following:

  • It had to have a small footprint.
  • It had to be energy efficient, low power, and put out little to no heat and noise.
  • It had to be able to run 64GB of RAM or more.
  • It had to be inexpensive.

  • With that list, you would think oh – and Intel NUC or a MAC MINI. But neither of those can use more than 16GB of RAM. Once you install vCenter, a nested ESX host, and a couple of VMs, you are out of RAM. In addition, the NUC is the only one that is inexpensive. However, you will have to purchase a few of them to be able to do anything worthwhile within a lab environment.

    This brings us to the setup of the mobile lab. All of my storage, I salvaged from previous equipment that I have had lying around from my earlier versions of my lab.

    Measurements: 7.5"x7.5"x3"
    Measurements: 7.5″x7.5″x3″

    HOME LAB v4.0 (Mobile Lab)
          SuperMicro Super Server Motherboard X10SDV-TLN4F
         (1) Intel Xeon D-1540 8-Core 2Ghz CPU
         UPDATE: 128GB RAM (Max)
         (2) 10Gb NICs
         (2) 1Gb NICs
         (1) IPMI Port
         Travla C299 Mni-ITX Case
    Internal Storage:
         (1) 250GB Samsung 840 EVO SSD
         (1) 1TB Western Digital 5400 SATA III HD Blue
    External Storage:
         (1) 2TB Seagate Backup Plus Slim External USB 3 Drive
         (1) SanDisk Cruzer Fit CZ33 32GB USB 2.0 Low-Profile Flash Drive
         Hypervisor: vSphere ESXi 6.0 U1b build 3380124
         Backups: VMware Data Protection 6

    The unit is tiny compared to many other options with the same featuresets. I can pack it into my backpack along with the power supply, a couple of ethernet cables, a small five port switch and still have room for a bag of Reese’s Pieces. 🙂

    The mobile lab is based on the SuperMicro Super Server Mini-ITX series of motherboards. It is the foundation of the entire lab. Within this base, is a complete nested vSphere 6 environment running almost a full VMware SDDC stack (I’m not running NSX).

    As time allows, I will detail the buildout of this lab in the future.

    Script: Merge Multiple Arrays

    Each Saturday my company does a refresh of a few different machines. This refresh consists of cloning a couple of production machines into our lab environment for development. It’s a very tedious process that takes the entire day to do. Until recently, this process has been done manually. I’ve been working on a script to automate the process as much as possible. Along the way, I’ve learned a great deal about powershell/powercli – especially from hitting a wall and trying to figure out a way around. This blog entry is about one of those snags along the path of progress.

    The refresh consists of two major Acts. Act I is all about cloning the source VMs, stripping them down, and converting them into templates. Act II is about deploying VMs using differing templates. There will be a later entry discussing this entire script in greater detail. This entry focuses on creating merged array to be used in the deployment CSV list for Act II.

    Each week, the refresh list changes. One week, the source VMs may be SourceVM01 & SourceVM05. Next week, it may be SourceVM01 & SourceVM03. I created a GUI frontend for this script using PrimalForms 2011. The GUI has a “pick-list” where you can cherry pick what SourceVMs and what DestinationVMs will be needed. Upon your selection, three arrays are built – $a = #VM Names, $b = #Specs, $c = #Template Names.

    For example;
    If I needed to refresh DEV-VM01, TEST-VM01, and QA-VM01; I’d check their boxes, and the following variables would be added to the three arrays. (You can start to see where if you had multiple Dev and Test VMs how these arrays can get quite complex.)

    $avm = “DEV-VM1” $avm = “TST-VM1” $avm = “QA-VM1”
    $bspec = “DEV” $bspec = “TST” $bspec = “QA”
    $ctmp = “TMPL-DEV01” $ctmp = “TMPL-TST01” $ctmp = “TMPL-QA01”

    So the question was, how do you take this information and merge it – with one array, and all the information within? That’s where I came up with this solution.
    I replay each of the arrays using a “counter” ($i) and building a new array with the information from the table above. The counter variable matches each record for that row (ie. $a.record1 with $b.record1 and $c.record1).

    The array will continue to loop, until it runs out of entries based on the $a array. Once this fourth array ($d) has been created, I can then use it to build my deployment CSV file (SEE THE DEPLOYMENT CSV LIST BUILD SCRIPT – To come).

    Script: Drive Letter Order

    I’m currently writing an application (it’s a huge script – 2100 lines of code) in powershell to automate a weekly VM refresh operation that my team does every Saturday. At the end of the script, I wanted to check the newly deployed virtual machines to verify that the automated scripts did what they were supposed to. One of the items on this checklist is to check the drive letters. For the business owners, the VM has to be setup similar to the source machine. The drive letters have to be setup as follows: C Drive (OS), D Drive (CD Rom), E Drive (Data).

    "Click for larger image."

    I use VMware’s clone ability to copy the source VM into a template. I use a “CustomizationSpec” to reset the VM’s identifiers and “sysprep” the virtual machine. During the “sysprep” process, the drive letters are reset to: C Drive (OS), D Drive (Data), E Drive (CD Rom). Since this doesn’t meet the customer’s requirement, I created a batch script that is called during the runonce section to change the drive letters. This batch script was placed on the source machine with its’s support files, and is thus carried forward in the clone.

    Continue reading “Script: Drive Letter Order”