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

@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 created this issue in vatesfr/xen-orchestra

open 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 created this issue in vatesfr/xen-orchestra

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

@bberndt Thanks for your report.

I've pushed a fix: https://github.com/vatesfr/xen-orchestra/commit/ea4a888c5e73e022cf331545c8a02231cfa46f15

Please test and let me know if you have any other issues

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/vm.create): allow additional props for VDIs and existingDisks

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

@samgaw How did you install your XO?

@Flying9167 It's indeed not possible at this to filter which users are allowed to sign in with XO auth plugins.

At this time it should be handled at the authentication provider itself and it does not look like GitHub OAuth implementation supports it.

@mietek Hello, this is due to incompatibility between xo-cli and xo-server due a change introduced 6 months ago, you can resolve it by updating xo-server.

Another solution is to update xo-cli as the recent versions contains awork-around for old versions of xo-server.

@olivierlambert https://github.com/vatesfr/xen-orchestra/blob/master/packages/xo-server/src/fatfs-buffer.mjs

I don't remember the details exactly, but it would probably be harder to do it with a partition table.

@FabioRizzo What exact error do you get?

@FabioRizzo I've updated my comment, please don't use this, it's broken and unnecessary.

@Gheppy It should be fixed, thanks for your report!

https://github.com/vatesfr/xen-orchestra/commit/b5578eadf7356098ac2fa4af63b75b18d34ba558

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/sr.{create,set}): name can be empty

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

Introduced by 65168c853

@prononext @mandrav The problem of empty username has been fixed in master.

The support of email for username field is currently in review in the PR linked in my previous message and will be available soon

Thanks for your help!

@mandrav I've just pushed a fix to prevent XO from creating users with an empty name.

Most likely your problem is that the plugin does not work with the setting username field set to email.

Please test the branch fix-oidc-email for a fix. Re-signing in the problematic user (if it has been created via OpenId Connect signin and has not been linked to another auth provider) should update the user name.

@hannes Full backup interval (and Force full backup in the schedule settings) forces the job to do a full export of the disk and not a delta based on a previous one.

It is not impacted by the retention as XO will always makes sure every chain has at least a full export at the beginning so that all backups are viable.

Which means you will have multiple full backups, always one at the beginning, and, those that have been triggered by the settings above.