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

@Byte0 The json: makes the rest of the value interpreted as JSON, otherwise it is interpreted as a plain string. It is therefore required for all non-string values.

Some method params (like memory for vm.set) accept both integers and strings, that's why it was working.

xoa network static supports setting IPv6 addresses but do not allow setting multiple gateways for a single interface at this time.

And indeed, it's also not possible to set XOA's network config from the UI.

@McHenry You can ask for the JSON format instead of a human readable excerpt:

xo-cli backupNg.getLogs --json

@Davidj-0 You can list VMs without a management agent with the following filter: power_state:running !managementAgentDetected?.

XO does not support this for halted VMs but that could be added indeed.

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