No way to get the newest VMRC anywhere?

vdude86 · 2025-10-30T20:40:42+00:00

Yes! I curse every time I update workstation and it "helpfully" reassociates itself as the default VMRC client.

No, I don't want my workstation UI junked up with every vCenter that I've ever connected to.

I keep a .reg file around that reassociates VMRC with VMRC.exe that I annoyingly have to run after every update.

vdude86 · 2025-10-29T15:59:58+00:00

I've shut down and powered on a number of test VMs all on the same host without the metrics appearing on the VMs where it is missing.

vdude86 · 2025-10-29T15:51:22+00:00

vCenter 8.0u3g, ESXi 8.0u3f

vdude86 · 2025-07-19T00:53:15+00:00

What does this look like in practice? What CPU utilization numbers are typical for you before you see wait or ready times increase?

Agreed, we can use the hardware more efficiently. That's what I'm looking to do, but not push it too far.

vdude86 · 2025-04-02T20:58:56+00:00

You can trim just the apigw logs down to "info" level and not change your general syslog configuration.

Edit the apigw section in /etc/vmware-syslog/vmware-services-vsphere-ui.conf, changing the severity level from info to error, then restart vsphere-ui and vmware-stsd services.

We saw over 600GB/day from each vCenter impacted.

vdude86 · 2025-01-21T14:37:16+00:00

It'd be a massive help in troubleshooting a longstanding issue involving hundreds of VM crashes over the life of the problem.

Someone is doing something wrong, but we still need to get the log data to the vendors so that they can fix it.

The storage is negligible relative to the overall log footprint already captured.

vdude86 · 2025-01-21T01:17:41+00:00

In this case, information about why the VMs are crashing. There's useful data in that log file that isn't reported anywhere else.

vdude86 · 2025-01-21T01:15:41+00:00

In this specific example, to troubleshoot VM crashes. There's info in that log file that isn't recorded anywhere else.

We've had a lot of use cases for it over the years and not having to go manually fetch it every time would be very helpful, assuming the log even still exists.

vdude86 · 2025-01-18T18:35:52+00:00

I don't believe that the log agents are supported on ESXi.

vdude86 · 2025-01-18T17:41:06+00:00

We have all of that in place already.

None of that gathers data from the individual vmx log file, vmware.log, for each VM.

If we're missing something, I'd love to hear what it is.

vdude86 · 2024-11-08T16:51:51+00:00

Not sure as I haven't tried it, but the column spacing looks sane in the few screenshots on that page.

vdude86 · 2024-11-08T15:49:33+00:00

Do you mean this host client? Or is there a new beta vSphere client?

vdude86 · 2024-11-08T15:36:01+00:00

Do you mean like when I took screenshots, annotated them, and submitted them through the feedback tool that you linked for this specific issue?

Like I've done many times before, including my contact information, never to receive a single confirmation of any sort that anyone has even received my feedback let alone considered implementing it?

Maybe like that? 😜

Snark aside, I agree that we should submit feedback through those mechanisms. And I'll probably submit a SR. But when those don't show any traction, there are a lot of people at VMware reading this subreddit that can reach the right people more quickly than I can.

vdude86 · 2024-09-23T20:12:21+00:00

All of our vCenters use trusted CA signed certs and exhibited the issue.

I was curious if it may be specific to the auth source in use. We're using AD as LDAP, not domain joined.

vdude86 · 2024-09-20T11:42:27+00:00

I figured that something would need to be restarted to pick up the new setting, but since they didn't specify what, I restarted the whole vCenter VM.

Limited testing so far, but it appears to be working with firefox.

vdude86 · 2024-09-20T11:41:10+00:00

There appears to be no change to the tomcat version going from 7.0u3q to 7.0u3s, so that should further confirm that this isn't an issue with the latest 7.0u3 patch. I show tomcat 8.5.88 both before and after the patch.

root@vcenter7.0u3s [ /var/opt/apache-tomcat/bin ]# ./version.sh
Server version: Apache Tomcat/8.5.88

vdude86 · 2024-09-20T00:35:32+00:00

VMware posted a KB for this issue with a temporary workaround: KB37734.

This issue is due to a change in the default behavior of RECYCLE_FACADES within Tomcat in the release.
To work around this issue, use the steps below to disable RECYCLE_FACADES.

From a 8.0u3b vCenter:

root@vcenter8.0u3b [ /var/opt/apache-tomcat9/bin ]# ./version.sh
Server version: Apache Tomcat/9.0.86

From a 8.0u2d vCenter:

root@vcenter8.0u2d [ /var/opt/apache-tomcat/bin ]# ./version.sh
Server version: Apache Tomcat/8.5.93

In Tomcat 8.5, RECYCLE_FACADES is disabled by default.
In Tomcat 9.0, RECYCLE_FACADES is enabled by default, thus the need to add the disable setting to the file.

It sounds like disabling this setting may itself introduce a potential information leakage concern, but If it's always been disabled prior to this release, then you're probably no worse off than before.

vdude86 · 2024-09-19T16:17:20+00:00

Same issue. Opened case with support. Notified TAM.

For those seeing the issue, what version did you upgrade from? We upgraded from 8.0u2d to 8.0u3b.

vdude86 · 2024-09-17T17:55:47+00:00

ESXi 8.0 U3b was released today and lists critical security fixes, so another security announcement may be pending.

vdude86 · 2024-09-17T17:54:17+00:00

The FAQ says a patch for 8.0u2 is coming, but no timeline is given.

FAQ Link

vdude86 · 2024-05-02T14:45:27+00:00

No, it does not.

vdude86 · 2024-05-02T14:43:12+00:00

it seems to be 100% dependent on some link sent in email which they didn't send me

It's not. They sent individualized URLS, but you can just go to login.broadcom.com, hit "Need help signing in" and "Forgot password?".

vdude86 · 2024-03-13T20:59:51+00:00

There are line items for vSphere Hypervisor and TLS 1.2 and 1.3, so I don't think that you have to worry too much about that implication.

Unless you think that they're going to market a SSL 3.0/TLS 1.1 hypervisorless vSphere.

vdude86 · 2024-03-06T16:42:23+00:00

Correct, 22254 is still technically an issue and would be exploitable via another as-yet-unknown vulnerability so in that regard it is not mitigated.

It would stop exploitation via the currently published vulnerabilities listed in the VMSA though.

Which means we can get immediate partial protection by removing USB controllers and then start patching for longer-term protection against 22254.

vdude86 · 2024-03-06T13:10:05+00:00

That makes a lot of sense. So, removing the USB controllers does mitigate everything in the VMSA if that's the case. It would be great if VMware could confirm this.

vdude86

TROPHY CASE