On 11/27/2017 12:09 PM, Paolo Bonzini wrote: > On 24/11/2017 19:13, Michal Privoznik wrote: >> On 11/24/2017 06:18 PM, Paolo Bonzini wrote: >>> On 24/11/2017 18:07, Michal Privoznik wrote: >>>> The helper is going to be daemonized (for the same reason >>>> that qemu process is) => there's no SIGCHLD for libvirtd to receive. >>> >>> Couldn't (or shouldn't!) libvirt register itself as a subreaper instead? >> >> Whether libvirt can't have a >> separate thread where nothing waitpid() would run? That could hardly >> work - not only would libvirt need to spawn separate thread for every >> helper, it would not work across restarts of libvirtd. We would have no >> guarantee that PID we recorded is still the same process as it was when >> we were dying. > > Oh, you're right. :( Even if libvirtd were a subreaper (see prctl(2) > manpage), the daemonized qemu-pr-helper would be reparented to init when > libvirtd restarts. > > libvirtd could test whether the helper is alive by connecting to its > socket. If that's not enough, I'll add an event. Well, connecting and staying connected? Otherwise mere connect followed by immediate disconnect would work only when libvirtd is starting up and reconnecting to already running domains. Not if the helper dies some time after libvirt started the domain and the helper. [1] > > Another thing: we have > > <reservations enable='yes'/> > > which represents "one daemon per QEMU" in privileged libvirtd and > "well-known socket path" in session libvirtd. What would the > live-domain XML look like? Maybe: > > <!-- one daemon per QEMU, privileged libvirtd --> > <reservations enable='yes' managed='yes'/> > <source type='unix' path='/var/lib/libvirtd/...' > mode='server'/> > </reservations> > > <!-- one daemon per host, session libvirtd --> > <reservations enable='yes' managed='no'/> > <source type='unix' path='/var/run/qemu-pr-helper.sock' > mode='server'/> > </reservations> This is a good idea. We can explicitly state if the helper is supposed to be managed by libvirtd or not. However, I'd prefer not exposing path in case managed='yes' because it's something that libvirt should manage. We don't expose monitor path either, for instance. With managed='yes' libvirt would: a) spawn daemon on per domain basis b) generate unique path for each helper it spawns c) label the socket (so that qemu can access it) d) put the path onto qemu's cmd line However, with managed='no' libvirt would: a) require path to be provided in the XML b) merely just put the path onto qemu's cmd line > > And then, would it be an error to specify the "wrong" managed setting in > the domain-creation XML? For now yes. For now specifying both path and managed='yes' would be considered an error. It gives us enough room to allow that in the future should anybody need it. > Or would it be possible to use a managed='no' > helper in privileged libvirtd? I take it as a "no" given your remark below. You're right. This is going to be forbidden too. Again, we can allow this if somebody needs it. 1: Also, it's worth nothing that libvirtd would restart the helper iff managed='yes'. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
