2014

I recently encountered an issue in vSphere 5.5 where I wasn’t able to change the interface speed on an ESXi host from auto-negotiate to anything else. After a good amount of troubleshooting I was able to determine that this issue was occurring due to the fact that the NIC firmware version and driver version on a blade server was out of date. VMware has a good KB article on how to grab the firmware and driver versions that I followed. However, the problem is that even on the most modest ESXi host that isn’t running 10G to it, you’ll likely have a minimum of 4 NICs on it. This means that you’ll have to enable SSH on every host you want to check, run one command per NIC each of them (or run a one line script that loops through them, but will that really save you time..?). It doesn’t take a very large cluster for that to become a very large endeavor.

This PowerShell script will connect to a vCenter server, allow you to scan all ESXi hosts, or only hosts within a particular cluster, and output the results in object format so that you can manipulate them how you wish.

I like having documentation, but I hate creating documentation.  I’ll be the first to admit that I’m slightly lazy at times, however, my own personal preferences for what I’ll call “Effort Allocation”, are not the root of my dislike for creating documentation.  The issue really stems from the fact that creating it is very time consuming, tedious, and usually lower on the priority list.

However, sometimes it’s not you that failed to create the documentation. Consultants frequently fall into this category.

The issue I’m handling here is documenting CDP information from the perspective of ESXi hosts using PowerCLI.

Over the past few months I’ve been doing a lot of work with VMware Horizon 6. I’m not going to go into details, as VMware has done a great job doing that, plus I’m under a NDA. Suffice to say, details that have been provided suffice if you’re just looking for info.

In my company sponsored lab environment, I have HWS 1.8 deployed in feature/option parity compared to production. Deploying a second instance of HWS (perhaps a pre-release version), is challenging, due to DNS/Reverse DNS Checks that are done.

Anyways – the reason you’re probably here is to find out how to systematically modify DNS records, so here ya go!

For anyone that’s ever been through the process of provisioning a new datastore to multiple ESX hosts, you know it can take some time. Below are the steps I use

1. Create Volume on NetApp
2. Set Security Style to Unix
3. Enable Storage Efficiency
4. Set NFS Export permissions to allow Read/Write + Root Permissions to all applicable hosts
5. Mount datastores on ESXi hosts

For a handful of hosts this is fine, but adding it to anything more than 4-5 hosts is reaaally painful in my experience. Below is a script you can use to take care of these steps in one swipe.

After upgrading several different environments to Horizon Workspace 1.8, it’s become clear to me that the “offline upgrade” feature is something that should be used whenever possible. Maybe it’s just the environments I’ve worked in, but going from 1.5 to 1.8 takes much much longer than going from 1.0-1.5. This guide is intended to help you accomplish an offline upgrade from 1.5 to 1.8, while having a plan to restore to 1.5 in case of a failure. This is the fastest process I have found to perform the upgrade. Even with these measures, I’d plan on getting a 4-5 hour outage window for a production environment (2 connector, service, gateway, data virtual appliances)