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

Hello all!

It should be fixed https://github.com/vatesfr/xen-orchestra/commit/72592a54d2225d5368a3410e4b3c19039f8e5df1

0 b-Nollet committed to vatesfr/xen-orchestra

fix(backups): correctly update allowed_operations - temporary fix (#7924)

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

`allowed_operations` are currently not updated correctly when `blocked_operations` are modified, which causes backup jobs to remove `migrate_send` and `pool_migrate` from VM's `allowed_operations`. This commit fixes that, until `allowed_operations` updates correctly again.

@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

@McHenry You need to register with the same credentials you use to sign in the web UI.

@vmpr It should be fixed, let me know if you have any issues

https://github.com/vatesfr/xen-orchestra/commit/eb39e149723b2fb0e19c22931348485bead654ab

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/rest-api): set apiContext

This makes the REST API more closely resemblethe JSON-RPC API and addresses
several issues such as the broken _Rolling Pool Update_ pool action.

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

@vmpr Thanks for your report, it's indeed a bug. I will try to fix it soon!

@Morpheus0x Your feature request has been noted and will be put in the backlog.

It appears to be trivial so it should we'll try to do it soon but I cannot tell you when.

@CodeMercenary Non-string values must be passed as JSON with xo-cli:

xo-cli vm.set id=$id blockedOperations=json:'{ "clean_shutdown": "blocked by Julien" }'

Also, entries passed to blockedOperations are merged with existing ones, if want to remove some entries, passed null as their values.

Hello all!

It should be fixed https://github.com/vatesfr/xen-orchestra/commit/72592a54d2225d5368a3410e4b3c19039f8e5df1

0 b-Nollet committed to vatesfr/xen-orchestra

fix(backups): correctly update allowed_operations - temporary fix (#7924)

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

`allowed_operations` are currently not updated correctly when `blocked_operations` are modified, which causes backup jobs to remove `migrate_send` and `pool_migrate` from VM's `allowed_operations`. This commit fixes that, until `allowed_operations` updates correctly again.