Automate with xo-cli
Use the xo-cli command-line client that ships with the appliance to read a small inventory with a short-lived token, then revoke the token. Do this test before you write automation that changes a VM. You run the commands in a shell inside the XOA-HL appliance, and revoke the token in a browser signed in as the same test user.
xoa-image-20261022-a280852, package v5.113.2_e281c536-ce40 (Xen Orchestra 5.113.2), with xo-cli 0.32.2 and xo-lib 0.11.1. Based on the released code; not yet tested on a lab system. The commands were only run against a simulated server.1. Prepare the shell and TLS trust
Before you start
- Check the installed release, as described in appliance maintenance.
- Have a normal test user account and a test VM that you can lose. Test what this user is allowed to do separately, with Users and permissions.
- Use an appliance DNS name that matches its certificate. The self-signed
xoa.localcertificate created at installation may need lab DNS or certificate work first. - Get the appliance’s public CA or certificate as a PEM file through a trusted channel. Check its fingerprint by a separate route.
- Open a new, dedicated Bash session inside the appliance. You use the bundled
/usr/local/bin/xo-clithere. - In the example in the next section, replace the PEM file path, the URL and the email address with your own.
NODE_EXTRA_CA_CERTS adds your certificate to the trusted list; the host name is still checked. If the TLS check fails, fix the name or the certificate. Never bypass it with --allowUnauthorized or NODE_TLS_REJECT_UNAUTHORIZED=0.
2. Register a short-lived token
The commands below keep the credentials in a new temporary folder, so your existing xo-cli configuration is not touched. umask 077 makes the new file readable by you only.
registerasks for the password. Do not add it as an argument, and never put a token in a URL.- If the account uses one-time codes (OTP), add
--otp CODEbefore the URL, with a current code.
umask 077
xoa_cli_config="$(mktemp -d)"
xoa_cli_ca="/path/to/verified-appliance-ca.pem"
xoa_cli() {
XDG_CONFIG_HOME="$xoa_cli_config" NODE_EXTRA_CA_CERTS="$xoa_cli_ca" xo-cli "$@"
}
xoa_cli register --expiresIn '1 hour' https://xoa.lab.example user@example.invalidThe token asks for 1 hour on purpose. By default the server gives a token 30 days, with a maximum of half a year; the server configuration can change these limits.
The token has all the rights of its user: it is not limited to reading. Treat the configuration folder like a password. Keep it out of shell traces, out of backups attached to issues, and out of source control. Registering creates a login token; the next commands only read data.
3. Discover and read the inventory
Run these commands. Put flags such as --json and --id before the parameters.
xoa_cli list-commands xo.getAllObjects
xoa_cli system.getServerVersion --json
xoa_cli list-objects --id --name_label --power_state type=VM
xoa_cli xo.getAllObjects --json 'filter=json:{"type":"VM"}' 'limit=json:1'| Command | What you get |
|---|---|
list-commands xo.getAllObjects | The parameters of the method, in readable form. Seeing a method does not mean you are allowed to use it |
system.getServerVersion --json | The server package version, "5.193.1" in this release. This is not the XO version (5.113.2) |
list-objects --id --name_label --power_state type=VM | A JSON array with only these properties. No VM state changes |
xo.getAllObjects --json … | A JSON object keyed by object ID, filtered by object type and limited to one object |
The json: prefix sends a typed value: limit=json:1 sends a number, while limit=1 sends a string. The last command sends this JSON-RPC request over a WebSocket to /api/ (it is not an HTTP POST):
{
"jsonrpc": "2.0",
"id": 1,
"method": "xo.getAllObjects",
"params": { "filter": { "type": "VM" }, "limit": 1 }
}Filters and selected fields only choose what you see: they are not access limits. Do not assume that the API returns only the objects shown in the user’s web interface, or that fields left out of the output were never fetched. Keep the results private, and check separately what the account can really see. A name is not a stable ID. This limited result is not a complete inventory, and it is not a reliable way to pick a VM.
4. Revoke the token and clean up
- In a separate browser session, signed in as the same test user, select the user icon in the menu to open User (
/#/user). - Under Authentication tokens, delete the token of this CLI client.
- Back in the shell, run the first command below before you remove anything locally. It must fail with an authentication error and a nonzero exit code.
- If it succeeds, the token is not revoked. Stop, and check the account and its tokens before you say that revocation worked.
- Run the other commands to remove the local credentials, then close the dedicated shell.
xoa_cli system.getServerVersion --json
xoa_cli unregister
rm -rf -- "$xoa_cli_config"
unset -f xoa_cli
unset xoa_cli_config xoa_cli_caCheck: after you delete the token in the browser, the version command fails with an authentication error.
unregister only removes the local server and token entries; it does not revoke the token on the server. Removing the temporary folder is only a local cleanup: it does not replace revocation. Lasting automation needs its own design for secret storage, renewal, revocation, error handling and narrowly limited rights; that is not covered here.
Sources
- Command-line client: xo-cli, where the client stores its settings, xo-lib.
- Tokens and inventory: token API, token expiry, inventory API, tokens on the user page.