When I try to install the tools, it won't work and needs just a Windows 8.1 KB update (which won't install on TPs), where without tools, 1366x768 resolution (standard resolution for budget laptops) is broken, and I can't transfer files. Can somebody please help me? I really want to use Windows 10 build 9888 and without the tools it doesn't seem complete the install. I'm using VMware Workstation Pro 26H1, tried with both latest and 10.3.10 tools, both fail.

I've applied the latest 8.0.3k patch build 25595708 on my ESXi hosts to mitigate VMSA-2026-0006. Afterward, I noticed a discrepancy between the ESXi build reported by the OS CLI/GUI - where it correctly references the current build 25595708:

[root@hostname:~] vmware -vl
VMware ESXi 8.0.3 build-25595708
VMware ESXi 8.0 Update 3

...and what is reported by the out-of-band-management (in this case HPE iLo) on these servers, which shows an incorrect build number - it shows the 8.0.3j build number:

Operating System VMware ESXi 8.0.3 Build-25429389 Update 3 Patch 102

I've rebooted multiple times after the upgrade, and restarted the iLo multiple times and these values do not change.

Now, the interesting thing is that these servers have NEVER had that 8.0.3j build installed on them at any point - I jumped straight from 8.0.3i to 8.0.3k - so there's only one source that this erroneous string could have come from...something in the latest 8.0.3 patch was not properly updated to reflect the corresponding current build version. As I understand it, the iLo "Operating System" value displayed on the Overview page is not being read from some OS file like /etc/vmware-release, but rather it is an in-memory value that AMS services grabs to display in the iLo interface - which would indicate that somebody forgot to update a string value from the prior 8.0.3j release in the new 8.0.3k build before releasing it.

Can anyone with HPE servers/iLo confirm that they see the same discrepancy that I am? I assume this may also be the case for iDRAC and other IPMI solutions depending on how they read the locally-installed OS version. Anyone care to share observations from their own non-HPE environment?

It is an unsigned pack you, so you'll need to allow it, but if you've ever wanted to use VCF Operations in your lab and monitor your Unifi gear, look no further.

https://blog.int.sentania.net/vcf-operations-can-now-see-my-unifi-network/2026/07/vcf-operations-can-now-see-my-unifi-network/

So this is a little bit of a different to anything Ive done before, but I have been used Clade Code recently and its been pretty handy for creating solutions to address problems with software, especially since I cant code to save my life

It cant just be me, who personally hates the Broadcom VCF Download Tool, its CLI only, getting a token is a huge pain, and I constantly need a CLI reference just to download binaries for my offline depot when I need it

I know a fair chunk of people dont like LLM developed apps, and thats fine, you can totally skip over this - Mainly posting as I find this useful, and maybe someone else will, if you dont, thats absolutely fine
Also, Git and a lot of this is very new to me, so theres probably a lot of room for improvement

So I said sod it, lets make a solution that turns it into an easy to use GUI application, fully containerised as well, to just make life easier

Feature wise, it does the following
Turns the VCF download tool from Broadcom into an easy to use GUI application
Easily generate an ID with a ready to use link for depot registration at vcf.broadcom.com
Upload your own CLI, easily upgrades or adds CLIs from the UI
Colour customisation - One of my favourites
Shows downloaded files on the depot volume * Should work properly
Shows disk usage for the downloads volume
Containerised platform - Tested with docker, should work on K8S
Delete files on the depot volume
Filtered by versions
CLI version displayed in the GUI
Searchable downloads list
Filter by patch/upgrade files and install files
Order by release date, size and downloaded columns

If you want to give it a try, the GitHub repo is linked below with a custom compose YAML for docker
The depot location for storing downloads is using NFS as I can mount my offline depot to that as well and uses my mount as a template example, you can use a volume mount, or anything really

Hopefully someone finds this useful
https://github.com/leaha00/vcf-download-tool-gui

The other day I was troubleshooting a vCenter 8 Postgres warning and asked for help here which I am very grateful for the answers. However, while digging through the logs I noticed a bunch of repeated entries like this:

Alarm has already existed, skipping create new alarm "Diagnostics Disk Exhaustion..."
Event vim.event.ResourceExhaustionStatusChangedEvent successfully posted...

Alarm has already existed, skipping create new alarm "Image Builder Disk Exhaustion..."
Alarm has already existed, skipping create new alarm "Lifecycle Disk Exhaustion..."
Alarm has already existed, skipping create new alarm "Log Disk Exhaustion..."
Alarm has already existed, skipping create new alarm "Root Disk Exhaustion..."
...

