Hello.
I spotted a small bug in the XO-Lite system page: Secure boot was always showing Disabled I'll fix this issue soon.

According to my tests, your VM isn't booting because Secure Boot is enabled, but your pool isn't configured for it.
If I remember correctly, in XO 5, Secure Boot is disabled by default, but in XOLite, if your template sets "platform.secureboot" to true or auto, the VM will be created with Secure Boot enabled.
Can you confirm that if you disable Secure Boot on your VM, it boots correctly?

ping @lsouai-vates to plane the possibility to enable/disable secure boot in the XOLite/XO6 UI, and possibly transform auto to false if the pool isn't compatible. Or at least, as in XO 5, warn the user

Hello @coolsport00
I'm unable to reproduce the issue on my side.
Can you confirm that the issue persists on the latest version of XO-Lite? (v0.14.0)

Have you imported any ISOs into your SR ISO?

Fix available on master

Hi.
A PR is open: https://github.com/vatesfr/xen-orchestra/pull/8900

If anyone can confirm that the issue is fixed, that would be great. Thanks.

MathieuRA opened this pull request in vatesfr/xen-orchestra

closed fix(@xen-orchestra/rest-api): fix watch tasks #8900

Hi @Andrew.
This PR should fix your issue https://github.com/vatesfr/xen-orchestra/pull/8854

MathieuRA opened this pull request in vatesfr/xen-orchestra

closed fix(xo-server): fix incorrect state when remove server #8854

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.

Hello @DevFlint.
/rest/v0/tasks/:id exists. It's not yet documented in Swagger, but it does exist.

FYI, "actions" endpoint are specific.
They can be executed asynchronously (which is what you're currently doing). In this case, a task is returned and needs to be monitored. Use /rest/v0/tasks/:id for this.
You can also execute your action synchronously by using sync=true as a query parameter. In this case, the VM ID will be returned in response.

This should normally be documented in Swagger. If it's not clear in the documentation, we can improve it

PR: https://github.com/vatesfr/xen-orchestra/pull/8599

MathieuRA opened this pull request in vatesfr/xen-orchestra

closed fix(xo-server/xen-server): fix disabling an enabled but disconnected server #8599

Hi, I will fix it ASAP. Thanks

@hanzzz This PR adds the ability to run a schedule. So, a temporary workaround is to create a job, create a schedule for this job, then run your schedule.

If you are not using XO from source, you will have to wait for version 5.106

Hi.
I confirm that no actions are currently available for hosts.

Hi @eeldivad

You can use the json flag. xo-cli rest --json get vdis

Hi @irtaza9
You have a typo in your vm-templates URL.
fields instead of field

Hi @irtaza9.
The REST API is only available for admin users.
It is planned to handle other types of users in a few months

@irtaza9 you need to use the user-id, not the username

Hi @irtaza9
FYI, for about 2 years, VMs expose a creation field:

"creation": {
    "date": string,
    "template": string,
    "user": string
  },

With this you can filter VMs by creation.user to list only VMs created by a user.
/rest/v0/vms?filter=creation:user:<user-id>

I will create a card for this feature request to discuss with the whole XO team. I will keep you updated here

Hi @rtjdamen
This should be doable using xo-cli.
xo-cli backupNg.runJob id=<your-job-id> schedule=<your-schedule-id> vm=<your-vm-id>

@RS if you are using XO from source, you need to change your branch and rebuild XO

Hi @RS
Just to let you know, there is a branch available to test RPU/install patches with XenServer 8. (xs-8-install-updates)
Feel free to test and give feedback. Thanks