PowerEdge: Exploring WSMAN beyond enumeration

WSMAN is the chosen management API for Dell iDRAC, and extensive efforts are underway to make remote system management as comprehensive and as possible. After studying the WSMAN protocol for a plugin
I found it gets complex following the initial enumeration action. There is no documentation or examples on how to invoke get/put/create/delete/custom Actions with the right key properties. The primary source for this information is the DMTF's WSMAN specification and WSMAN-CIM binding specification which are painfully lengthy to follow. Again, most of the content of this article is from the DMTF specification documents. This is an attempt to make that information to digest with some examples (on Linux).

 I already posted a whitepaper on how to get started with SFCB and openwsman at https://linux.dell.com/files/whitepapers/WBEM_based_management_in_Linux.pdf. If you are new to WSMAN and SFCB, the pdf would be a better starting point than this article. As in the above whitepaper primarily deals with openwsman and SFCB CIMOM implementations in this article

 Now, given a WSMAN server, is there a way to list all the components that are manageable by wsman API? Most of the WSMAN servers talk to a CIMOM on the backend and expose the management functionalities of the CIMOMs. Meaning, the management capabilities of a WSMAN server depend on the CIM providers registered to the CIMOM on the backend. The CIMOM has an intrinsic function by the name EnumerateClassNames defined that can be called to list all the classes that are registered to CIMOM.

Since there is no one-to-one mapping for EnumerateClassNames in the WSMAN specification, this method is invoked like any other custom function in WSMAN. Note, this is implementation-specific and applies to wsmancli implementation. This could be different or updated in future releases.

CIMOM's intrinsic EnumerateClassNames function can be called as follows with wsmancli:

 

wsman invoke -a EnumerateClassNames --hostname=test_host --port=5985 --username=abc --password=password http://schemas.openwsman.org/wbem/wscim/1/instrinsic  --namespace=root/cimv2

 

 <s:Body>

    <n1:EnumerateClassNames>

      <n1:name>root/cimv2:CIM_Service</n1:name>

      <n1:name>root/cimv2:Syslog_RecordInLog</n1:name>

      <n1:name>root/cimv2:Linux_SambaValidUsersForShare</n1:name>

       <n1:name>root/cimv2:Linux_BaseBoard</n1:name>

      <n1:name>root/cimv2:Linux_SambaForceUserForShare</n1:name>

      <n1:name>root/cimv2:Linux_Processor</n1:name>

      <n1:name>root/cimv2:CIM_RecordForLog</n1:name>

      <n1:name>root/cimv2:Linux_SambaShareForService</n1:name>

      <n1:name>root/cimv2:Linux_SambaServiceConfigurationForService</n1:name>

      <n1:name>root/cimv2:Linux_SambaHostsForService</n1:name>

      <n1:name>root/cimv2:Linux_SambaForceUserForGlobal</n1:name>

      <n1:name>root/cimv2:CIM_OSProcess</n1:name>

      <n1:name>root/cimv2:CIM_RunningOS</n1:name>...................

The output looks like above, indicating that in the namespace root/cimv2, Linux_Processor is one of the classes registered. Several CIM classes are inherited when new classes register in root or cimv2, and the command lists all those class names. Generally, you can ignore all the classes with CIM_ prefix. All the classes with Linux_ prefix are the classes registered by providers installed on a Linux system.
While working with Dell's iDRAC, you are mostly interested in classes with DCIM_ prefix.

 With the class names list, use the getClass function to extract the Linux_Processor class definition as follows:

 

wsman invoke -a GetClass --hostname=test_host --port=5985 --username=abc --password=password http://schemas.openwsman.org/wbem/wscim/1/intrinsic/Linux_Processor  --namespace=root/cimv2

 The above command lists all the properties that are defined in the Linux_Processor locally. Meaning any of the properties that are inherited from other CIM_* classes are not listed with the current implementation. Class definitions reveal methods, parameters, and key properties, but the command only returns local properties, making key properties unidentifiable. Again, this is an implementation limitation in wsmancli.

While GetClass is a good start, its output does not suffice to identify key properties for invoking get or put or create or custom actions.
So, what other techniques can be used to accomplish this? This is where EPRs can help.


End-Point Reference (EPR) is a pointer to an instance with two pieces of information: the ResourceURI and a Selector Set. The ResourceURI has the class name that the instance is created from and the Selector Set lists the properties an instance can be uniquely identified with. EPRs of a particular class can be enumerated with a command similar to:

