If you are a regular reader and like the content I create I would like you to consider voting for my sessions for VMworld 2013.
- Visit the following website: http://www.vmworld.com/cfp.jspa
- Log in with your VMworld account
- Vote for the following sessions
- 4555 vCenter Operations Manager – Troubleshooting Best Practises
- 4799 From vSphere to Hybrid Cloud – Best Practises
VMworld US 2013 is in San Francisco from August 26th to 29th and VMworld Europe is from October 15th to 17th. This year I have submitted two sessions to VMworld. VMworld Call for papers ended April 12.
The title of the first session is: “vCenter Operations Manager – Troubleshooting Best Practises” #4555. I did a session at the danish VMUG March 7th and it was very well received by the audience. This gave me the confidence that it was ready for a bigger audience and I have submitted it for VMworld US and VMworld Europe.
The second session is: “From vSphere to Hybrid Cloud – Best Practises” #4799. This is a session I have submitted with Michael Munk Larsen from Zitcom. In this session we are going to be talking about the move from vSphere to the hybrid cloud, and discuss the challenges and how to build the hybrid cloud.
Hopefully one or both of the sessions will be accepted. I know it is extremely hard to get sessions approved, but I keep my fingers crossed. In a few weeks I expect the public voting to start, and during the public voting I need your help to get attention to the sessions.
I was just working in my lab and wanted to play around with a vSphere 5.x feature. The feature I wanted to use required that the disk is SSD and the disk is Local. My lab environment is entirely virtual and I have no SSD. Here is what I did to accomplish it.
The first thing you need to do is list your devices. Everything is done from the local ESXi shell:
esxcli storage nmp device list
This gave me the following output. The information you need to look for is the “device id” and the “satp”
The next thing we can do is to mark the device as “Local” and “SSD”. I used the following command:
esxcli storage nmp satp rule add –satp VMW_SATP_LOCAL –device mpx.vmhba2:C0:T0:L0 –option “enable_local enable_ssd”
Then we have to claim the new rule:
esxcli storage core claiming reclaim -d mpx.vmhba2:C0:T0:L0
And at the end we can run the following command to verify our changes:
esxcli storage core device list –device=mpx.vmhba2:C0:T0:L0
After doing this ESXi detected the disk as a Local SSD and I could start working in my lab.
Most people who works with vSphere already knows the vCenter Performance Graphs. What most people don’t know is the “Metric Chart” in vCenter Operations Manager. In this article I want to discuss pros and cons of vCenter Performance Graphs vs. vCenter Operations Manager Metric Charts.
The Performance Graphs in vCenter can show information about the following CPU, Datastore, Disk, Memory, Network, Power, System, Virtual disk. You can the select if you want the graph to show: Real-time, Past day, Past week, Past month, past year or Custom.
When looking at these graphs the following table sums up what you are seeing.
So by looking at the Real-Time graph you actually looks at a graph that is updated by a frequency of 20 seconds. So 180 datapoints in just one hour. But when you look at Past Day your graph is updated every 5 minutes. This is where rollup occurs. Without rollup you vCenter database would grow a lot in size. Whatever data you look at in the Past Day the graph is updated in 5 minutes interval, but what happens if you look at the graph more than 24 hours ago? Well if it is in the past week your graph will be updated every 30 minutes, but if you are further back your graph is updated every 2 hours! This basicly tells us that vCenter Performance Charts is BEST in Real-Time, it is alright in Past Day but moving further back than 24 hour data is being rolled up and we loose valuable insight. Look at the following screenshots to see what happens:
You should have noticed how we lose information when we try to investigate performance back in time. The further back we go the more we lose. Not only does data points get rolled up. But try and go back to the first graph. On the first graph we had the counters “Ready” and “Used” but on the other two we only have “Ready”. No I did not remove it. This is another feature of vCenter. Not only does it roll up. But it also chooses to remove counters as soon as we are looking at data more than one hour ago.
Now you should know some of the limitation with vCenter. So what is the solution if you want to look at data that is 1) More than one hour ago or 2) more than one day ago. The answer is of course vCenter Operations Managers Metric Charts. vCenter Operations Manager collects every counter and does not remove them when looking back. And vCenter Operations Manager have data points every 5 minutes. So yes you can argue that the past hour graph in vCenter is better than vCenter Operations Manager! That is true. The only time you actually should use vCenter Performance Graphs is when looking at the “Real-Time” graph.
Lets take a look in vCenter Operations Manager:
The graph is for the “Last Hour” but I can dive into any period and see all counters updated every 5 minutes. Maybe it is monday morning now and we have a reported performance problem that happened this saturday between 2am and 3am. Well just change the graph to that interval. Data is there, and you have EVERY counter.
Yesterday the Danish VMware User Group held a meeting in The movie theater Palads in Copenhagen. The theme of the day was “Admin & monitor” and I did a presentation on vCenter Operations Manager. It was a great day. It is incredible how much of their own time the Danish VMUG team puts into these events. It is really appreciated. The next VMUG.dk events are already beeing prepared and it looks to be a good year.
- June 13th VMUG meeting at VMware in Nærum. This is an Annual event and after the meeting there is a tradition of home brewed beer and BBQ!
- December 3rd. VMUG meeting in Copenhagen @ Bella Centeret. This is the same place as VMworld Europe took place in 2010 and 2011. This VMUG will be a full day conference with 25-30 sessions. They hope to get at least 300 delegates. And of course it is free! So save these two dates. I hope to see you there.
Just wanted to get this out there. The next VMUG DK meeting will be in Copenhagen at “Palads” on March 7th.
You can register for the event here: http://www.eventbrite.com/event/5299404662#
The subject will be “Admin and Monitor”. I will be doing a 50 minutes presentation on “vCops Best Practises” (still working on the title)
After the event you will get tickets for the move “The Last Stand”.
I can’t wait! Hope to see you all there!
After teaching vCenter Operations Analyze & Predict and facilitating private workshops with customers I have had this one question that always pops up. What is the criteria for vC Ops to say a VM is oversized or undersized.
To understand how it is calculated is just one thing. What is more important is what you do with the sizing recommendation. Even though Operations may find a machine to be oversized it does not necessarily make it true.
First thing you will need to do is go into “configuration” from the vC Ops website. Here you can configure the thresholds for oversized and undersized VM’s. The settings in the screenshot is right now at default. I have made some marks in the screenshot. “1. Oversized threshold: 1%“, “2 CPU deman less than: 30%“, “3 Memory deman less than: 30%“
What this means is that if a virtual machines is using less than 30%CPU or 30%Memory for 1% of its running time it is considered oversized. Actually it is not based on time. But it is based on “Area” Look at the next screenshot. The threshold of 30% is the “U” and the threshold of 1% is the blue area. So if the area of the blue is more than 1% of the graph it will be considered oversized.
With the default settings of 30% CPU/Memory and oversized threshold of 1% I bet you are going to have A LOT of virtual machines that are considered oversized. For instance if you have some machines who are idling most of the time but in peaks need LOTS of CPU they will definitely be considered oversized even though from the administrator perspective it is not.
I would change the settings for the threshold. Per default you get way too many oversized virtual machines. I recommend the following:
- Oversized Threshold: 10%
- CPU Demand less than: 15%
- Memory Demand less than: 15%
With these settings a virtual machine is oversized if the area on the graph below the threshold “U” (15% CPU/MEM) is 10% or higher. This is just one recommendation, you can tweak the setting to your own liking.
I was just browsing Veeams website and stumbled over this and wanted to tell you about it. You can win a Samsung Galaxy Tab. All you have to do is register before February 14th.
I think they will have a new draw after this, so check back and see what else you can win.
I have been playing around with vCenter Operations Manager a lot lately. The more I use the product the more I find it useful. At first glance Operations Manager you just see a 3 major badges and 8 minor with some colors that tell you whether an object is performing like it should or not. When you go deeper into the product you find a very useful feature called Heat Maps. You find the Heat Maps under the “Analysis” tab. Here is an example
This is a custom created Heat Map that shows us every VM grouped by ESXi host and colored by the CPU Ready time in ms. This is the configuration for the heat map
What you should notice in the configuration is that the VM’s are colored by “cpu usage” but the size is fixed. This means that every VM will be the same size. If we wanted to we could add another the cpu usage | ready (ms) to the size. This would mean that that heat map would change to the following
And the config looks like this now
In this case we used the same counter for both color and size. To make it more interesting we could create a heat map with two counters. Lets say we wanted to figure out what machines in our environment used the most IOPS and had the highest latency then we could create a config like this
And the result would be the following heat where the biggest box is the “commands per second” (IOPS) and the color is based on the read latency (you could change to write or use overall latency)
The custom heat maps are a great feature to use the data your vCenter Operations have collected. I would suggest you to look into this feature if you are so lucky to have the product installed.