Then should we also emulate one AMM virtual device? one fsp virtual device? one IVE virtual device?
On Sat, May 5, 2012 at 3:10 AM, Corey Minyard <tcminy...@gmail.com> 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? Does anyone have > any > opinions on the possible ways to implement this? > > Thanks, > > -corey > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Zhi Yong Wu -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
