undersized and oversized vm reports

[jeremyh8]

I am wondering why these reports dont use "active memory" when analyzing memory? I have vms that have a 8gb of memory allocated to them and less than 1gb of that memory is active. The report does not suggest reducing this vms memory. Also can someone explain how it decides if a machine is over/under provisioned? thanks

[Vitaliy S.]

Hi Jeremy,

Actually we ARE using VM Memory Usage (Active/Granted) metric in our reports.

VM is considered as under-sized when its average CPU/Memory usage is above 90%, besides you should have CPU Ready, Swap Out Rate metrics above the defined threshold too.

As to over-sized VMs, then we are looking at both average usage and peak resource utilization to give you VM sizing recommendations. Keep in mind that looking just on average usage cannot give you the true picture of VM resource utilization, as for example your accounting department might be using the VM heavily only once a week and you should keep allocated RAM, CPU on the same level to satisfy the resources demand during the busiest day of the week for this VM. In addition to this logic, we reserve 25% of available resources, so that your VM is not starving on CPU,Memory resources during peak hours.

If you want to dig deeper, I would suggest reviewing weekly resources utilization of this VM - check out average and peak CPU, Memory usage and other related performance metrics.

Hope this helps!

[jeremyh8]

at the top of my undersized report it says "consumed" for memory
at the top of my oversized it says "usage"
I dont see active memory. If veeam does not use the same terminology as vmware then is there a chart somewhere that defines veeam metrics?

[Vitaliy S.]

Undersized report has a wrong column label, I will ask our dev team to fix it in the next update.

Usage is the correct term. Memory usage is calculated by dividing Virtual Machine Memory Active on Virtual Machine Memory Granted. Thanks!

[jeremyh8]

5206668 is the case i opened with support. It appears that both reports may be using consumed memory metrics instead of memory usage. I will update this post when i have a resolution.

[Vitaliy S.]

Jeremy, let me double-check this information with our dev team also. I will post back when I have more details.

[Vitaliy S.]

It seems like you were right, for the oversized VMs report "memory consumed" is used. While in most cases memory consumed might be "ok" to determine VM over-allocation, this approach will not work for SQL Server VMs which consume all the memory that has been allocated to them.

We'll update our reports with the new metrics in our next release, thanks for the heads up!

[kevinnaughton]

I have the same issue regarding Memory usage in the oversized VMs report. It seems to be the case for a SQL server (explained above) but also for my vCenter server and Veeam server. All show capacity, average usage, and peak usage as the same as what is provisioned for those VMs. Is it because all have SQL or SQLExpress running on them? Any ETA on the correction for this?

[Vitaliy S.]

Is it because all have SQL or SQLExpress running on them?

Correct.

Any ETA on the correction for this?

This report will be corrected in our next update which is scheduled to Q4.

[keithkleiman]

We have 2000 vms in our environment. According to the undersized report it suggests that 1940 of them are undersized due to vRAM. This does not appear to make much sense to me, but could someone clarify how I should be using this report? Is memoryConsumedMB the correct metric that should be used for this type of a report? I know that the amount actually used within the guest OS of these vms have plenty of available memory. I am using Veeam 6 within a SCOM 2012 environment. Thanks!

[Vitaliy S.]

Keith,

Are you using our Management Pack for SCOM or Veeam ONE to detect undersized VMs? Our report is using VM average resource consumption/swap rate/CPU ready metrics to detect whether you're oversized or undersized. What type of VMs do you have? Do you host lots of SQL Servers?

Thanks!

[keithkleiman]

I am using the mp for Veeam 6. We have some SQL servers, but not that many. Most of these systems have plenty of available memory according to the guest OS.

[Vitaliy S.]

Keith,

The reason why VMs can be reported as undersized could be the following:

