An ode to joy – or why you don’t have to mourn the free ESXi

An ode to joy, or why you don’t have to mourn the free ESXi. An obituary.

But before I go into depth here, I would like to declare the following:

This blog post is reflecting my personal opinion. Based on my knowledge and experience, as well as the things I have read on the internet and heard from people directly and discussed with them, I have written this blog post.

The title of this blog post says a lot. At least I think so. And I’m glad you stumbled across this blog post or clicked the link wherever it has been posted. In the last few days, there has been a lot of reading about the fact that VMware by Broadcom has canceled the free ESXi hypervisor. And yes, that may not be the fine English way to mash such a product. I don’t even know if there is a “good” way to do something like that.

Yes. It’s bad that the “free ESXi” has been canceled. At least according to what I read about on X (Twitter) and some IT news portals. People were (and still are) angry about this move of thinning out the product portfolio. I never used this free version, and I wasn’t even aware that this was such a big thing. But that doesn’t count here.

Yes. There are alternative hypervisors, like Hyper-V, Proxmox, and others, and they are free. You can run virtual machines even on storage systems like TrueNAS or Unraid (the last one does cost some bucks). And a free hypervisor, I don’t care about the flavor, might be just enough for some people. They may run a homelab with some VMs, maybe some production services for their home network like Pi-Hole, to name one.

But this is it.

Read more

Welcome and Goodbye – New Job!

The last few weeks, and probably months, it was very quiet on my blog. I hadn’t much time to investigate, test, try, and write things down. I had a more important focus over the past few months. And I usually don’t bring up personal things on my blog. But beginning with the 1st of December 2023, I’ll explore new horizons. No, I’m not going on a world tour, or a long holiday voyage. I’m switching my job.

The past

I worked for nearly six years for a company in the high-tech area, started there as an ICT systems specialist, and made it up to ICT systems engineering through the years, with lots of learning, certification, and dedication. My last employer was a company in the high-tech area, with surface treatments, coatings, filaments, etc. The last few months I’ve spent with different projects, documentation work, teaching our internal service and support people, and also handing over things to my team properly. I’m feeling confident that everything is fine and my former coworkers can get over “the loss”. Now it’s time for me to explore new horizons.

The future

The company which hired me is located in the healthcare branch. During the past few months, this company grew to the largest rehabilitation provider in Switzerland: they operate more than 800 beds and employ around 2,100 people. I’ll be working in the IT team (who would have thought) and will take over the responsibility for their VMware Horizon VDI infrastructure. What a great new challenge!

It’s not easy to quit a job and start something new. Everyone who did that probably knows what I’m talking about. And the fact that my last employer and I had a good relationship didn’t make it any easier.

Thank you

The last nearly six years have been very interesting, instructive, and challenging. I’ve met so many great people with in-depth knowledge and a sense for the business. I have to thank my boss for the many years and the trust he gave me. Also many thanks to my team and coworkers for all the support I received when I needed it. You did a great job folks!

How to reset the ESXi root password?

When I check my blog, I can see the last post from February 2022. That’s a long time ago already! Time to write something, isn’t it?

Back in the days when I was working as a Systems Engineer for an IT service provider, it was much easier to write blog posts. Now as a “customer” I don’t find the time or the ideas, or maybe I’m forgetting blog post ideas, not sure why. At least that’s my thought. I’m always struggling if I should blog about this or that, is it worth writing about it, or are there gazillions of blog posts writing about the exact same thing?

Today’s blog post is exactly such a topic, I assume, that has been written about already some times, at least. But it was a problem we had during an ongoing vSphere upgrade project just recently. And I was able to help our operations team to move on with their work. So why not write a blog post about it?

What happened?

As mentioned, we’re currently working on a global vSphere upgrade project. We’ve got many ESXi hosts and clusters all around the world. So far nothing special. And even when there are easy-to-understand guides available internally (I wrote these myself and triple verified), maybe one or the other point on a checklist is forgotten, or you just didn’t think of it in the heat of the moment. One point is “Check the current credentials if they are working”. Thanks to the following troubleshooting guidance, there was no show stopper and only a few minutes of delay for the upgrade of one ESXi host.

The root password for one of the ESXi hosts didn’t work. No chance to log in through the Web UI nor SSH. So what to do then?

There are only two officially supported ways to reset the root password of an ESXi host. You can reinstall the host from scratch or use host profiles. Well, reinstallation would be an option as we’re upgrading vSphere anyways. But this would require some additional time because of the ESXi configuration. Using a host profile can be done, but needs an Enterprise Plus license.

Because we have some spare licenses left for Enterprise Plus (not yet needed for hosts, but already planned to use), we decided to go the way with the host profile. And it wasn’t rocket science!

How can you do it?

