[pve-devel] [PATCH qemu] add pve-api-updates trigger

[Dominik Csapak]

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. 
pve-manager,qemu-server,pve-storage,etc.)
instead of having a penalty on every vm start...

but i am ok with the stat approach