How to Configure Syslog on VMware vSphere 9 ESX Hosts

VMWARE TECHNICAL GUIDE

What changed in vSphere 9, why the hypervisor is now called ESX, and the log message format deprecation that will break your parsers if you ignore it.

If you have configured syslog on ESXi before, most of what you know still applies. The daemon is still vmsyslogd, the settings are still Syslog.global.* advanced options, and ESXCLI still works the way it always has.

Three things are different in vSphere 9, and one of them will quietly break log parsing in a future release if you do not plan for it now.

What this guide covers

The rename from ESXi to ESX
The deprecated log message format, and what to do about it now
TLS 1.3 and TLS profiles
Configuring syslog on ESX 9 with ESXCLI, the vSphere Client and PowerCLI
The loghost string, unchanged
Verification, troubleshooting and FAQs

First: it is called ESX again

With vSphere 9 and VMware Cloud Foundation 9, the hypervisor is named ESX rather than ESXi. This is a naming change, not a product change: the same hypervisor, the same architecture, the same commands.

It matters for two practical reasons. Documentation and knowledge base articles increasingly use ESX, so searching for ESXi may return older material. And internally, your own runbooks, naming standards and configuration documents will drift out of step with vendor terminology unless you update them deliberately.

For clarity in this guide: we use ESX when referring to vSphere 9 hosts and ESXi when referring to vSphere 8 and earlier, matching current Broadcom terminology. The commands are identical in both.

Second: the log message format is changing

This is the change that deserves your attention. With ESX 9.0, the current message formats used in vmware.log and produced by vmsyslogd are deprecated. In a future release the format changes from:

TIMESTAMP SP SEVERITY SP THREAD-NAME SP OPID SP MSG

to:

TIMESTAMP SP SEVERITY SP APP-NAME SP PROC-IDENTIFIER STRUCTURED-DATA [SP MSG]

The new format aligns much more closely with RFC 5424, introducing an application name, a process identifier and a structured data element in place of the thread name and operation ID.

Who this affects: anyone with parsing rules, field extractions, dashboards, saved searches or alerting logic built against the current format. Splunk field extractions, Logstash grok patterns, Graylog extractors and SIEM correlation rules will all need revisiting. The deprecation is your notice period, so use it.

What to do about it now

Inventory every parsing rule, extraction and alert that depends on ESX log message structure. In most organisations nobody has a list, and building one is the bulk of the work.
Where your collector supports it, move to RFC 5424 formatting on the wire now by setting formatter=RFC_5424 in the loghost string. That gets structured handling in place ahead of the on-host format change.
Write parsers that tolerate both formats rather than replacing one with the other, so the transition is not a flag day.
Test against a vSphere 9 host in a lab before the format changes in production, not after.

Third: TLS handling has matured

vSphere 9 supports both TLS 1.2 and TLS 1.3, with TLS 1.3 supported at the protocol level. TLS administration moved to TLS profiles from ESX 8.0 Update 3 onwards, replacing the older per-service cipher options which are now deprecated and scheduled for removal.

For syslog specifically this means encrypted transport is easier to reason about: you choose a TLS profile for the host rather than assembling cipher lists per service. The syslog side of the configuration is unchanged, so use the ssl:// protocol and enable certificate checking.

Configuring syslog on ESX 9

The mechanics are the same as on ESXi 8. Here is the short version. For the full advanced option reference, see our vSphere 8 ESXi syslog guide.

Using ESXCLI

# Review what is configured
esxcli system syslog config get

# Encrypted collector, RFC 5424 formatting, octet counting framing
esxcli system syslog config set \
  --loghost='ssl://syslog.example.local:1514?formatter=RFC_5424&framing=octet_counting'

# Validate the collector certificate
esxcli system syslog config set --check-ssl-certs=true

# Persistent local logs with a per-host subdirectory
esxcli system syslog config set \
  --logdir='[datastore1] /systemlogs' --logdir-unique=true

# Apply the changes
esxcli system syslog reload

As on earlier releases, ESXCLI changes require the reload. Changes made through the vSphere Client take effect immediately.

Using the vSphere Client

Select the host, go to Configure, then System, then Advanced System Settings, click Edit, and filter for Syslog. Set Syslog.global.logHost to your collector specification and adjust Syslog.global.logDir and Syslog.global.logDirUnique as needed.