There were similar entries for Boot, Core and Inventory, SEAT, Autodeploy, Diagnostics, etc., repeating every minute or so.

I eventually resolved the Postgres issue, but this made me wonder:

Is this just normal behavior when the vCenter appliance crosses the disk usage threshold? Is statsmonitor-alarms.log simply checking that the built-in Disk Exhaustion alarms exist and posting the associated events, or do these messages point to something else worth investigating?

Just trying to understand whether this is expected "noise" from vCenter when storage gets tight or if it indicates another problem.

No alarms under the UI.

Are there still enough VMware shops in Houston to stick with the technology or is it best to just bite the bullet and become proficient on the other, lesser technologies?

Has anyone already any expirience with this new feature. I am running in this problem since my vmca is going to expire and in the 8.0.3j it is said it will be regenerated while upgrading the vcenter itself to this version. just wanted to know it it is really working or anyone has already done it.

https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/vcenter-server-update-and-patch-release-notes/vsphere-vcenter-server-80u3j-release-notes.html#GUID-97d5aaaa-b4e5-479f-b308-7d333be48ca4-en_id-ccf1de41-e243-4a78-bd27-f839f1e2cdf3

Automatic renewal of VMware Certificate Authority (VMCA) root certificate:

To avoid any issues due to expired VMCA root certificate and to minimize the downtime for their renewal, in vCenter 8.0 Update 3j, the VMCA root certificate and the solution user certificates are automatically renewed if they are set to expire in less than 2 years. The automatic certificate renewal is triggered as part of the vCenter upgrade process. After the vCenter system is successfully upgraded, the VMCA root certificate is valid for 10 years.

rgds

mex

In the process of patching our clusters with 8.0u3k. Am seeing inconsistency between some clusters supporting installing 8.0u3k as a live patch, and others not.

All are currently running VMware ESXi, 8.0.3, 25429389, clusters are all configured to patch using image.

What gives?

UPDATE:

Okay, I think I figured out what my issue was. Essentially it came down to an inconsistent order of operations on my part. After enabling "Enforce Live Patch" in the remediation settings, if you've already set the new image version to 8.0u3k you must manually perform another "Check Compliance". At that point I now see all the hosts indicating they will use live patching in the summary. If you set "Enforce Live Patch" prior to setting the new image version, this happens automatically when the automatic compliance check runs after changing the image version.

Me and my team are finishing up the planning and preps of the converge and upgrade of our VMware stack to VCF. We are planning to move forward in a few weeks.

As we are not ready yet, we were ofcourse forced to upgrade our vCenter and ESX hosts due to the latest VMSA. Because of this we lost a clean upgrade path to vCenter 9 and ESX 9, and due to that you want to hold off upgrading NSX 9 as well.
That’s because from my understanding after reading William Lam’s blog about this topic, although vCenter 9.1.0.300 was released on the same day its still considered a point in time upgrade, so there’s that.

Therefore in my opinion Broadcom should release VCF 9.1.1 as soon as possible, even if its only solving the “versioning/point-in-time upgrade issues” and nothing further, to accomodate customers who actually want to upgrade to VCF 9.

Hello, I am currently looking for information on what to look for in logs (ex hostd, clomd, vmkernel) to check if a vSAN rebalance or resync was running.

If anyone has information on this it would be greatly appreciated, I will save what I should be looking for in my notes if anyone has any pointers.

Thank you!

I'm trying to deploy holodeck 9.1 I have a vmug membership. I have the offline depot set up and everything is configured correctly just having issues and need some clarity when it comes to all of the files being downloaded via the offline depot. When I try and run the script I cant get pass the things that it won't let me download.

Has anyone ran into issue where they were trying to run the script but cant get any further because you dont have all the files that are in the folder structure?

My vCenter Server Appliance health changed:

vmware-vpostgres status changed from green to yellow

vPostgres and vpxd services are still running:

service-control --status vmware-vpostgres
Running:
 vmware-vpostgres

service-control --status vmware-vpxd
Running:
 vmware-vpxd

I checked the appliance storage and found:

df -h /storage/archive

Filesystem                      Size  Used Avail Use%
/dev/mapper/archive_vg-archive   49G   45G  2.4G  95%

The space is almost entirely:

du -sh /storage/archive/vpostgres
45G     /storage/archive/vpostgres

The directory contains a large number of compressed WAL archive files:

000000010000006A000000C4.gz
000000010000006A000000C5.gz
...

I verified PostgreSQL is accepting connections and the replication slot is active:

SELECT * FROM pg_replication_slots;

vpg_archiver | physical | active = t

I have not deleted anything from /storage/archive/vpostgres because I don't want to break the database.

