How to Configure Syslog on VMware VCF 9 Hosts (ESX)

VMWARE CLOUD FOUNDATION GUIDE

Standardising host logging across a VCF 9 fleet using vSphere Configuration Profiles, cluster-level desired state, drift detection and remediation.

Configuring syslog on a single ESX host is a five-minute job. Configuring it consistently across a VMware Cloud Foundation fleet, keeping it consistent as hosts are added and rebuilt, and being able to prove it to an auditor is an entirely different problem.

That second problem is what VCF 9 is built to solve, and the mechanism is vSphere Configuration Profiles. This guide covers the desired-state approach, how it differs from the per-host methods, and where the practical friction is.

What this guide covers

Why per-host configuration fails at fleet scale
The vSphere Configuration Profiles model
The practical workflow, step by step
What to standardise across a VCF fleet
Where the logs should go, and forwarding beyond VCF
Proving it for audit, verification and FAQs

Why per-host configuration fails at fleet scale

Every approach that works on one host has the same weakness when applied to many: nothing keeps the configuration in place afterwards.

Hosts get rebuilt. A host reimaged for a hardware fault comes back without your syslog settings unless something reapplies them.
Hosts get added. New capacity joins a cluster and quietly logs nowhere until someone notices.
Settings get changed. Someone troubleshooting an unrelated issue points a host at a different collector and does not change it back.
Nothing reports the gap. A host that has stopped forwarding logs is invisible to log-based alerting, by definition. The absence of data is not an event.

Host Profiles addressed some of this, but required the configuration to be specified in its entirety, which made profiles unwieldy to build and harder to maintain than the problem they solved.

vSphere Configuration Profiles: the model

vSphere Configuration Profiles manages ESX host configuration at cluster level. The important difference from Host Profiles is that you define only the deltas from the default configuration rather than capturing an entire reference host. The desired configuration is expressed as a JSON document, applied to the cluster, and continuously compared against the actual state of every host in it.

	Host Profiles	vSphere Configuration Profiles
Scope	Profile attached to hosts or clusters	Cluster-level desired state
What you specify	The entire host configuration, captured from a reference host	Only the changes from default
Format	Profile object managed through the UI	JSON document, editable and version-controllable
Drift handling	Compliance check and remediation	Continuous comparison against desired state, with remediation
Direction of travel	Legacy, still supported	Strategic mechanism from vSphere 8 onwards

Table 1 - Host Profiles compared with vSphere Configuration Profiles.

A useful property: because the desired state is a JSON document, it can live in source control alongside the rest of your infrastructure definitions, be reviewed through a pull request, and be replicated from one cluster to another by editing host-specific values. That is a materially better position than a profile object that exists only inside vCenter.

The practical workflow

The pattern that works is to configure one host correctly, extract the resulting configuration, generalise it, and then apply it as cluster desired state.

Enable vSphere Configuration Profiles on the cluster, or transition an existing cluster to it. A cluster that has not been transitioned cannot be managed this way.
Configure syslog correctly on a single reference host using ESXCLI or the vSphere Client: collector address, protocol, formatter, persistent log directory, unique subdirectory, and certificate checking if you are using SSL. Our vSphere 9 ESX syslog guide covers those settings in detail.
Extract the cluster configuration as JSON so you can see exactly how those settings are represented in the schema.
Edit the JSON to hold the syslog settings you want applied fleet-wide, keeping host-specific values such as host UUID, addressing and host names in the host-specific section.
Validate the document against the cluster before applying. Validation catches schema and syntax problems ahead of remediation, and JSON comma errors are a genuinely common cause of failure here.
Apply the desired configuration and remediate the cluster.
Check compliance on a schedule thereafter, and remediate drift as it appears.

One thing to know before you start: the advanced setting names you see in the vSphere Client do not map one-to-one onto the names used in vSphere Configuration Profiles. Broadcom publishes a mapping between ESX advanced system settings and their Configuration Profiles equivalents. Consult it rather than guessing at the schema path, because a plausible-looking guess will fail validation.

What to standardise across a VCF fleet

These are the settings worth fixing centrally rather than leaving to individual hosts.

Setting	Fleet-wide recommendation	Why
Syslog.global.logHost	Same collector specification across all hosts in a workload domain, with protocol and formatter explicit	Consistency is what makes correlation across hosts possible
Syslog.global.logDir	A persistent path, configured after persistent storage exists	Local logs on a RAM disk are lost at reboot
Syslog.global.logDirUnique	Enabled wherever hosts share a log location	Prevents hosts overwriting each other on shared storage
Syslog.global.defaultRotate and defaultSize	Sized to your retention requirement and the storage available	Defaults are rarely aligned to a real retention policy
Syslog.global.certificate.checkSSLCerts	Enabled wherever ssl:// is used	Encrypted transport without certificate validation gives confidentiality but not authenticity
Audit record settings	Enabled where a compliance regime requires it, after persistent storage	Audit records apply immediately and are frequently an explicit control requirement

