On Wed, Jun 13, 2018 at 03:23:09PM +0100, Daniel P. Berrangé wrote:
On Wed, Jun 13, 2018 at 11:17:30AM -0300, Eduardo Habkost wrote:
On Tue, Jun 12, 2018 at 01:50:33PM +0100, Daniel P. Berrangé wrote:
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.
So, what I'm really missing here is: do we have a good reason to support --daemonize + --preconfig today?
On the libvirt zero, I don't see a compelling need for it.
Good. :)
The options I see are: 1) complete daemonization before preconfig main loop [...] 4) Not supporting -preconfig + -daemonize [...] I believe the only reasonable options are (1) and (4).
Agreed.
If it was up to me, I would just go with (4) because it's simpler. But if somebody wants to implement (1), the caveats should be clearly documented. I would prefer to simply document "--daemonize --preconfig" as experimental, with something like: "Note: usage of --daemonize with the --preconfig option is experimental, because it can prevent QEMU from reporting machine initialization errors and prevent some features from working after QEMU is daemonized." -- Eduardo