Using PowerCLI across a cluster

$loghost = "ssl://syslog.example.local:1514?formatter=RFC_5424"

Get-Cluster "Production" | Get-VMHost | ForEach-Object {
    Get-AdvancedSetting -Entity $_ -Name Syslog.global.logHost |
        Set-AdvancedSetting -Value $loghost -Confirm:$false
    Get-AdvancedSetting -Entity $_ -Name Syslog.global.certificate.checkSSLCerts |
        Set-AdvancedSetting -Value $true -Confirm:$false
}

The loghost string, unchanged

Component	Accepted values	Notes
protocol	tcp, udp or ssl	Mandatory. Use ssl for encrypted transport, tcp where you need delivery reliability without encryption, udp only where the collector cannot accept anything else.
hostname	FQDN, IPv4, or IPv6 in square brackets	An FQDN requires working DNS on the host. An IP address removes that dependency but makes collector changes harder.
port	Any value from 1 to 65535	Optional. If omitted, UDP and TCP default to 514 and SSL defaults to 1514.
formatter	RFC_3164 or RFC_5424	Optional. RFC_3164 is the default. Use RFC_5424 where your collector supports structured data and you want reliable timestamps and host fields.
framing	non_transparent or octet_counting	Optional. non_transparent is the default. octet_counting is more robust for TCP and SSL streams carrying long messages.

Table 1 - Components of the ESX remote syslog host specification.

Defaults are the same as on earlier releases: UDP and TCP use port 514, SSL uses 1514, RFC_3164 is the default formatter, and non_transparent is the default framing. Given the format deprecation described above, RFC_5424 is now the more future-proof choice where your collector supports it.

At scale: vSphere Configuration Profiles

Host Profiles remain available in vSphere 9, but vSphere Configuration Profiles is the strategic mechanism for managing host configuration at cluster level. It requires you to define only the changes from default rather than capturing a full reference configuration, which makes standardising syslog across an estate considerably less painful.

If you are running VMware Cloud Foundation 9, this is covered in more depth in our companion guide on configuring syslog on VCF 9 ESX hosts, which deals with cluster-level desired state, drift detection and remediation.

Verification and troubleshooting

# Is the collector reachable from the host?
nc -z syslog.example.local 1514

# Inject a test message
esxcli system syslog mark --message="Consult Circle syslog test"

# Check the daemon error log
cat /var/log/.vmsyslogd.err

The failure mode to remember: if the host loses communication with the collector, forwarding stops and does not resume by itself. You will see a "failed to write log" entry in the daemon error log, and nothing is sent until the service is reloaded. Monitor for the absence of logs from each host rather than only for errors inside them, which is exactly what our Monitoring as a Service platform is built to catch.

Where to go next

How to Configure Syslog on VMware vSphere 8 ESXi Hosts, with the full advanced option reference.
How to Configure Syslog on VMware VCF 9 Hosts (ESX), for fleet-wide desired state.
VCF Upgrade Services if vSphere 9 is part of an upgrade programme.

Frequently Asked Questions

Why is ESXi now called ESX in vSphere 9?

Broadcom renamed the hypervisor to ESX with vSphere 9 and VMware Cloud Foundation 9. It is a naming change only. The architecture, the commands and the configuration are unchanged.

Is the syslog configuration different in vSphere 9?

The configuration mechanism is unchanged. You still use Syslog.global.* advanced options or esxcli system syslog. What has changed is that the log message format is deprecated and will change in a future release, and TLS is now managed through TLS profiles.

What is changing about the ESX log message format?

The format moves from timestamp, severity, thread name, operation ID and message to timestamp, severity, application name, process identifier, structured data and message. It aligns more closely with RFC 5424 and will break parsing rules written against the old structure.

Should I switch to RFC 5424 on ESX 9?

If your collector supports it, yes. Set formatter=RFC_5424 in the loghost string. It gives you structured handling now and reduces the work when the on-host format changes.

Does vSphere 9 support TLS 1.3 for syslog?

vSphere 9 supports both TLS 1.2 and TLS 1.3. TLS configuration is administered through TLS profiles rather than the older per-service cipher options, which are deprecated.

Do I still need to run esxcli system syslog reload on ESX 9?

Yes, for changes made with ESXCLI. Changes made through the vSphere Client apply immediately, and audit record settings apply immediately regardless of method.