Using vCops in the real world. A few findings along the way.
Ok, I have been using vCops for quite a while and I have mostly come across posts that are showing how to leverage a few of the features but they what I would call the “prescriptive lab” where everything is setup to show you a situation. I think that these posts are great and I know that I used them a lot when I first got into the product. Now, this could just be me being a bit simple but I found that when I scratched below these examples things got complex and there are so many settings and metrics that are not always that clear on how to use them and what to look for. So with that in mind here is a post with a few of my findings. I hope that they may help someone else out there!
Also, I have been a bit cheeky and lifted my notes straight into this post, so it may be a little rough around the edges!
When using non trend views set a lower interval as a VM or Host or Datastore for example must exist for the entire period that you have set to appear in the view and be taken into account.
Non trend views are summary views for example and are controlled globally in the settings and apply to all views.
Just a little bit of extra info on intervals. If you select Daily for example with an interval of 12 that would show the last 12 days of data. So interval is determined by the interval type selected. So I thought that if you selected daily and 12 intervals it would show you 2 hour samples through out the day. And like wise, select monthly and 12 and you get 12 points of data collection rolled up and presented. D’oh, talk about over complicating that one!
Demand or Allocation models
In the case of allocation and demand settings there are a few things to know. A container in the case of vCops is a cluster and not the folders that you pull from the VM and templates view. If you select to do both demand and allocation is will show the most restrictive case for the interval that you have set.
What we are seeing below is that our effective demand is more containing than allocation as our over allocation rule is set to 5:1 for CPU.
When we look at the usage and host usage we see and average usage of 38%, so how can that be? You must remember that is an average so we have to dig a bit deeper and look at the same report at a per host level.
Host 1 – Over by 5
Host 2 – Neutral
Host 3 – 1.6 VM capacity remaining
Host 4 – Over by nine
Using the operations tab you can get a breakdown of the hosts real-time work. Looking the CPU chart you can actually see that most hosts are showing a larger bar line for CPU demand when compared to usage.
At this point lets put a quick definition on demand. Demand is basically what the VMs want and would use providing that there was not any contention. So when demand is high and usage is below we have contention occurring. Now this could be from just one or two larger VMS and we can drill down to find out what the cause is. So to use another point in our case in these charts the VMS are looking for more than is available.
So this could be that a number of VMs have too many CPUs assigned and they are showing more demand but having to wait so high co-stp and cpu ready times, or it could be an in balance of VMs that DRS cannot fix or just lots of hungry applications!
You may have noticed that one of the hosts (02) was showing no data and this is due to a problem that has yet to be resolved….
** Note that capacity risk report also shows this info in a nice way. Less detail, more high level.
You need to have a policy in place that says what your over commit policy is. This is used to show in summary views how much remaining capacity you have based on that rule.
We have ours set to 5:1 that shows a neutral view to vCentre in terms of number of VMS that we have.
In terms of average VM spec vCops uses its trending information to determine a Small Med and Large profile for our environment
Setting a work week avoids backup traffic for example being classed as an everyday trend.
vCops polls vCentre every 20 seconds for its real-time data. It does not look back at its historical data.