Using the new vCenter Log Insight product, you can easily forward application logs from various products within the vCloud Suite for easy analysis and troubleshooting. However, one very important set of logs that we have not been able to collect in the past is the virtual machine logs (vmware.log) which are stored in the working directory of a virtual machine. These logs can be extremely useful from a VMware GSS perspective such as when a virtual machine panics, or if you need to rebuild the .VMX configuration file using these logs or for even general VM auditing purposes.
A recent conversation that I had with Daniel de Sao Jose, who works in our VMware GSS organization reminded of a neat little vSphere 5.1 feature that Daniel had shared with me awhile back. The feature allows you to configure a virtual machine to forward its vmware.log to ESXi's syslog file as well as storing them in the virtual machine's working directory. At the time, there were still a few open questions that required some additional testing and I made a note of this on my ever growing to-do list. I finally around to this and finish up the testing.
UPDATE 1 (04/25/18) - In ESXi 6.7, the ability to forward a VM's vmware.log to an external syslog server also been restored and along with the change, enabling this configuration has been simplified. Instead of having multiple entries to enable the feature and specifying a unique string, you now only have to add a single entry which is vmx.log.syslogID to your VM. The value should be a unique string identifier that the VMX associates with the VM in the syslog. For example, if I use the value of "foo", then the VMX ID will be replaced with "foo" when searching through your syslog entries.
UPDATE 2 (05/04/18) - In ESXi 6.5, 6.5 Update 1 & 6.5 Update 2, the ability to forward a VM's vmware.log to an external syslog server has also been restored and along with the change, enabling this configuration has also been simplified. Simliar to ESXi 6.7, you now only have to add a single entry which is vmx.log.syslogID to your VM. The only difference is that the unique string provided WILL NOT replace the VMX ID in the syslog entry. If you desire the original behavior, you will need to use vSphere 6.7.
To enable this feature, you will need to add the following advanced virtual machine setting:
vmx.log.destination = "syslog-and-disk"
This of course can be enabled using either the vSphere Web Client or vSphere C# Client as well as automated, take a look at this article for more details.
Here is a screenshot showing showing the contents of the vmware.log in the ESXi host's syslog which is located in /var/log/syslog:
Note: The vmware.log is only generated when a virtual machine is powered on.
You also have the option of disabling the local vmware.log from being created in the virtual machine's working directory and only forwarded to ESXi host's syslog. To do so, you would change the advanced virtual machine setting to the following:
vmx.log.destination = "syslog"
By default, the log entries will be identified by the keyword vmx and the specific virtual machine's process ID such as vmx[5313]. However, this is not very user friendly and would still require you to query the VM PID to get the virtual machine name. This can be a challenge if you are viewing the logs from a centralized syslog server such as vCenter Log Insight where you potentially could have logs being forwarded from hundreds if not thousands of ESXi hosts.
To help with this, you can specify the string in which the virtual machine will identify itself when forwarding its logs using the following advanced virtual machine setting:
vmx.log.syslogID = SOME STRING
It made the most sense to me to set this to the name of the virtual machine, so you can easily identify the source of the logs. Here is a screenshot showing the name of the virtual machine instead of the generic "vmx" string.
If you have configured your ESXi host to forward its logs to vCenter Log Insight, you can see how easy it is to view individual virtual machine logs with a click of a button isolating on the syslog source.
One caveat that I would like to mention with this solution is that you are now storing all virtual machine logs in the ESXi hosts syslog file which is also logging other things about the ESXi host. This would cause the local logs to rotate much more frequently on the ESXi host due to the verbosity when powering on and off a virtual machine. This may not be an issue if you are forwarding to a remote syslog server, but ideally it would be nice to have separate log file primarily for the virtual machine logs. In Part 2 of this article, we will take a look at how we can accomplish this by extending ESXi's logger component.
Paul Petty says
Great post and certainly worth doing for us as we have a central syslog server.
I wonder how this works with the licensing of vCenter Log Insight? I believe it is licensed per OS instance and as the logs are coming from the ESXi host would this mean that you would not need additional licences per VM instance to be able to send these logs to vCenter Log Insight? Would be a considerable saving if so...
William Lam says
The logs shown here is just the virtual machine log from the VMX process, it does not include or capture guestOS logs. SO from a vCenter Log Insight perspective, this would equate to just the ESXi host that is logging. If you require (which I recommend) guestOS logs, then that'll be additional hosts logging.
Josh Beard says
Running ESXi 6.0.u2 I've set the 'vmx.log.syslogID' value to the VM name but the logs are coming into the syslog server with the PID. Do you know if this setting has been deprecated or is still functional with 6.0?
Bruno Scota says
Is it still valid for newer releases ?
William Lam says
Yes, it should be afaik but should be easy enough to test it in your lab 🙂
Darren Lofthouse says
Any response on the comment above by Josh Beard? syslogID doesn't seem to be working in 6.0.
William Lam says
Folks,
Apologies for the delayed response. I just reached out to Engineering and it does appear that this no longer functions for 6.0/6.5 env as expected. We're hoping to get this resolved in a future update, but there's no ETAs. I do understand the importance of this capability and will update folks when I have something I can share
P. Cruiser says
William, any update on this? Was it fixed in an update for 6.0/6.5? Or are there plans for something new in the future? Or both?
IIvanov says
Tested on ESXi 6.7 - vmx.log.syslogID works!
William Lam says
Yes, this was fixed with vSphere 6.7, I've updated the article with a quick note and thanks for confirming
P. Cruiser says
Any hope for this to be fixed in future 6.0 and 6.5 updates?
J says
+1 to that, would be really handy
William Lam says
This has also been fixed in latest vSphere 6.5 Update 2 (which just GA'ed yesterday) - https://my.vmware.com/web/vmware/details?downloadGroup=ESXI65U2&productId=614&rPId=22693
Frederic Giroux says
I just tried using 6.5U2 (both ESXi and vCenter) and I unfortunately cannot make the vmx.log.syslogID parameter work. I see through the logs that the parameter is recognized as present, but all I see for the log entries is the vmx[procid] info.
William Lam says
FYI - After speaking with Engineering and thanks to Fredric's post, I have updated the details regarding this feature returning back to ESXi 6.5, 6.5 Update 1, 6.5 Update 2 & 6.7