On Mon, Oct 01, 2018 at 12:36 PM +0200, Peter Krempa <pkrempa@redhat.com> wrote: […snip…]
I would do all the precondition stuff (e.g. the priv->qemuCaps isn’t valid anymore) as early as possible in the overall “task/job” process.
Well, technically priv->qemuCaps is invalid and unneeded when the VM is not running and valid and immutable if it is running.
If the VM is not running, there is no qemu process associated to it so it does not make sense to store random qemuCaps along with it, since the qemu binary might change at the point when we attempt to start it.
Yep, that makes sense.
I was not a fan of needing qemuCaps in the post parse infrastructure of qemu, but at this point we can't do much about it especially as we want to keep the config stable after defined.
This patch does not seem to make sense with the justification provided here as the post-parse callbacks fill in the proper caps here and this part clearly uses a new domain configuration, so the default behaviour should be used.
Changing this would also need that we change the normal parser path to achieve the same results which is impossible as you don't have access to priv->qemuCaps prior to creating the virDomainObj object.
Yep, that’s why I said in the cover letter “With this patch series the behavior is still not (completely) fixed, but the performance has been significantly improved.”.
I don't see what should be fixed here, but mostly as I did not read the series.
The problem is that we currently don’t take into account that the QEMU binary can change during a task (e.g. define a domain). Therefore, it’s possible that two calls of virQEMUCapsCacheLookup return different QEMU capabilities. […snip] -- Kind regards / Beste Grüße Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294