Menu
▾
▴
#665 Support for IPMI v2.0 in ipmi plugin
Hi,
IPMI plugin is missing IPMI v 2.0 support (lanplus interface type, IPMI v2.0 RMCP+ LAN Interface). Many rack servers/chassises support now only v2.0 communication.
The ipmitool source code may shed some light on the topic: https://downloads.sourceforge.net/project/ipmitool/ipmitool/1.8.11/ipmitool-1.8.11.tar.gz?r=&ts=1322427679&use_mirror=ignum (look in src/plugins/lanplus/)
Thanks
Patches welcome :-)
Right, unfortunately I do not know IPMI spec, openhpi or ipmitool internals nor have the time to make a (probably quite substantial from what I can see in ipmitool) patch.
Do note that the OpenIPMI plugin is no longer being used, so we need to focus on the ipmidirect plugin instead. Does the ipmidirect plugin work for you?
Note that the IPMI LANplus protocol is only required for the IPMI Serial-Over-LAN console function, since according to the IPMI 2.0 spec, all IPMI 2.0 firmware implementations are required to also support the IPMI 1.5 LAN protocol. The IPMI LANplus protocol does include better security however.
Well, when looking briefly to IPMI spec & ipmitool sources it became clear to me that the v2 protocol is here mainly to support SOL and other protocols, making ipmi an encapsulation/encryption transport layer for them.
I actually tried to get openhpi working with HP ProLiant ML350 G5 with newest available ilo2 firmware 2.0.7. Both ipmi/ipmidirect plugins were of no use since they didn't manage to detect available auth methods. But neither did the ipmitool. When I switched ipmitool to lanplus it started working.
Probably the ipmi v2 is required to talk to that machine (even the ilo web gui shows "IPMI 2.0").
I also tried the ribcl plugin, but it failed on parsing some cpu information and didn't return any resource information at all.
We use openhpi 2.14.1 since we can't compile python bindings on newer versions (I submited a ticket couple of months ago for that issue)
I was also hoping to use ipmi plugin for talking to double desity blades, which are not supported either (a colleague submited that one).
Could you fill the issue ticket for ilo2_ribcl plug-in?
HP guys are much more active than IPMI guys.
As for python bindings: it is a separate software package and I am not sure how to deal with its releases. Could you provide an example/examples of how you use it?
Here is the ribcl issue: https://sourceforge.net/tracker/?group_id=71730&atid=532254
As for the python bindings, they simply fail to compile under openhpi > 2.14.1. API has changed and they need to be patched. I do not know what is the procedure on creating or fixing those bindings using swig.
This is what I did to compile them:
wget http://kojipkgs.fedoraproject.org/packages/python-openhpi/1.2/0.4.20090109svn6930.fc15/src/python-openhpi-1.2-0.4.20090109svn6930.fc15.src.rpm
rpm2cpio python-openhpi-1.2-0.4.20090109svn6930.fc15.src.rpm | cpio -idmv
tar -jxvf python-openhpi-svn6930.tar.bz2
cd python-openhpi
patch -p1 < ../python-openhpi-fumirollback.patch
patch -p1 < ../python-openhpi-totaltests.patch
python setup.py build
python setup.py install
Thanks!
For python: I mean small example of python code that uses OpenHPI python bindings.
I use it to list resources, i.e RPT, RDR data, read power status.
A method to list resources:
in connect
self._error, self._sid = saHpiSessionOpen(self._domain, None)
then
def resources_get(self, convert = True):
result = {}
nextid = SAHPI_FIRST_ENTRY
rpt = SaHpiRptEntryT()
while nextid != SAHPI_LAST_ENTRY:
self._error, nextid = saHpiRptEntryGet(self._sid, nextid, rpt)
if self._error != SA_OK:
self._error_msg = 'saHpiRptEntryGet: %s' % oh_lookup_error(self._error)
return -1
result[rpt.ResourceId] = self._rpt_convert(rpt) if convert else rpt
return result
Hope its what you were looking for. What do you need it for/?
I have completely different experimental python wrappers for OpenHPI.
Trying to make similiar interface as py-openhpi provides.
Hope there will be some progress in the python bindings topic. They seem to be left unmaintained.
As for the IPMI, are you planing on supporting v2 version in either of the plugins? If so, when can it be expected?
Thanks
Is it be painful if python interface changes?
Cannot say about IPMI 2.0.
IPMI plug-in is no longer supportrf.
IPMI Direct has no active maintainer.
Depending on the changes probably. But not really, provided that the general idea of interaction / data flow & types remain the same or very similar.
If I'm not mistaken current version of python interface was compiled using swig, which is mapping 1:1 to the c api. I don't actually think that methods should change, you could rename them to follow python markup / coding style but not necesairly.
I'd suggest a more pythonic approach wherever possible. Currently there are too much c/c++ leftovers in the exported symbols in the python module (over 1600 total, some include c data sizes for structs). Listing methods could be improved, to provide pagination or filtering interface as arguments to the method. Last but not least, stability would be an issue.
Just my 2c.
Could you try experimental python base library from there:
https://sourceforge.net/projects/openhpi/files/openhpi-development/snapshots/
openhpi_baselibs-3.1.0-20111223.tar.gz
Thanks for the christmas special! I had a look and the code seems to be solid. I've just made rpms of OpenHPI 3.0.0 for el5 and if it works with our hardware I will test the python extension.
What versions are the baselibs compatibile with?
What did you use to generate the Gen.py files ?
Thanks
Looking forward for your results.
Meanwhile I tried Java baselib on Android tablet.
http://www.youtube.com/watch?v=l60ozwVrVbk
It shall be compatible with OpenHPI >= 2.12.
We didn't break anything since that time (I hope!).
I wrote several python scripts to parse SaHpi.h and generate the code for different languages.
The scripts were rather ugly but they worked. :)
Old bindings were not compatibile with > 2.14.1 because of some code changes.
As for the testing itself, I was not able to get OpenHPI 3.0.0 working on our setup. Submitted a bug #3472381. When its fixed I will be able to test new language bindings.
This python baselib implements OpenHPI RPC protocol and does not use any libraries from OpenHPI at all. So only protocol changes may break it.
You could try it with working old OpenHPI if you had one before 3.0.0.
Right. I will look into that by the end of the week. I will be able to test this provided that the ammount of changes is not substantial. I will report back once I have the time.
Finally found the time to port the old openhpi code to new openhpi_baselib. Feedback
1. All strings are null padded to the maximum possible length: Example:
'IdString': 'Planar temperature sensor\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
I saw there is a parameter holding string length for each one. Consider using it to remove additional characters or trimm using for ex. c = c[:c.index('\00')]
This should be fixed ASAP.
2. In the old bindings the returned value for most methods was returned using a reference in the function call. The function actually returned error code, not the value itself directly. I initially thought it may be useful to leave the additional parameter so one can submit an empty object to the method. But then also the return value must be changed to the old method spec so there is no confusion. This would make transitioning from old bindings seamless and the switch to wether return the object by reference or by the 'return' statement can be decided on presence of this extra method argument.
3. Remove HpiCore.py: HpiCore.dump() call (when importing). Library should not output anything to stdout/stderr
4. Use absolute imports within openhpi_baselib
5. Change default for: OPENHPICLIENT_CONF to: "/etc/openhpi/openhpiclient.conf" in HpiCore::loadConf()
6. Since the methods and constants names are preserved, they should all be present (imported) in the module's '__init__' file for backwards compatibility.
7. In the old bindings I had to call: saHpiSessionOpen(domain_id, None) whilst now saHpiSessionOpen(domain_id) is enugh. saHpiSessionOpen should be changed for compatibility.
8. HpiUtil: follow sahpi_enum_utils.c method naming, example: fromSaErrorT as oh_lookup_error
Thats all for now. I will test it further when I have the time.
Thanks for test! Looking forward for your comments.
Overall comment 1:
100% compatibility with py-openhpi wasn't one of the targets.
I am trying to provide similar approach for several different language mapping.
And it is py-openhpi development but different project (not even announced in openhpi web site and mailing list).
Overall comment 2:
It is not py-openhpi project development but different project (not even well announced in openhpi web site and mailing list).
1:
All strings are null padded to the maximum possible length.
If you are about Data field in SaHpiTextBufferT then it is the way the data structure is.
HPI Spec defines it as:
==========================
typedef struct {
SaHpiTextTypeT DataType;
SaHpiLanguageT Language;
SaHpiUint8T DataLength;
SaHpiUint8T Data[255];
} SaHpiTextBufferT;
==========================
I introduced fromSaHpiTextBufferT and toSaHpiTextBufferT functions for converting between SaHpiTextBufferT and string.
2:
I found it confusing. For example in py-openhpi hpievents.py:
========================
error, sid = saHpiSessionOpen(SAHPI_UNSPECIFIED_DOMAIN_ID, None)
and
error = saHpiDomainInfoGet(sid, dinfo)
and
error, qstatus = saHpiEventGet(sid, Timeout, event, rdr, res)
========================
See different way of handling output parameters. I think it makes sense to use
uniform approach.
Arguments of tuple return are:
o) There is no need for empty object check inside baselib.
o) Use code is simpler. No need to define output arguments in user data.
What say?
3:
Yes, there will be no dump in final version.
4:
I am thinking about using relative imports.
http://www.python.org/dev/peps/pep-0328/#rationale-for-relative-imports
5:
That would work for unix-based OSes only.
And for installation with default prefix.
May be it makes sense to remove the file support at all?
6:
OK.
7:
Well, this is not a spec definition but OpenHPI utility library interface.
And I inmplemented only part of it: converting between HPI data type and string.
What about continuing the discussion in openhpi-devel mailing list?
It is definitely not IPMI-2.0 related. :)
Closing it now.
May be IPMI-2.0 will be implemented some day in the future.
As for python interface: I suggest to move discussion in python-specific tickets or in mailinf list.