December

Introduction Towards the end of 2019, I made a decision to aim for a certification in one of the primary public clouds. The decision on which cloud to focus on was relatively simple for me for a couple of reasons: Microsoft certianly seem to be doing awesome things with Azure and it feels like there is a lot of hype around Azure in the circles I travel in, at least more so than GCP or AWS I work for a partner and while not specifically in the team that are delivering public cloud solutions and managed services, we are currently 100% focused on Azure and are a Microsoft triple gold partner.

This one is just a quick post regarding an issue I came up against just before Christmas. To get straight to the point, I found an issue where in multiple separate environments, when cloning a virtual machine via the VMware vCenter HTML5 Web client interface, if you select the tick box to “customize this virtual machine’s hardware” and change any of the settings of the VM, the cloned virtual machine’s VMDK file(s) will be pointed to the VMDK file(s) of the source machine you used for the clone.

I was recently involved in an issue in an evnironment that started out looking like a simple SSL certificate replacement and ended with multiple hours of troubleshooting with GSS and redeployment of vSphere Replication. Fun times, right?! Let’s take a step back. This customer has a straight forward environment. Two physical sites, one vCenter Server and external PSC per site (6.5) in the same single sign on domain. Each site had one vSphere replication appliance and one Site Recovery Manager Server, version 8.

I was recently rolling out the base install of VMware NSX in my lab, where I ran in to a controller deployment issue. The lab is running NestedESXi, and I have two ‘sites’ that are nested, each with 3 ESXi hosts in a vSAN cluster. vCenter, PSC and NSX Manager / controllers are then deployed on to the nested ESXi hosts, so the storage is on the nested vSAN datastores.

I’ve recently been doing a lot of work in my home lab, which has involved me moving from a flat /24 network (yeah, I know) to a somewhat more realistic lab environment with a Cisco SG300 switch and Ubiquiti EdgeRouterx. Due to these networking changes, as I build out the environment I’ve been creating a lot of VLANs and subnets between my physical ESXi host, the Cisco switch and the ERx.

Just a quick note on something I spotted as I’ve been working through some blog posts for vSphere 6.5. It looks like you can now upload files for a Support Request to VMware directly from the vSphere Web Client. KB 1008525 lists some of the main methods for uploading diagnostic information to VMware including using the Support Assistant (which I am planning to do a post on), FTP and email. It does not yet contain information for this new feature in vSphere 6.

Every now and then I need to find the version and build number of VMware vSphere Update Manager that is running in a customer’s environment. I’ve written this post mainly as a reminder to myself, but hopefully it helps someone else down the track. VMware have a KB article for most of their products to correlate the build numbers with versions. The specific article for VUM is KB 2143837. Sometimes these aren’t always right up to date unfortunately.