On 24/11/2017 18:07, Michal Privoznik wrote: > On 11/24/2017 04:42 PM, Paolo Bonzini wrote: >> One daemon per QEMU is nicer IMO because it lets us do MCS. Of course >> one daemon per QEMU can only apply to system libvirtd; session must use >> one daemon per host. > > Agreed. One daemon per QEMU it is then. Just to make sure whether I> understand correctly - libvirtd would start it *before* exec()-ing qemu > (so that qemu can connect) and kill it after qemu dies. But what should > happen if the helper dies while qemu is running? Should qemu pause > itself, fire up an event on the monitor so that libvirtd can spawn the > helper again? QEMU currently tries to reconnect five times every second, and then fails the I/O command. This seemed okay to me because PRs are generally used in a HA environment where the failure will be broadcast and another node will pick up the work. > 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? > Also, I don't really expect anything special when it comes to migration, > just want to make sure I'm not mislead. No, everything is fine for migration. >> One daemon per host is easy, because it's just a couple new command-line >> options as far as libvirtd is concerned, but we need to check that it >> works well with MCS. > > It's very likely that it wouldn't. Users can chose arbitrary DAC/SELinux > labels for their qemus. In general we will not find any intersection > that the helper socket can have. I know some of those words. :) Can you explain to an SELinux layman? > Yup. In case of a unprivileged libvirtd there'll be a system-wide helper > daemon that: > a) will not be managed by libvirtd > b) has wide permissions so that any user can connect to it > > This basically follows what we have for vhostuser. Except that vhostuser > is not an implementation detail of qemu :-) Okay, thanks. Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
