VMware released ESXi 6.7 a little while ago, but it’s only been here recently have I started deploying it in my home and work lab environments. Below are two ways to easily upgrade your ESXi 6.5 hosts to ESXi 6.7 using the command line or by using the VMware ESXi offline bundle.
I was recently upgrading a VMware environment from vCenter Server Update 3b to Update 3e and during the scheduled change I had also planned on upgrading VMware Update Manager to Update 3e and ran into the following error:
VMware Workstation unrecoverable error: (vthread-3)
GetProcAddress: Failed to resolve ENGINE)load_aesni: 127
You can request support.
Looking for a possible solution at the VMware Knowledge Base came back with no results and to error message wasn’t overly useful either with “VMware Workstation unrecoverable error: (vthread-3)” as Workstation wasn’t installed on this server.
Just recently we have some hardware issues in our primary datacenter and during that time had a few VM’s that became unresponsive and needed to get them back online. The VM’s had stopped responding to the normal vSphere commands to reboot, shutdown or even restart. I didn’t want to power cycle the entire ESXi host and instead just power off an unresponsive VM.
Here is a quick and easy way to do just that using ESXTOP.
Just a quick heads up! Over the last week I’ve been upgrading our vCenter servers from version 5.5 to the most recent 5.5 Update 3b version and have ran into a small hiccup.
The upgrade of SSO, Web Client, Inventory Service and even vCenter server all went as expected without any issues. Then I rebooted the vCenter server and after the reboot noticed that the vCenter server service hadn’t started and when I tried to start it manually I then received the following error:
Error 1053: The service did not respond to the start or control request in a timely fashion.
VMware just published KB 2136854 regarding a new bug found in ESXi 6.0 that causes virtual machine backups, which use Changed Block Tracking (CBT), to be inconsistent. VMware says the cause of the issue is this:
This issue occurs due to an issue with CBT in the disklib area, this causes the change tracking information of I/Os that occur during snapshot consolidation to be lost. The main backup payload data is never lost and it is always written to the backend device. However, the corresponding change tracking information entries which occur during the consolidation task are missed. Subsequent QueryDiskChangedAreas() calls do not include these missed blocks, hence a backup based on this CBT data is inconsistent.
I’ve been asked several times how and why I setup my home lab to use NFS on my Synology NAS and thought a post detailing the steps would be best. First the why, when I purchased my Synology DS412+ about two years I recall seeing several people stating NFS was out performing iSCSI (like this post) on the Synology. It was strictly from reading other peoples findings that I started with NFS and have continued to use NFS without any issue. In fact I’ve been very happy with my DS412+ in a RAID 10 setup.
How I setup NFS on the Synology for my ESXi homelab is pretty simple as well.