VMware Workstation Home Lab Part 1 - PFSense Networking

In any VMware environment, you need several networks and DNS as a prerequisite. To replicate the network aspect in a nested situation, I decided to use a PFSense VM to function as a firewall, router, and DNS server for the other VMs. The WAN interface is connected to the VMware Workstation NAT network, and then other interfaces are connected to Host-Only networks. This way, we can create and fully control new networks like management, vMotion, and vSAN the way we would manage them in a physical environment.

While troubleshooting a Rocky Linux VM that wouldn’t customize itself correctly, I discovered something interesting. Normal guest customization on linux uses perl scripts to change the IP, hostname, password, etc as requested by vCloud Director. However, I noticed in the logs that it checks if cloud-init is installed first, before it performs the perl actions.

Isilon Smart Connect is a feature that automatically connects users to their access zones based on the DNS name they connect to. For example, if you have are using DNS zone vdude.local, you can have tenant1.isilon.vdude.local and tenant2.isilon.vdude.local point connect to 2 separate access zones on the Isilon. However, to do this you need to delegate the Isilon as a nameserver in your domain/DNS zone.

Configuring an IPSec VPN on vCloud Director is easier than ever. Here’s a quick run through of how to do it with a PFSense firewall.

I’ve been running VM performance tests in vCloud Director, and noticed something strange when the VMs are at 100% CPU utilization even when they’re the only VM on the ESXi host. For example, I had a 48 vCPU VM running on a 48-core ESXi host. At 100% CPU utilization, there was about 20% co-stop as reported by vROps.

While complex passwords with random numbers and letters tend to be secure, they’re not very human friendly. In the VMware world, there are still a lot of times where you might need to enter a password by hand vs pasting it in from some password vault. Additionally, if you aren’t careful, your random password may actually be less secure than a human readable one (Ref: Relevant XKCD)

There’s been a lot of hype around vROps being able to send REST notifcations since vROps 6.5 rolled out, including some confusing messaging that webhooks make it possible to integrate with chat services right out of the box. However, setting up vROps notifications to Slack is not exactly a walk in the park. Here are the high level requirements:

Am I crazy or is there not a metric that shows how much total RAM has been assigned to a VM at the cluster level? Like if I have a cluster with 10VMs at 10GB of RAM each, I want a metric that tells me that cluster has 100GB of RAM assigned. I lokoed high and low and could not find such a metric. Luckily, vROps supermetrics make it easy to build exactly that.

In my previous post, I showed how to add specific details (IP and FQDN) to vCenter objects ion vROps as custom properties. That’s a handy thing, but it’s a pretty limited use case. To expand the scope a little, I wrote a function that will add any custom property and value to any vROps object.

Adding custom properties to vROps objects is something that can come in super handy but it’s not extremely straightforward how to do it. The vROps API makes it possible using REST, but for Winbros like myself, PowerCLI provides a way as well. A more detailed walkthrough is available on the VMware blog site.

vSphere Tags are something I didn’t use very often until I started using vROps. In vROps, it’s possible to create a Custom Group based on the vSphere tag which can really speed up the creation of those Custom Groups. In a large environment, however, it can be a real chore to create and assign tags on lots of objects in multiple locations. Using PowerCLI, we can easily create and assign tags across multiple vCenters.

We’ve been testing out VSAN here at work and noticed that one of the clusters we rolled out had serious latency issues. We initially blamed the application running on the hosted VMs, but when it continued to get worse we finally opened a case with VMware. Here’s a chart of the kind of stats we were seeing (courtesy of SexiGraf):