Re: [Qemu-devel] [PATCH 4/9] Add a base IPMI interface

[Corey Minyard]

On 07/10/2012 04:17 AM, Daniel P. Berrange wrote:
> On Mon, Jul 09, 2012 at 02:17:04PM -0500, address@hidden wrote:
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 125a4da..823f6bc 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -2204,6 +2204,41 @@ Three button serial mouse. Configure the guest to use 
> > Microsoft protocol.
> >   @end table
> >   ETEXI
> >   
> > +DEF("ipmi", HAS_ARG, QEMU_OPTION_ipmi, \
> > +    "-ipmi [kcs|bt,]dev|local|none  IPMI interface to the dev, or internal 
> > BMC\n",
> > +    QEMU_ARCH_ALL)
> > +STEXI
> > address@hidden -ipmi [bt|kcs,address@hidden|local|none
> > address@hidden -ipmi
> > +Set up an IPMI interface.  The physical interface may either be
> > +KCS or BT, the default is KCS.  Two options are available for
> > +simulation of the IPMI BMC.  If @code{local} is specified, then a
> > +minimal internal BMC is used.  This BMC is basically useful as a
> > +watchdog timer and for fooling a system into thinking IPMI is there.
> > +
> > +If @var{dev} is specified (see the serial section above for details on
> > +what can be specified for @var{dev}) then a connection to an external IPMI
> > +simulator is made.  This interface has the ability to do power control
> > +and reset, so it can do the normal IPMI types of things required.
> >
> > +The OpenIPMI project's lanserv simulator is capable of providing
> > +this interface.  It is also capable of an IPMI LAN interface, and
> > +you can do power control (the lanserv simulator is capable of starting
> > +a VM, too) and reset of a virtual machine over a standard remote LAN
> > +interface.  For details on this, see OpenIPMI.
> > +
> > +The remote connection to a LAN interface will reconnect if disconnected,
> > +so if a remote BMC fails and restarts, it will still be usable.
> > +
> > +For instance, to connect to an external interface on the local machine
> > +port 9002 with a BT physical interface, do the following:
> > address@hidden @code
> > address@hidden -ipmi bt,tcp:localhost:9002
> > address@hidden table
> > +
> > +Use @code{-ipmi none} to disable IPMI.
> > +ETEXI
> I tend to question the wisdom of exposing a remote accessible TCP socket
> with no encryption or authentication, which can be used to shutdown/reset
> QEMU instances, and who knows what other functions in the future.

Actually, by default it's the other way around.  You create a server 
that takes a connection, and you connect from QEMU to the server. Still 
not perfect security, of course.

> While it might be claimed that one would only enable this if QEMU were
> on a "trusted" management LAN, IMHO, current network threats/attacks
> mean there is really no such thing as a trusted LAN anymore. So I can't
> see this being practical to actually use in a production deployment.

I would recommend not putting this on a LAN at all.  Just use localhost 
and use a root-only socket number.  That way, only root can run the 
server, and there's no external network access.

We debated this a bit over on the kvm list and there was no clear 
answer.  If you want a fully extensible IPMI management controller, I 
don't see putting that into QEMU.  It's big, the configuration is 
complicated, and it's limiting.  It seems more appropriate to me to make 
that external.  I could look at using ssl, but the key management will 
become a pain.

And you do have the "internal" version of a management controller. It 
doesn't do much, but if you need a secure one and you don't need a 
capable one, it would do fine.

-corey