Best Practices


ESX Tip — Having a Baseline

by Steve  | January 13th, 2009

We have all had those defining moments where something has gone terribly wrong.  You find yourself sitting behind your monitor with what seems like all of upper management behind you.   The first thing you do is open up the logs and start looking for the needle in the haystack, the root cause to your problem.  One thing I have found is, as soon as you starting looking at the logs, you find all sorts of things you did not know about.  How much of what you find is normal and how much of the logs point to the problem?   Would you really know? 

Let me share a tip with you that might save you some time when things go wrong.  I am a firm believer that VMware’s ESX server should be treated as an appliance.  When there is a problem, rebuild.  If it is not a hardware issue then a rebuild should solve your problem.  Upper management likes to know “root cause.”   They like to be able to report that X was the problem caused by Y and fixed by Z.  Now is the time to make that support call to VMware and the first thing the support technician will have you do is run the vm-support script and send the output to VMware for review. 

So, what is the tip you ask?  When you build or rebuild an ESX server this is an excellent time to get a baseline to compare to later.  Once the configuration is done, run the vm-support script before you put that host into production. When a problem arises, you can send both script outputs to VMware and now you have a way to compare the way the host was before the problem and the way it is now.  This is a good, easy method to help speed up root cause analysis.


Tags , , , , , , , , , , , ,

This entry was posted on Tuesday, January 13th, 2009 at 4:19 pm and is filed under Virtual Tech. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Comments

Hey Steve, nice post and good point.

I sometimes tend to reinstall an ESX host when it doesn’t do what I want but the logging/explanation is usually more important. But with your suggestion you can get your environment quickly up-and-running again and start analyzing later-on.

I’ll definitly try to adopt your suggestion quickly, see how it works.


Add a Comment

x

Subscribe to The Virtual Black Hole RSS Feed Email Notification

Enter your email address:

Delivered by FeedBurner