Main server: a Dell PowerEdge T110 II server (Intel Xeon E3-1230v2, 32 GB RAM, 512 GB SSD, 3 HDDs, 2 NICs) running 24/7 in my hallway, with VMware ESXi 5.5 installed.
Instructions for installing the (free) ESXi Embedded Host Client can be found at https://labs.vmware.com/flings/esxi-embedded-host-client#instructions.
I run all my Oracle development VM's on that server (most of those run CentOS, some Windows). Some Windows VM's as well; I do 90% of my daily work on one of those via Remote Desktop. And an OpenVPN Access Server Virtual Appliance takes care of VPN access (more info).
A highly recommended setup; it has been extremely reliable since I installed all that in 2013.

And to complete the server setup:
A HP ProLiant MicroServer G7 N54L with 6 GB RAM, Windows 10 and 1.5 GB HDDs (in RAID 5) acts as the (on-site, offline) backup server.
For off-site backups I use a couple of external HDDs.
Synchronization of data between the different machines on the network is handled by Resilio Sync (automatic) and SyncBack (manual).
An APC UPS and Zyxel Armor Z1 AC2350 router complete the server setup.

• Early 2020 update: The ESXi server and UPS mentioned above were running 24/7, while not being used for much besides hosting my website. So when I moved my site to an OVH VPS, I switched those off. Saves some power - and noise :-)
• Mid 2020 update: The Zyxel Armor Z1 AC2350 router has been replace by a Netgear Orbi 53S. The Zyxel was still running OK, but it did need a restart every few weeks, and the wi-fi of the Orbi covers the house a lot better.
• End 2020 update: I turned the ESX-i server back on for some test and fileserver stuff. I also upgrade to ESX-i 6.7, which is the last version that is (semi-)officially supported on the Dell PowerEdge T110 II, and works like a charm. Note that for ESX-i 6.7, I needed the A05 ISO (VMware-VMvisor-Installer-6.7.0.update03-16075168.x86_64-DellEMC_Customized-A05.iso) which can be found here. Older ISO versions gave "missing_dependency_vibs" errors during installation.

Problem:
"Recently we have installed some dev machines using Windows 10 as the latest system by Microsoft. Since we’re using VMware ESXI 5.1, we wanted to use the vSphere client to access the VM host using this GUI. However, we ran into issues installing the vSphere setup to the brand new Windows 10 system.
The problem: You simply cannot get the client to install. At some point, the installer stops and you don’t see the window to show up anywhere on your desktop. If you check the window title in Task manager, it says something about contact your network administrator."

Solution:
Unzip the installer file (using 7-zip) and manually install Microsoft .NET Framework and Microsoft Visual J# 2.0 x64 (located in the unzipped redist directory).

Source and more info: http://blog.pragbits.com/it/2015/09/07/vsphere-client-install-windows10/

If your mouse pointer doesn't match the cursor position in a VM console, making the VM quite uncontrollable, this probably has to do with Windows DPI settings.

For me (ESXi 5.5 on Windows 10 Pro build 1803 with a 4K monitor), this fixed it:

• Locate the VMware vSphere Client (in my case this is at "C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe").
• Right-click and select Properties.
• Go to tab "Compatibility" and click on "Change DPI Settings".
• Under "High DPI scaling overrride", make sure "Override high DPI scaling behavior" is checked and set the "Scaling performed by" dropdown to "Application".
• Click OK and Apply, and OK again.

The application doesn't look very good after this fix (all sorts of scaling issues, and things are very small on my 4K monitor) but at least it is workable.

Some more info (a bit outdated): https://answers.microsoft.com/en-us/windows/forum/windows8_1-hardware/vmware-cursor-position-doesnt-match-screen/5bf103d6-eb6f-4d90-a417-31c78c0da0e1

Workstation Player (15.5) also has some scaling issues on my Windows 10 (2004) machine. If you resize the Player window of a CentOS 7 VM with a Gnome desktop (with VMware Tools installed) the cursor position goes haywire. And I suspect any other OS will have the same issue as well.
The fact that there are 2 external monitors attached to my laptop (and 1 internal of course), all with different resolutions and DPI's, probably doesn't help :-)

A partial solution is similar to the vSphere Client solution above, except that I needed to select "System" instead of "Application". "System (Enhanced): works as well.
It is not a 100% fix however; scaling the Player windows works fine now, but if you move the windows to another monitor the same issue occurs.

Open up the following file in a text editor:
%Appdata%\VMware\preferences.ini

Add this line, changing the path to your desired location:
prefvmx.defaultvmpath = "D:\VMs"

Save, restart VMWare Player, and your new location should work when creating a new VM.

Add a Windows 11 compliant TPM to the VMware Workstation (Player) 16.2.0
Info to be found here.

• Ensure you are updated to version 16.2.0 (Pro - Player ~600mb)
• Ensure VMware (manager) is not running
• Go to the directory where the VM is stored (for example D:\VM\Windows 11 Dev)
• Open the file with the .vmx extension with Notepad
• Add the line managedvm.autoAddVTPM = "software"
• Save the file by closing it
• Double click on it to open it in VMware Workstation Pro or Player
• Start your VM

