[libvirt PATCH v2 6/9] qemu: prepare and stop the dbus daemon

[Marc-André Lureau]

Hi

On Tue, Feb 25, 2020 at 12:49 PM Daniel P. Berrangé <berrange at redhat.com> wrote:
>
> On Tue, Feb 25, 2020 at 10:55:10AM +0100, marcandre.lureau at redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau at redhat.com>
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau at redhat.com>
> > ---
> >  src/qemu/qemu_process.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> > index 8c1ed76677..3a6cb4b2b0 100644
> > --- a/src/qemu/qemu_process.c
> > +++ b/src/qemu/qemu_process.c
> > @@ -58,6 +58,7 @@
> >  #include "qemu_extdevice.h"
> >  #include "qemu_firmware.h"
> >  #include "qemu_backup.h"
> > +#include "qemu_dbus.h"
> >
> >  #include "cpu/cpu.h"
> >  #include "cpu/cpu_x86.h"
> > @@ -6480,6 +6481,9 @@ qemuProcessPrepareHost(virQEMUDriverPtr driver,
> >      qemuDomainObjPrivatePtr priv = vm->privateData;
> >      g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(driver);
> >
> > +    if (qemuDBusPrepareHost(driver) < 0)
> > +        return -1;
>
> This launches dbus unconditionally for every VM regardless of whether
> its actually going to be used.

No, it is qemuDBusStart()

>
> There is certainly a nice conceptual simplicity in doing this, but
> I'm pretty concerned that there are going to be mgmt apps which
> do not like this extra overhead being added for every VM. I'm
> thinking KubeVirt and Kata containers in particular. This is also
> relevant for the libvirt embedded driver which is trying to eliminate
> all libvirt added overhead on managing QEMU, so that our fastest
> QEMU startup time can match that achieved by running QEMU directly.
> Unconditionally starting dbus will make that much more challenging.
>
> This is a long winded way of saying I think we need to do this
> only when it is actually required. This will certainly add complexity
> as we'll need to cope with dynamically launching DBus when we hotplug
> certain types of device which require it. I think we can ignore the
> hot-unplug case at least, as once you've taken the overhead for DBus
> for the VM, I don't think there's much to complain about, even if the
> device using it is unplugged.

It is done on-demand, by qemuSlirpStart() at the moment, and actually
only when the backend has dbus support.