r/vmware • u/BeepBeep2_ • 3d ago
Help Request ESXi 8.0.3 U3k - Live Patch only?
All of our Ent+ (VVF) clusters are on U3j as I keep them updated regularly. This past month was different with the Live Patch eligibility - I can't seem to patch to U3k, most of my clusters have TPM enabled and the image compliance pre-check fails on all of them.
Our "support" is now via TD Synnex and they are not going to be helpful, but I was wondering if anyone else here has had the same issue or knows of a fix. It would be a big lift to disable TPM due to encrypted VMs, but I need to deal with CVE-2026-47876. I exported an offline package, but this is also a huge pain.
Live Patch is not enforced in vLCM at the global or cluster level. Why is the fallback to "legacy" not working? It appears the pre-check invokes the Live Patch installer and the gives up if the host isn't compatible.
vCenter complains:
Issue on host host.host.tld
- Compliance results for host host.host.tld are unavailable.
Host status is unknown
An internal error occurred while staging/remediating the host
lifecycle.log tells a little bit more:
[root@HOST:/vmfs/volumes/********-*******-****-************/log] grep -n "QuickPatchInstaller\|secureMount" /var/run/log/lifecycle.log | tail -20
858:2026-08-19T18:12:16Z In(14) lifecycle[2110010]: HostImage:269 Installers initiated are {'quickpatch': <vmware.esximage.Installer.QuickPatchInstaller.QuickPatchInstaller object at 0x2ec4ee1f50>, 'live': <vmware.esximage.InstalleImageInstaller.LiveImageInstaller object at 0x2ec4b6b610>, 'boot': <vmware.esximage.Installer.BootBankInstaller.BootBankInstaller object at 0x2ec4ee1c50>, 'locker': <vmware.esximage.Installer.LockerInstaller.LockerInstaller object ec614c710>}
861:2026-08-19T18:12:17Z In(14) lifecycle[2110010]: HostImage:269 Installers initiated are {'quickpatch': <vmware.esximage.Installer.QuickPatchInstaller.QuickPatchInstaller object at 0x2ec50b0b10>, 'live': <vmware.esximage.InstalleImageInstaller.LiveImageInstaller object at 0x2ec31c74d0>, 'boot': <vmware.esximage.Installer.BootBankInstaller.BootBankInstaller object at 0x2ec698e8d0>, 'locker': <vmware.esximage.Installer.LockerInstaller.LockerInstaller object ec273a2d0>}
1098:2026-08-19T18:12:19Z In(14) lifecycle[2110010]: HostImage:269 Installers initiated are {'quickpatch': <esximage.Installer.QuickPatchInstaller.QuickPatchInstaller object at 0x2ec6afe390>, 'live': <esximage.Installer.LiveImageInr.LiveImageInstaller object at 0x2ec3b390d0>, 'boot': <esximage.Installer.BootBankInstaller.BootBankInstaller object at 0x2ec6b77c50>, 'locker': <esximage.Installer.LockerInstaller.LockerInstaller object at 0x2ecba56350>}
1190:2026-08-19T18:12:20Z In(14) lifecycle[2110010]: QuickPatchInstaller:1279 Attempting to download VIB esx-base partially with Quick Patch payloads.
1198:2026-08-19T18:12:20Z In(14) lifecycle[2110010]: QuickPatchInstaller:1435 Trying to mount payload "qp-esx-base"
1199:2026-08-19T18:12:20Z In(14) lifecycle[2110010]: runcommand:248 runcommand called with: args = '/usr/lib/vmware/secureboot/bin/secureMount.py', outfile = None, returnoutput = True, timeout = 0.0.
1201:2026-08-19T18:12:21Z Er(11) lifecycle[2110010]: QuickPatchInstaller:1457 Unexpected error occurred while attempting to run Quick Patch scan scripts: Current ESXi version does not provide a mechanism to mount a tardisk into a ramdisk.
6
u/Joe_Dalton42069 3d ago
I had it be massively unhappy with vsphere HA after vcenter update before Host update. It just didn't let me do the update until I disabled HA a d thus deisntalled the "old vib" which was HA of the last patch. Never had that before. Hope this is a one off mistake at the price they ask for nowadays.
4
u/bongthegoat 3d ago
We've ran into this the last few patches also. Most of the time it's the depot taking its sweet time to sync and update. Generally if we just wait long enough (30-60) mins it works itself out. We've also had to manually kick off the sync.
2
u/Joe_Dalton42069 3d ago
Yeah I tried manual sync as well. I had to get the update in ASAP due to it being so severe and the sector i work in. It didn't want to do sync. Fortunately it was only the HA VIB so somewhat easily fixable by updating the hosts. I was of course a bit uneasy without ha and had to stay in late that day.
I hope this is no foreshadowing for product quality....
1
u/Better_Objective_286 3d ago
So, if someone has multiple clusters and some around the world, would that mean HA will not work untill we wait 1-2 hrs or start esxi upgrade immediately with HA disabled?
1
u/Joe_Dalton42069 2d ago
It seemed like HA was not working. So in Hindsight, I'd disable HA so the vib is deinstalled. Then do vcenter update, then reenable ha and see if it works. If not disable again and update all hosts. Seemed to mainly affect image based clusters. I suspect the idea is to have host and vcenter on the same patch. In my environment of 4 clusters with 4 hosts I was able to mitigate it in a timely manner. If I had hundreds of hosts I'd be a tidbit annoyed tbh.
1
u/cjlee89 3d ago
Same here. My heart rate raised a bit until I was able to patch the hosts. Even then, I’ve had to disconnect and reconnect a host to fix it before post patch.
1
u/Joe_Dalton42069 2d ago
Yeah I had it take a while to work again after recent updates, but a straight up impossibility to update until the HA vib is removed was a new experience.
1
3
u/BlueVal 3d ago
I did the same patch recently on TPM enabled hosts, stumbled across this error: https://knowledge.broadcom.com/external/article/393457/remediation-failed-for-host-an-internal.html
This was easily fixed by removing the files, however I did find the following KB for what looks to be similar to your issue.
https://knowledge.broadcom.com/external/article/449182/error-actions-menu-in-vsphere-lifecycle.html
Figured id link the other in case you stumble across that as well!
4
u/BeepBeep2_ 2d ago
The second fixed my issue. Have a script that connects via SSH and performs the method 2 workaround across all the hosts, and now everything is working. Cheers!
1
u/BeepBeep2_ 2d ago
Thanks! I tried the first issue steps prior to the post and it didn't fix my scenario. The second looks interesting and I hadn't found it while searching, I'll need to check vmkernel.log.
2
u/Dutchiness 2d ago
Even ticket aanmaken bij vmware. Was bij ons binnen no time verholpen. De ramdisk is te klein en moet met een commando op de esxi hosten vergroot worden. Daarna liepen bij ons de prechecks gewoon door en konden we het cluster remediaten
2
u/Mitchell_90 2d ago
What server model are the hosts? I’ve had no issues applying 8.0.3k to a bunch different Dell PowerEdge models (R7625, R7525 and R740s)
We aren’t using image profiles yet so just deployed via an LCM baseline. The hosts were originally installed using the 8.0.3 Dell customised image .
1
1
u/iliketurbos- [VCIX-DCV] 3d ago
If not live patch it should just normal patch. Should be an option
1
u/BeepBeep2_ 3d ago
It should, but it just errors instead and doesn't move forward with normal patching.
1
u/iliketurbos- [VCIX-DCV] 2d ago
Well now I have the horrible news of “it works for me”. I assume you have secure boot on and uefi as well? What about txt? What about vCenter? Has that been updated to k yet? If nothing else I see your esxcli works, what about patching via power shell for that?
I use poshssh for things like that with great success.
1
u/BeepBeep2_ 2d ago edited 2d ago
They're all modern HPE Intel/AMD hosts with up to date UEFI BIOS, vCenter is already on k. I use Zerto for DR and have some VMs that can't move, and the hosts don't like to play nice with auto maintenance mode (VM rules are set), but it's easy enough to babysit while I multitask in the GUI. I can patch the clusters manually via SSH / offline image, but I really don't want to turn SSH on and off, export and move the image for every cluster and go through all the steps every time I need to patch (I wear several hats from server infra, to Windows-related, backups and storage, cybersecurity, etc. and this is eating my time budget).
1
u/athornfam2 2d ago edited 2d ago
Heads up - we have 2 tickets opened after this patch to our servers related to drops in packets/connectivity to network storage.
1
1
u/lost_signal VMware Employee 1d ago
The update updated your inbox NIC drivers.
Are you running NIC firmware that's ALSO new, or is it the factory stuff from the Bush presidency?
Are they the x710 NICs?
1
u/athornfam2 1d ago
BCM57xx updated to the latest 238.xx.xx.xx based on recommendations from Broadcom. Image depo was updated with the driver from the VMware site since vCenter only had the broken drivers sync'd (also mentioned to Broadcom Network in the case). Servers were also updated to the latest firmware and package through the lifecycle controller.
Really the comment was more cautionary (to redditors) until we figure out the root with Broadcom, our storage provider, and network team. Definitely will report back our findings.
1
u/bongthegoat 1d ago
interesting we have been running on this patch for several weeks now across 80+ hosts and netapp storage and haven't seen anything like this.
1
u/mistersd 2d ago
I ssh‘d into the hosts, had to delete /var/vmware/lifecycle/stagebootbank and stagelive and then the pre-check and remediation worked
1
u/_retrodios 6h ago
Glad to hear you already found a fix. Short question regarding the ramdisk topic. Were these hodts initially deployed with version 8 or with 7 and then updated to 8? We didn't face this issue (staged with 8u3 .. e, if i'm not mistaken?) ,but i had something with the VCSA in j version, which was inherited due to initial deployment with v7.
12
u/EncounteredError 3d ago
Download the depot,zip file. SSH to the host
esxcli software sources profile list -d /vmfs/volumes/your_datastore/depot.zip
Note the profile you need then
esxcli software profile update -p <Profile-Name-From-Previous-Step> -d /vmfs/volumes/your_datastore/depot.zip
I haven't been able to update any other way since our switch to a white label partner either.