From mboxrd@z Thu Jan 1 00:00:00 1970 From: Corey Minyard Subject: Adding an IPMI BMC device to KVM Date: Fri, 04 May 2012 14:10:50 -0500 Message-ID: <4FA429BA.3040006@acm.org> Reply-To: minyard@acm.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: kvm@vger.kernel.org Return-path: Received: from mail-gh0-f174.google.com ([209.85.160.174]:36506 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753480Ab2EDTKx (ORCPT ); Fri, 4 May 2012 15:10:53 -0400 Received: by ghrr11 with SMTP id r11so3113234ghr.19 for ; Fri, 04 May 2012 12:10:52 -0700 (PDT) Sender: kvm-owner@vger.kernel.org List-ID: I've been working on adding an IPMI BMC as a virtual device under KVM. I'm doing this for two primary reasons, one to have a better test environment than what I have now for testing IPMI issues, and second to be able to better simulate a legacy environment for customers porting legacy software. For those that don't know, IPMI is a system management interface. Generally systems with IPMI have a small microcontroller, called a BMC, that is always on when the board is powered. The BMC is capable of controlling power and reset on the board, and it is hooked to sensors on the board (voltage, current, temperature, the presence of things like DIMMS and power supplies, intrusion detection, and a host of other things). The main processor on a system can communicate with the BMC over a device. Often these systems also have a LAN interface that lets you control the system remotely even when it's off. In addition, IPMI provides access to FRU (Field Replaceable Unit) data that describes the components of the system that can be replaced. It also has data records that describe the sensor, so it is possible to directly interpret the sensor data and know what the sensor is measuring without outside data. I've been struggling a bit with how to implement this. There is a lot of configuration information, and you need ways to simulate the sensors. This type of interface is a little sensitive, since it has direct access to the reset and power control of a system. I was at first considering having the BMC be an external program that KVM connected to over a chardev, with possibly a simulated LAN interface. This has the advantage that the BMC can run even when KVM is down. It could even start up KVM for a "power up", though I'm not sure how valuable that would be. Plus it could be used for other virtual machines. However, that means there is an interface to KVM over a chardev that could do nasty things, and even be a possible intrusion point. It also means there is a separate program to maintain. You could also include the BMC inside of KVM and run it as a separate thread. That way there doesn't have to be an insecure interface. But the BMC will need a lot of configuration data and this will add a bunch of code to KVM that's only tangentially related to it. And you would still need a way to simulate setting sensors and such for testing things. Either way, is this interesting for including into KVM? Does anyone have any opinions on the possible ways to implement this? Thanks, -corey