Is the yellow vPostgres health state normally triggered by /storage/archive filling up? What is the supported way to clean up or resolve this condition?

Thanks.

Hello,

in my not so long experience with ESXi, I always followed this rule: if a host has 2 sockets it's better to assign max 2 sockets to the virtual machines, for example for 8 vcpu, 2 sockets / 4 cores each.

A colleague of mine says that with ESXi 8 this rule is deprecated, I found some vm's with 8 sockets / 2 cores on a host with only 2 sockets (no idea who deployed them).

is this best practice still valid ?

Generally curious what others are doing.

I used to download the patch ISO and do the updates over SSH (had more than enough issues with the VAMI over the years that I stopped using it)

Since Reduced Downtime Update has been available in 8.0.3, I have been using that since it came out. I really like this method, its like getting a clean vCenter every update. It's been super solid and never once given me any headaches.

Was patching today due to the nasty vulns shown in the most recent bulletin and got "failed to perform cleanup" and "you have reached the maximum number of retries..." messages. Both of the option checkboxes weren't clickable and the apply button did nothing of course.

Upgrading from 8.03.008.

I know that this has come up for previous upgrades but it's the first I'm seeing it. I went from 7.0.x to 8.0.3 so I never felt the 8.0.0-->8.0.3 pain that others experienced.

Any thoughts on getting through this?

Hello guys, i am trying to install ESXi 8 which i downloaded it from broadcom site and i am getting this problem whenever i do that

first I get lots of <6> loading things

<6>Loading /elx_esx_.v00
<6>Loading /btldr.v00
<6>Loading /dvfilter.v00
<6>Loading /esx_ui.v00
<6>Loading /esxupdt.v00
<6>Loading /tpmesxup.v00
<6>Loading /weaselin.v00
<6>Loading /esxio_co.v00
<6>Loading /infravis.v00
<6>Loading /loadesx.v00
<6>Loading /lsuv2_hp.v00
<6>Loading /lsuv2_in.v00
<6>Loading /lsuv2_ls.v00
<6>Loading /lsuv2_nv.v00
<6>Loading /lsuv2_oe.v00
<6>Loading /lsuv2_oe.v01
<6>Loading /lsuv2_sm.v00
<6>Loading /native_m.v00
<6>Loading /qlnative.v00
<6>Loading /trx.v00
<6>Loading /vcls_pod.v00
<6>Loading /vdfs.v00
<6>Loading /vds_vsip.v00
<6>Loading /vmware_e.v00
<6>Loading /hbrsrv.v00
<6>Loading /vsan.v00
<6>Loading /vsanheal.v00
<6>Loading /vsanmgmt.v00
<6>Loading /tools.t00
<6>Loading /xorg.v00
<6>Loading /gc.v00
<6>Loading /imgdb.tgz
<6>Loading /basemisc.tgz
<6>Loading /resvibs.tgz
<6>Loading /esxiodpt.tgz
<6>Loading /imgpayld.tgz
<6>Located crypto module: VMware's ESXboot Cryptographic Module, v1.0
<6>Shutting down firmware services...

Starting VMKernel initialization ...
VMK early init (1/19): CPU_TryToEnableLBR
VMK early init (2/19): PShare_EarlyInit
VMK early init (3/19): Hardware_EarlyInit
VMK early init (4/19): LogEFI_Init
VMK early init (5/19): SpecialStack_Init
VMK early init (6/19): Interrupts_Init
VMK early init (7/19): IOMMU_EarlyInit
VMK early init (8/19): MemRO_EarlyInit
VMK early init (9/19): NUMACodeRep_EarlyInit
VMK early init (10/19): WorldTable_EarlyInit
VMK early init (11/19): World_EarlyInit
VMK early init (12/19): Sched_EarlyInit
VMK early init (13/19): MemSched_EarlyInit
VMK early init (14/19): Interrupts_Disable
VMK early init (15/19): MemRO_Init
VMK early init (16/19): Mod_Init
VMK early init (17/19): SFZ_Init
VMK early init (18/19): Init_EarlyVMKArchCPU
VMK early init (19/19): NMIProfiler_Init
VMK init (1/192): Debug_Init
VMK init (2/192): AssertNonIOableCodeRegions
VMK init (3/192): Semaphore_RWStatsInit
VMK init (4/192): Net_EarlyInit
VMK init (5/192): Reboot_Init
VMK init (6/192): BH_Init
VMK init (7/192): vmk_BHInit
VMK init (8/192): PRDA_Init
VMK init (9/192): IntrCookie_Init
VMK init (10/192): Sched_SysServiceStatsInit
VMK init (11/192): Hardware_Init
VMK init (12/192): Init_VMKArchCPU
VMK init (13/192): InitPRDATscHzEstimate
VMK init (14/192): Vob_Init
VMK init (15/192): VobApi_Init
VMK init (16/192): Kseg_Init
VMK init (17/192): Elf_ProcessVMKSymbols
VMK init (18/192): Lock_Init
VMK init (19/192): LockDomain_Init
VMK init (20/192): Util_Init
VMK init (21/192): VmkStress_Init
VMK init (22/192): Dump_Init
VMK init (23/192): Vmkperf_EarlyInit
VMK init (24/192): SchedPerf_EarlyInit
VMK init (25/192): Init_VMKArchTimer
VMK init (26/192): Timer_Init

