Home Lab Design Considerations

I’ve recently had several discussions with a friend about building a home lab. We covered various aspects including defining requirements, creating networks, and figuring out DNS domain names to use.  In the next few blog posts, we will document lessons learned.

To get started we had to articulate our goal — to learn VMware SDDC products, gain hands on experience, and prepare for certification exams.  The second consideration was how the lab was going to be used.  For example, did we want an environment that could be quickly recreated for a specific purpose or did we need an environment on the other end of the spectrum with a long life / persistence?  This longer life environment would likely require that we perform upgrades, troubleshoot when things broke, and have sample data for systems like vRealize Operations or Log Insight.  For the first use case of an ephemeral, non-persistent environment, a solution like the VMware Hands On Labs would be perfect.  It would have no cost, be easy to instantiate, and then could be torn down and recreated with just a few clicks.  For a more persistent environment, we would likely need to acquire our own hardware, which would add costs and force us to understand system requirements of all of the solutions we would like to deploy in advance and go through a capacity planning exercise.  Through our discussions a decision was reached that a more persistent environment would be necessary.

The next step was to document hardware requirements.  I would recommend starting by creating a list of all of the workloads that you would like to run in the lab.  Interesting data points you’d want to capture for each workload would be the number of virtual CPU required, the amount of RAM needed and total disk capacity.  In my home lab experience the 1st place you’ll run low is on RAM, so I would take the total you think you are going to need, double that number, and start there.  With rough hardware requirements in hand, the next step would be to find a solution that meets budget constraints.  There are a lot of options in this space, from large, loud, & power-hungry refurbished server grade hardware on one end down to small, quiet, & power saving micro devices like the Intel NUC.   There are plenty of sites to review some of the hardware other folks are using, and its worth checking out the collection of HomeLab BOMs at https://github.com/lamw/homelab

With hardware ordered and on the way the next step will be to talk about networking. Please look for the next post where we will discuss getting started with home lab networking.

Posted in Lab Infrastructure | Leave a comment

My completed (for now) Home Office improvements

I’ve recently made several improvements to my home office / desk setup. Several people have asked for details on the parts/pieces I used to complete this, so I wanted to take a moment and document them here.

I started with an Autonomous SmartDesk 2 – Home Office motorized sit/stand desk. There is a premium version of this desk that appears to have more range (can go lower/higher) than the home version, but for my needs the home office version seemed to have very similar specs and was slightly less expensive.

I already had a very good desk chair (the Autonomous ErgoChair 2), but also added a Topo Comfort Mat for when I’m standing. This was a touch more than I planned to spend, but came highly recommended and initial impressions are very good.

I’m using two different monitor arms, one from my previous setup and a new ErGear Adjustable Gas Spring mount which was very inexpensive (only $25) and supported the weight required by my monitor (the specs for the monitor arm show it supports up to 26.5 pounds).

Lighting was the toughest problem to solve. I wanted to have a primary light source that was centered in front of me, to reduce shade cast from one side of my face for video calls, but also desired more light than most round / camera lights provide. I also preferred an indirect light source that would bounce of the ceiling first, but not be blocked by my monitor when in a standing position. My first thought was a very tall floor lamp, but I didn’t really want a base that I would be kicking right in front of my feet, and couldn’t find anything tall enough anyway. I found some desk mounted lamps that looked like they might work, but I couldn’t find any with the right height to be able to reach over my monitor. What I settled on was a fairly custom solution. I purchased a Twinkle Star Floor lamp with Remote Control, but disassembled / rewired part of it and mounted it to an unused monitor arm I had laying around using some bolts and rubber wire clamps. The end result is a desk mounted lamp that’s the perfect height (and adjustable), but also has a remote control that can adjust light temperature and brightness.

I hope you find this info useful!

Posted in Lab Infrastructure | Leave a comment

Clone Template to new vCenter

On a recent TAM Lab session (TAM Lab 082) I covered several methods for managing vSphere templates. At the end of the presentation we had a brief bonus method that showed using PowerCLI to clone a template to a different vCenter. This could be used once you update your primary copy of a template in vCenter1 and you wanted to make that template available in a different environment. The script used in the demo is available below.

$creds = Get-Credential

$sourceVC = Connect-ViServer t036-vcsa-01.lab.enterpriseadmins.org -Credential $creds
$destVC   = Connect-ViServer core-vcenter01.lab.enterpriseadmins.org -Credential $creds

