On Mon, Oct 01, 2018 at 12:36 PM +0200, Peter Krempa <pkrempa@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
