On 04/05/2018 07:06 PM, Laine Stump wrote: > On 03/28/2018 11:18 AM, Daniel P. Berrangé wrote: >> When we split up the daemons, libvirtd will need to forward different >> sets of APIs to different daemons. This means libvirtd is going to need >> to have multiple virConnectPtr instances open. > > Have you done any thinking about what will need to be added to the > network driver API (or how)? I'd like to be involved with that. > > One part that troubles me is that there will no longer be a parent-child > relationship between the process keeping track of network allocations > and the qemu process - currently if a qemu process dies, libvirtd knows > about it and can recover the resources that had been allocated, There's no parent-child relationship between qemu and libvirt nowadays. I mean, qemu is daemonized and the only way libvirt notices dead qemu is via EOF on monitor socket. > but with > the network driver in a separate process, qemu could die and > libvirtd-qemu might not be around to notify libvirtd-network (or > whatever we end up calling the processes). I don't think this is any different to current situation. If qemu dies and libvirtd is not around no resources are freed. They are freed once libvirtd is started again. In the new paradigm this would be done once libvirtd-qemu starts up in which case it would notify libvirtd-network to free up resources. One problem though, if no libvirtd-* daemon is running and qemu dies and then only libvirtd-qemu is started it'll try to notify libvirtd-network (which is still not running) which will fail so that even if libvirtd-network is started later it will not free resources. But this is more generic problem and not specific just to libvirt-qemu and libvirtd-network. The solution I see consists of a queue of messages to be delivered to the other daemons. So whenever libvirtd-qemu wants to notify network that domain died, the message will go to a queue so it doesn't get lost. And then once libvirt-network is started all messages from the queue will be sent. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
