WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / Uncategorized / ESXi syslog caveat

ESXi syslog caveat

06.24.2010 by William Lam // 5 Comments

There are two easy methods of capturing logs for both an ESX or ESXi server:

  1. Use VMware vMA and vilogger to setup a syslog server. Simon Long wrote a very detailed article on how to configured and set it all up, check it out here.
  2. Configure ESX or ESXi server to remotely log to an existing syslog server.

In ESXi, there are potentially three sets of logs to be captured: messages, hostd, and vpxa (if your host is being managed by vCenter). If you are using option #1 and you have enabled logging using vilogger, you will see the following:

If you are using option #2, there is a caveat to be aware of if you are using vCenter to manage your ESXi host, the vpxa logs are not actually being captured.

Here is an ESXi 4.0 Update 1 host that is configured to remotely log to a syslog server, tailing the logs you will notice only the messages and hostd logs:

I was recently made aware of this problem from VMTN community user aenagy who ran into this in his environment. After filing a support request with VMware, he found out there is an entry that is not added to vpxa.cfg configuration file when the host is joined to a vCenter. Per VMware, it was not considered a bug, but I would disagree.

To enable vpxa log capture, you will need to login to the unsupported Busybox console, also known as Tech Support Mode, for instructions please take a look at this VMware KB. You need to edit the following /etc/opt/vmware/vpxa/vpxa.cfg this is the configuration file for the vCenter agent running on the ESXi host:

<outputToSyslog>true<outputToSyslog>
<syslog>
    <ident>vpxa</ident>
    <facility>local4</facility>
</syslog>

Append the above entries between the ... tags. Once you have updated the vpxa.cfg file, you will want to run the follow command on the Busybox console to ensure the changes are saved and backed up to the local bootbank for ESXi. There is an automated cron job that runs every hour which calls /sbin/auto-backup.sh

You can just run that command manually which will backup the changes and you will see the diff at the bottom with the changes that were made:

~ # /sbin/auto-backup.sh
config implicitly loaded
local.tgz
etc/dropbear/dropbear_dss_host_key
etc/dropbear/dropbear_rsa_host_key
etc/opt/vmware/vpxa/vpxa.cfg
etc/opt/vmware/vpxa/dasConfig.xml
etc/opt/vmware/aam/configBackup.tar.gz
etc/opt/init.d/vmware-aam
etc/sysconfig/network
etc/vmware/hostd/authorization.xml
etc/vmware/hostd/hostsvc.xml
etc/vmware/hostd/pools.xml
etc/vmware/hostd/vmAutoStart.xml
etc/vmware/hostd/proxy.xml
etc/vmware/ssl/rui.crt
etc/vmware/ssl/rui.key
etc/vmware/vmkiscsid/initiatorname.iscsi
etc/vmware/vmkiscsid/iscsid.conf
etc/vmware/config
etc/vmware/dvsdata.db
etc/vmware/esx.conf
etc/vmware/license.cfg
etc/vmware/locker.conf
etc/vmware/snmp.xml
etc/vmware/vmware.lic
etc/dhclient-vmk0.leases
etc/group
etc/hosts
etc/inetd.conf
etc/chkconfig.db
etc/passwd
etc/random-seed
etc/resolv.conf
etc/shadow
etc/syslog.conf
etc/sfcb/repository/root/interop/cim_indicationfilter.idx
etc/sfcb/repository/root/interop/cim_indicationhandlercimxml.idx
etc/sfcb/repository/root/interop/cim_listenerdestinationcimxml.idx
etc/sfcb/repository/root/interop/cim_indicationsubscription.idx
--- /etc/opt/vmware/vpxa/vpxa.cfg Wed Jun 23 18:48:34 2010
+++ /tmp/auto-backup.26548.dir/etc/opt/vmware/vpxa/vpxa.cfg Wed Jun 23 18:47:00 2010
@@ -8,11 +8,6 @@
10
1048576
false
- false
-
- vpxa
- local4
-
error
config implicitly loaded
Saving current state in /bootbank
Clock updated.
Time: 18:48:38 Date: 06/23/2010 UTC

Once the backup has completed, you will need to reboot the host before the configuration can take effect. Once your host is back online, if you take a look at the logs on your syslog server, you will notice now that vpxa logs are also being captured:

Hopefully VMware resolves this, because this is definitely a bug and can be a painful one to remediate, especially if you are managing a few hundred ESXi hosts.

Thanks to aenagy for the information.

UPDATE:

After the blog post, I received a few questions:

1) The first question was if the modification would persist from an upgrade and I can confirm it does. My test was originally from an ESXi 4.0u1 and after the change, I upgraded the host using VUM to 4.0u2 and the changes were preserved. The reason for this is because the /sbin/auto-backup.sh was executed which backs up the ESXi configuration and is reloaded upon ever reboot including upgrades.

2) The other question was around automating this change and the answer is yes! Assuming you have SSH access enabled on your ESXi host, you can use the following "ash" script (ESXi does not have a bash) to push the changes out to your host.

You can download the script here called esxiVPXASyslogFix.sh and make sure you have the right permissions on the script to execute.

The script will first check to see if the entry exists, if it does not, it will then update the vxpa.cfg and automatically /sbin/auto-backup.sh

Once the backup has completed, you will see a message that asks you to reboot the host for the changes to take effect.

More from my site

  • Quick Tip - Monitoring ESXi remote syslog forwarding
  • Dynamic ESXi firewall rulset for non-standard syslog ports in vSphere 8.0 Update 2b
  • Enhanced vCenter Server Audit Event & Logging in vSphere 6.7 Update 2
  • Getting started with VMware Pivotal Container Service (PKS) Part 9: Logging
  • Getting started with VMware Pivotal Container Service (PKS) Part 8: Monitoring Tool Overview

Categories // Uncategorized Tags // syslog, vpxa

Comments

  1. *protectedTom Howarth says

    06/24/2010 at 7:35 am

    is there anyway this change could be automated by a script?

    Reply
  2. *protectedWilliam says

    06/24/2010 at 7:10 pm

    Tom,

    Definitely! I'll have an update for you tonight. This should be pretty simple, assuming SSH is enabled on the ESXi host.

    --William

    Reply
  3. *protectedTom Howarth says

    06/27/2010 at 9:02 pm

    Yeah simple for a scripting god like yourself maybe, neigh on imposible for mere mortals like myself 😀

    Reply
  4. *protectedCurt says

    12/10/2010 at 7:56 am

    Given the differences between ESX and ESXi logs:

    http://www.simonlong.co.uk/blog/2010/06/03/vmware-esxi-4-log-files/

    Do you know if the same asymmetry exists when getting logs from an ESX host? (Syslog vs. vMA)

    Reply
  5. *protectedrobonoe says

    02/16/2012 at 8:58 am

    Any idea if this is still an issue with vSphere 5?

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025