[pve-devel] [PATCH qemu] add pve-api-updates trigger
d.csapak at proxmox.com
Mon Aug 12 12:06:29 CEST 2019
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.csapak at 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.
instead of having a penalty on every vm start...
but i am ok with the stat approach
More information about the pve-devel