Re: Adding an IPMI BMC device to KVM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <tcminyard@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux