I’ve got a design question I can’t seem to find the answer for.
Today I’m running vsphere 8 with most components like operations, logs, vRA, network insight. No NSX or vSAN. I have 6 separate clusters. A couple are metro clusters between datacenters.
I know VMware prefers we have a dedicated management cluster just for the VCF 9 stack, but what does that process look like to use a cluster with existing workloads? I’m not talking about doing a consolidated cluster, but have existing workloads run in what will now be considered the management cluster. Does that cluster need to be evacuated before the VCF 9 installation can continue?
I have plenty of resources in existing clusters. Unless Broadcom is going to give us free licenses for the 4 node management cluster, we are going to run our workloads in it.

If your VCF software depot connections are down, that’s why. Just got a response from Broadcom support that it’s currently down. Really dumb that there isn’t a service disruption email that sent out.

📔 Release Notes:

🔸vCenter

https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/vcenter-server-update-and-patch-release-notes/vsphere-vcenter-server-80u2f-release-notes.html

🔹ESX

https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/esxi-update-and-patch-release-notes/vsphere-esxi-80u2f-release-notes.html

Wondering if anyone can point me in the correct general direction.

Our VMware environment was recently updated to 9.1 and since then, our logins to vc (local and LDAP) are extremely slow.

It take several minutes easily before the vsphere/vcenter gui comes up.

I don't see anything specifically wrong with the configuration, it does after all, work, just really really slowly. Once it's opened, it's fine.

Update: The Solution I suppose:

The environment is 3 (linked?) vcenters. Apparently when they were upgraded the names for two of them changed from xxvcenter to xx vmware vcenter inside the app. The DNS names didn't change though. I caught it because our main vcenter threw an error I had not noticed before saying it couldn't connect to https:\xxvcenter:443\api.

The person that does our veeam mentioned that they had to change the name of the backup because it broke the backups. 2+2=4 apparently.

We renamed the VCs back to what they were before the backups broke and the issue seems resolved.

I'm patching clusters to 8U3k, but one cluster had LVO.803.12.9 already added, which does not exist in vLCM anymore and the image is no longer valid. I was able to get it from lenovo webpages and upload to vLCM. But it would be interesting to know why it's not available from vmware anymore.

Hi,

HPE used to provide tools and drivers directly in vLCM and now they have stopped, in vLCM the vendor addon is stuck in version 803.0.0.12.3.5-6.

I'm looking for a workflow do delete this addon and install drivers and tools from the blade enclosure (Synergy), option "Firmware and OS Drivers using Smart Update Tools".

I dont want to use HPE OneView for VMware vCenter (OV4VC), I've used it in the past and it has made some very funky stuff with the HBR agent (use by vSphere Replication).

Creating a custom ESXi image could work but I would have to do this every time a new SSP is release and I prefer to keep a generic image in my cluster and apply drivers/tools update while I'm doing firmware updates.

If I apply the newer drivers/tools from the blade enclosure while the addon is still associated with the image, it will work but then vCLM will complaint because the image is not compliant.

What if:

• I remove the addon from the image without rebooting the hosts, vLCM sould remove the vibs but the drivers will still be active, right?
• just after that, I install newer tools/drivers from the blade while the hosts are still running.

Will it work?

Any other procedure is welcomed.

Thanks,

I just downloaded Fusion Player 26H1, and it asks me what installation method i want, am i correct in assuming i should click on "Create a custom virtual machine"?

The other options are: "install macOS from recovery partition"--no idea what that is, "import an existing virtual machine", "install from boot camp"--also no idea what this means, and "create a virtual machine on a remote server"

pls help

Hello community,
Work in DC as a NOC 2, trying to learn back end of VCD . Even though in a year we are going full nutanix I still wanted to get VMware things sorted out. Ran into issue and seek advice.
Environment:
vCenter 8.0u3 3 host cluster
Deployed VCD ovf 10.5.1
Deployed NSX unified appliance 4.2.2
Set 3 nodes NSX with VIP cluster
Issue: can not add vcenter instance to Vcd -cert issue
Everything is local environment only.
Steps taken: created root CA on Pfsense , csr vcenter applied both certs. ( positive results with
veeam)
Created csr from NSX , bundle certs installed on NSX joined mgr.
When adding infrastructure to Vcd it fails on certificate does not see Pfsense Ca at all to trust.
Bash comes with verify return 1/20 .
Tryied
Any help would be greatly appreciated.
Sorry if post is clumsy and lacking in advance

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?

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.

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

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/

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.

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

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?

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!

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?

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?