How to install Windows 11 without a Microsoft account
Basically, turn off your internet connection... more info here.

Windows 11 on Workstation 16 gives "This virtual machine is encrypted"
After moving my VM to another SSD (on the same PC), I got this message.
I found some info that seemed helpful: https://communities.vmware.com/t5/VMware-Fusion-Discussions/VM-encrypted-itself-don-t-know-the-password/td-p/2874949 and a possible solution here: https://www.syvik.com/multidesk/howto.win11.vmware16.en.html.
Haven't tried that solution yet - it was just a VM for testing, so why bother - but it might come in handy in the future.

I was wondering how VMware Workstation Player (16) handled assignment of cores and threads.
The Processors section of the Settings is a bit confusing, stating you can choose "Number of processor cores".
So to test it I set that to 4 on a Windows 11 VM. While Taskmanager reports 2 sockets and 2 virtual processors (which is a confusing way of reporting it, but sort of logical), Cinebench R23 reports just 2 cores. And my 12 core (24 thread) AMD 5900X Windows host reports that while Cinebench is running, only 11% CPU is used. Which would indicate around 2 out of 12 CPU cores including their threads (plus some overhead).
Since the maximum I can set it to is 24 (same as the number of threads on my host CPU), it would seem that "Number of processor cores" actually means "Number of host threads presented as virtual cores, using X sockets".
The outdated VMware documentation on this subject is from 2019, and still talks about "Number of cores per processor". Not very useful for version 16.

For about a year now, my VMware host restarts every few weeks, without any obvious reason. At first I didn't pay too much attention to it; it was inconvenient but I wasn't doing any daily work on it so it didn't bother me too much.
But for the last few months I started using a Windows VM on a daily basis, and then spontaneous restarts (while having way too many files open at once, of course) really get on your nerves.
I put it down to the age of my server (hardware slowly dying is always a possiblity), or maybe the fact that ESXi 6.7 is not really supported, or that I added an unsupported second NIC.
However, after a while I started to notice a pattern: according to the uptimerobot service I use, the server restarts always happened a few minutes after midnight, which seemed weird. So, time for some digging :-)

SSH on the ESXi host, as root:
cd /var/run/log grep vobd.log -e 'esx.audit.host.boot' 2021-01-10T11:48:03.548Z: [UserLevelCorrelator] 50342654us: [esx.audit.host.boot] Host has booted. 2021-02-06T23:06:15.577Z: [UserLevelCorrelator] 51158219us: [esx.audit.host.boot] Host has booted. 2021-02-24T15:38:50.493Z: [UserLevelCorrelator] 50567138us: [esx.audit.host.boot] Host has booted. 2021-03-06T23:06:16.126Z: [UserLevelCorrelator] 50567641us: [esx.audit.host.boot] Host has booted. 2021-04-06T22:06:16.518Z: [UserLevelCorrelator] 50933847us: [esx.audit.host.boot] Host has booted. 2021-05-06T22:06:13.808Z: [UserLevelCorrelator] 50970934us: [esx.audit.host.boot] Host has booted. 2021-05-14T10:55:02.566Z: [UserLevelCorrelator] 50933709us: [esx.audit.host.boot] Host has booted. 2021-06-06T22:06:16.396Z: [UserLevelCorrelator] 51071448us: [esx.audit.host.boot] Host has booted. 2021-07-06T22:06:20.640Z: [UserLevelCorrelator] 51693107us: [esx.audit.host.boot] Host has booted. 2021-08-06T22:06:16.022Z: [UserLevelCorrelator] 51166492us: [esx.audit.host.boot] Host has booted. 2021-09-06T22:06:17.246Z: [UserLevelCorrelator] 51240447us: [esx.audit.host.boot] Host has booted. 2021-10-06T22:06:14.434Z: [UserLevelCorrelator] 51262225us: [esx.audit.host.boot] Host has booted. 2021-10-17T12:24:34.733Z: [UserLevelCorrelator] 52099901us: [esx.audit.host.boot] Host has booted. 2021-11-06T23:06:17.710Z: [UserLevelCorrelator] 51001575us: [esx.audit.host.boot] Host has booted. 2022-01-07T23:06:19.156Z: [UserLevelCorrelator] 51726893us: [esx.audit.host.boot] Host has booted. 2022-02-07T23:06:15.391Z: [UserLevelCorrelator] 51643770us: [esx.audit.host.boot] Host has booted. 2022-02-19T16:28:53.646Z: [UserLevelCorrelator] 51771957us: [esx.audit.host.boot] Host has booted. 2022-03-07T23:06:17.550Z: [UserLevelCorrelator] 51714480us: [esx.audit.host.boot] Host has booted. This log uses UTC, so the majority of host boots indeed happened 6 minutes after midnight (local time). And all on day 6 or 7 of the month - so this must be software related, not hardware.

