Storing VMware ESXi syslog events on a remote Linux server

A remote Linux server is a valuable place to store VMware ESXi syslog events – especially if disaster strikes.

More on VMware ESXi syslog

Forwarding event logs to a

    Requires Free Membership to View

centralized logging system for compliance

Collecting diagnostic data and logging for VMware environments.

Manipulating VMware log file space via log file rotation settings

If a security breach occurs, for example, it is essential that you're able to analyze what went wrong.  VMware ESXi uses syslog to record information about important events, such as changes to the state of network interfaces or connections to the storage area network. By examining these ESXi syslog events, you can retrace problems in your virtual environment.

But, if the VMware ESXi syslog events are stored on the same server that generates them, you may be unable to access that critical information during a breach. That is why using a remote server to externally store syslog messages is essential for a secure logging infrastructure. With some addition hardware, software and tweaks to the ESXi hypervisor, you can set up an inexpensive, remote Linux server to record VMware ESXi syslog events.

Configuring a remote Linux server for ESXi syslog events
By default, syslog stores ESXi logs on the host itself. While it’s better than nothing, it’s better to set up an external log host, and Linux is a convenient platform for that server.

There are many flavors of Linux, and it doesn't really matter which one you select for the log host. In this example, I’ll use OpenSUSE, a free Linux distribution that is the basis for SUSE Linux Enterprise Server.

After performing a default installation of OpenSUSE, you need to configure rsyslogd, the log server that runs on OpenSUSE. First, configure syslog to receive log messages from other hosts, selecting whether you want to receive log files via Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). By default, rsyslogd uses UDP as the transport mechanism. That’s a fine choice if the underlying network is trusted and reliable. But, if log messages are sent over an untrusted network connection and there's a risk that packets may get lost, TCP is the better choice to ensure that messages arrive at the log host.

For a first trial of your rsyslog log host, I'd recommend UDP. But you can always switch over to TCP, if there's a need to add increased reliability.

To enable UDP log reception on the syslog host, open the configuration file /etc/rsyslog.d/remote.conf with an editor, such as gedit or vi. Make sure the following lines are included at the beginning of the file:

$ModLoad imudp.so

$UDPServerRun 514

Now that you've enabled the rsyslog on the remote Linux server, restart it. To do this, use the command service rsyslogd restart. Next, configure the ESXi hosts to send their syslog events to your freshly configured remote Linux server.

In part two of this series, you'll learn how to configure vSphere to log messages to remote hosts.

This was first published in February 2012

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.