In Search of CPUs and Cores

Who among you has ever looked at the CPU information that the Altiris hardware inventory gathers and said "That's not what I need. I need to know how many physical CPUs are there, or how many cores there are, or whether this is a hyper threading CPU, etc."

Why is this important? Well, my primary interest is licensing of software, in particular server software for this information. Let's look at some examples of a real server.

First: What does the Altiris hardware inventory shows about the server:

This shows a CPU count of 8 CPUs. Now let's say we were installing MS SQL Server on that box, licensing it on a per-processor basis. That would mean that we would need to purchase 8 CPU licenses for the server in order to operate it in this mode, right? Well, actually wrong...

Click to view.

The problem comes in that Microsoft defines a processor as a physical chip, not a core. I prefer to think of it as "per-socket" rather than "per-processor" licensing. So with the 8 CPUs here, is it 8 single-core CPUs, 4 Dual Core, or 2 Quad Core CPUs? This distinction changes, by a factor of 4, the amount you need to spend on SQL Server licenses, from around $12,000 down to $3,000, and that's just for one server.

Now, you're left with a few choices as an Asset Manager:

• Assume there are 8 single core CPUs, and pay the $12,000 for SQL Server, just to make sure you're not under licensed
• Assume you have 2 quad core CPUs and pay the $3,000 to keep your costs as low as possible, and risk being non-compliant in the event of an audit
• Ask the server administrator, and have him respond with "Don't YOU do inventory?"
• Dig through your financial records to see what was purchased

None of these options is particularly appealing (I personally hate the third one the most!)

I tend to operate on two guiding principles:

1. I can never have too much information
2. I don't trust other people to tell me things that systems can gather

So, I went in search of a way to gather CPU and Core information in some way.

First stop: WMI. You've all heard it, WMI has everything, and from any kind of examination, it seems to be incredibly comprehensive. In fact, a search of Microsoft's website will show that there is a NumberOfCores property...until you dig deeper and find it's a new attribute in Vista (potentially a hotfix to add it to XP/2003...Server 2000, you're outta luck!) Doh!

Next stop: Google...I was absolutely certain that someone, anyone, had to have solved this problem. So off I went into the wide world of the Internet to find a kindred spirit who had already solved my problem.

After several hours of reading message boards with many, many people saying "Yeah, if you find out how to do that, let me know too!", I finally stumbled onto something pretty cool...a paper from an organization who ought to know how to do this: Intel...Detecting Multi-Core Processor Topology in an IA-32 Platform. Not only that, but they have a utility that kicks out the relevant information and runs nicely from a command-line...it gets better and better. Finally, not only do they have the utility, but they've also released the source code for the utility!!! OK, so my C++ skills are a bit weak, and I decided to go another direction for this, but for those of you so inclined, you can make the Intel utility skip a ton of my steps!

Now to make this play nice with Altiris. Running the utility, I found four lines in the output to be of interest (from the server above):

 
 Hyper-Threading Technology: Not capable 
 Multi-core: Yes 
 Multi-processor: Yes
AND
System wide availability: 2 physical processors, 8 cores,8 logical processors

Getting the server to spit out the information is one thing, I want to be able to report on the information! So, how do we get this data from this format into something that uploads into the Altiris database. I selected a 2 step approach: Perl and Custom Inventory.

First, manipulating and extracting information from verbose text is what Perl was made for. So, I build a short Perl script that converts from the wordy output of the Intel utility to an INI file. Then I use a custom inventory to take that INI and upload it into the Altiris database, where I can report on it at my leisure.

First the Perl:

#! perl
/* ParseCPU.pl compiled with the Perl Development Kit from ActiveState (http://www.activestate.com) into parseCPU.exe
*/
@Input = `echo a | cpucount.exe`;

$ht = $Input[17];
$mc = $Input[18];
$mp = $Input[19];

