(copied qemu-devel) On 05/04/2012 10:10 PM, Corey Minyard wrote: > 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?
Not kvm, but certainly it would make a good addition to qemu, which kvm then uses. > Does anyone have any > opinions on the possible ways to implement this? My preference would be the second alternative. The issue you raise is a good one. There are two ways we can approach it: - have the management system intercept IPMI requests, start up a qemu instance (if it's down), and let it handle the event. - change the whole system to keep a running qemu even when the guest is down. This is a much larger change; it involves reducing the memory footprint to almost nothing when the guest is down (deallocating memory and threads) so it doesn't impact guest density, but it allows for other minor features such as wake-on-LAN and RTC alarm wakeups. -- error compiling committee.c: too many arguments to function
