Hi!
It is not the XOCE to xo-server link, it is the credential xo-server uses to log into XAPI on your host.
It has to be reversible, not hashed, because xo-server replays it to XAPI on every connect and auto-reconnect. So yes, plaintext by default is expected. The security perimeter here is Redis itself (bound to localhost or a unix socket, never exposed) and root access on the XO VM.
That said, since XO 6.5 there is an opt-in encryption at rest. In your xo-server config:
[redis]
encryptCredentialDatabase = true
On the next start, every record is encrypted with AES-256-GCM (values get an enc: prefix) and index keys become HMAC-SHA256 blind indexes, so hostnames and emails are not readable either. The key is split in two halves, one in XenStore (vm-data/xo-encryption-key) and one in /var/lib/xo-server/data/xo-encryption-key.
Caveats for a source install:
XO must run as a VM on XCP-ng/XenServer with xen-tools, and xo-server needs access to the xenstored socket (root, typically).
Config export then requires a passphrase.
If you lose one key half while encryption is on, do not restart: XO would regenerate both halves and the existing records would become undecryptable.
Full doc: https://docs.xen-orchestra.com/credential-encryption
About the PoolAlreadyConnected part, that is a separate issue. It means two server entries resolve to the same pool, typically a slave host registered next to the master, or the pool re-added after a master change. Removing the entry with DEL xo:server:<id> is not the right fix: it drops the hash but leaves the id in xo:server_ids and in the host index. Remove the server from the UI instead. If the error persists, it is the other entry pointing to that same pool that needs to go.
