Skip to contentSkip to conversation

Adding an IPMI BMC device to KVM

DISCUSSION Corey Minyard 1 participant 1 message May 7, 2012 1 message not in the archive KVM

lore
Share & tools
lore
#1 lore raw
In reply to a message not in the archive

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 <[email protected]>
Reply-To: [email protected]
To: Anthony Liguori <[email protected]>
CC: [email protected], Avi Kivity <[email protected]>

Quoted 3 lines · Anthony Liguori

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.

Quoted 3 lines

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

Quoted 82 lines

Regards,

Anthony Liguori

Quoted 2 lines · On May 4, 2012 2:10 PM, "Corey Minyard" <[email protected]…

I've been working on adding an IPMI BMC as a virtual device under

KVM. I'm

Quoted 1 line

doing this for two primary reasons, one to have a better test

environment than

Quoted 4 lines

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

Quoted 1 line

systems with IPMI have a small microcontroller, called a BMC, that

is always on

Quoted 1 line

when the board is powered. The BMC is capable of controlling power

and reset

Quoted 1 line

on the board, and it is hooked to sensors on the board (voltage,

current,

Quoted 1 line

temperature, the presence of things like DIMMS and power supplies,

intrusion

Quoted 1 line

detection, and a host of other things). The main processor on a

system can

Quoted 1 line

communicate with the BMC over a device. Often these systems also

have a LAN

Quoted 3 lines

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

Quoted 1 line

describes the components of the system that can be replaced. It

also has data

Quoted 1 line

records that describe the sensor, so it is possible to directly

interpret the sensor

Quoted 3 lines

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

Quoted 1 line

configuration information, and you need ways to simulate the

sensors. This type

Quoted 1 line

of interface is a little sensitive, since it has direct access to

the reset and power

Quoted 3 lines

control of a system.

I was at first considering having the BMC be an external program

that KVM

Quoted 1 line

connected to over a chardev, with possibly a simulated LAN

interface. This has

Quoted 2 lines

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.

Quoted 1 line

Plus it could be used for other virtual machines. However, that

means there is

Quoted 1 line

an interface to KVM over a chardev that could do nasty things, and

even be a

Quoted 1 line

possible intrusion point. It also means there is a separate program

to maintain.

Quoted 2 lines

You could also include the BMC inside of KVM and run it as a

separate thread.

Quoted 1 line

That way there doesn't have to be an insecure interface. But the

BMC will need

Quoted 1 line

a lot of configuration data and this will add a bunch of code to KVM

that's only

Quoted 1 line

tangentially related to it. And you would still need a way to

simulate setting

Quoted 3 lines

sensors and such for testing things.

Either way, is this interesting for including into KVM? Does anyone

have any

Quoted 8 lines

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 [email protected]

<mailto:[email protected]>

Quoted 1 line

More majordomo info at http://vger.kernel.org/majordomo-info.html