Playing around in the lab this week, I noticed something interesting.  I’m not sure if it’s a bug, or by design, but it’s new with vSphere 5 so I wanted to share.

I have one lab that has vSphere 5 installed on internal hard drives, and everything looks just like it should.  When I look at the logging options under Configuration Tab | Software | Advanced Settings | Syslog | Global I see the following:


Note that the logDir is set to “[] /scratch/log” putting the logs on the local disk.

In my other lab, I have vSphere 5 installed on USB sticks (as detailed in this post).  After install, there is an alarm on each host that looks like this:


Interesting, right?  Same install, just to different media, and it appears that vSphere knows that there’s no persistent disk and has decided to leave the logging unconfigured since it doesn’t know how much space is available for it.  Now I’m totally guessing on that point, but it does make sense.  Does anyone out there have a more “official” answer for the change in behavior?

If I check the Advanced Settings on the host with the alarm, I can see that there’s no logDir defined at all:


Sure enough, when I browse the /scratch/log directory, it’s completely empty.  Just for kicks I decided to put the same default value in on one of the unconfigured hosts and see what happened.  The value is accepted and the alarm goes away.  When I look in the /scratch/log directory now, I see all of the expected log files:


In the abstract, this seems like a welcome change.  For hosts that are being installed diskless, vSphere appears to be acknowledging that fact and leaving the logging options unconfigured.  While this means that you have to manually add the logging path (whatever you want it to be) after the fact, it would seem to be intended to prevent a situation where the default logging settings would cause an issue.  A small feature, sure, but one that could be very useful.  If you have any thoughts on this “feature” or if you have a more official answer to why the install process is different based on the media being installed to, let me know in the comments!

16,829 total views, no views today


6 Responses to vSphere 5: System Logging Not Configured By Default

  1. Mcowger says:

    I think that for diskless servers, VMware is acknowledging that the right way to do logging is with a centralized log host (vMA or what have you).
    I’d argue thats the right way regardless, but, hey :)

  2. I wouldn’t even worry too much about the scratch partition. For stateful and stateless hosts, the should be populated with a living syslog server. Even a stateful ESXi host loses all its logs once it’s rebooted. Therefore, centralized logging is a best practice. It can be the vMA or it can be the new installable syslog server that comes on vCenter 5 installation media. This can all be configured with a simple PowerCLI script, host profiles, or simple point, click, type, save.

  3. Agreed on the best practice of central logging even though I detest syslog. :-) I found it interesting that the install behavior is different based on what you are installing to, which is AFAIK new for vSphere5.
    Thanks for the comments, gents!

  4. DuncanYB says:

    The reason for this is that ESXi installed on USB does not have a Scratch Partition and as such this cannot be used for logging. This is not new behavior to be honest, same behavior applies to versions prior to 5.0. it is recommended to configure a scratch partition with ESXi and use a syslog server to allow for “simpler” root cause analysis etc.

  5. Duncan, couple questions if you don’t mind. It appears that there IS a /scratch partition on the USB install and I can point the logging there if I choose, it’s just left unconfigured bu default. Is the install behavior new in v5, or is it just that the host alarm is new? I don’t recall ever seeing the alarm before…
    Either way, you are right that it doesn’t matter except in the lab, where I typically don’t bother setting up syslog unless that’s what I’m testing. Thanks again for the comment!

  6. DuncanYB says:

    the alarm is new, the behavior isn’t. The “scratch” on the USB is non-persistent as far as I know so not really useful :)