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

[Corey Minyard <tcminyard@gmail.com>]

On 07/10/2012 04:17 AM, Daniel P. Berrange wrote:
> On Mon, Jul 09, 2012 at 02:17:04PM -0500, minyard@acm.org 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
>> +@item -ipmi [bt|kcs,]@var{dev}|local|none
>> +@findex -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:
>> +@table @code
>> +@item -ipmi bt,tcp:localhost:9002
>> +@end 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