wsman enumerate -M epr  http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor -h test_host-P 5985 -u abc -p password -O out

 <?xml version="1.0" encoding="UTF-8"?>

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">

  <s:Header>

    <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>

    <wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/enumeration/PullResponse</wsa:Action>

    <wsa:RelatesTo>uuid:ca52c9e9-cd47-1d47-8003-a52924d9bed4</wsa:RelatesTo>

    <wsa:MessageID>uuid:ca622bb3-cd47-1d47-8097-a52924d9bed4</wsa:MessageID>

  </s:Header>

  <s:Body>

    <wsen:PullResponse>

      <wsen:EnumerationContext>ca4fdd21-cd47-1d47-8095-a52924d9bed4</wsen:EnumerationContext>

      <wsen:Items>

        <wsa:EndpointReference>

          <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>

          <wsa:ReferenceParameters>

            <wsman:ResourceURI>http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor</wsman:ResourceURI>

            <wsman:SelectorSet>

              <wsman:Selector Name="__cimnamespace">root/cimv2</wsman:Selector>

              <wsman:Selector Name="SystemCreationClassName">Linux_ComputerSystem</wsman:Selector>

              <wsman:Selector Name="SystemName">localhost.localdomain</wsman:Selector>

              <wsman:Selector Name="CreationClassName">Linux_Processor</wsman:Selector>

              <wsman:Selector Name="DeviceID">0</wsman:Selector>

            </wsman:SelectorSet>

          </wsa:ReferenceParameters>

        </wsa:EndpointReference>

      </wsen:Items>

    </wsen:PullResponse>

  </s:Body>

</s:Envelope>

Of all the processors in the target system the above output is of one processor.
In the output, the resourceURI is listed as https://sblim.sourceforge.net/wbem/wscim/1/cim-schema/2/Linux_Processor and the SelectorSet lists the values of __cimnamespace, SystemCreationClassName, SystemName, CreationClassName, and DeviceID. This means of all the properties in the class inherited and locally defined) these properties can be used to uniquely identify an instance.

 So, you can expect a valid response from a command like:

wsman get  http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor?SystemCreationClassName="Linux_ComputerSystem",SystemName="localhost.localdomain",CreationClassName="Linux_Processor",DeviceID="3",__cimnamespace="root/cimv2" -h test_host -P 5985 -u abc -p password -O get

 If any other properties are used in the above request, the CIMOM in the backend cannot identify an instance uniquely. To run custom methods on an instance, use the class's EPR to identify key properties for method invocation.

You can enumerate the EPRs of an association as well. Given a class name one cannot figure out if it is a standard Class name or an association class. An association instance points to two instances, so its EPR includes the EPRs of the instances or objects it refers to. The following is an example of the same:

wsman enumerate -M epr  http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_CSProcessor -h test_host -P 5985 -u abc -p password -O out

 <?xml version="1.0" encoding="UTF-8"?>

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">

  <s:Header>

    <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>

    <wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/enumeration/PullResponse</wsa:Action>

    <wsa:RelatesTo>uuid:2efbfcad-cd4b-1d4b-8003-a52924d9bed4</wsa:RelatesTo>

    <wsa:MessageID>uuid:2efc1c6f-cd4b-1d4b-80b3-a52924d9bed4</wsa:MessageID>

  </s:Header>

  <s:Body>

    <wsen:PullResponse>

      <wsen:EnumerationContext>2ef7f6f5-cd4b-1d4b-80b1-a52924d9bed4</wsen:EnumerationContext>

      <wsen:Items>

        <wsa:EndpointReference>

          <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>

          <wsa:ReferenceParameters>

            <wsman:ResourceURI>http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_CSProcessor</wsman:ResourceURI>

            <wsman:SelectorSet>

              <wsman:Selector Name="__cimnamespace">root/cimv2</wsman:Selector>

              <wsman:Selector Name="GroupComponent">

                <wsa:EndpointReference>

                  <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>

                  <wsa:ReferenceParameters>

                    <wsman:ResourceURI>http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem</wsman:ResourceURI>

                    <wsman:SelectorSet>

                      <wsman:Selector Name="CreationClassName">Linux_ComputerSystem</wsman:Selector>

                      <wsman:Selector Name="Name">localhost.localdomain</wsman:Selector>

                      <wsman:Selector Name="__cimnamespace">root/cimv2</wsman:Selector>

                    </wsman:SelectorSet>

                  </wsa:ReferenceParameters>

                </wsa:EndpointReference>

              </wsman:Selector>

              <wsman:Selector Name="PartComponent">

                <wsa:EndpointReference>

                  <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>

                  <wsa:ReferenceParameters>

                    <wsman:ResourceURI>http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Processor</wsman:ResourceURI>

                    <wsman:SelectorSet>

                      <wsman:Selector Name="SystemCreationClassName">Linux_ComputerSystem</wsman:Selector>

                      <wsman:Selector Name="SystemName">localhost.localdomain</wsman:Selector>

                      <wsman:Selector Name="CreationClassName">Linux_Processor</wsman:Selector>

                      <wsman:Selector Name="DeviceID">0</wsman:Selector>

                      <wsman:Selector Name="__cimnamespace">root/cimv2</wsman:Selector>

                    </wsman:SelectorSet>

                  </wsa:ReferenceParameters>

                </wsa:EndpointReference>

              </wsman:Selector>

            </wsman:SelectorSet>

          </wsa:ReferenceParameters>

        </wsa:EndpointReference>

      </wsen:Items>

    </wsen:PullResponse>

  </s:Body>

</s:Envelope>

Linux_CSProcessor links Linux_ComputerSystem and Linux_Processor, showing Processors are in Computer Systems, detailing GroupComponent and PartComponent sections.

I spent time understanding EPRs and their use for accessing instances, thinking it might help others. Feel free to leave me your comments or suggestions below.

Disclaimer:

Above article is for informational purposes only. The content is from my interpretation of the technologies and terminologies mentioned. This information is provided as is and may contain some typographical errors and or technical inaccuracies.