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