The actual troubleshooting chapter is divided into two parts. The first part is changing the current license of an ESXi host, the second part is all about the host profile.

If you don’t have an Enterprise Plus license, then you have to plan reinstalling the ESXi server from scratch.

Change the host license

  1. Log in to the vCenter WebClient (https://yourvcenter.domain.com/ui)
  2. In vCenter, go to Home and then choose Administration and then Licenses
  3. Click the Assets tab and then the HOSTS button
  4. In the Asset column, you can click the filter icon and search for the ESXi host where you want to assign a different license
  5. Select the host, then click Assign License just above the list
  6. Choose the Enterprise Plus license, and click OK
  7. The host will now have an Enterprise Plus license, and you can continue with the steps below.

Remember to switch back the license to the one that was assigned to the ESXi host before.

Extract, change, and apply the host profile

  1. Log in to the vCenter WebClient (https://yourvcenter.domain.com/ui)
  2. In vCenter, go to Home and then choose Policies and Profiles, and click Host Profiles
  3. Click → Extract Host Profile
  4. In the Extract Host Profile menu wizard → Select the host you want to update the password for, then click Next
  5. Name the Host Profile and click Next and then Finish to complete the capture of the host profile template
    • The new host profile should appear on the Host Profile Objects Field
  6. Right Click the new Host Profile and choose → Edit Host Profile
  7. In the Edit Host Profile wizard, uncheck all boxes
  8. Then using the search filter search for → root
  9. Highlight and then select the check box for → User Configuration / root
    • Make sure to only select this item when searching for root
  10. A configurable window will display the root user configuration
  11. At the Password subsection, choose → Fixed password configuration
  12. Here you have to fill in the new password and confirm it before proceeding
  13. Double-check that all other non-applicable boxes have no check marks and proceed to Finish
  14. Once the task completes, right-click the new host profile and choose → Attach/Detach Hosts and Clusters → then select the host in the wizard
  15. Right-click the host profile again, and select Remediate
  16. Remove/detach the host profile from the host
    • At this time the host password should be successfully upgraded

Please be careful. It is recommended that you do this when the host is in maintenance mode. If it is part of a cluster, great. You can move all VMs away from that host with DRS (automatically or manually). If it is a standalone host, make sure to shut down the VMs first, just in case the host reboots. During the writeup, the affected host did not reboot, but there was a checkbox in the remediation settings that could cause the host to reboot.

Setting up Visual Studio Code for WSL 2

Recently, I’ve published a blog post on how to set up the Windows Subsystem for Linux version 2 (WSL 2). I’m currently learning Ansible and I was searching for a solution that fits my needs in terms of usability, knowledge, etc. I’ve tested some Linux distributions, tried to connect remotely with my coding tool of choice, Visual Studio Code, but all were complex or didn’t work as expected. That’s the reason I gave WSL 2 a try.

I really like Visual Studio Code. It’s fast, supports a wide range of languages, and it’s free. Yes, free. And you don’t even need a registration nor a login to download it! VSCode also supports a variety of extensions. If it detects that you’re writing something in YAML, it might help you with a pop-up that there is an extension for it, for example, to properly highlight the syntax of that language. And that’s just one great example. With the combination of WSL 2 and VSCode, I’m able to write scripts (or playbooks in Ansible terms) and run them directly in the same tool. How cool is this?

Today, I’m going to show you how you can set up Visual Studio Code to use it with your already installed WSL 2 Linux distribution (at least when you read my previous blog post and followed the guide there).

Read more

Setting up Windows Subsystem for Linux Version 2 (WSL 2)

A few weeks ago I started getting familiar with Ansible. I’m far away from being an expert, and I’m probably not going so far anyway. But I want to learn some new things and train my skills. One quote which reminds me every day when I try and fail at something:

Even a lesson learned the hard way is a lesson learned.

Before getting deeper into Ansible, I had to find out how I can use Ansible, how I have to set up everything I need to get started. And it wasn’t easy. But I might have found a very convenient way. I’m not a Linux pro, but I know some things, and I’m flexible in learning new things. I have created the following guide for my own documentation, but hopefully, you find it helpful If you’re new to Ansible and you want to find out more like I wanted to do.

And before we dive deep here, I just assume that you already know that Ansible is an automation engine, driven by so-called playbooks. The playbooks contain your code (like for example, the instruction to search updates and install them in a specific Linux VM), which you then run against your infrastructure.

So let’s dive into the topics now. And yes, there are many guides available on the internet, showing you how to set up WSL 2. I’ve checked many of these guides during my initial setup tests etc. Unfortunately, most were not complete, others missed some steps (which means more research and tests needed). This guide has been developed and tested by myself, step by step, to make the setup of WSL 2 as easy as possible for you.

Read more