Again, XCP-ng and Xen Orchestra are really meant to work together: that’s by design. Our goal is to offer a unified stack with one consistent REST API to manage everything, across any number of pools. XO already handles a ton of things: auth (with oidc, SAML etc.), multi-pool aggregation, RBAC/ACLs, task tracking, templates, backups, live migrations, etc. By building on top of XO, we can focus on adding real value instead of re-implementing all that logic again in any 3rd party program we maintain in full open source and for free. And honestly, I don’t see any issue relying on XO: everything is fully open source, and all features are available for free from the sources, just like it’s always been. Nobody’s forcing you to use one or the other: if you’d rather build directly on XAPI, you absolutely can.

Release v2.2.0 This new version introduces a new field, 'memory_min', for the VM resource and makes a slight change to the 'memory_max' field, which now sets both the dynamic and static maximum memory limits and providing better control of VM memory. What's Changed feat: Update TF provider to get VM memory improvements by @gCyrille in https://github.com/vatesfr/pulumi-xenorchestra/pull/420 Full Changelog: https://github.com/vatesfr/pulumi-xenorchestra/compare/v2.1.0...v2.2.0 JavaScript/TypeScript: @vates/pulumi-xenorchestra Python: pulumi-xenorchestra Go: github.com/vatesfr/pulumi-xenorchestra/sdk .NET: Pulumi.Xenorchestra gCyrille opened this pull request in vatesfr/pulumi-xenorchestra closed feat: Update TF provider to get VM memory improvements #420