From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxkA2-0004lB-A0 for qemu-devel@nongnu.org; Wed, 05 Nov 2008 10:19:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxkA1-0004kX-Jm for qemu-devel@nongnu.org; Wed, 05 Nov 2008 10:19:09 -0500 Received: from [199.232.76.173] (port=57095 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxkA1-0004kO-7e for qemu-devel@nongnu.org; Wed, 05 Nov 2008 10:19:09 -0500 Received: from ey-out-1920.google.com ([74.125.78.148]:43116) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KxkA0-0001kb-R3 for qemu-devel@nongnu.org; Wed, 05 Nov 2008 10:19:09 -0500 Received: by ey-out-1920.google.com with SMTP id 4so20392eyk.4 for ; Wed, 05 Nov 2008 07:19:06 -0800 (PST) Message-ID: <4911B966.6070000@codemonkey.ws> Date: Wed, 05 Nov 2008 09:19:02 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Live migration - exec: support to be reintroduced? References: <49113157.3090101@codemonkey.ws> <20081105100546.GA25523@redhat.com> <491199A2.1040207@redhat.com> <4911AA29.1090101@codemonkey.ws> <20081105143731.GM25523@redhat.com> In-Reply-To: <20081105143731.GM25523@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org Daniel P. Berrange wrote: > It is useful from a security point of view - it means QEMU doesn't > need to be given permissions to create files, merely append to an > opened file handle. > > On a related note, Avi pointed out to me that SCM_RIGHTS fd passing > would be important for NIC hotplug to allow parity with -net arg > on the command line. If the QEMU process is running unprivileged, > it will not have rights to create TAP devices & giving it a setuid() > network script is not desirable. The management app invoking QEMU > could open the TAP device, and do any setup before passing the FD > to the NIC hotplug command in the monitor. > Yup. If libvirt has a use case for it, then I'm more than happy to review patches. I'm always looking for an excuse to use SCM_RIGHTS :-) I think the monitor interface could use improvement. I think it would look better as: (qemu) receivefd /path/to/unix/socket /* waits until it receives an fd on /path/to/unix/socket */ fd=10 (qemu) closefd 10 Then all of the existing uses of fd= can be preserved. I like the idea of using a temporary socket because you don't have to rely on the monitor being on a unix socket. This will be especially useful when we can support tunneling the monitor through VNC. Regards, Anthony Liguori > Daniel >