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

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 and Turbo #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

Should be fixed now, please let me know if you have other issues.

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

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/collection/redis#{add,update}): cast to string before inserting in db

Fixes https://xcp-ng.org/forum/post/51933
Fixes #6359

Introduced by 36b94f745

@bullerwins It may be necessary to upgrade multiple times the proxy if the VM is not known to the main XO.

If it does not work, open a support tunnel on your XO and we'll take a look directly.

@olivierlambert Nope, {address} is not supported in the cloud configs.

AFAIK, there is no IP configuration done during VM creation, what value should it take?

@Danp And of course if there is a real risk/issue, keep us posted and we'll take care of it

@Danp I don't think so, from what I can tell the concerned packages are used by xo-web build system. Their (theorical) vulnerabilities should have no effect in prod and upgrading them would probably be too hard.

Small targeted PRs fixing some of these issues are welcome though.

@Andrew My test results:

• install time: Yarn 17.58s → npm 50.80s
• build time: custom 71.68s → Turborepo 76.13s

I agree the install time is not very good with npm, I'll try to understand why and if we can improve the situation, still we can probably stay compatible with both, and maybe even try to be compatible with pnpm.

With Turborepo and the cache system, the build time is greatly improved in following runs (~10s in my second one), so I think that's a plus

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 and Turbo #6559

@Steve_Sibilia Yes.

1. Take a look at a specific snapshot to see the available fields, note snapshot_time which is a Unix timestamp.
2. Use a filter (syntax documentation), example:

   /rest/v0/vm-snapshots?filter=snapshot_time%3A>1669044124
   

Hello,

Yes, the list of VM snapshots in now exposed by the REST API, the path is /rest/v0/vm-snapshots.

The list of available collections is under the path /rest/v0.

More info in the documentation: https://xen-orchestra.com/docs/restapi.html

@ashinobi Currently it's only possible to export the whole config of the XOA, for a single job, unless it's a real issue, you'll be better creating a new one

@ashinobi Disabling is enough, but keep in mind that creating a new job (as opposed to exporting/importing the config) will create a job with a different id, detached from the previous one, ie it will not continue the delta backup chains but create new ones