Hi On Tue, Feb 25, 2020 at 12:49 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > On Tue, Feb 25, 2020 at 10:55:10AM +0100, marcandre.lureau@xxxxxxxxxx wrote: > > From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > > > > Signed-off-by: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > > --- > > 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.
