Partager via

Physical Computer System View Profile

  • Article

Out-of-band management is a critical tool within a datacenter (also useful to small/medium businesses).  Essentially, it enables one to remotely manage a computer system independent of the operating system: system is powered off, operating system is not functioning, or operating system is not installed yet.  For Servers, there are really two standards adopted (some newer systems support both): IPMI and SMASH.  In my view, I can summarize these two as:

  1. IPMI
    1. de facto standard – widely available
    2. simpler for an OEM to implement – limited capabilities, but more consistent across OEMs
    3. fast binary protocol
  2. SMASH
    1. de jure standard – broad adoption
    2. rich capabilities – harder to implement and use, optional Profiles means less predictable capabilities across OEMs
    3. easy for OEM to extend – based on CIM model
    4. supports WS-Man protocol (although not mandatory) – manageable using generic CIM cmdlets

DASH is the equivalent of SMASH for desktops, although WS-Man is mandatory for DASH.  As you can see, each have some pros and some cons.  In an effort to bridge the gap between these two and provide a solution with some of the pros from both sides, the Physical Computer System View Profile (henceforth referred to as PCSV) was created and standardized within the DMTF.

I worked with representation from HP, Intel, Broadcom, and AMI to create a new management Profile that complements SMASH by providing more simplicity and predictability while still enabling richness and extensibility.  We focused our efforts on the top scenarios that customers cared about and created a view class that reused existing CIM schema from existing management Profiles: Computer System, Power Utilization Management, Sensors, Record Log, Boot Control, Software Inventory, System Memory, Physical Asset, OS Status, CPU, and Software Update.  Although many of the features of PCSV are optional, we made basic capabilities such as identity and setting the device state as mandatory.

image

This UML diagram taken from the PCSV Profile spec shows that the CIM_PhysicalComputerSystemView class is really a composition of properties and methods from existing CIM schema.  This means that OEMs that already implement these Profiles already have the data needed to populate the view class making it easier to implement.  For OEMs writing new implementations, they can decide whether they want the richness of implementing the full Profiles or only implement the PCSV Profile for targeted use cases.

As part of the Datacenter Abstraction Layer (DAL) initiative, one of the new cmdlets we introduced in Windows 8.1 and Windows Server 2012 R2 is the PCSVDevice cmdlets.  These cmdlets use PCSV as an abstraction to provide a single view whether you are targeting a device that implements IPMI, SMASH, or just PCSV. 

image

Here you can see that I used the same cmdlet against a Dell server using IPMI as well as Compaq desktop using WS-Man.  Although I’m only showing a subset of the information you can retrieve, the Get-PcsvDevice cmdlet is able to return all the same information as modeled in CIM_PhysicalComputerSystemView including asset information, firmware information, boot configuration, sensors, etc…

The Set-PcsvDeviceBootConfiguration cmdlet allows you to set a device’s one-time boot source.  For example, you would use this to do a PXE (Network) boot to install an OS image.  The Start/Restart/Stop-PCSVDevice cmdlets allow you to power-on, power-reset, and power-off the device.  More details about the PcsvDevice cmdlet is available in this PowerShell blog post.

In preparation for new PCSV enabled devices, I’ve also updated my HardwareManagement PowerShell module to use PCSV if implemented. 

image

In this example, I have a prototype implementation of PCSV (running on a PC).  This quick demo shows the benefit of using the view class where it is a single request/response operation to retrieve 36 sensors while using the full Sensors Profile implementation incurs a request/response for each batch of sensors which takes almost 3.5 times as long.

For completeness of supporting DASH, I also added network discovery capabilities by supporting RMCP Ping (also supported by IPMI devices):

image

The updated module is available at the same TechNet location.

Happy Holidays!

Steve Lee
Principal Test Manager
Windows Server Standards Based Management