Thank you for this constructive argument

Have a nice day.

This should work:

xe vm-param-set uuid="$uuid" \
  xenstore-data:vm-data/ip="$ip" \
  xenstore-data:vm-data/netmask="$netmask" \
  xenstore-data:vm-data/gateway="$gateway"

Optionally the default DNS server can be replaced as well:

xe vm-param-set uuid="$uuid" xenstore-data:vm-data/dns="$dns"

Don't forget to restart the XOA afterward!

Thank you all, this is now fixed.

https://github.com/vatesfr/xen-orchestra/commit/07bd9cadd4732554c57e441cd9d860b63f73fe02

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/vm.create): typo during VIF creation

Introduced by ecae554a7

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

@markhewitt1978 Hi, thank you for your feedbacks!

We are aware that this limitation bothers a lot of users and we have plan to address that in the next major version of XO.

XO 5 was already a major improvement over its predecessor because it allows viewing and handling a much bigger infra.

XO 6 will go further in this direction by introducing a tree view and the possibility to edit and handle many objects at the same time.

@Danp That may not be directly to script but to the external environment: SMB works much better if cifs-utils is installed on the system, something that is present on our doc but might be missing in some install scripts.

We have no animosity whatsoever regarding these scripts but we prefer our appliances (or even manual installs from our documentation) because we understand much better what's going on and it's easier to replicate and fix the issues

Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome

@M92 There is now a /groups collection which lists all the groups and two new collections, /groups/:id/users and /users/:id/groups which list respectively all users in a group and all groups a user belongs to.

These new collections have the same behaviours than the others, which means they accept the fields, filter and limit parameters.

And yes the limit parameter should work correctly, let me know if you have any issue.

@M92 Hello, no, groups are not exposed at this time, will do it ASAP.

@josh383451 The bug was fixed 3 days ago: https://github.com/vatesfr/xen-orchestra/commit/73d88cc5f1a5458c68e6935a9d5a9240616007b1

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/vm.convertToTemplate): handle VBD_IS_EMPTY (#6808)

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

@olivierlambert Done: https://github.com/vatesfr/xen-orchestra/commit/33b45d2eda2ce6d8071541da246bdcfd06b133b8

It's not perfect but that should help

Example:

vm.start
{
  "id": "123e4f2b-498e-d0af-15ae-f835a1e9f59f",
  "bypassMacAddressesCheck": false,
  "force": false
}
{
  "errors": [
    "R620-L3: VM_REQUIRES_SR(OpaqueRef:21fa00fc-62ce-4694-8b49-fcecd600a89e, OpaqueRef:4dd615a7-9a8c-4698-aceb-c10f782321c8)",
    "R620-L1: HOST_NOT_ENOUGH_FREE_MEMORY(216430280704, 18778341376)",
    "R620-L2: VM_REQUIRES_SR(OpaqueRef:21fa00fc-62ce-4694-8b49-fcecd600a89e, OpaqueRef:4dd615a7-9a8c-4698-aceb-c10f782321c8)"
  ],
  "message": "",
  "name": "Error",
  "stack": "Error: 
    at Xapi._startVm (file:///home/julien/dev/vatesfr/xen-orchestra/packages/xo-server/src/xapi/index.mjs:1358:15)
    at Xapi.startVm (file:///home/julien/dev/vatesfr/xen-orchestra/packages/xo-server/src/xapi/index.mjs:1393:7)
    at Api.callApiMethod (file:///home/julien/dev/vatesfr/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:307:20)"
}

2 julien-f committed to vatesfr/xen-orchestra

feat(xo-server): better info when failing to start a VM

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

@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

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