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

I know it's actively worked as we speak (ACLv2). So I would say this year at least It's in our (soon published) roadmap in the "Next" section, just after the "now".

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

@SethNY you could even enhance this VM_LIST = with TAGs on VM, so that you manage the selection directly in XOA

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

Yes, they are created either: on demand for users when we need in XO 6 Now, XO 6 is becoming the main driver for new endpoint as the UI is providing more and more features.

Thanks @MathieuRA !

@olivierlambert Fun fact -lah is short for lazy ass human AI is coming... [image: 1761837446934-feb6ff1a-7269-4c37-84b8-8ed1d64c3d68-image.png]

I was curious if there had been any updates to mounting ISOs via the API? Thanks.

@Kptainflintt you are welcome We are always delighted when we can quickly unblock a user! Have a good day and don't hesitate to come back if you have other issues in the future.

@bryonadams said in Trouble Creating VM via API: Is there a place I can submit a feature request to allow setting a description and other settings from the UI to get feature parity when creating a VM? Otherwise, there's not much point since I have to go in and touch the new VM anyway. Unless I'm going about this wrong to begin with? You can create a feature request on Xen Orchestra github repository (https://github.com/vatesfr/xen-orchestra/issues), and if you have subscribed to support via XOA you can send a request through Zammad.

Haha, glad it works now, that's what matters anyway

This is normal, as the tasks endpoints are in the old REST API (undocumented by Swagger). We are gradually migrating to the new REST API to document all endpoints.

This page is being improved as we speak It shouldn't be in "Future improvements" because it's here