Read the active scratch location together with the syslog destination. A configured persistent directory does not prove that ESXi has started using it. If logging still resolves to a ramdisk, a reboot can remove the very evidence needed to explain the previous failure.
This diagnostic focuses on ESXi 8.0.x. KB 317690 lists USB/SD boot media smaller than 32 GB in its environment (7.0.x/8.0.x); its logDir/scratch mechanism is used here with that boot-media context. Sources are KB 317690 and KB 302451. It is source-only: no host was inspected, no probe executed and no reboot performed.
Follow the destination, not the directory name
ESXi can retain logs on persistent storage or forward them to a remote syslog service. The host's internal ramdisk is not durable across reboots. The existence of a directory on a datastore therefore matters only if the effective logging configuration directs records there.
Syslog.global.logDir identifies the local log destination. If it is blank or refers to scratch, inspect ScratchConfig.CurrentScratchLocation. The word Current is important: this is the active scratch location, which must not be confused with the location configured for a later activation. KB 317690 explicitly notes that scratch changes require a reboot to take effect and that the current and configured locations must agree after successful activation.
This does not authorise a diagnostic reboot. Preserve currently available records first, particularly if the active destination is volatile. A reboot may destroy evidence without resolving an invalid destination.
Read the effective configuration
Prerequisites are authorised read access to the host's settings and existing logs, its ESXi build, and enough storage inventory information to identify the destination. In the vSphere Client, select the host and inspect Configure → System → Advanced System Settings. Record Syslog.global.logDir, ScratchConfig.CurrentScratchLocation, the configured scratch location field and Syslog.global.logDirUnique where relevant.
Interpret those values together:
| Evidence | Interpretation |
|---|---|
| Explicit logDir points to a temporary location | The configured local logging destination is volatile. |
| Blank logDir and current scratch on a ramdisk | Logging inherits a non-persistent scratch destination. |
| Configured scratch is persistent but current scratch remains temporary | A saved setting has not established active persistent scratch. |
| Persistent destination and fresh records there | Evidence of current writes; retention and historical completeness remain separate questions. |
The KB documents datastore syntax as [Datastorename]/foldername; a scratch-relative destination can be blank or use []/foldername. Read the existing value, not a replacement copied from an example. If several hosts share the same parent destination, inspect whether per-host separation is configured rather than assuming similar-looking log files belong to this host.
When the scratch path uses a volume UUID, the source supplies this read-only identity query:
esxcli storage filesystem list
Its syntax is source-checked only; verify installed help and existing approved shell access before use. The KB uses SSH as root; enabling SSH or changing access is a separate security change and is outside this inspection. Match the mount point or UUID to the volume name, mounted state and filesystem type. The listing identifies storage; it does not prove that the logger is writing to it. Do not create, mount or format a filesystem as part of this inspection.
Worked example: a saved path, a volatile writer
Suppose a fictional host has a configured scratch directory on DS-LOGS, but CurrentScratchLocation still points under /tmp. Its logDir is blank. An administrator sees the persistent directory and concludes the next reboot is safe for evidence retention.
That conclusion skips the active destination. With blank logDir, the current scratch location is material, and it is still temporary. Existing records under /tmp should be treated as vulnerable. The next technical decision is to establish why the supported destination has not become active, using the host's change history and the exact vendor procedure, while preserving current evidence.
A different host might have matching persistent values but no fresh records in the destination. That is not a retention-window problem yet: first establish actual receipt and the correct host identity. Conversely, an old file in the directory may belong to a previous boot or another host and cannot establish current logging.
Storage and evidence limits
KB 317690 specifically excludes vSAN datastores as scratch or persistent-log targets and warns of host unresponsiveness. Do not select the cluster's vSAN datastore simply because it has free space. Boot-media replacement, reinstalling ESXi and registering coredumps are separate operations; their instructions are not reproduced here.
Remote logging can preserve another copy, but KB 302451 states that ESXi cannot guarantee the receiver's retention policy. The sender configuration alone is not proof of remote receipt or durable retention. Remote-forwarding troubleshooting is outside this local-destination diagnosis.
Acceptance and safe reversal
The read-only result should identify the effective destination, its backing storage and current records belonging to the host. That is stronger than a saved setting, but a planned restart-survival test remains separate and unexecuted. Never restart a production host solely to test this article.
Inspection requires no rollback. Any eventual configuration change needs the old values and the supported activation procedure; restoring a setting cannot recover records already lost from a ramdisk. Preserved incident evidence should remain available independently of that change.
Learning notes
- A configured scratch path and an active scratch path are different facts.
- A blank logDir can inherit scratch rather than mean logging is disabled.
- Durable storage and fresh, correctly identified records are both needed.
References
- A03-S1: Alarms "System logs are stored on non-persistent storage" triggered on ESXi hosts using USB/SD boot media
- A03-S2: Determining whether an ESXi host has persistent logging