On 24/11/2017 15:52, Daniel P. Berrange wrote:
So what has been suggested so far is:
<disk type='block' device='disk'> <source dev='/dev/sda'> <target dev='sda' bus='scsi'/> <reservations enable='yes'/> </disk>
<reservations> without an inner <source> element leaves libvirtd with the choice of a daemon per QEMU, or a daemon per host in a well-known location. Unprivileged libvirtd would always use the latter; for privileged libvirtd it is implementation-defined. I like it. <reservations> with an inner <source> always gives a daemon per host in a custom location. It can be used by either unprivileged or privileged libvirtd.
Now, my question is, in the first case - how should libvirt chose the path? Should it be different for each disk/domain? How is the daemon started in the first place - should libvirt start it? And when should libvirt kill it?
The core question is one daemon per QEMU, or one daemon per host. I'd be more inclined to have one daemon per QEMU so we always have isolation and thus do't have to worry about a shared daemon being a potential attack point between distinct QEMU's.
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. 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.
If one daemon per host, then for privileged libvirtd, we should make sure the daemon ships with a systemd unit file + socket activation file, then we have a well-known cross-distro standardized socket path.
Ok, then I will send a patch for upstream QEMU that adds the Fedora systemd unit files to contrib/. They are useful anyway. Thanks, Paolo
If one daemon per QEMU, then we should just put the socket in the VM's private dir under /var/run/libvirt/qemu/$GUEST/