5.0 to 5.1 upgrade on host with flash drive only - ScratchConfig

[gpalmon]

I have upgraded ESXi 5.0 to 5.1 on 3 hosts out of 5 i have,

on 1 of the hosts i am getting a warning under the summary tab which says:

Configuration Issues

System logs on host xxx.xxx.xx.xxx are stored on non-persistent storage.

This specific host have no local hard drives/datastores and is running on a 8GB flash usb drive.

The other 2 hosts are different as they have a local datastore as well as the 8GB flash drive where ESXi is installed.

Comparing these hosts i can see that under:

Configuration > Advanced Settings > ScratchConfig > ScratchConfig.ConfiguredScratchLocation

The yet to be upgraded 5.0 hosts have nothing configured, and it is stated below that (greyed out) that /tmp/scratch

is currenty being used as a scratch space (that is a ram disk as far as i know)

These hosts are not giving any warning with this configuration under 5.0

The hosts which were upgraded to 5.1 and have a local store have : /vmfs/volumes/4ff2eb2d-98622fdc-e85e-bc305be3c5d9/.locker

configured at this same place, it is most likely something which was changed during the upgrade process and is now pointing to that volume.

The host which was upgraded to 5.1 and have NO local store still have that field blank, but as stated at the start - is giving a constant warning which cant go away.

Is there any way to Acknowledge this, make this warning go away? (of course it adds yellow exclamtion mak on the host too...)

[admin]

Hi   gpalmon,

Welcome to the communities.

boot to the RAID Controller and F2 the controller to clear the configuration and

then create a new Virtual Disk, the initialize is either part of the advanced screen

when creating the raid or you can F2 the Virtual Disk an select initialize there

"Life is never easy for those who dream"

[gpalmon]

Hi Aarav,

Not sure what are you refering but i am not intending to use any local disks on that host

[etieseler]

If I am understanding your problem, it sounds like something that I have run into. I would recommend you set all the ESXi hosts to have a scratch volume on your SAN.

If I remember correctly from VMworld, the hosts will complain like that if the scratch volume is on a RAM disk or a local USB/SD storage. I had all my hosts complaining about this and I have no local storage beyond local SD storage where ESXi is installed on.

I created a small volume on our SAN and set the scratch volume to that, creating a folder for each ESXi hosts.

I suggest giving that a try unless you have some reason against doing it.

Ed

[gpalmon]

Thanks Ed,

That sounds like a good solution.

I also wish VMware would have let me acknowledge that warning for good if i wouldnt want to take any steps for changing the current setup.

[etieseler · Accepted solution]

Your welcome gpalmon.

I too would think you should be able to acknowledge and clear the alarm, but I guess VMware wants its customers to set a permanent storage location for these logs.

Don't forget to award points for helpful, answers, to your posts. 😃

Ed                                                                                                                                                                                                                                                                                                                                                                                                                  

[gpalmon]

Thank you Ed

[adrianych]

Hi, sorry to open up this old wound....

I think VMware does not really comply to their logic....

1. VMware ESXi has a small footprint (Approx 140MB), so small that it can fit into 1GB storage.

2. However, after time passes, stuff like logs can grow, especially with that many updates (for me, upgrading since ESX 4.0), then the footprint, if including logs may no longer be small or at least exceeds the 140MB.

3. Furthermore, it is not easy to purge the logs, from both ESXi and vCenter nor to limit the logs retention period or max size.

4. VMware is promoting the use of shared storage (such as SAN or VSA) and therefore more people are finding the local storage being less useful, thus the use of RAID 1 SD cards to store ESXi seems like the almost perfect Win-Win solution, which is cost effective and more power efficient.

5. When we use Enterprise grade SLC SD cards (1GB), it should be regarded as persistant storage to some extent....

So is there a way to disable or clear away the amber alert (Cinfiguration Issues) ?

I would rather reserve the alerts and warnings for more important issues....

[adrianych]

If I am understanding your problem, it sounds like something that I have run into. I would recommend you set all the ESXi hosts to have a scratch volume on your SAN.

If I remember correctly from VMworld, the hosts will complain like that if the scratch volume is on a RAM disk or a local USB/SD storage. I had all my hosts complaining about this and I have no local storage beyond local SD storage where ESXi is installed on.

I created a small volume on our SAN and set the scratch volume to that, creating a folder for each ESXi hosts.

I suggest giving that a try unless you have some reason against doing it.

Ed

