, , , , , , , ,

Managing vCenter Logs: Locations, Retention, and Best Practices

vCenter 8 log management dashboard

Hey folks, let’s dive into the subject of vCenter logs (specifically vSphere 7/8 VCSA) where they live, how long they stick around, and how to keep things tidy and clean.

As a vSphere admin, I’ve messed around with logs enough to know they’re critical for troubleshooting but can be a headache if not managed properly. So, here’s a quick, technical rundown to keep your vCenter humming.

Logs and Events: The Basics

vCenter splits its diagnostic data into two main buckets: database events and log files. The vCenter database stores tasks and events with a default retention of 30 days. You can tweak this in the vCenter settings, but proceed with caution—extending retention can bloat the database to the point where vCenter might choke and shut down. Keep an eye on DB size if you’re tempted to stretch this beyond the default.

Log files, on the other hand, are stored in /storage/log/ and bundled into vc-support bundles when you need to share diagnostics with support. As each log grows, it is rotated over a series of numbered component-nnn.log files. Log file retention is governed by size and rotation limits. Each log grows to a set size, then rotates into numbered files (component-xxx.log), with older ones compressed. The system keeps a fixed number of compressed logs, deleting the oldest first.

Regularly review these settings in VAMI or SSH to avoid storage creep, and remove old log bundles to free up space. If /storage/log/ nears capacity, archive old logs to external storage and delete them from the appliance. Avoid letting partitions hit 100%, as this can halt vCenter services.

Check logs usage in VAMI. Login to VAMI, click on Monitor -> Disks, and examine the logs partition.

Check in SSH by logging in and running

ls -lh /storage/log/

Or, my preference, cd to /storage/log and run

df -h

Similarly, core dumps – the files generated when a vCenter service crashes – land in /storage/core/. These also require manual cleanup and can slow down the vc-support bundle process if left unchecked. And note…if you spot recent core dumps without an obvious cause, open a support case to dig into what’s crashing.

For example, I have a single core dump file on my lab VCSA, and it takes up 2GB of storage!

What Controls Logging?

Logging behavior in the vCenter Appliance hinges on three key settings:

  1. Log level verbosity: Options range from none to trivia (error, warning, info, verbose, etc.). Higher verbosity means more details but also more resource demand.
  2. Log file size: Each log grows until it hits a size limit, then it’s compressed, and a new file starts. Logs are rotated into numbered files (e.g., component-xxx.log), with some platforms compressing older ones.
  3. Retention of compressed logs: The system keeps a set number of compressed logs, deleting the oldest (first in, first out) when the limit is reached.

Best Practices for Log Management

To keep your vCenter lean and mean, stick to these guidelines:

  • Leave log verbosity at default unless you’re troubleshooting a specific issue with VMware support’s guidance. Cranking up verbosity can strain resources and fill up storage faster than you’d like.
  • Regularly check /storage/log/ for old log bundles and /storage/core/ for core dumps. Delete anything outdated or no longer needed to reclaim space.
  • Monitor core dumps closely. If you see recent ones without a clear explanation, don’t just sweep them under the rug – open a support case to investigate the root cause.

Wrapping Up

Managing vCenter logs isn’t glamorous, but it’s essential for keeping your environment stable and troubleshoot-ready. Stick to default settings unless you have a compelling reason to change them, and make a habit of checking /storage/log/ and /storage/core/ for cruft. If you’re digging deeper, here are some handy VMware resources to bookmark:

Keep those logs in check, and your vCenter will thank you. Got any log management tips or war stories? Drop them in the comments!

Leave a Reply

Your email address will not be published. Required fields are marked *