if ($ht =~ /: (.*)\n/)
{
 $ht=$1;
}
if ($mc =~ /: (.*)\n/)
{
 $mc=$1;
}
if ($mp =~ /: (.*)\n/)
{
 $mp=$1;
}

if ($Input[24] =~ /: (.*) physical processors, (.*) cores,(.*) logical processors/)
{
 $phy = $1;
 $core=$2;
 $log = $3;
}
else
{
 print "Parse Error\n";
}

print "[Capabilities]\n";
print "Hyperthreading=$ht\nMultiCore=$mc\nMultiProcessor=$mp\n\n";
print "[ProcessorCounts]\n";
print "Physical=$phy\nCores=$core\nLogical=$log\n";

Put simply, this script executes the utility, then extracts 6 things from the output, and outputs those items into an INI file:

[Capabilities]
Hyperthreading=not capable 
MultiCore=Yes 
MultiProcessor=yes

[ProcessorCounts]
Physical=2
Cores=8
Logical=8

Many of you may have experience using Custom Inventory to read data from an INI file, and it's pretty simple to do. First you build a Custom Inventory script in XML:

<InventoryClasses>
 <InventoryClass name='CPUCount' manufacturer='Altiris' description='' version='1.0' platform='Win32' mifClass=Altiris|CPUCount|1.0'>
  <xml xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14"  xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema">
   <s:Schema id="RowsetSchema">
    <s:ElementType name="row" content="eltOnly" rs:updatable="true">
     <s:AttributeType name="c0" rs:name="HyperThreadCapable" rs:number="1" rs:nullable="true" mifAttrId="1">
      <s:datatype dt:type="string" dt:maxlength="50"/>
     </s:AttributeType>
     <s:AttributeType name="c1" rs:name="MultiCoreCapable" rs:number="2" rs:nullable="true" mifAttrId="2">
      <s:datatype dt:type="string" dt:maxlength="50"/>
     </s:AttributeType>
     <s:AttributeType name="c2" rs:name="MultiProcessorCapable" rs:number="3" rs:nullable="true" mifAttrId="3">
      <s:datatype dt:type="string" dt:maxlength="50"/>
     </s:AttributeType>
     <s:AttributeType name="c3" rs:name="PhysicalProcessors" rs:number="4" rs:nullable="true" mifAttrId="4">
      <s:datatype dt:type="int" dt:maxlength="4"/>
     </s:AttributeType>
     <s:AttributeType name="c4" rs:name="Cores" rs:number="5" rs:nullable="true" mifAttrId="5">
      <s:datatype dt:type="int" dt:maxlength="4"/>
     </s:AttributeType>
     <s:AttributeType name="c5" rs:name="LogicalProcessors" rs:number="6" rs:nullable="true" mifAttrId="6">
      <s:datatype dt:type="int" dt:maxlength="4"/>
     </s:AttributeType>
    </s:ElementType>
   </s:Schema>
   <rs:data>
    <%set filepath = ".\parsecpu.ini" %>
    <z:row 
     c0 = "<%writexml "ini:%filepath%\[Capabilities]\Hyperthreading"%>"
     c1 = "<%writexml "ini:%filepath%\[Capabilities]\MultiCore"%>"
     c2 = "<%writexml "ini:%filepath%\[Capabilities]\MultiProcessor"%>"
     c3 = "<%writexml "ini:%filepath%\[ProcessorCounts]\Physical"%>"
     c4 = "<%writexml "ini:%filepath%\[ProcessorCounts]\Cores"%>"
     c5 = "<%writexml "ini:%filepath%\[ProcessorCounts]\Logical"%>"
    />
   </rs:data>
  </xml>
 </InventoryClass>
</InventoryClasses>

This custom inventory will specifically read the INI file created by the Perl script and render it as an NSI file:

