qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: kvm@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>,
	minyard@acm.org, Corey Minyard <tcminyard@gmail.com>
Subject: Re: [Qemu-devel] Adding an IPMI BMC device to KVM
Date: Mon, 07 May 2012 17:44:23 +0300	[thread overview]
Message-ID: <4FA7DFC7.4080603@redhat.com> (raw)
In-Reply-To: <4FA7DCA1.2010804@codemonkey.ws>

On 05/07/2012 05:30 PM, Anthony Liguori wrote:
> On 05/06/2012 09:39 AM, Avi Kivity wrote:
>> On 05/06/2012 05:35 PM, Anthony Liguori wrote:
>>> On 05/06/2012 08:11 AM, Avi Kivity wrote:
>>> libvirt is essentially the BMC for a virtual guest.  I would suggest
>>> looking at implementing an IPMI interface to libvirt and exposing it
>>> to the guest through a USB RNDIS device.
>>>
>>
>> That's the first option.  One unanswered question is what to do when the
>> guest is down?  Someone should listen for IPMI events, but we can't make
>> it libvirt unconditionally, since many instances of libvirt are active
>> at any one time.
>>
>> Note the IPMI external interface needs to be migrated, like any other.
>
> For all intents and purposes, the BMC/RSA is a separate physical
> machine.  

That's true for any other card on a machine.

> If you really wanted to model it, you would launch two instances of
> QEMU.  The BMC instance would have a virtual NIC and would share a USB
> bus with the slave QEMU instance (probably via USBoIP).  The USB bus
> is how the BMC exposes IPMI to the guest (via a USB rndis adapter),
> remote media, etc.  I believe some BMC's also expose IPMI over i2c but
> that's pretty low bandwidth.

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).

> 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?

> 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.

> I don't think there's a tremendous amount of value in QEMU making
> itself look like an IBM IMM or whatever HP/Dell's equivalent is.  As I
> said, these stacks are hugely complicated and there are better ways of
> doing out of band management (like talk to libvirt directly).

I have to agree here.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-05-07 14:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4FA429BA.3040006@acm.org>
2012-05-06 13:11 ` [Qemu-devel] Adding an IPMI BMC device to KVM Avi Kivity
2012-05-06 14:35   ` Anthony Liguori
2012-05-06 14:39     ` Avi Kivity
2012-05-07 14:30       ` Anthony Liguori
2012-05-07 14:44         ` Avi Kivity [this message]
2012-05-07 14:55           ` Anthony Liguori
2012-05-07 15:11             ` Avi Kivity
2012-05-07 15:21               ` Anthony Liguori
2012-05-07 18:07                 ` Corey Minyard
2012-05-07 19:45                   ` Dave Allan
2012-05-07 20:47                     ` Corey Minyard
2012-05-07 23:17                   ` Anthony Liguori
2012-05-18 13:08         ` Stefan Hajnoczi
2012-05-18 14:57           ` Corey Minyard
2012-05-18 15:01           ` Corey Minyard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FA7DFC7.4080603@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=minyard@acm.org \
    --cc=qemu-devel@nongnu.org \
    --cc=tcminyard@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).