Re: [Qemu-devel] Adding an IPMI BMC device to KVM

[Dave Allan <dallan@redhat.com>]

FWIW, the idea of an IPMI interface to VMs was proposed for libvirt
not too long ago.  See:

https://bugzilla.redhat.com/show_bug.cgi?id=815136

Dave

On Mon, May 07, 2012 at 01:07:45PM -0500, Corey Minyard wrote:
> I think we are getting a little out of hand here, and we are mixing
> up concepts :).
> 
> There are lots of things IPMI *can* do (including serial access, VGA
> snooping, LAN access, etc.) but I don't see any value it that.  The
> main thing here is to emulate the interface to the guest.  OOB
> management is really more appropriately handled with libvirt.  How
> the BMC integrates into the hardware varies a *lot* between systems,
> but it's really kind of irrelevant.  (Well, almost irrelevant, BMCs
> can provide a direct I2C messaging capability, and that may matter.)
> 
> A guest can have one (or more) of a number of interfaces (that are
> all fairly bad, unfortunately).  The standard ones are called "KCS",
> "BT" and "SMIC" and they generally are directly on the ISA bus, but
> are in memory on non-x86 boxes (and on some x86 boxes) and sometimes
> on the PCI bus.  Some systems also have interfaces over I2C, but
> that hasn't really caught on.  Others have interfaces over serial
> ports, and that unfortunately has caught on in the ATCA world.  And
> there are at least 3 different basic types of serial port interfaces
> with sub-variants :(.  I'm not sure what the USB rndis device is,
> but I'll look at it.  But there is no IPMI over USB.
> 
> The big things a guest can do are sensor management, watchdog timer,
> reset, and power control.  In complicated IPMI-based systems like
> ATCA, a guest may want to send messages through its local IPMI
> controller to other guest's IPMI controllers or to a central BMC
> that runs an entire chassis of systems.  So that may need to be
> supported, depending on what people want to do and how hard they
> want to work on it.
> 
> My proposal is to start small, with just a local interface, watchdog
> timer, sensors and power control.  But have an architecture that
> would allow external LAN access, tying BMCs in different qemu
> instances together, perhaps serial over IPMI, and other things of
> that nature.
> 
> -corey
> 
> 
> On 05/07/2012 10:21 AM, Anthony Liguori wrote:
> >On 05/07/2012 10:11 AM, Avi Kivity wrote:
> >>On 05/07/2012 05:55 PM, Anthony Liguori wrote:
> >>>>>For all intents and purposes, the BMC/RSA is a separate physical
> >>>>>machine.
> >>>>
> >>>>That's true for any other card on a machine.
> >>>
> >>>
> >>>It has a separate power source for all intents and purposes.  If you
> >>>think of it in QOM terms, what connects the nodes together ultimately
> >>>is the "Vcc" pin that travels across all devices.  The RTC is a little
> >>>special because it has a battery backed CMOS/clock but it's also
> >>>handled specially.
> >>
> >>And we fail to emulate it correctly as well, wrt. alarms.
> >>
> >>>
> >>>The BMC does not share Vcc.  It's no different than a separate
> >>>physical box.  It just shares a couple buses.
> >>
> >>It controls the main power place, reset line, can read VGA and emulate
> >>keyboard, seems pretty well integrated.
> >
> >Emulating the keyboard is done through USB.  How the VGA thing
> >works is very vendor dependent.  The VGA snooping can happen as
> >part of the display path (essentially connected via a VGA cable)
> >or it can be a side-band using a special graphics adapter.  I
> >think QEMU VNC emulation is a pretty good analogy actually.
> >
> >>
> >>>>That is one way to do it.  Figure out the interactions between two
> >>>>different parts in a machine, define an interface for them to
> >>>>communicate, and split them into two processes.  We don't usually do
> >>>>that; I believe your motivation is that the two have different power
> >>>>domains (but then so do NICs with wake-on-LAN support).
> >>>
> >>>The power still comes from the PCI bus.
> >>
> >>Maybe.  But it's on when the rest of the machine is off.  So Vcc is not
> >>shared.
> >
> >That's all plumbed through the PCI bus FWIW.
> >
> >>
> >>>
> >>>Think of something like a blade center.  Each individual blade does
> >>>not have it's own BMC.  There's a single common BMC that provides an
> >>>IPMI interface for all blades.  Yet each blade still sees an IPMI
> >>>interface via a USB rndis device.
> >>>
> >>>You can rip out the memory, PCI devices, etc. from a box while the
> >>>Power is in and the BMC will be unaffected.
> >>>
> >>>>
> >>>>>At any rate, you would have some sort of virtual hardware device that
> >>>>>essentially spoke QMP to the slave instance.  You could just do
> >>>>>virtio-serial and call it a day actually.
> >>>>
> >>>>Sorry I lost you.  Which is the master and which is the slave?
> >>>
> >>>The BMC is the master, system being controlled is the slave.
> >>
> >>Ah okay.  It also has to read the VGA output (say via vnc) and supply
> >>keyboard input (via sendkey).
> >
> >Right, QMP + VNC is a pretty accurate analogy.
> >
> >>>>>It really boils down to what you are trying to do.  If you want to
> >>>>>just get some piece of software working that expects to do IPMI, the
> >>>>>easiest thing to do is run IPMI in the host and use a USB rndis
> >>>>>interface to interact with it.
> >>>>
> >>>>That would be most strange.  A remote client connecting to the IPMI
> >>>>interface would control the power level of the host, not the guest.
> >>>
> >>>IPMI with a custom backend is what I mean.  That's what I mean by an
> >>>IPMI ->  libvirt bridge.  You could build a libvirt client that exposes
> >>>an IPMI interface and when you issue IPMI commands, it translate it to
> >>>libvirt operations.
> >>>
> >>>This can run as a normal process on the host and then network it to
> >>>the guest via an emulated USB rndis device.  Existing software on the
> >>>guest shouldn't be able to tell the difference as long as it doesn't
> >>>try to use I2C to talk to the BMC.
> >>
> >>I still like the single process solution, it is more in line with the
> >>rest of qemu and handles live migration better.
> >
> >Two QEMU processes could be migrated in unison if you really
> >wanted to support that...
> >
> >With qemu-system-mips/sh4 you could probably even run the real BMC
> >software stack if you were so inclined :-)
> >
> >>But even better would
> >>be not to do this at all, and satisfy the remote management requirements
> >>using the existing tools.
> >
> >Right.
> >
> >Regards,
> >
> >Anthony Liguori
> 
>