Let’s start with the definition of a VMWare lab. It’s a non production scale system that has enough hardware and software to perform the function under test. In my case that’s a couple of different Intel NUC devices with 500GB to 1TB of SSD, 32GB DDR3 or DDR4 RAM and an i5 or i7 CPU. I also have run everything under ESXi as the host OS.The decision to use ESXi was a tough one. VMWare offers a free version however there are limits to it’s capability like access to APIs which permits docker-machine to spawn client instances. I could have installed CoreOS and run everything in Docker containers but that has it’s limits too.Things get even more sketchy because the CLI version of the updater has a number of limits. For example if the /tmp folder partition is not big enough the update process will complain about insufficient disk space… and worse yet the only documented work around does not work.Here’s how I managed my latest upgrade: log into vmware and get the latest patch file as a .ziphttps://my.vmware.com/group/vmware/home enable SSH services on the target host suspend or shutdown all of the active clients on the target host SSH-mount the target host upload the .zip file from step (1) ssh into the target host[7.1] list the contents of the .zip file and determine which patch to applyesxcli software sources profile list -d /vmfs/volumes/SSD_01/update-from-esxi6.7-6.7_update02.zip[7.1] perform the upgrade (get the target path correct)esxcli software profile update -p ESXi-6.7.0-20190402001-standard -d /vmfs/volumes/SSD_01/update-from-esxi6.7-6.7_update03.zip probably require a reboot… as indicated in the result. It’s a good idea to connect a monitor so you can see the results. I have one machine that will refuse to boot from time to time. restart or resume the guests on the target hostHere is a good reference but I would double check the URLs very carefully to make sure i was not running anything that make my systems vulnerable… like downloading the patch from a 3rd party and there are plenty of those.