Building an On-Demand Cloud Lab

This time last week, I was in Palo Alto, California for the VMUG leader summit, which was great.  Prior to the summit I submitted an entry into a new VMUG program called SPARK.

To participate in SPARK a leader was asked to submit two power point slides outlining an idea for a way to provide value back to the VMUG community. Additionally we were asked to submit a video that would be played back at the summit which would be played back before all leaders present voted for the favorite submission. The Indianapolis VMUG submission was an On-Demand Cloud lab built on VMware Cloud on AWS.

It was a tight race, but I’m proud to say that Indianapolis VMUG won the first VMUG SPARK contest and will receive $5000 funding to help make this idea a reality.

Here’s the point of the post though. I can’t do this alone, and in fact I don’t want to. I want to involve the community to make it as great as it can be. I want to hear other’s ideas as to how we can create an infrastructure that can be spun up quickly and easily and help other VMUG members learn new skills.

We will be holding our initial planning calls after the new year at whatever date/time works for the best for the most participants. If you would like participate please reach out to me via Twitter. My DMs are wide open and all are welcome. We can make a great platform for everyone to learn on if we work together!


OVA Template Deployment Stuck “Validating”? Try PowerCLI!

I recently made the switch from working as a customer to working as a Solutions Architect at a VAR. I had bought a number of Intel servers from various OEMs during my career but never Cisco UCS. However I have plenty of customers these days who are currently UCS customers or are interested in UCS in their infrastructure.

For this reason I decided to download the Cisco UCS Platform Emulator. The UCS Platform Emulator is a free tool that allows risk-free experimentation in a UCS manager environment. It can be downloaded as a .zip containing all virtual disks and metadata, or simply as a singly .ova file for easy deployment. Naturally I opted for the .ova file as I have a full vSphere environment running in my homelab thanks to VMUG Advantage.

Once I had the bits in hand I fired up the new HTML5 vSphere client and started the “Deploy OVF Template” wizard. Even though the new HTML5 client is new to me, the wizard was intuitive and similar to what I was previously used to with the C# client and Flash based vSphere Web Client. I hit a roadblock at one point though when the wizard display a message that it was “Validating” and appeared to make no progress.


Ooookay, well I guess I’ll fire up the Flash client, wait for it to load and deploy from there.


Well it looks like I can no longer deploy templates from the vSphere Web client in vSphere 6.5. Apparently my choices are troubleshooting the HTML5 client or nothing….or are they?

Enter PowerCLI

I’ve spent the last 12-16 months familiarizing myself with PowerCLI so this was the perfect opportunity to see if there was a way to deploy my template without the need of the GUI. I quickly found the Import-Vapp cmdlet which is thoroughly documented here.

Running through the options available I constructed the test below:

Import-VApp -Source \\\Data\HomeLab\CiscoUCS\UCSPE_3.1.2e.ova -Name UCSPE -VMHost (Get-VMHost -Name -Datastore (Get-Datastore -Name NFS-FS2-ProductionFast) -DiskStorageFormat Thin -Location (Get-ResourcePool -Name Normal) -Whatif
What if: Performing the operation "Importing '\\\Data\HomeLab\CiscoUCS\UCSPE_3.1.2e.ova'" on target "Host ''".

Adding -Whatif allows testing before making any actual changes to objects in PowerCLI/PowerShell. With this test behind me I dropped the -WhatIf parameter and deployed my OVA file for real.

Import-VApp -Source \\\Data\HomeLab\CiscoUCS\UCSPE_3.1.2e.ova -Name UCSPE -VMHost (Get-VMHost -Name -Datastore (Get-Datastore -Name NFS-FS2-ProductionFast) -DiskStorageFormat Thin -Location (Get-ResourcePool -Name Normal)

The deployment went by so quickly I wasn’t sure if everything completed properly. A quick check with “Get-VM” showed that the new VM did exist.

Get-VM -Name UCSPE

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
UCSPE                PoweredOff 1        1.000

A quick power on and check of the VM console showed that the VM was in fact deployed and booting properly.


You can try this for yourself. Just replace the text in the brackets with the necessary information in your own environment.

Import-VApp -Source <FullPathtoTemplate.ova> -Name <VMName> -VMHost (Get-VMHost -Name <ESXiHostName>) -Datastore (Get-Datastore -Name <DatastoreName>) -DiskStorageFormat Thin -Location (Get-ResourcePool -Name <ResourcePoolName>)

Mixing CPU/Server Generations in a vSAN Cluster – What’s Supported?

When designing vSphere clusters, vSAN or not, its pretty common knowledge that the hardware should match as much as possible. This includes the server make and model, CPU/RAM configuration, HBA, disks, NICs etc. There are times when this is not possible, or doesn’t make sense. Examples would be when the servers in your cluster are EOL or you know they will be soon and you would rather purchase the newer server generation than buy hardware that will soon not be supported by the manufacturer.

I recently asked my local vSAN SE if VMware had an official stance regarding mixing server or CPU generations in a vSAN cluster. His response was that he certainly wouldn’t recommend it but he stopped short of saying mixed configurations would not be supported. We didn’t have enough time to discuss further so I basically walked away with the attitude that I would have to ensure that whenever I was designing a vSAN cluster for a customer I would ensure that I was using hardware that they would be able to easily duplicate for the next few years should they have the need to expand their cluster.

Fast forward to this week when this question was brought up by another individual on the vExpert Slack channel and it cause a bit of a debate. Several of us were discussing this and we basically came to the conclusion that we could not find an official VMware stance on this. Some of the documentation found on gave some guidance but nothing definitive.

So assuming you can keep everything the same aside from CPU/motherboard does vSAN care? The conclusion we came to during this discussion is that as long as you are using EVC then vSAN shoudln’t care. It is certainly considered best practice to keep hardware identical whenever possible. It is important to be mindful when mixing CPUs that vSAN will essentially be bound by your weakest CPU when serving IOs in this type of scenario.

During the conversation a couple of VMware employees chimed in and confirmed that as long as you are keeping CPU/RAM/Storage balanced accross hosts in the cluster, it shouldn’t matter. There was even an implication that this is officially documented somewhere but I have not been able to find any source for this as of yet.

Bottom line, when expanding a vSAN cluster keep the hardware identical if possible. When its not possible pay close attention to the hardware in the new hosts and make it as balanced as possible.