I have one host with this error message – no persistent cache location. It is identical to my other 3 hosts but they do not have this error. I am starting to get PernixData FVP installed and somewhere in their documentation (install guide) they mention the persistent scratch situation should be taken care of. Since I had one server with the error that I don’t have a persistent cache location I needed to deal with it since that means there is no persistent scratch location. I do not in fact know why it has this error when the other hosts do not. I thought it might be due to my using this host as a vSphere 6 host, and then doing a destructive install of vSphere 5 on it. So I removed the partitions on the SD (using GPartEd), and installed vSphere 5 on it. And I give it a persistent scratch location. Now I do not get the error message about no persistent cache location. But I do get an error:
No coredump has been configured. Host core dumps cannot be saved.
This is I think misleading. Again why do the other hosts not have this issue?
But when I think about this, I realize that the no persistent cache message is legit and should be seen on all servers since they are all booting from their own 2 GB SD. Where is the persistent cache location in that circumstances? In RAM I think so not persistent.
But below is the info on doing a persistent scratch location which will solve the issue about no persistent cache location. It even has a core folder in it which I think is for saving coredumps but I still get that error on one host. See below the error.
Creating a persistent scratch location
I think that this might be a best practice for when you boot from SD. Use the steps below to create a persistent scratch location. BTW, here is a VMware KB article that talks a little about this.
You will need to create a datastore for your hosts. I have set aside 10 GB for each host – thinking it may hold a coredump but not sure about that – plus VMware would normally create a 4 GB one if it could. I have used a NFS datastore for this.
In my screenshots I am using as the location a datastore called esxscratch that is mounted on each host. This means when we configure the settings to use it the path will look like below.
In this scratch location you should create a folder for each host. I use the host name for the folder name. It would look like:
You will need to be working in the vSphere Web Client. You will need to be in Advanced System Settings. At that time use the search bar on the right and look for scratch. See below what this looks like.
Now edit the variable called
And add to the value field the appropriate value. In my case it looks like below.
Now you will need to do this for each host. Once you are done with that you need to do maintenance mode, and restart each host.
After the restart of each host
Once your host is restarted, if you look in your scratch location you will see something like below.
As well, if you go back to the advanced settings area and look at the scratch location it will look a little different.
The reason is that the datastore name – esxscratch is in fact an alias and what you see in the screenshot above is the actual name. This also shows you that you are in fact using the new location.
I think it is a good idea to have a persistent scratch location when you are using SD to boot your ESXi hosts. You have seen how to do that above. I still have the no coredump error on one single host and I will investigate that and update this article when I figure it out.
- 4/13/20 – this does not work with vSphere 7. And vSphere 7 has new method that I have not figured out yet.
- 10/20/19 – I used this with vSphere 6.7 U2, and vSphere 6.7 U3 and the HTML5 client and had no issues. Worked good.
- 3/17/19 – if you need to use this, the info above works good with 6.7 U1. I do like the idea of bigger USB or SD but if that is not possible – like in my lab, than doing this process is good and it works.
- 4/14/15 1620 – I would suggest that you do not use your storage array for the scratch location – or carefully consider the decision. If the array has an issue your ESXi hosts can respond oddly due to the lack of access to their scratch location. Some ideas might be to use bigger USB or SD, or use a local disk as a datastore.
=== END ===