1. The peak usage during the past period + 25% of headroom > then currently configured value.
2. SQL Server VMs will always consume all the memory you allocate to these VMs, so the best way to check its sizing is to use all these metrics (Active Memory, Consumed Memory and In-Guest Memory usage).
3. You can disregard the headroom that we add to the RAM configuration and then check VM configurations against our recommendations.

Thanks!

[samh22a]

Is this working with hyperv as well ? If not, any eta

In the doc, it says zombie vm and other right sizing reports are only available with vmware

Thx

[Vitaliy S.]

Hi Sam,

There reports are not currently available for Hyper-V, we are looking into possibility of adding these reports in our upcoming versions. Can you please tell me what TOP 5 reports you would like to see in Veeam ONE?

Thanks!

[samh22a]

undersized - oversized VM
Zombie VM
powered off vm
unused template
etc

I would expect to not only list the VM but to actually give me a recommendation on what the proper sizing should be. Ex: Add 2 CPU, remove 6 gigs of ram..etc

I haven't seem the version for ESX as we are only using hyper-V.

[Shestakov]

Hi Sam,
Thank you for the feedback! We will work on it in upcoming versions.
Nikita

[keithkleiman]

For the memory usage analysis dashboards, wouldn't it be better to use MemoryActivePct as opposed to using memoryConsumedMB? My reason is best explained in a scenario we just had. We had a host that generated an alert for high memory usage. I right clicked in the host and opened the Memory usage anlaysis dashboard in hopes of seeing what vm might have influenced this. Displayed was the list of vms with the top memoryConsumedMB. This is just the vm that is configured to use this amount of memory, but not actively using it if I am correct. Based on my understanding it seems like MemoryActivePct would be better used in this dashboard.

[Shestakov]

Hello Keith,
What you are talking about makes sense. However, it`s probably better to have an option which counter to choose for the report.
I`ll forward your reference to the development team.
Thank you for the participation.

[Morgenstern72]

I was directed from your support to this forum:
"We do receive complaints about this report. It would be best for you to directly discuss this issue with our product management on Veeam Forums. As a support person I am not eligible to argue on the logic of the report. I'd recommend contacting our PM that would surely make better progress. Apologies for any inconvenience.
Please let me know if you have any questions."

Problem/Bug
I did my first "Oversized VMs" report, configured for the last two months. It did tell me that I can hugely resize machines. The problem is, when you do the report again after one week it tells me to reduce already reduced machines based on the old values!

Example
Server, 12 CPUs -> peak usage 60% -> configure with 8 CPUs -> done
Report one week later shows Server, 8 CPUs -> peak usage 60% -> configure with 5 CPUs!

It looks like the report does not modify the peak usage regarding to already changed CPUs and still takes the value of 12 CPUs instead of now 8 CPUs. This leads to a recommendation that seems to be quite wrong. When I go on like this I would end with 2 CPUs!
It's quite bad because good recommendations (of so far unchanged VMs) are mixed now with these ones and without a printout of an old report I am not able to see which VMs I can really resize.

This seems to be clearly a bug but support means it is not a bug but "Please bear in mind that Oversized\Undersized Vms reports are more of informative nature and do not oblige you to follow the recommendations". Well, that's rendering the reports useless....

[Vitaliy S.]

Joachim,

Thanks for the detailed feedback.

It looks like the report does not modify the peak usage regarding to already changed CPUs and still takes the value of 12 CPUs instead of now 8 CPUs.

You're correct, that reports looks at the historical data and I'm not sure how it should modify performance usage for the new configuration. You cannot map historical performance to new configuration.

This leads to a recommendation that seems to be quite wrong. When I go on like this I would end with 2 CPUs

These recommendations are not wrong, they are based on the existing performance data. I would recommend running this report once a month, in order to have enough data to anaylize the trend and make recommendation.

It's quite bad because good recommendations (of so far unchanged VMs) are mixed now with these ones and without a printout of an old report I am not able to see which VMs I can really resize.