$destTemplateName = 'template-tinycore11.1_tamlabtest'
$splatNewVM = @{
  Name     = $destTemplateName
  Template = 'template-tinycore11.1'
  VMHost   = 't036-vesx-01.lab.enterpriseadmins.org'
$vm = New-VM @splatNewVM -Server $sourceVC

$splatMoveVM = @{
  VM                = $vm
  NetworkAdapter    = (Get-NetworkAdapter -VM $vm -Server $sourceVC)
  PortGroup         = (Get-VirtualPortGroup -Name 'VLAN10' -Server $destVC)
  Destination       = (Get-VMHost 'test-esx-33.lab.enterpriseadmins.org' -Server $destVC)
  Datastore         = (Get-Datastore 'test-esx-33_nvme' -Server $destVC)
  InventoryLocation = (Get-Folder 'vc1_TAMLab082' -Server $destVC)
Move-VM @splatMoveVM

Get-VM $destTemplateName -Server $destVC | 
Set-VM -Name 'template-tinycore11.1-bonus' -ToTemplate -Confirm:$false

This script uses splatting to improve readability. You can read more about_Splatting here. There are a couple basic components. First we connect to both vCenters, in this case using the same credentials. We then create a new VM from template on the source side, then move that VM to the destination side, and finally rename the destination VM and convert it to a template. We did this as multiple steps as Move-VM has additional parameters to assist with changing the destination network adapter to specify the correct portgroups and such.

Posted in Scripting, Virtualization | Leave a comment

Skyline Health Diagnostics custom SSL certificates

I recently read about the new Skyline Health Diagnostics tool. Here is a short quote that captures what this tool is all about.

VMware Skyline Health Diagnostics for vSphere is a self-service tool to detect issues using log bundles and suggest the KB remediate the issue. vSphere administrators can use this tool for troubleshooting issues before contacting the VMware Support. The tool is available to you free of cost.


Installation was very straight forward and captured in the official documentation here. I deviated slightly, and opted to use the Photon 3.0 OVA instead of installing Photon from the ISO image. If you go down this route, you may want to grow your root filesystem beyond the 16GB from the initial OVA, if you need help with that check out this blog post.

After setting up the appliance, I decided to replace the SSL certificates for the web site. This is described in the documentation as well, but I made a couple of changes that I’ll outline below.

The first change I made was to the SSL conf file. The official documentation has you edit the entries in the [req_distinguished_name] section so that the entries for commonName and DNS.1 are correct. In addition to doing this, I added a DNS.2 and DNS.3 option to capture the short name of the server as well as a friendly / alias name.

After applying the certificate, I was able to access the interface with the FQDN of the server, but not with the alias information or IP address. After doing a bit of research I found that adding a server_name entry to the nginx configuration would allow me to specify additional names/alias information. I also noticed that there wasn’t an automatic redirect from http to https, which I wanted to add. To do this I edited the nginx configuration with vi /etc/nginx/nginx.conf and added the following information:

server {
        listen 80 default_server;
        server_name _;
        return 301 https://$host$request_uri;

This above section tells nginx to listen on port 80, accept any wildcard server names that come in, then do a http 301 redirect to the https port, using the original host name and URL that were provided.

I then edited the existing sever 8443/ssl section and added the following below the listen 8443 ssl; line: server_name servername.lab.enterpriseadmins.org servername skylinehealth.example.com;

The above line instructs nginx to listen for incoming requests for my FQDN, short servername, IP address, or friendly alias. I could have used the wildcard symbol as shown in the http example, but I wanted to limit SSL requests to only values which were included in the SAN certificate to prevent possible certificate warnings.

The above screenshot shows the relevant section of the /etc/nginx/nginx.conf file. The green lines to the left denote the entries which were added.

Additionally, I had to update firewall rules to allow incoming HTTP requests. I used sample entries described here: https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands to make this happen, specifically running the following two commands:

iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT

With these minor changes I’m able to access Skyline Health Diagnostics using FQDN, IP Address, and Alias using HTTPS. If I forget and accidentally try to connect over HTTP, nginx will help me out and do the necessary redirect.

Posted in Lab Infrastructure, Virtualization | Leave a comment

Photon OS 3.0 Grow Filesystem

I recently had a need to grow the root filesystem on a Photon OS 3.0 virtual machine. This is something I’ve done before with Ubuntu Linux (blog post here), but Photon OS does not include the growpart command out of the box, so that process did not work.

After resizing the virtual machine disk, I rescaned from within the running OS (I could have also rebooted, but who wants to do that) by running this command:

echo 1 > /sys/class/block/sda/device/rescan

I then installed the parted utility with the command tdnf install parted and started by typing parted at the shell prompt. Once at the parted menu, I typed print to show the disk information. A warning appeared letting me know there was extra space available for use and asking if I wanted to fix the GPT to use all the space, which I entered Fix to accept.

From here you can see that Disk /dev/sda has a size of 26.8GB, but the last partition #3 ends at 21.5GB. It happens that the last partition is the one I want to grow, so I type resizepart 3 . I’m notified that the partition is being used and I confirm with Yes. To answer the new question for where I want the partition to end, I entered 26.8GB which was the value previously returned by the print command.

With the partition table issues resolved, I entered quit to exit the parted utility.

Back at the shell, I ran resize2fs /dev/sda3 to resize the filesystem to consume all of the space. I can now confirm that my filesystem has the extra free space with the command df -h .

After testing this out, I realized the environment where I really needed to make the change did not have internet access, even through a proxy. Because of this I was unable to install parted with tdnf. Not to worry, we have two different workarounds for that.

First, we can install the parted RPM manually without tdnf. To do this we browse to the Photon repo here: https://dl.bintray.com/vmware/photon_release_3.0_x86_64/x86_64/. Looking through the list of packages, we find the one starting parted-*, in this case parted-3.2-7.ph3.x86_64.rpm. We download the file and copied it to the Photon VM (using WinSCP or the like). From our shell prompt we then run rpm --install /tmp/parted-3.2-7.ph3.x86_64.rpm to install the manually downloaded RPM. We can then run the rest of the steps as outlined previously.

Alternatively, if we don’t want to install parted in the guest and are okay with a brief outage, we could use a bootable CD image which contains partition management tools. One such tool that I’ve had good luck with is gparted. You can download the image here: https://gparted.org/download.php. This tool takes care of all the steps, both growing the partition and extending the filesystem.

Posted in Virtualization | 3 Comments