<InventoryClasses> 
<InventoryClass name='CPUCount' manufacturer='Altiris' description='' version='1.0' platform='Win32' mifClass='Altiris|CPUCount|1.0'> 
<xml xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14"  xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema"> 
<s:Schema id="RowsetSchema"> 
<s:ElementType name="row" content="eltOnly" rs:updatable="true"> 
<s:AttributeType name="c0" rs:name="HyperThreadCapable" rs:number="1" rs:nullable="true" mifAttrId="1"> 
<s:datatype dt:type="string" dt:maxlength="50"/> 
</s:AttributeType> 
<s:AttributeType name="c1" rs:name="MultiCoreCapable" rs:number="2" rs:nullable="true" mifAttrId="2"> 
<s:datatype dt:type="string" dt:maxlength="50"/> 
</s:AttributeType> 
<s:AttributeType name="c2" rs:name="MultiProcessorCapable" rs:number="3" rs:nullable="true" mifAttrId="3"> 
<s:datatype dt:type="string" dt:maxlength="50"/> 
</s:AttributeType> 
<s:AttributeType name="c3" rs:name="PhysicalProcessors" rs:number="4" rs:nullable="true" mifAttrId="4"> 
<s:datatype dt:type="int" dt:maxlength="4"/> 
</s:AttributeType> 
<s:AttributeType name="c4" rs:name="Cores" rs:number="5" rs:nullable="true" mifAttrId="5"> 
<s:datatype dt:type="int" dt:maxlength="4"/> 
</s:AttributeType> 
<s:AttributeType name="c5" rs:name="LogicalProcessors" rs:number="6" rs:nullable="true" mifAttrId="6"> 
<s:datatype dt:type="int" dt:maxlength="4"/> 
</s:AttributeType> 
</s:ElementType> 
</s:Schema> 
<rs:data> 
<z:row 
c0 = "not capable" 
c1 = "Yes" 
c2 = "yes" 
c3 = "2" 
c4 = "8" 
c5 = "8" 
/> 
</rs:data> 
</xml> 
</InventoryClass> 
</InventoryClasses>

The NSI can then be picked up and submitted to the NS in the same way as any other Inventory process. To summarize, 4 things happen to get this inventory:

1. The Perl script is executed
2. The Perl script executes the Intel utility, and transforms its output into an INI file
3. The AexCustInv.exe reads the INI (with the help of the XML script) and generates an NSI file
4. AeXNSInvCollector.exe takes the NSI and posts it to the server's notification server

I chose to deploy this Custom script with a dedicated package. This package consists of the following five files:

• ParseCPU.EXE (I use the Perl Developer Kit from ActiveState to create an EXE from my Perl, so I don't need to deploy the Perl interpreter)
• CPUCOUNT.EXE (from Intel)
• AexCustInv.exe
• AeXNSInvCollector.exe
• parsecpu.xml (the Custom Inventory Script)

I execute these steps with a single batch file:

parsecpu.exe > parsecpu.ini
aexcustinv.exe /in .\parsecpu.xml /out .\parsecpu.nsi
AeXNSInvCollector /s . /useguid /nsctransport /hidden

Once that step is done, simply create a task to execute the batch files on you "All 32-bit Windows Servers" collection (sorry, the paper was limited to IA-32, so 64 bit is still unsolved).

The data initially comes in under the Default Folder under the Inventory tab in Resource Manager:

Click to view.

Now, you have data in the database that you can utilize. The final step is to convert data into information, and that's a reporting function. In the above example, with MS SQL Server, I can now go into the server and see that even though it reports 8 CPUs, I only need to pay for 2 of them for Microsoft (we'll leave what I would have to pay for Oracle or others to another rant!) More importantly, if we do move to an application with a different metric (or even have multiple on the same box with SQL Server and Tivoli Storage Manager for example), I have the information at my fingertips to give good advice to server administrators as to what they need to purchase, I have good information to give to auditors/vendors to tell them to leave me alone, and more importantly, I don't look stupid asking server admins for information that I really should have had in the first place.