You're correct here, that currently it is not possible to differentiate VMs that have been modified from the VMs that are still over-provisioned. The same question was raised by our QC team in one of the internal report discussions.

What if we create another table in this report which will list all VMs that have been recently modified? In this case you will be able to filter VMs that have been changed and collect more performance data for them in order to re-evaluate their new configuration later.

Thank you!

[Morgenstern72]

Hi Vitaly

thx for the fast response

Is there no way to store your own data and so be able to recognize changed VMs (only CPU and RAM) in the reports? Or is there maybe a way to get VMWare to tell your app if a VM has changed RAM/CPUs in the same time that you choose the report to query and highlight/exclude changed machines?
At last there should be a warning that changes are not reflected in historical data.

A second report would be a nice workaround, especially if you could combine/chain it to the Oversize/Undersize Report.

[Vitaliy S.]

Joachim,

Veeam ONE does store VM configuration in its database and we are able to track VM configuration, so additional query to VMware might slow down report generation.

At last there should be a warning that changes are not reflected in historical data.

Good idea, thanks!

A second report would be a nice workaround, especially if you could combine/chain it to the Oversize/Undersize Report

Yes, I was thinking about having this table in the same report.

BTW, I have just thought about this situation once again, and according to my math, this "issue" should not be present in VM memory recommendations engine. When doing VM memory analysis, we know what absolute configured values are, also we know what is the current value of memory usage in absolute values, so it does not actually matter when you have changed VM configuration. Both values can be matched and correlated at any time, so recommendations of reducing memory will not show up in the report.

The situation is a bit different with CPU, since usually max configured value in absolute values is the physical CPU limit of the host (unless you're using reservations/limits in advanced VM configuration). Given all this, in order to detect VMs over/under provisioned status I believe CPU usage in "%" is used (will double-check that), and that is why VMs may show up multiple times in the report. Let me run a couple of test in our own lab to confirm that.

Thanks!

[keithkleiman]

Vitaly,

Late getting back, however the problem seems to be that the oversized report is still using memory consumed and not active which really eliminates the validity of determining if more memory should be allocated to a virtual machine. For example I have a simple server (not sql or anything like it) with 16 gb of memory allocated to it. When the undersized report is run it shows 16 gb memory consumed and recommends adding 4 gb to up it to 20 gb. However when you look at the actual amount of memory used it is like 17%. Perhaps the issue is my understanding of memory consumed vs active and how this report should be used.

Keith

[keithkleiman]

Perhaps the oversized report may be useful for charge back purposes, but not actually determining if more memory is needed to service the application on the vm. Continuing my previous example, if I have a vm with 16 GB allocated and showing 17% actively used and it recommends allocating 4 gb more. Would you say this is a useful recommendation and if so can someone explain how this would be useful? I have an application owner who saw this report and is confused if more memory is needed, but the VMWare admins are looking at this report and don't believe it is a valid recommendation.

[Vitaliy S.]

Hi Keith,

Late getting back, however the problem seems to be that the oversized report is still using memory consumed and not active which really eliminates the validity of determining if more memory should be allocated to a virtual machine.

Over-sized VMs report has an option which metric to use, you need to select that in the report parameters > http://helpcenter.veeam.com/one/70/repo ... hines.html

Can you please tell me what values does it show for you VM (trying both options)?

Thanks!

[keithkleiman]

I just realized this thread is on the Veeam One page and the doc you referred me to was for VeeamOne. I actually have the Veeam 7 mp implemented in my SCOM 2012 environment. I do not see this parameter available. I assume this is not yet available, but please confirm.

[Vitaliy S.]

Ah... now I understand where the confusion comes from. Yes, you're correct, currently only memory consumed is used in this report, which might not be 100% applicable for VMs like Exchange and SQL Server as these VMs will always consume all allocated memory. I have checked with the R&D team regarding making changes to this report, so in the next update there will be a separate report using in-guest memory usage for making recommendations.