Almost on a daily basis, I get questions from colleagues and customers about specific advanced settings. Somehow they spotted a vSphere advanced setting and wonder if they should set it. They go on a hunt to figure out what it is this specific vSphere advanced setting does and typically find a description on a random website that makes it sound like it is a good idea to configure it. I even had someone asking if I could give a list of all optimized values for the advanced kernel parameters recently. My answer was short and maybe a bit blunt, but I think it was clear:
I hope the sign above makes it clear you should not randomly set advanced settings. Some of you will laugh and say “well that is obvious” while others probably will scratch their head and open their vSphere client and check the advanced settings section. I know I discuss advanced settings every once in a while, but you should only apply these settings when:
- You have a requirement to implement this advanced setting, do not tweak them “just because you can”. An example would be in a stretched cluster you set “disk.terminateVMOnPDLDefault” because of the infrastructure implemented.
- The advanced setting solves a problem in your environment (and preferably, in that case, see 3)
- When recommended by VMware Global Support Services
If you have implemented an advanced setting, document it and with every update or upgrade validate it is still applicable to that specific version or not. (If you are aspiring to be a VCDX, this is key.) If it no longer applies, remove revert to default!
Fred Peterson says
How often is it because people want to ‘optimize’ their environment versus it being more of a curiosity thing to tinker with just to see what happens, they are not necessarily looking to solve a problem just “gain a couple more percent performance”
Reminds me of tinkering with configuration files in first person shooters to gain a perceived edge. When ultimately the top players don’t actually do much tinkering at all.
Duncan Epping says
It is all about weighing the risk up against the potential gains… and key here us “potential”. Agreed, not the smartest strategy. Keep it simple!
James says
I always find that it is some manager poking around at the UI and see’s that “advanced settings” section. They want to stick something in there like a fork to an electrical socket. You might get zapped playing with the wrong things!
– burdweiser
Michael Webster says
I see this often that people are trying to play with advanced settings without a good justification. The default settings are good for most situations and I try and stick to the defaults as much as possible. As soon as you move away from a default setting it is one more additional thing that has to be managed and considered as part of the environment lifecycle. There are less and less instances where you should modify defaults these days. Especially as more of the common optimizations are being made available through the vSphere Web Client, such as the new Latency Sensitive Setting. Even for business critical apps the defaults are good and do not need to be modified for most situations.
Phil says
Michael,
Has documentation surfaced yet as to what exactly those Latency Sensitive settings do? There must be some negative to it otherwise we may as well just configure every VM as latency sensitive to ensure performance.
Andrew Mitchell says
It’s a trade off between CPU utilization and latency. Refer to http://www.vmware.com/files/pdf/techpaper/VMW-Tuning-Latency-Sensitive-Workloads.pdf for details.
Miguel says
Duncan,
Great post!
“Is there an issue? Is there a VMware KB article addressing a fix? Will it cause an outage or is there risk of an outage? These are the things I look at before making changes in the advanced settings. NetApp VSC has an optimization for the hosts that is like the old school HUK, but now it is automated. That will change advanced settings as well, and can skew your VMware Health Check output, which can also cause you to scratch your head, if you are not aware of this. How do I know?…..Leave the advanced settings in, use good process and documentation. My 2 euro:)”
Ross Cavanagh says
Thank you, thank you, thank you! Oh, I how much I want to post this blog everywhere in our offices. I feel like I’ve been banging my head against a brick wall sometimes at my current workplace due to their wild advanced setting tweaks. So, I just really want to say a big thank you for writing this and I’ll be using it as a reference point for everyone within the company that dabbles in changing such settings.
Alexander Thoma says
Amen!
In my many years as a VMware PSO consultant I have seen a lot of customers playing around with advanced settings just for the sake of it. Many times I have been asked why VMware does not document all of them. My answer always was: “Because you are not supposed to change them anyways! So why do you want to know them?”
By the way – if VMware PSO does a Health Check of your environment, you better have a documented list of changes to advanced settings and their justification handy. You will be asked of it :-).
Bottom line is – only change them if requested by VMware Support or necessary by documented requirements (KB articles, VMware documentation etc.).