From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRPB3-0002od-3i for qemu-devel@nongnu.org; Mon, 07 May 2012 10:44:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRPAu-0007pJ-37 for qemu-devel@nongnu.org; Mon, 07 May 2012 10:44:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRPAt-0007o5-Q2 for qemu-devel@nongnu.org; Mon, 07 May 2012 10:44:31 -0400 Message-ID: <4FA7DFC7.4080603@redhat.com> Date: Mon, 07 May 2012 17:44:23 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4FA429BA.3040006@acm.org> <4FA6788A.8080500@redhat.com> <4FA68C1E.3070503@codemonkey.ws> <4FA68D35.7060704@redhat.com> <4FA7DCA1.2010804@codemonkey.ws> In-Reply-To: <4FA7DCA1.2010804@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Adding an IPMI BMC device to KVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm@vger.kernel.org, qemu-devel , minyard@acm.org, Corey Minyard 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