@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

0 julien-f committed to vatesfr/xen-orchestra

feat(xo-web/new-vm): new cloud-init template var `{index}`

@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.

@probain Noted in backlog

@dj423 It's because the cloud-init configs in XO are template and some entries are replaced:

• {name} with the name of the VM
• % the index of the VM starting from 0, only useful when the advanced setting Multiple VMs is enabled, always 0 otherwise

Would it fix your problem if we change the behavior so that % is simply removed when Multiple VMs is not enabled?

@AlexQuorum This has been fixed, thank you

https://github.com/vatesfr/xen-orchestra/commit/649add3ab363a331a65097b986628ce227b539c1

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server-audit): ignore host.isPubKeyTooShort

Fixes https://xcp-ng.org/forum/post/84464

@AdamG XO's vm.create creates a disk containing the files expected (meta-data & user-data) by Cloud Init, nothing else.
It is up to the VM template to have Cloud Init installed and to look for the files at the right place.

The params cloudConfig and networkConfig must contain the configs themselves for vm.create to put into the related files, not paths.

Hello @Andrew, thanks for your question!

First off, I haven't tested Deno or Node with Xen-Orchestra yet. Changing the Node version can sometimes introduce bugs—some of which may be subtle. For that reason, I’d prefer not to venture into this unless it truly proves to be worth the effort.

Secondly, in my experience, benchmarks don’t always translate into meaningful results in complex applications.

That said, we are keeping an eye on alternative engines, both in terms of performance and the new features they offer. If we determine that the benefits are significant, we’d definitely consider migrating.

Additionally, if any users want to experiment with Deno or Bun, they’re welcome to start dedicated threads on the forum to collaborate. We’d be happy to review and merge compatibility PRs as long as they don’t break Node and aren’t overly complex.

@manilx Thank you for your report, we are already investigating: https://xcp-ng.org/forum/post/83312

@Tristis-Oris Thanks for your report, it should be fixed now, thanks to https://github.com/vatesfr/xen-orchestra/commit/2ea2f8040a5b005e059fb2e90d8395d3d44e7cc1

0 pdonias committed to vatesfr/xen-orchestra

fix(xo-web/render-xo-item/Schedule): handle undefined job/schedule name (#8024)

See https://xcp-ng.org/forum/topic/9690
Introduced by d520e53f9e7ad0d45ee45ebfd13d402a970deede