Thank you for this constructive argument

Have a nice day.

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

@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

@stucamp I finally had time to investigate this, it should now be fixed

Thanks for your report!

https://github.com/vatesfr/xen-orchestra/commit/24cac9dcd5d83c3170175c9c874d0a3ae51f4e6d

0 julien-f committed to vatesfr/xen-orchestra

fix(xen-api/getResource): fix redirection handling

Introduced by ab96c549a

Hello everyone,

We have been using Yarn 1 in XO because it had support for workspaces, which npm lacked at the time.
But now that npm has caught up, and Yarn 1 is frozen, I think it's time to get back to using it.

Also, we are thinking about using Turborepo instead of our own custom scripts to build the repository. This would, among others, bring caching, i.e. packages are no longer rebuilt if there were no changes.

I hope these changes will not introduce any problems (I'm thinking about https://xcp-ng.org/forum/post/54567).

I you want to test, please take a look at this PR: https://github.com/vatesfr/xen-orchestra/pull/6559

Keep me posted if you have encounter any issues

julien-f opened this pull request in vatesfr/xen-orchestra

draft chore: use npm #6559

@maverick Aggressive (even passive) comments are not tolerated here.

We are doing what we can and are open to questions, suggestions and even better, contributions.

On your other thread, you are suggesting a solution, which is a better approach to this kind of problems, we'll try to look into it and if it's easy enough and does not cause other issues we may integrate it.

In the mean time, you can add the following setting to your xo-server's config to keep the previous behavior:

[backups]
useGetDiskLegacy = true

Let us know if you have issues.

Thank you for your reports, we have pinpointed the issue and we'll fix it soon

https://github.com/vatesfr/xen-orchestra/pull/6404

MathieuRA opened this pull request in vatesfr/xen-orchestra

closed fix(xo-server): handle unfetched VDIs in pool.$ha_statefiles #6404

@DustyArmstrong Perfect, thanks for your feedback

@KPS Both APIs are completely different, the oldest one has never been intended for public consumption, it was developed for XO's internal needs even though we are not preventing anyone from using it

The REST API has been created exactly to address the need of a public API, use it if it covers your need.

Also, feel free to provide feedback and we'lll improve it.

Regarding the limit issue, it has been fixed 6 weeks ago, please make sure you are up to date.

@KPS Hello, yes it's possible, you can specify fields=* to get all of them. It is not documented because it should not be used in production, users should specify exactly what fields they need when fetching a collection.

An alternative way to discover the fields is to too look to a specific record:

xo-cli rest get vms/123e4f2b-498e-d0af-15ae-f835a1e9f59f

@DustyArmstrong I'm reluctant to add a sort feature, but I think it makes sense for the limit to be applied at the end of the sorted collection

@CJ Please test the branch email-local-hostname which make the local hostname configurable and keep me posted.

@DustyArmstrong filter and limit are now supported for backups/logs: https://github.com/vatesfr/xen-orchestra/commit/8a26e081027c5410757dcc7ae4ece6ffa7bd81a9

0 julien-f committed to vatesfr/xen-orchestra

feat(xo-server/rest-api): `filter`/`limit` support for `{backups/restore}/logs`

Fixes https://xcp-ng.org/forum/post/64789

@DustyArmstrong

1. The parameter used for filtering is filter not s, if you saw the last one in the documentation, it's an error, please let me know and I'll fix it
2. Filtering and limiting is not implemented for backup logs yet, I'll do it now.

@CJ Which field would you want to be optional?

@DustyArmstrong No, your URL is not correctly formatted, the parameters should be passed in a standard query string which uses ampersand (&) to separate parameters:

http://xo.localdomain/rest/v0/backups/logs?fields=id,status,jobName&limit=10

Regarding your second question, filter is the parameter used for search, ie filtering results. The value is a string that uses the XO filter syntax, and because it is part of an URL, should be properly percent encoded. In JavaScript, you can use the encodeURIComponent() function to achieve that:

encodeURIComponent('power_state:running jobName:"My job"')
// power_state%3Arunning%20jobName%3A%22My%20job%22

Hello everyone,

First of all, XO tasks are completely separate from XAPI tasks., they have a different structure, and are handled internally by XO.

Task logs are not deletable, the red button can be use to ask the abortion of the task, and is obviously not usable once the task has finished (or if the abortion has already been requested).

Logs of ended tasks are not deletable at this time, because they reflect what happens and we did not see a real reason for them to be deleted.