Am I the only one being bothered by this?

Hi all,

last year I posted a thread about a problem in the VI client (and/or the VC server):

Resource pool showing negative memory usage[/url]

To say it short: If you create a Resource pool and look at its summary-tab the Memory Usage[/b] displayed there will turn negative[/b] once it raises over 2 GB. There is obviously a variable overflow somewhere in the VC code.

Regarding this issue I filed a support request with VMware in December 2006. Their first answer was: "This is perfectly normal". I've already seen this answer one or more times in the forums here, but nobody could really explain WHY this should be "normal". When I asked back VMware support about how to interpret the negative values, they finally admitted that it is a bug that needs to be worked on.

Half a year later this SR is still open, and the bug is unfixed. I was assured by a VMware engineer that this is only a display issue, and that it does not affect the correct functionality of the Resource pool.

If this is true why does it take so long to fix it? The VI SDK Perl toolkit returns the same negative number that is displayed by the VI client..., so this is not a VI client issue, but it is somewhere in the server code!

Am I the only one being bothered by this? Are there only very few people actually using this Resource pool thing, and has none of them ever looked at the memory usage display?

Comments please!


\- Andreas

Twitter: @VFrontDe, @ESXiPatches | |
0 Kudos
1 Reply

I hear you.

I've submitted some issues in the feature request forum and I don't feel it's beeing looked at. One item has been an problem I have complained about since the VirtualCenter 1.x days. I've submitted the feature request twice, with no response on either request.

I've now gotten some feedback from a VMware employee that my issues are being investigated and I should see some traction one way or another.

I think you just need to be persistent in order to grab some attention. Escalate through your local Sales and SE people.

VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+