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

["Daniel P. Berrange" <berrange@redhat.com>]

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.

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.


BTW, the syntax you show here is the legacy approach where both front
and backend device config is mixed.  Does you patch work with the
modern QEMU syntax which is something like

  -chardev name=impi0,tcp:localhost:9002 -device bt,chardev=ipmi0

if it doesn't work, then you'll need to update your patches to support
this approach.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|