Table 2 - Syslog settings worth standardising across a VCF fleet.

Where the logs should go

VCF includes VCF Operations for Logs, and for most VCF estates it is the natural collector for ESX host logging. It integrates with vCenter and can be configured to collect from hosts automatically, including the option to configure hosts that are not yet sending and to keep doing so as new hosts appear.

That auto-configuration capability is useful, but it is worth being deliberate about which system owns the configuration. If VCF Operations for Logs is configuring hosts automatically and vSphere Configuration Profiles is asserting a desired state, you have two systems with an opinion about the same setting. Decide which one is authoritative and configure the other accordingly, or you will spend time chasing configuration that keeps changing back.

A clean pattern: let vSphere Configuration Profiles own the host-side syslog configuration as part of cluster desired state, and point it at VCF Operations for Logs or your SIEM. Use the collector for collection, analysis and retention rather than for configuring hosts. One system owns the setting, and drift is then meaningful rather than expected.

Forwarding beyond VCF

Many organisations need host logs in an enterprise SIEM as well as in VCF Operations for Logs, typically for security monitoring, retention or regulatory reasons. Two approaches are available.

Multiple collectors on the host. Syslog.global.logHost accepts a comma-delimited list, so hosts can send to both directly. Simple, but every collector change means a fleet-wide configuration change, and good practice is to keep the list to five or fewer.
Forward from the collector. Hosts send to one collector, which forwards onward. Keeps host configuration stable and gives you a single place to change routing, at the cost of a dependency on that collector being available.

For most VCF estates the second is easier to operate, provided the forwarding path itself is monitored.

Proving it, for audit

The reason to do this properly is usually that somebody will eventually ask you to demonstrate it. A desired-state approach makes that straightforward in a way that per-host configuration does not.

The desired configuration document is the statement of intent, and it can be version-controlled with a change history.
The compliance status of each cluster is the evidence that intent is being met.
Drift and remediation events form the audit trail of exceptions.
Audit record settings, where enabled, give you host-level audit logging as a separate control.

Compare that with the alternative: a spreadsheet asserting that syslog was configured on every host at some point in the past, and no way to demonstrate it is still true.

Verification

Desired state tells you that configuration matches intent. It does not tell you that logs are arriving. Verify both.

# From a host: is the collector reachable?
nc -z syslog.example.local 1514

# Inject a test message
esxcli system syslog mark --message="VCF fleet syslog test"

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

Then confirm at the collector that every host in every workload domain is present. A host that appears in a compliance report as configured, but sends nothing, is the failure mode that matters, and only a check at the collector will find it. Continuous "is this host still sending" checking is part of our Monitoring as a Service offering.

Where to go next

How to Configure Syslog on VMware vSphere 9 ESX Hosts, including the log message format deprecation.
How to Configure Syslog on VMware vSphere 8 ESXi Hosts, with the full advanced option reference.
VCF Design Services and VCF Upgrade Services for the wider Cloud Foundation programme.

Frequently Asked Questions

How do I configure syslog across a whole VCF 9 fleet?

Use vSphere Configuration Profiles to define the syslog settings as cluster-level desired state, then apply and remediate. This keeps configuration consistent as hosts are added, rebuilt or changed, which per-host configuration does not.

What replaced Host Profiles in VCF 9?

vSphere Configuration Profiles, first introduced in vSphere 8.0. Host Profiles remain supported, but Configuration Profiles is the strategic mechanism and requires only the deltas from default rather than a complete reference configuration.

Can VCF Operations for Logs configure ESX hosts automatically?

Yes, it can configure hosts and periodically configure any that are not yet sending. Decide whether it or vSphere Configuration Profiles owns the setting, because two systems asserting the same configuration will fight.

Can ESX hosts send logs to both VCF Operations for Logs and a SIEM?

Yes. Either list both collectors in Syslog.global.logHost, or send to one collector and forward onward from there. Forwarding from the collector is usually easier to operate at fleet scale.

How do I find the right setting name in vSphere Configuration Profiles?

The names differ from the advanced system settings shown in the vSphere Client. Broadcom publishes a mapping between ESX advanced system settings and their Configuration Profiles equivalents, so use it rather than guessing.

How do I prove syslog is configured for an audit?

The desired configuration document is your statement of intent, cluster compliance status is the evidence, and drift and remediation records are the exception trail. Verify separately at the collector that every host is actually sending.