On 07/10/2012 04:17 AM, Daniel P. Berrange wrote:
On Mon, Jul 09, 2012 at 02:17:04PM -0500, miny...@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
