@poddingue Confirmed working, thank you so much for the heads-up, this made my day! Got it wired into the n8n flow and it's running perfectly. One gotcha for anyone else landing here, name_description gets rejected with a 422 "excess property", it has to be nameDescription. Working body: { "nameDescription": "nginx, app-1, app-2 | 2026-06-01" }

Bit of a necropost on your necropost, but this got easier in XO 6.5. The REST API now accepts a txChecksumming parameter when you create a VIF (PR #9793, https://github.com/vatesfr/xen-orchestra/pull/9793), and it maps straight onto the ethtool-tx / other_config value you were setting by hand. So, for new interfaces, you can do it through /rest/v0 now instead of the XAPI script. I think it's on the create path rather than existing VIFs, though, so for the firewalls already running your script or the gear icon is probably still the way, and I haven't tested it against a live VIF myself. Either way, it's nice to have it native in the API now. All-Ki opened this pull request in vatesfr/xen-orchestra closed feat(rest-api): add support for txChecksumming and rateLimitting on V… #9793

Hi @r0123456789, GET /rest/v0/hosts/:id/stats is available in the REST API

Hi @dan89, It is possible to create an authentication_token using the REST API. POST /rest/v0/users/me/authentication_tokens

Hi @Steve_Sibilia, FYI, ACL V2 / RBAC is now available in the REST API. You can see the RBAC doc. A dedicated thread is available on the forum thread, please feel free to share your feedback. Thank you.

Hi @halvor, FYI, ACL V2 / RBAC is now available in the REST API. You can create a privilege that only give you read privilege on your host. You can see the RBAC doc. A dedicated thread is available on the forum thread, please feel free to share your feedback. Thank you.

Hi @jedimarcus, FYI, VIF creation is possible via the REST API POST /rest/v0/vifs

@florent OK cool, thank you for the info.

@olivierlambert & @mathieura thanks for the speedy response. Duly noted, very much appreciated.

@gduperrey Worked swell, thanks

@MathieuRA Glad to see this finally fixed. I brought this up a while ago... https://xcp-ng.org/forum/post/102102

@rama said: @olivierlambert thank you. but is it possible to keep tracking all the CURD operation like we have in terraform. but currently MCP have only Read tasks. Like if some new interns in my lab don't know about this and in this agentic framework if he/she need a VM's, delete or update it can be done very quick. it will save many hours. I hope this will be available in future or if you wish to do tell me how far it is. The plugin MCP Server is read only by design to keep using it safe, to have an MCP for reading and another for writing is best practice. If you desire to have a separate MCP server for the writing actions, feel free to suggest that in the feedback portal. You can even develop your own MCP server, which makes calls to the write side of the XO REST API. https://modelcontextprotocol.io/

@Danp alright, thanks. I'll give that a try.

@Pilow tags can work and the path to them is much more succinct. Thanks!

@florent, I had to do the same for Xen Orchestra Community Edition. In my case, config.toml already contained the [authentication] section, so adding a separate config.tokenValidity.toml file did not work. Instead, I had to modify the existing config.toml located at /opt/xo/xo-server. In my opinion, it is best to keep defaultTokenValidity set to 30 days as a fallback in case no value is specified. You can then simply increase maxTokenValidity to the duration you prefer. [authentication] defaultTokenValidity = '30 days' # default value of 0.5 years # comment out and increase to 5 years #maxTokenValidity = ' 0.5 year' maxTokenValidity = '5 year'

@MathieuRA Thank you, perfect Br,

But giving your feedback on how you solved it might help many people in the future Thanks!

@MathieuRA The context for my question is I created an app to control my VMs and though my app said a VM started it really didn't. When I went into the logs I noticed an error, so my thought is to be able to check the logs would be helpful to find out if there is an error or not. Let me update my app because I'm thinking I can get around not having access to the logs. Thank you for the prompt response! Have a blessed day!

@Pilow that probably would have been a good idea hey! [image: xoa_homeassistant-tile-example.png?raw=true] That's the example tile from dashboard-card-example.yaml. But it's Home Assistant. You make it look however you want right? Having the entities available to use is most of the challenge.