Re: [libvirt] New QEMU daemon for persistent reservations
On 11/24/2017 04:42 PM, Paolo Bonzini wrote:
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.
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? The helper is going to be daemonized (for the same reason
that qemu process is) => there's no SIGCHLD for libvirtd to receive.
Also, I don't really expect anything special when it comes to migration,
just want to make sure I'm not mislead.
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.
> 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.
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 :-)
Michal