VMware Cloud Community
DLally
Enthusiast
Enthusiast
Jump to solution

Reclaimable waste

So I'm coming from vKernel, where the right sizer takes into account peaks when giving recommendations on removing/adding resources.  According to the configuration on oversized VM's, it's only looking at an average utilization over the period I have setup(30 days).  So when I look at a large VM in vCOPS, it's saying change a VM from 6 vCPU to 1 and change memory from 42gb to 18gb.  The thing is when I view a 30 day report on memory, I see a spike above that 18gb that was recommended.   It seems like if I'm not accounting for peaks, I could potentially cripple an application.   So if I make my own judgement call, then I'll always have reclaimable waste and it'll be a never ending cycle.

My thinking, maybe someone can help me here.  Is that the recommendation doesn't take into account that high peak, possibly because it categorizes it as an anomaly?

I'm just trying to get a better understanding on how/why vCOPS is giving these recommendations, so any help would be much appreciated.

0 Kudos
1 Solution

Accepted Solutions
jddias
VMware Employee
VMware Employee
Jump to solution

Hi DLally,

  Every system peaks at some point, the question is "do we need to anticipate and plan for that peak?"  The recommendations made by vC Ops guide you to systems that may have reclaimable resources due to over allocated VMs.  One thing to keep in mind is that the "reclaimable waste" is an opportunity, not a target.  In other words, vC Ops is offering recommendations to avoid or delay hardware upgrades and also telling you what you can do with the resources you have today based on utilization.  A lot of times admins see the "Efficiency" score and treat it like an operational problem and that's not how you should look at it.  Generally speaking, don't worry about chasing down over sized VMs unless you need the capacity to add machines or avoid hitting the "time remaining" wall for a resource.  Using "All Metrics" to validate peaks in resource areas over a 7 or 30 day period is a good idea when considering resizing.

  You can fine tune vC Ops to take peak behavior into consideration using policies.  You can adjusts the Oversized and Undersized determination as well as include Stress (a better word for 'peak') in time remaining and capacity available calculations.  Also, there are some OOTB policy templates that are tuned for 15-min and 30-min peak workloads.  Check those out as well.

Visit my blog for vCloud Management tips and tricks - http://www.storagegumbo.com

View solution in original post

0 Kudos
2 Replies
jddias
VMware Employee
VMware Employee
Jump to solution

Hi DLally,

  Every system peaks at some point, the question is "do we need to anticipate and plan for that peak?"  The recommendations made by vC Ops guide you to systems that may have reclaimable resources due to over allocated VMs.  One thing to keep in mind is that the "reclaimable waste" is an opportunity, not a target.  In other words, vC Ops is offering recommendations to avoid or delay hardware upgrades and also telling you what you can do with the resources you have today based on utilization.  A lot of times admins see the "Efficiency" score and treat it like an operational problem and that's not how you should look at it.  Generally speaking, don't worry about chasing down over sized VMs unless you need the capacity to add machines or avoid hitting the "time remaining" wall for a resource.  Using "All Metrics" to validate peaks in resource areas over a 7 or 30 day period is a good idea when considering resizing.

  You can fine tune vC Ops to take peak behavior into consideration using policies.  You can adjusts the Oversized and Undersized determination as well as include Stress (a better word for 'peak') in time remaining and capacity available calculations.  Also, there are some OOTB policy templates that are tuned for 15-min and 30-min peak workloads.  Check those out as well.

Visit my blog for vCloud Management tips and tricks - http://www.storagegumbo.com
0 Kudos
DLally
Enthusiast
Enthusiast
Jump to solution

Thank you, that helps me out a bit more.

0 Kudos