Offline
@nickdsl This is a known limitation: at the moment, xo-server doesn’t filter objects based on permissions: permissions are currently applied during actions.
We’re actively working on resolving this in XO6 and the new REST API to improve overall functionality.
@chr1st0ph9 Local remotes are disabled by default for XO Proxies because they can be confusing: they are local to the XO Proxy itself and not the XOA they are defined in.
You can enable them by creating a config file on the XO Proxy Appliance, /etc/xo-proxy/config.toml:
[remotes]
disableFileRemotes = false
@ewoudstra Simply updating the git repo and rebuilding should be enough, but it depends a lot of how your previous XO.
The data should be kept across version as they are stored in Redis and in a LevelDB database as long as you are using the same ones.
And, as @olivierlambert said, if you cannot figure out the problem, simply export the config of your previous XO and import it into the new one.
@Bambos A timeout error means that the host did not reply in the expected delay, which, if I'm remembering correctly is 5 minutes.
I suspect a problem on your host but we will take a look further on your support ticket.
Yes, you can use JSON-RPC et REST APIs together for now 
We will try to add support for CPU settings soon.
Also, expect things to accelerate in 2025 regarding the REST API.
@irtaza9 As explained in the documentation, the method is a POST (cf. https://github.com/vatesfr/xen-orchestra/blob/master/packages/xo-server/docs/rest-api.md#start-an-action).
As explained in the documentation, you can list the available actions at /rest/v0/pools/_/actions and see the list of available params for a specific action by checking out its endpoint (/rest/v0/pools/_/create_vm for create_vm).
To create/alter disks, you need to use the vdis param, if you do not see it on your instance, it means it is not up-to-date.
CPU settings are not available at this time.
@irtaza9 Creating a VM is an action on a pool.
Check out the /rest/v0/pools/_/actions endpoint for the available actions and expected params.
@olivierlambert It's still possible to use the VM number in the cloud-init template: {index} since XO 5.100 (% before)
See the changelog.
@samuelolavo Shell only handles string values, to pass other types to xo-cli you need to encode them in JSON and use the json: prefix:
xo-cli resourceSet.create name=test-resource subjects=json:'["d301d9ea-9e22-4480-bf40-111111111111"]' objects=json:'["8fb06362-d8fe-598b-f819-11111111111111"]' shareByDefault=json:true
@cirosantos0 Indeed, our detection is wrong in this case, I will put this in our backlog, but don't expect it to be fixed soon.
PRs are welcome though
@dj423 It should be fixed in the master branch: https://github.com/vatesfr/xen-orchestra/commit/30e6d4b4f14ddbb6ee34cd456e4ca707486df2db
{index} is now used in place of %% is still working when Multiple VMs is enabled% and \% will be replaced by % when Multiple VMs is disabled@samuelolavo No, users management and self service are not in the REST API yet.
@nick-lloyd Yes, you can filter collection using the same syntax of XO's Home page as explained in the REST API documentation:
xo-cli rest get plugins/audit/records filter=data:method:vm.snapshot
@dj423 Then my solution would not work as it would break all your tags.
But indeed, maybe we should not replace % at all when Multiple VMs is disabled.
I know it's a bit cumbersome but in the meantime, you can escape the problematic character: \%.
@olivierlambert Never heard of invalid code lengths set.
Also, it's strange that this command is not working but others are… Maybe it's related to the size of the response…
You can try to use the REST API:
xo-cli rest get -o records.ndjson plugins/audit/records fields=data,event,subject,time,id ndjson
@samuelolavo I have node idea why some xo-cli commands would work but not others.
Also, fs is a builtin Node package, it should always be available.
Make sure that you are running Node 20 and that your PHP setup is not messing with the environment.
@vkeven What's the error you received? Interrupted?
Yes, normally the proxy continue the backup on its own.
Humm we need to do some test but how we will know than backup is successfull ?
There are no logs but you should be able to see the created VM backups in Backup/Restore
@vkeven Not exactly, if the connection is interrupted between XOA and XO Proxy, the backups will still be done normally but the logs are lost and the state of the backup will not be visible in XO. This is a known issue that will work on at some point.
As you said, the XO Proxy is running the backup job by itself.
@florent It was working before, this is likely something that has been broken when the handling of snapshots has been moved from VMs to VDIs.
We need to fix this.