[pve-devel] [PATCH qemu] add pve-api-updates trigger
t.lamprecht at proxmox.com
Mon Aug 12 11:43:02 CEST 2019
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
Else I'd either just:
* restart pve- proxy/daemon "manually" in the configure step
* improve the caching detection by doing your proposed "/usr/sbin/kvm"
* removing caching entirely
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.
> debian/triggers | 1 +
> 1 file changed, 1 insertion(+)
> create mode 100644 debian/triggers
> diff --git a/debian/triggers b/debian/triggers
> new file mode 100644
> index 0000000..59dd688
> --- /dev/null
> +++ b/debian/triggers
> @@ -0,0 +1 @@
> +activate-noawait pve-api-updates
More information about the pve-devel