From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sod9z-0004md-SC for qemu-devel@nongnu.org; Tue, 10 Jul 2012 12:19:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sod9t-0004go-Ak for qemu-devel@nongnu.org; Tue, 10 Jul 2012 12:19:35 -0400 Received: from mail-qc0-f173.google.com ([209.85.216.173]:34996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sod9s-0004gW-V8 for qemu-devel@nongnu.org; Tue, 10 Jul 2012 12:19:29 -0400 Received: by qcab12 with SMTP id b12so166131qca.4 for ; Tue, 10 Jul 2012 09:19:27 -0700 (PDT) Message-ID: <4FFC5606.6080207@acm.org> Date: Tue, 10 Jul 2012 11:19:18 -0500 From: Corey Minyard MIME-Version: 1.0 References: <1341861429-6297-1-git-send-email-minyard@acm.org> <1341861429-6297-5-git-send-email-minyard@acm.org> <20120710091709.GC23460@redhat.com> In-Reply-To: <20120710091709.GC23460@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/9] Add a base IPMI interface Reply-To: minyard@acm.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Corey Minyard , qemu-devel@nongnu.org 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