From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57535) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUDTO-0004W5-WC for qemu-devel@nongnu.org; Tue, 15 May 2012 04:51:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUDTI-0005YJ-KB for qemu-devel@nongnu.org; Tue, 15 May 2012 04:51:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUDTI-0005Y3-Bu for qemu-devel@nongnu.org; Tue, 15 May 2012 04:51:08 -0400 Message-ID: <4FB218F4.6030605@redhat.com> Date: Tue, 15 May 2012 10:51:00 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <87vcjz0wal.fsf@elfo.elfo> <4FB127CE.1050706@codemonkey.ws> In-Reply-To: <4FB127CE.1050706@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call agenda for June, Tuesday 15th List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: KVM devel mailing list , quintela@redhat.com, corey Bryant , qemu-devel@nongnu.org, Eric Blake Am 14.05.2012 17:42, schrieb Anthony Liguori: > On 05/14/2012 07:41 AM, Juan Quintela wrote: >> >> Hi >> >> Please send in any agenda items you are interested in covering. > > -open-fd-hook proposal > > The discussion seems to have tapered out without a consensus. I asked for really good reasons to justify it, and the only response you gave was along the lines of "because it's easy to implement". Actually, I think it's not very easy at all when you start considering cases like libvirt crashing (or restarting during an upgrade, as Daniel mentioned). Currently we have a very simple unidirectional structure: qemu is a standalone program that keeps running on its own. libvirt is the user of qemu. Often enough it's already hard to get things working correctly in error cases with this simple structure - do you really want to have qemu depend on an RPC to libvirt? You're right that the proper fix would be in the kernel, but in qemu a much better solution that RPCs to libvirt is allowing all QMP commands that open new files to pass a block device description that can contain a fd. This would much better than first getting an open command via QMP and then using an RPC to ask back what we're really meant to open. To the full extent we're going to get this with blockdev-add (which is what we should really start working on now rather than on hacks like -open-fd-hook), but if you like hacks, much (if not all) of it is already possible today with the 'existing' mode of live snapshots. So if you want -open-fd-hook, please give us use cases that can't be solved by passing the file descriptor directly in the QMP command (or on the command line). I believe you might find some obscure ones that don't work today, but I don't really expect that it enables anything that -blockdev wouldn't enable. Kevin