From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVOcR-00087b-8p for qemu-devel@nongnu.org; Fri, 18 May 2012 10:57:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SVOcK-0007Eb-Bh for qemu-devel@nongnu.org; Fri, 18 May 2012 10:57:26 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:38514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVOcK-0007E6-3h for qemu-devel@nongnu.org; Fri, 18 May 2012 10:57:20 -0400 Received: by yhoo21 with SMTP id o21so3789945yho.4 for ; Fri, 18 May 2012 07:57:17 -0700 (PDT) Message-ID: <4FB66349.1060405@acm.org> Date: Fri, 18 May 2012 09:57:13 -0500 From: Corey Minyard 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: Content-Type: multipart/alternative; boundary="------------090702090802080103080905" Subject: Re: [Qemu-devel] Adding an IPMI BMC device to KVM Reply-To: minyard@acm.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Anthony Liguori , Avi Kivity , kvm@vger.kernel.org, qemu-devel This is a multi-part message in MIME format. --------------090702090802080103080905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/18/2012 08:08 AM, Stefan Hajnoczi wrote: > On Mon, May 7, 2012 at 3: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: >> So what's really the use case here? Would an IPMI -> libvirt bridge get you >> what you need? I really think that's the best path forward. > I'm still curious about this and didn't see it answered in the thread. > You mentioned "watchdog timer, sensors and power control" but what > exactly should they expose? Many of our customer use the standard watchdog timer and power controls on IPMI. Basically, the watchdog timer needs to be able to power off, power cycle, reset, and send an NMI. The IPMI watchdog can be configured to do all those things. (The NMI is for a "pretimeout" that generally triggers a panic.) Power control is no big surprise. It's true that you have ACPI to do this, but that's not terribly useful on non-x86 (and non ia64, I suppose) systems. > > Do you want to expose host sensors - the challenge is that they don't > reflect the hardware that the virtual machine sees? Or do you want to > have synthetic sensors - which virtual sensors are useful to have? A few sensors, notably the watchdog timer sensor, are not synthetic. The others generally are. Sensors cover things beyond just power and temperature. Important other ones in IPMI deal with the presence of FRUs in the system, BIOS/OS state, and intrusion detection. Two main reasons for synthesized sensors exist. One, in a legacy situation, is to "fool" the management system into thinking everything is ok, since it is expecting to see these sensors with specific values. You could even possibly reflect the state of real sensors, mapping them somehow, if you wanted. The other reason is for testing. It's pretty hard to induce some of these sensors to go out of range in a real system. So without simulation, you need a hack-ed up management controller in a real system to truly test your software. > > Is the IPMI watchdog useful, QEMU already supports the i6300esb PCI > watchdog (see qemu -watchdog option documentation)? That's only useful if you can simulate an i6300esb. Probably not possible on non-x86. Plus legacy systems may be expecting the capabilities of the IPMI watchdog. > > Some use cases that illustrate how the guest is going to use IPMI > would be interesting and could help guide the discussion. You are probably right. I've mentioned a couple above. One other possible one, that someone else mentioned, is the ability to control a VM using standard tools like ipmitool or OpenIPMI over network interfaces. People may already have management systems that are designed around IPMI, and it would make a move to virtual machines easier. This was the request mentioned that was in the Redhat database. Such a capability would require re-thinking things a bit. You have two basic options that I see. Either have the "management controller" run outside qemu and define a simple interface to it, or modify qemu to be able to run the management controller internally. My preference in to run it outside qemu, for the following reasons: * It decouples things that are IPMI internals from having to go through getting into qemu repositories. * The management controller then becomes useful for a number of other purposes. I already have one mostly done that I use for testing. It could be used by other VMs. * A full management controller is a fairly big piece of software, especially if you include the network access. It probably doesn't belong in qemu. * No offense, I don't want to muck around inside qemu to accomplish this :). There are, of course, disadvantages. Some I can think of: * There can be confusion about which versions of two things work together. * Overall, it is more complex to get working. * There are possible security implications. So I guess those are points we can talk about... -corey --------------090702090802080103080905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/18/2012 08:08 AM, Stefan Hajnoczi wrote: 
On Mon, May 7, 2012 at 3:30 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:

On 05/06/2012 09:39 AM, Avi Kivity wrote:

On 05/06/2012 05:35 PM, Anthony Liguori wrote:

So what's really the use case here?  Would an IPMI -> libvirt bridge get you
what you need?  I really think that's the best path forward.

I'm still curious about this and didn't see it answered in the thread.
 You mentioned "watchdog timer, sensors and power control" but what
exactly should they expose?

Many of our customer use the standard watchdog timer and power controls on IPMI.  Basically, the watchdog timer needs to be able to power off, power cycle, reset, and send an NMI.  The IPMI watchdog can be configured to do all those things.  (The NMI is for a "pretimeout" that generally triggers a panic.)

Power control is no big surprise.  It's true that you have ACPI to do this, but that's not terribly useful on non-x86 (and non ia64, I suppose) systems.


Do you want to expose host sensors - the challenge is that they don't
reflect the hardware that the virtual machine sees?  Or do you want to
have synthetic sensors - which virtual sensors are useful to have?

A few sensors, notably the watchdog timer sensor, are not synthetic.  The others generally are.  Sensors cover things beyond just power and temperature.  Important other ones in IPMI deal with the presence of FRUs in the system, BIOS/OS state, and intrusion detection.

Two main reasons for synthesized sensors exist.  One, in a legacy situation, is to "fool" the management system into thinking everything is ok, since it is expecting to see these sensors with specific values.  You could even possibly reflect the state of real sensors, mapping them somehow, if you wanted.

The other reason is for testing.  It's pretty hard to induce some of these sensors to go out of range in a real system.  So without simulation, you need a hack-ed up management controller in a real system to truly test your software.


Is the IPMI watchdog useful, QEMU already supports the i6300esb PCI
watchdog (see qemu -watchdog option documentation)?

That's only useful if you can simulate an i6300esb.  Probably not possible on non-x86.  Plus legacy systems may be expecting the capabilities of the IPMI watchdog.


Some use cases that illustrate how the guest is going to use IPMI
would be interesting and could help guide the discussion.

You are probably right.  I've mentioned a couple above.

One other possible one, that someone else mentioned, is the ability to control a VM using standard tools like ipmitool or OpenIPMI over network interfaces.  People may already have management systems that are designed around IPMI, and it would make a move to virtual machines easier.  This was the request mentioned that was in the Redhat database.

Such a capability would require re-thinking things a bit.  You have two basic options that I see.  Either have the "management controller" run outside qemu and define a simple interface to it, or modify qemu to be able to run the management controller internally.

My preference in to run it outside qemu, for the following reasons:
  • It decouples things that are IPMI internals from having to go through getting into qemu repositories.
  • The management controller then becomes useful for a number of other purposes.  I already have one mostly done that I use for testing.  It could be used by other VMs.
  • A full management controller is a fairly big piece of software, especially if you include the network access.  It probably doesn't belong in qemu.
  • No offense, I don't want to muck around inside qemu to accomplish this :).

There are, of course, disadvantages.  Some I can think of:

  • There can be confusion about which versions of two things work together.
  • Overall, it is more complex to get working.
  • There are possible security implications.

So I guess those are points we can talk about...

-corey

--------------090702090802080103080905--