From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Michal Privoznik <mprivozn@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
ldoktor@redhat.com, libvir-list@redhat.com,
qemu-devel@nongnu.org, mreitz@redhat.com, pbonzini@redhat.com,
pkrempa@redhat.com
Subject: Re: [Qemu-devel] [libvirt] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
Date: Tue, 12 Jun 2018 13:50:33 +0100 [thread overview]
Message-ID: <20180612125033.GF24690@redhat.com> (raw)
In-Reply-To: <20180612144205.2169e7a2@redhat.com>
On Tue, Jun 12, 2018 at 02:42:05PM +0200, Igor Mammedov wrote:
> 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.
NB, libvirt only ever uses --daemonize when probing capabilities, never
when launching QEMU for a real VM. In the latter case, we now use FD
passing, so libvirt opens the UNIX domain socket listener, and passes
this into QEMU. So libvirt knows it can connect to the listener
immediately and will only ever get a failure if QEMU has exited.
We can't use FD passing for the capabilities probing because of the
chicken & egg problem - we need to probe capabilities to find out
if FD passing it available or not. Fortunately with capabilities
probing, we don't care about using --preconfig, as were not running
a real VM
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 :|
next prev parent reply other threads:[~2018-06-12 12:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 14:00 [Qemu-devel] [PATCH v3 0/2] fix -nodefaults and -daemonize regressions caused by --preconfig introduction Igor Mammedov
2018-06-05 14:00 ` [Qemu-devel] [PATCH v3 1/2] cli: Don't run early event loop if no --preconfig was specified Igor Mammedov
2018-06-05 18:12 ` Eduardo Habkost
2018-06-06 7:22 ` Igor Mammedov
2018-06-11 17:34 ` Eduardo Habkost
2018-06-05 14:00 ` [Qemu-devel] [PATCH v3 2/2] vl: fix use of --daemonize with --preconfig Igor Mammedov
2018-06-05 15:13 ` Eric Blake
2018-06-05 15:28 ` [Qemu-devel] [PATCH v4 " Igor Mammedov
2018-06-05 18:30 ` [Qemu-devel] [PATCH v3 " Eduardo Habkost
2018-06-06 8:34 ` Igor Mammedov
2018-06-06 8:37 ` [Qemu-devel] [PATCH v5 " Igor Mammedov
2018-06-06 13:50 ` Eduardo Habkost
2018-06-07 12:00 ` [Qemu-devel] [PATCH v6 " Igor Mammedov
2018-06-08 13:21 ` Eduardo Habkost
2018-06-11 13:16 ` Igor Mammedov
2018-06-11 19:06 ` Eduardo Habkost
2018-06-11 21:29 ` Igor Mammedov
2018-06-11 22:36 ` Eduardo Habkost
2018-06-12 9:17 ` [Qemu-devel] [libvirt] " Michal Privoznik
2018-06-12 12:42 ` Igor Mammedov
2018-06-12 12:50 ` Daniel P. Berrangé [this message]
2018-06-13 14:17 ` Eduardo Habkost
2018-06-13 14:23 ` Daniel P. Berrangé
2018-06-13 17:09 ` Eduardo Habkost
2018-06-14 12:32 ` Igor Mammedov
2018-06-12 13:04 ` Michal Privoznik
2018-06-12 13:10 ` Peter Krempa
2018-06-12 13:17 ` Daniel P. Berrangé
2018-06-06 8:55 ` [Qemu-devel] [PATCH v3 0/2] fix -nodefaults and -daemonize regressions caused by --preconfig introduction no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180612125033.GF24690@redhat.com \
--to=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=ldoktor@redhat.com \
--cc=libvir-list@redhat.com \
--cc=mprivozn@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pkrempa@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.