Introduction
Recently we had to upgrade a lot of our Usage Meter estate from version 4.8 to version 9. After the upgrade, we had a lot of Usage Meters that did not complete collections correctly. It did not seem we had any other issues that made obvious what was happening.
Troubleshooting
Heading to the logs for troubleshooting we found not much, but the following was found in the following log file: /opt/vmware/cloudusagemetering/platform/log/ollection-vcenter-error.log
2025-07-09 08:13:19.217 ERROR --- [collector-main-thread] c.v.u.v.vsan.VsanCollectionException : Unexpected error while getting claimed capacity for cluster with id: domain-cxxxxx
2025-07-09 08:13:19.217 ERROR --- [collector-main-thread] c.v.u.v.vsan.VsanCollectionStage : Error while getting claimed capacity
com.vmware.um.vccollector.vsan.VsanCollectionException: Unexpected error while getting claimed capacity for cluster with id: domain-cxxxxx
at com.vmware.um.vccollector.vsan.VsanServiceSession.getClaimedCapacity(VsanServiceSession.java:749)
at com.vmware.um.vccollector.vsan.VsanCollectionStage.getClaimedCapacity(VsanCollectionStage.java:506)
at com.vmware.um.vccollector.vsan.VsanCollectionStage.collectClusterUsage(VsanCollectionStage.java:300)
at com.vmware.um.vccollector.vsan.VsanCollectionStage.collectUsage(VsanCollectionStage.java:165)
at com.vmware.um.vccollector.VCCollector.collectStages(VCCollector.java:270)
at com.vmware.um.vccollector.VCCollector.collect(VCCollector.java:212)
at com.vmware.um.vccollector.VCCollector.collect(VCCollector.java:39)
at com.vmware.um.collector.CollectionHelper.collectFromServer(CollectionHelper.java:642)
at com.vmware.um.collector.CollectionHelper.collectFromServersWithReporting(CollectionHelper.java:808)
at com.vmware.um.collector.CollectionHelper.collectWithReporting(CollectionHelper.java:617)
at com.vmware.um.collector.SynchronousCollectionExecutor.triggerCollection(SynchronousCollectionExecutor.java:42)
at com.vmware.um.collector.AbstractCollectorComponent.handleCollectCommand(AbstractCollectorComponent.java:134)
at com.vmware.um.collector.AbstractCollectorComponent.handleCommand(AbstractCollectorComponent.java:55)
at com.vmware.um.collector.CollectorComponent.handleCommand(CollectorComponent.java:25)
at com.vmware.um.collector.CollectionHelper.processCommand(CollectionHelper.java:894)
at com.vmware.um.collector.AbstractCollector.processCommand(AbstractCollector.java:263)
at com.vmware.um.umcomponent.CommandRunner$CommandExecutionWrapper.execute(CommandRunner.java:397)
at com.vmware.um.umcomponent.CommandRunner.invokeCollector(CommandRunner.java:248)
at com.vmware.um.umcomponent.CommandRunner.lambda$executeCommand$1(CommandRunner.java:204)
at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: Unable to resolve WSDL method name VsanClusterGetClaimedCapacity in vsan.version.version20 (vsan/reserved)
while parsing SOAP body
at line 1, column 102
while parsing SOAP envelope
at line 1, column 38
while parsing HTTP request before method was determined
at line 1, column 0 Please see the server log to find more detail regarding exact cause of the failure.
and in the following log file there were also some mentions:/opt/vmware/cloudusagemetering/platform/log/ollection-vcenter-main.log
2025-07-08 16:13:13.194 ERROR --- [collector-main-thread] c.v.u.v.vsan.VsanCollectionException : Unexpected error while getting claimed capacity for cluster with id: domain-cxxxxx
2025-07-08 16:13:13.194 INFO --- [collector-main-thread] c.v.u.v.vsan.VsanServiceSession : vSAN vsanClusterGetClaimedCapacity API took 0ms
2025-07-08 16:13:13.194 ERROR --- [collector-main-thread] c.v.u.v.vsan.VsanCollectionStage : Error while getting claimed capacity
com.vmware.um.vccollector.vsan.VsanCollectionException: Unexpected error while getting claimed capacity for cluster with id: domain-cxxxxx
at com.vmware.um.vccollector.vsan.VsanServiceSession.getClaimedCapacity(VsanServiceSession.java:749)
at com.vmware.um.vccollector.vsan.VsanCollectionStage.getClaimedCapacity(VsanCollectionStage.java:506)
at com.vmware.um.vccollector.vsan.VsanCollectionStage.collectClusterUsage(VsanCollectionStage.java:300)
at com.vmware.um.vccollector.vsan.VsanCollectionStage.collectUsage(VsanCollectionStage.java:165)
at com.vmware.um.vccollector.VCCollector.collectStages(VCCollector.java:270)
at com.vmware.um.vccollector.VCCollector.collect(VCCollector.java:212)
at com.vmware.um.vccollector.VCCollector.collect(VCCollector.java:39)
at com.vmware.um.collector.CollectionHelper.collectFromServer(CollectionHelper.java:642)
at com.vmware.um.collector.CollectionHelper.collectFromServersWithReporting(CollectionHelper.java:808)
at com.vmware.um.collector.CollectionHelper.collectWithReporting(CollectionHelper.java:617)
at com.vmware.um.collector.SynchronousCollectionExecutor.triggerCollection(SynchronousCollectionExecutor.java:42)
at com.vmware.um.collector.AbstractCollectorComponent.handleCollectCommand(AbstractCollectorComponent.java:134)
at com.vmware.um.collector.AbstractCollectorComponent.handleCommand(AbstractCollectorComponent.java:55)
at com.vmware.um.collector.CollectorComponent.handleCommand(CollectorComponent.java:25)
at com.vmware.um.collector.CollectionHelper.processCommand(CollectionHelper.java:894)
at com.vmware.um.collector.AbstractCollector.processCommand(AbstractCollector.java:263)
at com.vmware.um.umcomponent.CommandRunner$CommandExecutionWrapper.execute(CommandRunner.java:397)
at com.vmware.um.umcomponent.CommandRunner.invokeCollector(CommandRunner.java:248)
at com.vmware.um.umcomponent.CommandRunner.lambda$executeCommand$1(CommandRunner.java:204)
at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: Unable to resolve WSDL method name VsanClusterGetClaimedCapacity in vsan.version.version20 (vsan/reserved)
while parsing SOAP body
at line 1, column 102
After reviewing this I found a release note mention for the upgrade to Usage Meter v9:
Incomplete vCenter collection for some vSAN versions below 8 Update 3 If the vSAN version is below 8 Update 3, you might receive an Incomplete collection status for the vCenter collection. The following error appears in the log. Caused by: com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: Unable to resolve WSDL method name VsanClusterGetClaimedCapacity in vsan.version.version20 (vsan/reserved) The issue does not affect the correctness of the core vSAN usage report.
While we did read the release notes, obviously this was forgotten once we noticed this error. Because I was curious what was happening and I found a KB with some more information I wanted to let you see what is happening.
So the issue itself is that the output from vCenter Server on the following HTTP call: https://<vc_ip>/sdk/vsanServiceVersions.xml contains characters and a version that cannot be processed by the new code in Usage Meter v9. Eventhough these versions of vSphere are compatible. Executing the call on our environment yielded the following:
<namespaces version="1.0"> <namespace> <name>urn:vsan</name> <version>vSAN 7.0U3</version> <priorVersions> <version>7.3</version> <version>vSAN 7.0U2</version> <version>vSAN 7.0U1</version> <version>7.2</version> <version>7.1</version> <version>7.0</version> <version>vSAN 6.7U3</version> <version>6.8.7</version> <version>vSAN 6.7U1</version> <version>VMC M5</version> <version>6.7</version> <version>6.7.0</version> <version>6.6.2</version> <version>6.6.1</version> <version>6.6</version> </priorVersions> </namespace> </namespaces>
The issue seems to be that once there is a current version that starts with a letter instead of a number the ‘WSDL method name VsanClusterGetClaimedCapacity’ call fails in the Usage Meter. If we have a look at a newer environment we can see the following:
<namespaces version="1.0"> <namespace> <name>urn:vsan</name> <version>8.0.0.4</version> <priorVersions> <version>8.0.0.3</version> <version>8.0.0.2</version> <version>8.0.0.1</version> <version>7.4</version> <version>vSAN 7.0U3</version> <version>7.3</version> <version>vSAN 7.0U2</version> <version>vSAN 7.0U1</version> <version>7.2</version> <version>7.1</version> <version>7.0</version> <version>vSAN 6.7U3</version> <version>6.8.7</version> <version>vSAN 6.7U1</version> <version>VMC M5</version> <version>6.7</version> <version>6.7.0</version> <version>6.6.2</version> <version>6.6.1</version> <version>6.6</version> </priorVersions> </namespace> </namespaces>
As you can see, this output starts with a number.
Conclusion
Unfortunately there is no resolution for this. It seems that (at the moment) Broadcom is not actively trying to fix it because it does not impact the collection process that much for the licensing report that will be billed to you.
This means we can’t do anything about it (yet) and there is no reason for concern. I hope with this blogpost you can understand the issue a bit better.
0 Comments