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

@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

0 julien-f committed to vatesfr/xen-orchestra

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