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, ...). On the other hand, since it would be libvirt creating the socket what would happen on libvirtd restart? > Can we do this way on libvirt side when --preconfig is in use > (it might even be fine for normal flow without -preconfig)? I think passing pre-opened socket and --preconfig are orthogonal. What if somebody wants to use --preconfig does not pass any FD? Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
