From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSjAk-0006w2-9I for qemu-devel@nongnu.org; Tue, 12 Jun 2018 09:17:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fSjAg-0006Gw-T2 for qemu-devel@nongnu.org; Tue, 12 Jun 2018 09:17:18 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:46942 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fSjAg-0006G0-NG for qemu-devel@nongnu.org; Tue, 12 Jun 2018 09:17:14 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4A620401EF2F for ; Tue, 12 Jun 2018 13:17:14 +0000 (UTC) Date: Tue, 12 Jun 2018 14:17:08 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Message-ID: <20180612131708.GG24690@redhat.com> Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20180606135051.GR7451@localhost.localdomain> <1528372809-175770-1-git-send-email-imammedo@redhat.com> <20180608132105.GA24764@localhost.localdomain> <20180611151625.4b2420b8@redhat.com> <20180611190607.GU7451@localhost.localdomain> <20180611232924.6e04b6f8@igors-macbook-pro.local> <20180611223633.GG7451@localhost.localdomain> <5cef972d-250b-5464-7482-90fa24d36c80@redhat.com> <20180612144205.2169e7a2@redhat.com> <1282921e-0d38-7bd2-de8b-64d327dd2549@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1282921e-0d38-7bd2-de8b-64d327dd2549@redhat.com> Subject: Re: [Qemu-devel] [libvirt] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michal Privoznik Cc: Igor Mammedov , Eduardo Habkost , ldoktor@redhat.com, libvir-list@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, pbonzini@redhat.com, pkrempa@redhat.com On Tue, Jun 12, 2018 at 03:04:42PM +0200, Michal Privoznik wrote: > On 06/12/2018 02:42 PM, Igor Mammedov wrote: > > >>> > >>> Do we really need to make -daemonize and -preconfig work > >>> together? libvirt uses -daemonize only for its initial > >>> capability probing, which shouldn't require -preconfig at all. > >>> > >>> Even on that case, I wonder why libvirt doesn't simply create a > >>> server socket and waits for QEMU to connect instead of using > >>> -daemonize as a sync point. > >>> > >> > >> because libvirt views qemu as well behaved daemon. Should anything go > >> wrong libvirt reads qemu's stderr and reports error to upper layers. > > We can keep daemonizing flow in QEMU as it's now. > > But Eduardo's idea about libvirt created socked + letting QEMU connect to it > > has a merit. It should fix current deadlock issue with as monitor > > won't be depending on lead exit event. > > Not sure about the benefits. Currently, libvirt spawns qemu, waits for > monitor to show up (currently, the timeout dynamic depending on some > black magic involving guest RAM size) and if it does not show up in time > it kills qemu. The same algorithm must be kept in place even for case > when libvirt would pass pre-opened socket to qemu in case qemu deadlocks > before being able to communicate over qmp. The only advantage I see is > libvirt would not need to label the socket (set uid:gid, selinux, ...). As mentioned in my other reply, we already do FD passing, and that code has intentionally got rid of the timeout, because timeouts cause false failures to launch QEMU. This is a particular problem when using many disks that are encrypted, since LUKS encryption has a minimum 1 second delay on opening each disk, so with many disks we're at risk of hitting the timeout even when QEMU is still starting normally. I don't see a reason to special case startup with timeouts to deal with hangs, while ignoring the possibility of hangs after initial startup. > On the other hand, since it would be libvirt creating the socket what > would happen on libvirtd restart? We're creating a *listener* socket, not a client connection, so on restart we simply connect again as normal. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|