From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:46737)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1SR2YQ-0008KJ-8Z
	for qemu-devel@nongnu.org; Sun, 06 May 2012 10:35:19 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1SR2YO-0002gX-A3
	for qemu-devel@nongnu.org; Sun, 06 May 2012 10:35:17 -0400
Received: from mail-ob0-f173.google.com ([209.85.214.173]:58957)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1SR2YO-0002ft-5D
	for qemu-devel@nongnu.org; Sun, 06 May 2012 10:35:16 -0400
Received: by obbwd20 with SMTP id wd20so8322059obb.4
	for <qemu-devel@nongnu.org>; Sun, 06 May 2012 07:35:14 -0700 (PDT)
Message-ID: <4FA68C1E.3070503@codemonkey.ws>
Date: Sun, 06 May 2012 09:35:10 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <4FA429BA.3040006@acm.org> <4FA6788A.8080500@redhat.com>
In-Reply-To: <4FA6788A.8080500@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Adding an IPMI BMC device to KVM
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Corey Minyard <tcminyard@gmail.com>, minyard@acm.org, kvm@vger.kernel.org

On 05/06/2012 08:11 AM, Avi Kivity wrote:
> (copied qemu-devel)
>
> On 05/04/2012 10:10 PM, Corey Minyard wrote:
>>
>> Either way, is this interesting for including into KVM?
>
> Not kvm, but certainly it would make a good addition to qemu, which kvm
> then uses.
>
>> Does anyone have any
>> opinions on the possible ways to implement this?
>
> My preference would be the second alternative.  The issue you raise is a
> good one.  There are two ways we can approach it:
>
> - have the management system intercept IPMI requests, start up a qemu
> instance (if it's down), and let it handle the event.
> - change the whole system to keep a running qemu even when the guest is
> down.  This is a much larger change; it involves reducing the memory
> footprint to almost nothing when the guest is down (deallocating memory
> and threads) so it doesn't impact guest density, but it allows for other
> minor features such as wake-on-LAN and RTC alarm wakeups.

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.

Regards,

Anthony Liguori

>