On 8/12/19 11:43 AM, Thomas Lamprecht wrote:
Am 8/12/19 um 10:37 AM schrieb Dominik Csapak:
we want to notify the api that there is a new qemu-binary, since
the version will be cached in qemu-server and instead of
checking the version every time, just restart pveproxy/pvedaemon
whenever there is a qemu update
this fixes a rare theoretical issue when only updating qemu, that
the pvedaemon starts a vm with a new version but with the
defaults of an old version because of the version cache,
breaking live migration
Signed-off-by: Dominik Csapak <d.csa...@proxmox.com>
---
i do not know if that issue was ever triggered, but it seems
very unlikely, so this is just to be safe
the other alternative, either dont cache the version, or caching
and checking the file timestamp would also work, but this is the 'cheaper'
solution overall, since we do not update pve-qemu-kvm that often
This also triggers a full HA LRM/CRM restart, not really cheap either.
Is the LRM with the direct access to the API module (in a always newly
forked worker) also affected by the caching "issue" from a call to the
"QemuServer::kvm_user_version" method?
afaics yes, since we do a 'require and import' of the QemuServer package
in the BEGIN block which does not get rexecuted after forking there,
am i right?
Else I'd either just:
* restart pve- proxy/daemon "manually" in the configure step
is not solving the problem for lrm (if affected)
* improve the caching detection by doing your proposed "/usr/sbin/kvm"
stat call
possible and ok for me
* removing caching entirely
i think we should not do that
Maybe you could benchmark if the removal of the caching is really a big
performance "hit", I'd guess so as fork+exec is not too cheap..
If it's not just a few percent points I'd to the stat thing, I really
want to avoid LRM/CRM restarts if possible.
i proposed this change since the frequency of which we update qemu is
rather low (~once per month) which mostly is shipped together with other
updates which trigger the api-update anyway (e.g.
pve-manager,qemu-server,pve-storage,etc.)
instead of having a penalty on every vm start...
but i am ok with the stat approach
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