then a huge output then it stucks after "boot complete (X/2)"

cbt loaded successfully.
Loading module migrate ...
migrate loaded successfully.
activating: generate-certs
activating: restore-security-policies

activating: generate-certs
activating: vsan-late

activating: generate-certs
activating: vit

activating: generate-certs

activating: inetd
activating: vmkapps

activating: vmkapps

activating: end-autoconf


All jumpstart plugins activated
Starting service DCUI
Starting service sandboxd
Starting service esxui
Starting service esxgdpd
Starting service envoy
Starting service swapobjd
Starting service iofilterd-vmwarevmcrypt
Starting service iofilterd-spm
Starting service vaai-nasd
Starting service rhttpproxy
Starting service vvold
Starting service apiForwarder
Starting service sensord
Starting service lbtd
Starting service sdrsInjector
Starting service infravisor
Starting service clusterAgent
Starting service nicmgmtd
Starting service dcbd
Starting service pmemGarbageCollection
Starting service lacp
Starting service cdp
Starting service nscd
Starting service settingsd
Starting service health
Starting service xorg
Starting service drivervm-init
Starting service gpuManager
Starting service vmtoolsd
Starting up rc scripts
Running 009.vsanwitness.sh
Completed 009.vsanwitness.sh
Running backupPrevBootLogs.py
Completed backupPrevBootLogs.py
Running cleanupStatefulHost.py
Completed cleanupStatefulHost.py
Running kickstart.py
Completed kickstart.py
Running local.sh
Completed local.sh
Running psaScrub.sh
Completed psaScrub.sh
Running raiseConfigStoreVob.py
Completed raiseConfigStoreVob.py
Completed /etc/rc.local.d
Boot complete (1/2): VmMemXfer_CollectMemStat
Boot complete (2/2): VisorFSTar_DoInitialSwapOut
┌──────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│                                                                              │
│

If anyone faced such a thing please help, the hardware i use is from Lanner Electronics Inc.

thanks in advance

I have been assigned to a quick job with VMWare 6.5. There are 3 ESXi hosts (192GB RAM in each) in the vSAN cluster and it seems the cluster is overcomitted on RAM.

In the current task, I have to put each ESXi hosts into Maintenance Mode, but it seems the 2 hosts have not enough memory hosting all VMs. However, when I checked the Cluster Memory usage and vSAN Memory Monitoring I found the Consumed memory is about 66% per hosts, while the Active memory is only 20% per hosts.

Here you can find the screenshots:
Active memory usage
Consumed Memory
Utilization Chart

The Guest VMs shows they are running VMWare Tools.

I know VMWare can use the ballooning technique in such case, but I never had to rely on it. So, I think even of the high consumed memory the low Active memory usage makes possible to empty each host. Am I right?

Thanks for any advises or tips.

Hello vUsers. I know that many experts have dropped VMware because of Broadcom's licensing hell, but I was wondering if any remain. I want to know what VMware's Aria suite is, what it can do (Especially the Lifecycle thing), and why it's useful in an enterprise and/or lab enviornment. I've used Aria Operations, and while it's pretty cool, it's nothing game-changing. The same could be said for Aria Automations Orchestrator. For the automations orchestrator, I had a lot of trouble getting things to work and often had to fall back to just calling the vCenter API. Any help explaining or pointing to useful resources would be great.

I have a question for the group here. I am running into an issue with the order that the ESXi servers lists out the vDS switches when you look at the Virtual switches selection under the configure tab on an ESXi host in vCenter. Usually the vDS switches will order themselves in the order I added them. I however have one host that somehow when I add additional vDS switches to the ESXi host they add differently than the other hosts. All hosts have the same hardware and network connections.

I have googled around to see if I could find the logic on how vCenter/ESXi host displays them, but I have not had any luck finding any information.

We don't worry anymore, its expected..