Stephen Krujelskis

At the beginning of April, an ice storm hit Quebec and caused power outages lasting several days, particularly in areas with older trees where utility lines are not underground. When I started my ESXi host after 5 days offline, I ran into an error I've never seen before: It seemed like all of the VIBs were now failing UEFI Secure Boot validation. My first instinct was that due to an unclean shutdown, data on the boot volume was corrupted, and a reinstall would be required. The voice of my VMware TAM was in the back of my mind: I'm running non- HCL hosts, with NVMe SSDs not on the VSAN HCL , I should be thankful this works at all. And he's right. And I am.  However, I'm happy to report this had a quick fix: while goofing around in the BIOS to see how I could bypass Secure Boot and load ESXi, I noticed that my system clock had rolled back to 2017! As it turns out, I had been foiled by a $1 CR2032 battery  meant to keep time while the board is not connected to power. By s...

I originally posted this on LinkedIn. I'm still figuring out syntax highlighting on Blogger so please bear with the basic formatting for the moment. This morning I got a strange IM from one of my colleagues. A virtual machine he was working on had become inaccessible in vSphere, but seemed fine otherwise. I decided to have a look around. Hostnames have been changed and sequences have been shortened to protect my institution. The Summary page for the server, which we'll call dummy-vm-3, indicated that the host it was registered on was vm-host-13. However, the last migration in the Tasks logs before the machine disappeared, indicated a vMotion from vm-host-7 to vm-host-6. Odd. From the ESXi shell, we can tell which VMs are running, whether they are listed in the client or not. I sshed into "vm-host-13" and ran the following: ~ # vim-cmd vmsvc/getallvms Skipping invalid VM '1394' Vmid Name File Guest OS Version Annotation 1 dummy-vm-1 [datastore...