Re: [RFC] dbus-vmstate: Connect to the dbus only during the migration phase

[priyankar jain]

On 20/11/20 12:17 am, Daniel P. Berrangé wrote:
> On Thu, Nov 19, 2020 at 06:28:55PM +0000, Priyankar Jain wrote:
> > Today, dbus-vmstate maintains a constant connection to the dbus. This is
> > problematic for a number of reasons:
> > 1. If dbus-vmstate is attached during power-on, then the device holds
> >     the unused connection for a long period of time until migration
> >     is triggered, thus unnecessarily occupying dbus.
> > 2. Similarly, if the dbus is restarted in the time period between VM
> >     power-on (dbus-vmstate initialisation) and migration, then the
> >     migration will fail. The only way to recover would be by
> >     re-initialising the dbus-vmstate object.
> > 3. If dbus is not available during VM power-on, then currently dbus-vmstate
> >     initialisation fails, causing power-on to fail.
> > 4. For a system with large number of VMs, having multiple QEMUs connected to
> >     the same dbus can lead to a DoS for new connections.
>
> The expectation is that there is a *separate* dbus daemon created for
> each QEMU instance. There should never be multiple QEMUs connected to
> the same dbus instance, nor should it ever connect to the common dbus
> instances provided by most Linux distros.
>
> None of these 4 issues should apply when each QEMU has its own dedicated
> dbus instance AFAICT.
>
>
> Regards,
> Daniel

How does having a separate dbus daemon resolve issue (2)? If any daemon 
restarts between VM power-on and migration, the dbus-vmstate object for 
that VM would have to be reinitialized, no?

Secondly, on a setup with large number of VMs, having separate 
dbus-daemons leads to high cummulative memory usage by dbus daemons, is 
it a feasible approach to spawn a new dbus-daemon for every QEMU, given 
the fact that majority of the security aspect lies with the dbus peers, 
apart from the SELinux checks provided by dbus.

Regards,
Priyankar Jain