Re: [libvirt] New QEMU daemon for persistent reservations

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.