Next step, the kernel log (a few minutes before the latest restart):
cd /var/log vi vmkernel.log [...] 2022-03-07T23:00:14.050Z cpu2:2099872)NetPort: 1580: disabled port 0x2000006 2022-03-07T23:00:16.195Z cpu7:2099862)VSCSI: 2623: handle 8195(vscsi0:0):Reset request on FSS handle 986341 (0 outstanding commands) from (vmm0:win10-server-01) 2022-03-07T23:00:16.195Z cpu7:2099862)VSCSI: 2623: handle 8196(vscsi0:1):Reset request on FSS handle 1117411 (0 outstanding commands) from (vmm0:win10-server-01) 2022-03-07T23:00:16.195Z cpu0:2097360)VSCSI: 2903: handle 8195(vscsi0:0):Reset [Retries: 0/0] from (vmm0:win10-server-01) 2022-03-07T23:00:16.195Z cpu7:2099862)VSCSI: 2623: handle 8197(vscsi0:2):Reset request on FSS handle 1117412 (0 outstanding commands) from (vmm0:win10-server-01) 2022-03-07T23:00:16.196Z cpu0:2097360)vmw_ahci[0000001f]: scsiTaskMgmtCommand:VMK Task: VIRT_RESET initiator=0x43071c914080 2022-03-07T23:00:16.196Z cpu0:2097360)vmw_ahci[0000001f]: ahciAbortIO:(curr) HWQD: 0 BusyL: 0 2022-03-07T23:00:16.198Z cpu0:2097360)VSCSI: 2691: handle 8195(vscsi0:0):Completing reset (0 outstanding commands) 2022-03-07T23:00:16.198Z cpu0:2097360)VSCSI: 2903: handle 8196(vscsi0:1):Reset [Retries: 0/0] from (vmm0:win10-server-01) 2022-03-07T23:00:16.198Z cpu0:2097360)vmw_ahci[0000001f]: scsiTaskMgmtCommand:VMK Task: VIRT_RESET initiator=0x43071c914480 2022-03-07T23:00:16.198Z cpu0:2097360)vmw_ahci[0000001f]: ahciAbortIO:(curr) HWQD: 0 BusyL: 0 2022-03-07T23:00:16.200Z cpu0:2097360)VSCSI: 2691: handle 8196(vscsi0:1):Completing reset (0 outstanding commands) 2022-03-07T23:00:16.200Z cpu0:2097360)VSCSI: 2903: handle 8197(vscsi0:2):Reset [Retries: 0/0] from (vmm0:win10-server-01) 2022-03-07T23:00:16.200Z cpu0:2097360)vmw_ahci[0000001f]: scsiTaskMgmtCommand:VMK Task: VIRT_RESET initiator=0x43071c914840 Notice the combination of "Reset" and "vmm0:win10-server-01" on some lines, that is suspicious... VM "win10-server-01" is one of my Windows 10 clients, mainly used as a file and backup server.

So, on to the event logs on that Windows VM: Event Viewer -> Event Viewer (Local) -> Windows Logs -> System
I could match ALL the "6 minutes after midnight" host boot events to entries like this: The process C:\Program Files (x86)\APC\PowerChute Personal Edition\mainserv.exe (WIN10-SERVER-01) has initiated the shutdown of computer WIN10-SERVER-01 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Legacy API shutdown Reason Code: 0x80070000 Shutdown Type: shutdown Comment: --- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="User32" Guid="{b0aa8734-56f7-41cc-b2f4-de228e98b946}" EventSourceName="User32" /> <EventID Qualifiers="32768">1074</EventID> <Version>0</Version> <Level>4</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x8080000000000000</Keywords> <TimeCreated SystemTime="2022-03-07T23:00:03.5531126Z" /> <EventRecordID>26829</EventRecordID> <Correlation /> <Execution ProcessID="444" ThreadID="1364" /> <Channel>System</Channel> <Computer>win10-server-01</Computer> <Security UserID="S-1-5-18" /> </System> - <EventData> <Data Name="param1">C:\Program Files (x86)\APC\PowerChute Personal Edition\mainserv.exe (WIN10-SERVER-01)</Data> <Data Name="param2">WIN10-SERVER-01</Data> <Data Name="param3">Legacy API shutdown</Data> <Data Name="param4">0x80070000</Data> <Data Name="param5">shutdown</Data> <Data Name="param6" /> <Data Name="param7">NT AUTHORITY\SYSTEM</Data> </EventData> </Event>
APC PowerChute Personal Edition is an application that monitors the APC UPS attached to the ESXi host. As to why it would periodically shut down the client at the beginning of each month: no idea...
I have been experimenting with this in the past, in an attempt to have the application gracefully shut down the ESXi host during a power cutoff. But as far as I can recall I never managed to get that to work - but maybe I did somehow. Even so, I certainly didn't intend it to restart the host instead of doing a shutdown!...
This nice VMware article Determining why an ESXi host was powered off or restarted (1019238) did not provide any additional info this time, but it might come in handy in the future.

Maybe I will dive into this again some day, but for now I will just uninstall the APC application and unplug the USB cable of the UPS - and see what happens on April 6th or 7th 2022...
Update on April 7th 2022: Still up and running!