From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel <qemu-devel@nongnu.org>,
Corey Minyard <tcminyard@gmail.com>,
minyard@acm.org, kvm@vger.kernel.org
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
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2012-05-07 14:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 19:10 Adding an IPMI BMC device to KVM Corey Minyard
2012-05-06 13:11 ` Avi Kivity
2012-05-06 13:11 ` [Qemu-devel] " Avi Kivity
2012-05-06 14:35 ` Anthony Liguori
2012-05-06 14:35 ` [Qemu-devel] " Anthony Liguori
2012-05-06 14:39 ` Avi Kivity
2012-05-06 14:39 ` Avi Kivity
2012-05-07 14:30 ` Anthony Liguori
2012-05-07 14:30 ` Anthony Liguori
2012-05-07 14:44 ` Avi Kivity [this message]
2012-05-07 14:44 ` Avi Kivity
2012-05-07 14:55 ` Anthony Liguori
2012-05-07 14:55 ` Anthony Liguori
2012-05-07 15:11 ` Avi Kivity
2012-05-07 15:11 ` Avi Kivity
2012-05-07 15:21 ` Anthony Liguori
2012-05-07 15:21 ` Anthony Liguori
2012-05-07 18:07 ` Corey Minyard
2012-05-07 18:07 ` Corey Minyard
2012-05-07 19:45 ` Dave Allan
2012-05-07 19:45 ` Dave Allan
2012-05-07 20:47 ` Corey Minyard
2012-05-07 20:47 ` Corey Minyard
2012-05-07 23:17 ` Anthony Liguori
2012-05-07 23:17 ` Anthony Liguori
2012-05-18 13:08 ` Stefan Hajnoczi
2012-05-18 13:08 ` Stefan Hajnoczi
2012-05-18 14:57 ` Corey Minyard
2012-05-18 14:57 ` [Qemu-devel] " Corey Minyard
2012-05-18 15:01 ` Corey Minyard
2012-05-18 15:01 ` Corey Minyard
2012-05-07 15:17 ` Zhi Yong Wu
2012-05-07 18:53 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.