Duplicate Processors in CPU - Servers Report

[Tim McGue]

When I run the CPU - Servers report I get reports of too many processors per physical machine. Typically it is double the number of actual processors but sometimes it is greater than that. I weed through this by counting only the ones that something in the Slot Number field (although the data in that field is often incorrect by showing 0 for all slots). Anyone else seeing this? I think the memory report has the same type of problem.

Tim

[Anthony Sawyer]

I have the same issue. I have duplicate processors and memory being reported.

One other item is that when I run a Server Inventory report, I get a number of duplicate machine listings. However, this is not visible within the System Overview or All Server Systems view.

Very annoying.

[James Kennedy_4]

I've had this happen before, some reason there is duplicate entries in the database. I've found that deleting the server object, waiting a few minutes and then recreating it, usually fixes the problem.

[David Orwig]

Is hyperthreading enabled?

[David Claypool]

Actually, these aren't actually duplicates. If a system has been both WBEM/WMI and the Insight agents (SNMP) available then data collection will be done with both.

[Rob Buxton]

David,
Is that one of the issues addressed in 4.1 as it does make reporting a bit problematic.

[Tim McGue]

David,

First, let me say publicly that your dedication to this group, knowledge on the product, and over all desire for success is very much appreciated.

Secondly, I don't like your answer. I understand your point. HP SIM has collected the same information twice. Understandable. However, when people (generally management) want reports the most basic desire is to have accurate information. To them, this is inaccurate information. This report is unusable in its current format. I can't very well tell someone to split the number in half. What if the box doesn't support WMI/WBEM? I think the reports that show duplicate information need to be corrected to show only one set of information. I'm not familiar with the HP SIM data scheme, so I don't know if this is something greater then just a report re-write.

Thanks Again,
Tim

[David Claypool]

Thanks, Tim, I'm blushing. :8)

The development team agrees that this could be improved. One of the things I'd like to compliment the group on is their dedication as well, particularly to a new product. The general payoff is the ability to act as an agent of change.

Back in February, I compiled a list of items being experienced by users as reported in the forum and met with the dev and QA teams and we went over them in detail to see if they were part of the list they were tracking to change in 4.1. The database collection was not one of them, and so we added it and a number of others to the official list. Unfortunately, the timing of the meeting in February and the scope of the work to address this was such that it did not make the 4.1 cut.

There is a possible workaround, though not the most palatable.

First, you could choose not to use WBEM at all, and that would not affect the quality or scope of data collected from ProLiants. I know that is not the best option, and would guess that WBEM is desirable to some or all because of the ability to get stuff from non-ProLiants.

That gives us option #2, which is to disable WBEM for ProLiants. There is not a straightforward way of doing this. It will have to involve mucking with the WBEM passwords.

- If you have a minority of ProLiants running Windows, it would be best to keep the WBEM login/pw in the global settings and then go to each ProLiant's System Protocol settings and say to use a custom user/pw for these systems and leave it blank thereby not using the global one. (This is not so bad as it seems. Start with a custom list of all the affected ProLiants, check the box at the top of the list to select them all, choose Options --> Protocol Settings --> Systems Protocol Settings and you can do it once for all of them)

- If you have a majority of ProLiants, keep Global settings blank and use the like procedure in the above to set the system protocol settings for all of the others.

I haven't tried this out, but I'm guessing that if you are currently using historical data collection, you may want to select single instance, do a data collection, then go and set to historical again.

The good news is that in general we try to have 2 minor releases a year (or one major and one minor). 4.0 came out in 2003, so...