Enthusiast
Enthusiast

I just want to suppress this alarm; System logs on host <hostname> are stored on non-persistent storage

I am getting this error on 6.0 hosts running SSD local storage on hosts; System logs on host <hostname> are stored on non-persistent storage. I already know how to set up log locations on a datastore, however I do NOT want to do this. I understand the risks and want to suppress the alarm and keep the logs on SSD. But I don't want to see the alarm all the time.

Tags (4)
13 Replies
Hot Shot
Hot Shot

Sorry realised my pre post made no sense.

Normally to suppress these type of warnings you would go to

  1. Select the ESXi host from the Inventory.
  2. Click the Configuration tab.
  3. Click Advanced Settings in the Software menu.
  4. Navigate to UserVars > UserVars.SuppressXXXWarning.
  5. Set the value from 0 to 1.
  6. Click OK.


Since there isn't an option for scratch (just shell and coredump) i doubt you can do it that way, would maybe be easier to just move the scratch from /tmp

Rich

0 Kudos
Enthusiast
Enthusiast

Yeah this is the correct answer;

To supress the messages do the following;

1. Connect to vcenter server via the vsphere client.

2. Click on the affected host.

3. Click on the configuration tab

4. Under the software section click on advanced settings.

5. Scroll down and click UserVars

6. Scroll down to UserVars.SuppressCoredumpWarning, the default value is 0, change it to 1 and click ok to close it.


I did have to reboot the hosts to get the alarms to clear.

0 Kudos
Enthusiast
Enthusiast

Actually this does not work. Just tested it; have the setting correct but the alert persists.

persistantstorage.JPG

0 Kudos

I know you want to suppress it, but wouldn't it be better to have the logs when you need them. Follow the link below, save them somewhere else, with the benefit of not having the alert, AND having the logs if something goes awry.

VMware KB: Creating a persistent scratch location for ESXi 4.x/5.x/6.0

Ita feri ut se mori sentiat
0 Kudos
Enthusiast
Enthusiast

If something goes wrong with the software layer on a host, we just blow it away and auto deploy it again. It's a large environment and we don't really care what caused it unless it recurs or becomes chronic. We are also more concerned about logs filling up datastores and don't really like that option, so we just want the alerts to go away. The solution proposed is also what support told me, but it doesn't work after testing to verify.

0 Kudos
Hot Shot
Hot Shot

Yes, you can only suppress Coredump and Shell, i would suggest pointing the scratch somewhere other than /tmp.

Its a fairly simple change and since you are blowing these away if you have an issue, I would just get a host profile setup with it in, would make your life easier.

Rich

0 Kudos
Enthusiast
Enthusiast

This is the final answer; after rebooting the host, the alert appears again. After talking to support there is NO WAY to suppress this specific alert currently.

0 Kudos
VMware Employee
VMware Employee

While there is no way to suppress the warning. you can point the ESXi to use a syslog server, which will remove the config alert

Verified on vSphere 6.0 U1

0 Kudos
Expert
Expert

Another two cents here.

It is not that the log files are stored on SSD or flash media of any type, the log files are kept in RAM (as is the scratch data) until you create a persistent scratch location.

+The Invisible Admin+ If you find me useful, follow my blog: http://johnborhek.com/
0 Kudos
Enthusiast
Enthusiast

I'm not sure about that. This was on a new install where the ESX was installed on SSDs.  I did nothing to set up persistent log storage; it was all default settings. In order to suppress the alarms, I had to CHANGE the EXISTING log location from the SSD to a datastore. At least that's the way it worked in my scenario, which was all on new hardware.

0 Kudos
Contributor
Contributor

Hello,

This worked for me, just add your datastore name as below.

Configure -> System -> Advanced System settings -> Edit -> Syslog.global.logDir

Change:

[] /scratch/log

To:

[datastore] /scratch/log

Contributor
Contributor

All attempts to set valid drive location for scratch failed.  Taking the lead from gsinjari's last reply, I realized that all my VM hosts had the same datastore name as standalone servers, but when added to vCenter, they took on numbers to keep them unique.  Changing the global value to the following was accepted and finally resolved the warning icon...


     [vCenter_datastore_Name] /scratch/log

In my case, I did not like the variants of original datastore and appendages, so changed the datastore names to reflect Host, such as "datastore-hostX".  This is the value that went into Syslog.global.logDir value for that Host, as in

     [datastore-hostx] /scratch/log

0 Kudos
VMware Employee
VMware Employee

Sorry I'm late to the party. Setting "127.0.0.1" as the syslog host will suppress the warning.