Resending to the list, plan text only. Sorry about that...
-------- Original Message --------
Subject: Re: Adding an IPMI BMC device to KVM
Date: Mon, 07 May 2012 16:57:06 -0500
From: Corey Minyard <tcminyard@xxxxxxxxx>
Reply-To: minyard@xxxxxxx
To: Anthony Liguori <anthony@xxxxxxxxxxxxx>
CC: kvm@xxxxxxxxxxxxxxx, Avi Kivity <avi@xxxxxxxxxx>
On 05/05/2012 09:29 AM, Anthony Liguori wrote:
You could just use a USB rndis device and then run an IPMI server on
the host. That is probably the simpliest way to test.
I'm trying to figure out how RNDIS would be helpful here. You can't
have the guest talk USB for this, it's going to talk the standard
interfaces.
However, I am loathe to create my own protocol for talking between the
BMC and QEMU. Perhaps RNDIS could be useful, but it's massive
overkill. It also doesn't provide any security. If there were client
and server libraries that would run over a socket, that would be tempting.
I'm wondering if security is that big a deal, though. If you use a
chardev, and you have QEMU make a connection to the BMC, maybe that
would be ok.
BMCs typically run a full OS like Linux making emulation as a device
in QEMU prohibitively hard.
BMCs are generally very simple 8-bit microcontrollers, unless they are
something like an ATCA shelf manager. Emulation is pretty easy. Well,
emulation of an ATCA shelf manager wouldn't be easy, but that's
hopefully not required in the near future.
-corey
Regards,
Anthony Liguori
On May 4, 2012 2:10 PM, "Corey Minyard" <tcminyard@xxxxxxxxx
<mailto: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
<mailto:majordomo@xxxxxxxxxxxxxxx>
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
