Not sure to understand but for example if you run xe vm-start <uuid> on slave1 but the vm is started on slave2 (because it uses a storage local to slave2) then the resident-on will be slave2. It's because the task Async.VM.start is really created on slave2 even if the initial command has been received by slave1. Does it answer your question?

@olivierlambert as you said the resident-on field of a task is set by the helper which creates the task. So the value should be the name of the host where the task has been created.

Oh no in fact the discussion that I remember (just find it) was about why not accept SHA 384: https://github.com/xapi-project/xen-api/pull/6467

lindig opened this pull request in xapi-project/xen-api

closed CP-307865 accept SHA512 for custom server certs #6467

@jivanpal said in Installation: expecting an rsa key, any plans to support elliptic curve keys?:

uses an unsupported algorithm

The only supported algorithms are RSA 2048 and 4096. I'm not sure if there are good reason to not support ECDSA. I remembers some discussions about this, will try to find them.

Does it fails using directly the xe CLI: xe host-logs-download file-name="/tmp/logs.gz" uuid=<hostuuid>
The host uuid can be any host of the pool. I didn't reproduce yet with 8.3 by there are not many logs on my hosts.

@olivierlambert do you know who on XOA side can have a look?

@rvreugde it is really strange... I only have one host on my setup that I'm using for testing and I don't see this behavior... But I see almost every minutes a message in my /var/log/xensource.log saying:
Feb 10 14:55:58 xcp-gthvn1 xapi: [debug||518 HTTPS 10.1.0.100->:::80|host.call_plugin R:dd18d954e8e1|audit] Host.call_plugin host = 'd7f4a210-369a-410e-9c73-4acb59fe5e7c (xcp-gthvn1)'; plugin = 'updater.py' ; fn = 'check_update' args = [ 'hidden' ]
I don't know who is calling this. But for me the file is always released properly. No process that locks the file... Not sure about what to test next. Is there someone on the forum with the same issue?

In fact on my testing host (xcp-ng 8.3) the file is also there. So it looks like it is normal to not delete it. Can you run the command several times? Because on my host even if the file is not deleted I can run the command several times. So I guess that sometimes a process still holds the file and we need to delete it but most of the time the file is just closed and it works.
EDIT: Oh but in fact it looks like by default the update is run by XO so you will see the file that is updated (time is modified each minute on my host). But I'm discovering this plugin and I'm not sure how it is used...

And if you run the command from pool master for pool master you still have an empty list?

xe host-call-plugin host-uuid=20cacce5-ffac-4ace-ac7c-e48f4e6dfc8e plugin=updater.py fn=check_update

Maybe this command must be run from pool master (I'll be surprised...)?

@rvreugde said in Patching XCP-ng via XOA:

xe host-call-plugin host-uuid=20cacce5-ffac-4ace-ac7c-e48f4e6dfc8e plugin=updater.py fn=check_update

Can you try to run the command directly on xcp-080 ?