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

[Daniel P . Berrangé]

On Wed, Dec 02, 2020 at 09:25:27PM +0530, priyankar jain wrote:
> 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?

The private dbus damon for QEMU is expected to exist for the lifetime of
that QEMU process.

> 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.

The memory usage of a dbus daemon shouldn't be that high. A large portion
of the memory footprint should be readony pages shared between all dbus
procsses. The private usage should be a functional of number of clients
and the message traffic. Do you have any measured figures you're concerned
with ?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|