The VMTurbo Workload View and Chart

Discussion created by tcoz on Sep 10, 2014
Latest reply on Sep 24, 2014 by tcoz

[A picture of a workload chart is attached that you can reference as you read through this]


Without a doubt, I get more questions about the Workload View (which contains the Workload Chart and Workload Summary) than anything else.


So if you just can't make heads or tails of why we seem to think it's a very powerful tool, or you do use it but suspect you might not know all the ins and outs, feel free to ask away.


Here's the pitch I often give when I'm approached about it starting with the Workload Chart (which you need to grok in order to completely grok the Workload Summary).


If you look at managing a virtual environment (or any complex and dynamic enterprise for that matter) entirely in terms of dealing with lower-order details and/or one-dimensionally, you're in for a tough ride. Virtual environments are exploding in size and capability, and there's every reason to believe this is going to accelerate.


Eventually, like anything else that contains vast amounts of moving parts that produce vast amounts of data, detailed reports of that produced data is going to get overwhelming. You need to become selective about what data you look at NOW, and what data you know can be looked at some other time, if at all.


That is what the Workload Chart does. It's an at-a-glance view that shows you the overall state of your active workload environment, in terms of Utilization Index ( 0 to 100% ). A quick inspection of it tells you right away, do I have critical (or underutilized etc.) VMs? Do I have VMs running on critical (or underutilized etc.) hosts and/or critical (or underutilized etc.) storage?


You can see all the combinations at once, and identify areas of interest instantly, if you know how to read it.


That breaks down like this:


You have Hosts, and Storage. They provide resources (commodities) to VMs (which provide commodities to Applications and so on). This is a foundation of "workload".


We call things like Hosts, Storage, and VMs, "Service Entities". Every service entity of every kind has its own Utilization Index value (what I will call UtIx to avoid confusing with UI in a GUI discussion...) that ranges from 0 - 100%.


So, let's put Host UtIx on the X axis, and Storage UtIx on the Y. All of my Hosts fall somewhere on the X axis, all of my Storage somewhere on the Y axis, based on their UtIx.


Divide each axis into 10 segments, this creates a 10x10 grid (each representing a 10% UtIx interval). I call the whole grid the Utilization Index Field, or Utix Field, and each segment of the grid, a UtIx Segment.


Every active VM you have, is deployed somewhere in that UtIx Field within one of those Utix Segments, because the Host entity it chose to consume from has a UtIx somewhere between 0 - 100% (on the X axis), and the Storage entity it chose to consume from has a UtIx somewhere between 0 - 100% (on the Y axis).


The more VMs that fall in a given UtIx segment, the higher the concentration of VMs in that UtIx segment of the UtIx Field. This concentration is represented on the workload chart by a "Ring". The bigger the Ring, the more VMs are running at that UtIx Segment. Note that the precise position of the Ring within a given UtIx Segment is determined by some averaging-normalizing-etc. math of all the VMs found in that UtIx Segment.


So (very important...) "Rings" are not individual VMs. They are indications of concentration at a given UtIx Segment in the UtIx Field. The bigger the Ring, the more I have concentrated at that UtIx Segment. Note that on the workload chart the Ring sizes are all made relative to the largest ring (so smaller ring = fewer VMs at that UtIx segment).


So if you are thinking, "since there are 100 UtIx Segments, there can never be more than 100 Rings" you would be correct. This is by design; if a ring was a single VM, imagine an environment with 12,000 VMs. The chart would be unusable (for fun I tried it...believe me it looked like the contents of a circus garbage can).


The color of the Ring, indicates the severity, based on UtIx, of the most critical VM. If all your VMs at that UtIx segment are underutilized, the ring will be blue. If ANY of the VMs at that UtIx segment are normal, the Ring will be green. Any of them warning, yellow, and any of them critical, red.


So, say I see a big red ring, far bigger than any other, running in the high upper, and far right, of the UtIx field.


That would read, "I have a high concentration of VMs (a big Ring), running on host entities with a very high UtIx on the X axis, and storage entities with a very high UtIx on the Y axis. The Ring is red, so I have at least one VM with very high UtIx there."


Now, using your mouse, click/drag to draw a square around that ring on the chart.


A window will pop up, showing a list of the VMs at that selection area, sorted by UtIx, and a list of the Recommendations related to those selected VMs (we changed this so they are side-by-side now instead of having to toggle back and forth). This is how you get your counts of how many VMs are actually here and there, and what their criticality, based on UtIx, is, and what Recommendations are related to them.


Each VM in the now-open VM list also shows the name and UtIx of that VM's host and storage entity (both by number and color); clicking any of the names (VM, host, or storage) will take you to a detail screen where you can get to the lower-order stuff.


That's usually how I get people started; explain it's an abstraction showing concentrations of VMs based on the UtIx of their providers, which gives an at-a-glance opportunity to be selective about what you want to look at immediately, what recommendations are on the board for that selected area, and a short path to drill into the typical monitoring details and so forth if you need to.


Ask away...


Message was edited by: Tim Consolazio  Picture of a Workload Chart added.