MitchDrage commented on code in PR #14398:
URL: https://github.com/apache/cloudstack/pull/14398#discussion_r4278837055
##########
server/src/main/java/com/cloud/server/StatsCollector.java:
##########
@@ -1220,6 +1220,7 @@ class VmStatsCollector extends AbstractStatsCollector {
protected void runInContext() {
try {
SearchCriteria<HostVO> sc =
createSearchCriteriaForHostTypeRoutingStateUpAndNotInMaintenance();
+ sc.addAnd("managementServerId", SearchCriteria.Op.EQ,
managementServerNodeId);
Review Comment:
Thanks for raising this.
The result for KVM is that the value returned by
LibvirtComputingResource.getVmStat is a delta since the last poll by any
management server, so the total will be the same, just counted less often.
I'm only familiar with KVM so I went looking into your question a bit
further to be sure.
For VMware and Xen it's a bit more interesting... From the best I can see
(and I got some AI help to confirm), each poll there returns an average over a
fixed window, so every management server stores roughly the same value. With
vm.stats.increment.metrics on, those rows get added up, so the totals have been
N times the real value (where N is the number of management servers). My fix
inadvertently solves a bug I didn't see.
For example, a VMware VM receiving a steady 100 KB/s with 3 management
servers stores three rows of ~100 every minute which get added up, so the total
goes up by 300 each minute. With one management server, or with this fix, it
goes up by 100.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
