I deployed a new vSphere VCSA for my homelab in December 2019 (last month). By default these come with a self-signed SSL certificate that’s valid for 10 years. Of course I typically replace these with a signed certificate but it’s not always the first thing that I do.
What I found this time however is that on my Mac neither Chrome or Brave would allow me to reach the web UI. Only Firefox would. I expect security warnings for self-signed (and hence untrusted) certificates. On the former two browsers though the message suggests that the certificate is invalid in some other way:
What’s actually happening is that as of MacOS 10.15 and iOS 13 SSL certificates have to meet certain criteria to be deemed to be valid. These are documented here: https://support.apple.com/en-us/HT210176.
In the case of the vCenter VCSA, the duration (10 years) is over 825 days. Hence no dice. It would be better if Chrome was clearer about that.
About 18 months ago I wrote a post on my experience upgrading my homelab from vSphere 6.5 to vSphere 6.7. Since that time it has had a few rebuilds and reconfigurations, been off for several months, been idle, been busy and generally just worked. The one constant though was the build of ESXi that I was using. It was always 6.7 GA.
Having been switched off for some time, I brought it back up over the Christmas break after a long lunch with homelab hero @virtualhobbit. The point of this post is not the reasons why my lab has come back to life (I’ll cover that at some point), but about how I got it updated to the latest version of vSphere.
As a recap, and to save anyone reading my previous post, my lab is constructed from Dell workstations that don’t appear on the HCLs for VMware. As any homelabber will attest, sometimes compromises have to be made to run your own lab. In my case, updates aren’t as straightforward as they should be but that’s offset by the cheaper cost and age of the hardware. That said, I will most likely not be able to run the next version of vSphere owing to the deprecation of the vmklinux driver stack.
Coming back to the topic in hand, vSphere Update Manager tends to complain when I use it owing to my unsupported processors. Updating my hosts via esxcli however still works. My first attempt at an update was not successful however. I had downloaded the offline update bundle from VMware’s site and placed it on a shared VMFS datastore.
But I was met with the following error when I tried to apply it:
VIB VMware_bootbank_esx-base_6.7.0-3.73.14320388 requires esx-update >= 6.7.0-3.73, but the requirement cannot be satisfied within the ImageProfile.
VIB VMware_bootbank_esx-base_6.7.0-3.73.14320388 requires esx-update << 6.7.0-3.74, but the requirement cannot be satisfied within the ImageProfile.
Please refer to the log file for more details.
Maybe my esxcli is rusty. Luckily there’s another way if you have ESXI hosts that can connect to the internet. The first step is to open up the hosts’s firewall so it can connect out:
esxcli network firewall ruleset set -e true -r httpClient
Next, to prove connectivity and get the correct update name, the following command can be use to list the available software profiles:
esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep ESXi-6.7.0-201912
The “grep” command at the end can be adjusted to filter the results. You don’t want to soft through EVERY update available.
In my case that returned me four results:
ESXi-6.7.0-20191201001s-standard VMware, Inc. PartnerSupported 2019-11-25T11:42:42 2019-11-25T11:42:42
ESXi-6.7.0-20191204001-standard VMware, Inc. PartnerSupported 2019-11-25T11:42:42 2019-11-25T11:42:42
ESXi-6.7.0-20191201001s-no-tools VMware, Inc. PartnerSupported 2019-11-25T11:42:42 2019-11-25T11:42:42
ESXi-6.7.0-20191204001-no-tools VMware, Inc. PartnerSupported 2019-11-25T11:42:42 2019-11-25T11:42:42
The second entry is the one that I wanted. To apply it, just pop the name of the profile in to the following command:
If the update is successful (it can take a few minutes, be patient), you should see something like this (I’ve truncated the output as it’s a bit long):
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: VMW_bootbank_bnxtnet_184.108.40.206-24vmw.6220.127.116.1120388...
All that remains in theory is to close the firewall access off and reboot the host:
esxcli network firewall ruleset set -e false -r httpClient
That worked for two of my hosts. But the third refused to play ball. When I tried to apply the update I got an error.
[Errno 28] No space left on device
vibs = VMware_locker_tools-light_18.104.22.16873994-15160134
Please refer to the log file for more details.
This was pretty simple to solve by adjusting the system swap settings for the host through vCenter. Head to the Configure tab for the host and locate “System Swap”. Edit the settings, and enable the host to use a specific datastore (the first option below).
I retried the update and it went through. vCenter updates were applied via the normal mechanisms (https://vcenter-fqdn:5480).
vSphere 6.7 was released several months ago, and I’ve been meaning to upgrade my homelab for a while now. vSphere 6.5 has been pretty rock-solid, but it’s time for me to keep up with the Joneses. This post covers my upgrade process and experiences.
My original vCenter server was built straight on to version 6.5 when that first launched, way back when. In theory there was nothing wrong with it, except for a deployment decision that I was no longer happy with. When I deployed my vCenter previously, I configured it with an external Platform Services Controller (PSC) as I wanted to mess about with load balancing PSCs at the time. The messing around didn’t take long and I moved on to other things. Problem is, you cannot (currently) go from an external PSC to an embedded one and the external PSC was an extra piece of complexity that I just didn’t need anymore.
That pretty much left me with one option: migrate to a new vCenter.
Deploying vCenter is a doddle, and I won’t cover how that works. What I will mention though is how I moved my hosts and VMs across. The first step was to liberate one of my 6.5 ESXi hosts from the original cluster and add it to the new vCenter. At this time, I didn’t upgrade the host itself to 6.7 for reasons that will be apparent in a minute or two.
Secondly, I went through the VMs that I had registered in my original vCenter and weighed up whether or not I still needed them. Things like old distributed vRA deployments to a quick trip to the virtual bin, other things like AD, jumphosts, remote access solutions etc were powered down and removed from the inventory before being re-added to the new vCenter.
Before long, there wasn’t much left and what little is left will probably be left idle for a couple of weeks before I bin it completely.
A colleague of mine was working with a customer recently on some changes to their automated VM provisioning process (they’re not vRA customers… yet). He got stuck trying to get around a particular challenge with the automatic naming of network interfaces in certain Linux distributions.
The customer in question is using vRealize Orchestrator (vRO) to create (not clone) their Virtual Machines from a JSON structure that is supplied by an external system. In that structure there are definitions for the hardware, OS network identity (name, IP etc) and OS installation sources (ISO file for installation and floppy image for a ks.cfg (KickStart) file).
Once the JSON object is provided to the vRO workflow, the VM is created, booted and automatically starts to install and configure itself.
Customer’s Simple VM
Simple VMs have a number of disks defined (for root, opt, var, swap etc partitions) that are attached to a single ParaVirtual SCSI adapter. The VM is also equipped with a single VMXNET3 network adapter.
In this configuration, there is no problem. The installation of the OS runs through to completion and the VM is handed off to Puppet and eventually goes in to service.
Customer’s Complex VM
For the provision of Linux-based Oracle servers however, the customer wanted to be able to specify not only extra disks and partitions, but extra SCSI controllers too. Continue Reading →
A customer that I’m working with at present asked this week if the minimum privileges required for vRA to access a vSphere Endpoint could be documented. As someone who isn’t a fan of unnecessary wheel re-invention, my initial response was to direct them to the relevant VMware documentation (vRA 7.3 vSphere Agent Requirements).
Then they explained why that wouldn’t quite cover their requirement. I won’t explain exactly why, but they wanted a matrix that showed exactly what privileges each of the vRealize products (and associated management packs) needed in vCenter to provide to their security team. Somewhere in the dark and dusty reaches of my mind, a lightbulb flicked on…
Wait, I’ve done this before!
Like a number of other bloggers in my industry, I started this as a place to record some of things that I was doing in the hope that they might be useful to someone else, or even useful for myself in the future. Continue Reading →
Unless you’re new to vSphere, you’ll probably have heard about PowerCLI. You may already be using it regularly or perhaps you’ve found the occasional use for it and used one or more of the many excellent scripts that can be found on the internet. Either way, unless you’re an advanced user (or even a guru) of PowerCLI, there’s a book that’s been released recently that could be worth a look.
“Learning PowerCLI”, by Robert van den Nieuwendijk, was released just a few weeks ago from publishers Packt Publishing. The author has posted many times on his blog with useful scripts, one-liners and tips for using PowerCLI in the past. Several times an issue that I’ve had has lead me to his blog so I was very interested to see if his knowledge and experience had translated well into book form.
Although I did read through the book from cover to cover, it’s not really that sort of book. PowerCLI and Powershell are technologies that you can easily dip into when a specific need arises and I found that trying to absorb the entire contents of the book was hard-going. That shouldn’t be taken as any sort of slight against the author’s writing style, it’s just the subject matter doesn’t lend itself to being the kind of book that you can’t put down. It is, though, the kind of book that you want to pick up and learn from. I’ve been using Powershell and PowerCLI for many years and I was surprised at the number of things that I learned!
The book starts simply enough by covering the installation and instantiation of PowerCLI as well as proving a few common examples of PowerCLI’s most commonly used cmdlets so that a reader new to the technology can see some immediate benefit. Before things get too heavy, Robert covers some of the most useful Powershell commands available: Get-Help, Get-Command and Get-Member. He also covers a number of useful Powershell tips and best practices whilst simultaneously keeping the reader’s mind on PowerCLI before delving into some more focussed topics, such as:
Working with vSphere hosts
Working with Virtual Machines
Working with Virtual Networks and Storage
Managing core vSphere / vCenter functionality
As I’ve already stated, I found the book very useful as it taught me a number of things I didn’t already know, allowing me to correct some bad scripting habits and improve a number of areas of scripts that I’m producing for a current project. People with a very strong grasp of Powershell and PowerCLI already might find that there’s a limit to what they gain from the book but beginners and intermediates alike should find that there’s plenty to take away and use.
(This is all based on information that’s in the public domain at the time of writing and is all my own opinion. I may very well be wrong!)
ESXi first saw the light of day as version 3.5 in 2007 / 2008. Rumours were rife after ESXi 4.0 was released in 2009 that the clock was now ticking on ESX “Classic”. With the release of 4.1 in 2010 VMware finally confirmed the rumours and, from 5.0 onwards it’s been ESXi only.
You know this already of course if you’ve been working with vSphere for any length of time. The reason that I’m bringing it up though is because I think it’s a clue as to what’s going to happen to vCenter in the future.
The vCenter Server Appliance (vCSA) first appeared as a technology preview called “vCenter 2.5 on Linux”. It became vCSA as of vSphere 5. Subsequent releases (5.1 and 5.5) have seen many changes and it’s becoming more compelling with each version. Could it be only a matter of time before VMware announce that vCSA will be the only version of vCenter available? I believe it is VMware’s intention, yes.
Consider VMware’s recently published convergence plan for vCD. It states that the functionality offered in vCD will gradually be separated and merged into either vSphere / vCenter or into vCAC. The timetable for this change isn’t clear yet but given that vCD is Linux based, it might be more logical (or simpler) to integrate some of its functions into vCSA rather than into vCenter for Windows.
Look at many of VMware’s other products and a good number are linux appliance based. Of course there are exceptions, with perhaps some of the biggest currently being vCAC and Horizon View, but they’re both acquired products.
Increasingly we’re also seeing a move away from a Windows vSphere Client to a Web Client. Some functionality in vCenter 5.5 is only accessible via the Web Client. Of course the Windows Client might be kept on as a means to administer the free version of ESXi – time will tell.
None of these things are concrete proof of intent but they, and other things, make my spider senses tingle. It might not happen with vSphere.next as there could be some challenges to overcome still. There would have to be complete support and integration with VMware’s other products as one example. As another example, some customers might want vCSA to support MSSQL before they’d consider it ready for production.
In short though, I think that vCenter’s days on Windows are numbered. What that number is though, I couldn’t say.
Today, VMTurbo have launched their Virtual Health Monitor tool and they are letting it loose on the world for the whopping figure of… wait for it…
$0 – That’s right, free.
The tool is an updated and evolved version of the Community Edition of VMTurbo’s Operations Manager product and comes without restrictions on where and how often you deploy it and what it monitors. Ok, that’s not so clear.
The tool is downloaded as an appliance from VMTurbo’s website in a format optimised for one of the following platforms:
RedHat Enterprise Virtualisation (RHEV)
The format of the appliance is the only difference that you should find between the versions though as it’s capable of monitoring all of them at the same time. You just download the format that matches the virtual infrastructure where you want to host the tool.
The features that VMTurbo offer with the tool include:
Instant visibility to health and performance;
Unlimited use across virtual data centers of any size;
Free monitoring and reporting for any hypervisor;
Lowest total cost of ownership (TCO) due to innovative product architecture;
Weekly analysis of utilisation rates and areas to improve efficiency and reduce risk
As I’m waiting for the 428Mb appliance to download over the wet bit of string that is my broadband tonight I can’t speak to the experience of deploying it and what it looks like yet but I hope to have the time to kick the tyres on it tomorrow.
Besides being a good read in and of itself, the first book was good to help with VCAP4-DCD preparation. I imagine that this edition will be equally useful for VCAP5-DCD preparation. I look forward to reading it. Well, I will when my copy shows up (family rule: I’m not allowed to buy anything for myself in the month of my birthday).