Re: [libvirt] Can jobs suck like qemu-pr-helper does be transfered to libvirtd?
On Mon, Mar 18, 2019 at 11:24:03 +0000, Zhangbo (Oscar) wrote:
Hi all:
qemu-pr-helper exits to help qemu do the high-privileged scsi related jobs. LIBVIRTD is
responsible to launch qemu-pr-helper and qemu, and set selinux/DAC labels for them and
their socket.
#
#
#
#
# ___________
# ___________|libvirtd |__________
# | |___________| |
# | | |
# | | |
# _________|________ _____|______ ___|____
# | qemu-pr-helper |__| vm1.sock |_____| qemu1 |
# |__________________| |____________| |________|
There may be other jobs quite like qemu-pr-helper, shall we make them as
"complex" as the qemu-pr-helper scheme?
Will it be OK to just let qemu send an EVENT to libvirtd, and let libvirtd do the
SCSI/other jobs? Will it be OK if we remove qemu-pr-helper and similar processes?
What's the disadvantage if we let libvirtd do there high privileged jobs instead
qemu-pr-helper-like processes?
No what you describe is not desired. Any process which is vital for the
runtime of the VM needs to stay as simple and minimal as possible and
separate from libvirtd.
Libvirtd is a complex big application dealing with multiple things at
once and also the architecture allows for libvirtd to be stopped and
upgraded.
This does not play well with the fact that processes as the PR helper
are always required.
Merging them into libvirtd would make the VM stop until libvirtd is
running again. Additionally if any of the operations require persistent
kernel state as e.g. file descriptors, this would be impossible as
stopping libvirtd process would close the FDs which may be then
impossible to reopen properly e.g. due to state.
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)