I am using Dell EQL and already have a few data stores such that the ESXi hosts can see, how do I set such that the ESXi hosts use one of the data stores ?

[Hooman201110141]

Well isn’t this interesting, I had the same question before and I have yet to setup 5.1

I talked to VMware about this and they said you can leave it in memory and I should NOT use NFS volumes (this is the only solution we have)

Their ideology was if anything happens to that drive the host would die! This is a very scary thought!

Has anyone seen any issues with their setup?

[adrianych]

Welll....I found a workaround....use the datastore, for me I used the datastore which I stored the vCenter, and created 3 folders (each per esxi host). I an in the midst of upgrading from 5.0 to 5.1a.

I have yet to test it out as I just vMotioned some VMs over, I am upgrading the 3rd host. Dumb thing need to reboot to take effect.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=103369...

Well isn’t this interesting, I had the same question before and I have yet to setup 5.1

I talked to VMware about this and they said you can leave it in memory and I should NOT use NFS volumes (this is the only solution we have)

Their ideology was if anything happens to that drive the host would die! This is a very scary thought!

Has anyone seen any issues with their setup?

This was not an issue in ESXi 4.0, ESXi 4.1 & ESXi 5.0.

Ok...maybe NFS gives issue if network is unstable (most network are.....there is almost no such thing as a 99.999% uptime).

Weird thing is that the logs can store in memory but not in a location that is not valid....at least for a while....

But what has this got to do with 700mb of SD card space for us who boot using SD card ?

[adrianych]

Hi...just an update.....

The KB only works if the datastore is on a local drive or local data store which runs on HDD which if your server already has connection to, the message does not appear. No reboot required but somehow it was not immediate (may need to disconnect ESXi hosts then reconnect to cluster).

It works on a datastore, but pls remember to create folders.....one folder per host....

I put the config in new folders with my vCenter's Datastore.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=103369...

So is there no way to remove the alert ?

Else what does the logs do or how will no logs affect the ESXi if the datastore goes offline ?

[etieseler]

Adrianych,

I'm not sure if you already found out how this is done, but in the 'advanced settings' under the 'software' section on the 'Configuration' tab of the host in question, go to the 'ScratchConfig' section. Here is where you enter the path to the shared storage location. use the path with the volumes device ID, such as /vmfs/volumes/4f22ffff-024284ad-8875-643150507138/.locker-hostname  where .locker-hostname is the locker folder for each individual host.

I also placed the syslog location in the same shared storage, using the pathing convention for syslog:  [volume-name] /path/to/syslog/folder

After I did these and rebooted I no longer had the alarm light on.

However, after just checking it right now, it seems my syslog configs are not displayed anymore... I'll have to check if its still working correctly.

-Ed

[merc123]

This has plagued me for three days now.  I currently boot 2, ESXi 5 hosts from a 32GB flash drive.  One of them had scratch space configured and I also created its own datastore/LUN on the fibre channel SAN some time in the past.  Basically I could no longer use VUM on this host but could the other.  I was also getting VM tools install errors (ISO not found) on that host.  

I had been trying to configure the "broke" hosts to use the scratch space on the SAN and it would not.  Finally after creating a local storage datastore it picked it up automatically.  The SAN volume always gave me something like the following error in the system logs on the console:

2012-03-27T08:34:35Z jumpstart: mount point '/vmfs/volumes/4f4363b2-98987a8f-512a-0026b9096143' not restored, waiting 32 seconds

2012-03-27T08:35:07Z jumpstart: mount point '/vmfs/volumes/4f4363b2-98987a8f-512a-0026b9096143' not restored, waiting 64 seconds

2012-03-27T08:36:11Z jumpstart: mount point '/vmfs/volumes/4f4363b2-98987a8f-512a-0026b9096143' not restored before timeout, giving up

I did a fresh install of ESXi, replaced the flash drive and reinstalled ESXi on the new one and still won't work for me.

As soon as I created the local storage though it worked with no issues and automatically assigned that as the scratch space.  I'm assuming because after the mount points can not be restored it automatically tries to locate a suitable VMFS datastore to put them on.  The local storage just happens to have enough space and be suitable so I'm guessing it's defaulting to that.

One thing you can do is SSH to the hosts that have the local storage and do "ls -l" (that's an L) to list the symbolic links and see if the scratch space volume points to the same place as the one in the ScratchConfig.ConfiguredScratchLocation under the Advanced Setting.  I bet it does.  Now SSH to the host that does not have local storage and I'm sure the scratch will show /tmp/scratch or something like that.