I had this tab still open which lets me realize that despite we packaged vmfs6-tools and updated the documentation at https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/#local-migration-same-host, we didn't inform you here. Now it's done

Hello everyone, I absolutely understand the point regarding datacenters. I am using xcp-ng for years in smaller - non datacenter - environments and its great. Therefore I added the nut packages (8.2 and 8.3) and it works like a charm. It's installation is well explained in: https://xcp-ng.org/forum/topic/4300/performing-automated-shutdown-during-a-power-failure-using-a-usb-ups-with-nut-xcp-ng-8-2/13?_=1742229073030 However, I agree with @Kajetan321 that it would be great if the nut package could be included in the standard "updated" packages repo since its added quite some benefits (imho) for "smaller" IT environments. However, I do not know how much effort it takes to maintain that.

I have not had time to work on this, and my lab changed significantly, had to spend a bunch of money to move it to a new rack and that rack has been disconnected for months so no real work in XCP or vSphere and learning to migrate VMs from vSphere to XCP which was one of my big intentions. But a recent post confirms that this "oddity" of trying to create a UEFI VM from XO-lite is still present. I'd bet money that this gets fixed before or when the full release is provided. https://xcp-ng.org/forum/topic/11227/boot-new-vm-to-iso-in-xo-lite Workaround is to either click the button provided to download XOA, or install Linux and XO from sources in BIOS mode. Then you have the full XO to work with to bring everything else up the way you want it. I see it as a minor annoyance right now, not really a bug or problem.

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

I worked with ChatGPT on this for a bit. We have narrowed it down to an issue with the NFS Storage that I ship the backups to. "When you recreated storage and moved data back, OMV is technically exporting a different underlying filesystem object than before. NFS clients that had an old handle cached (your XCP-ng host) try to access it and get ESTALE. That explains the initial backup errors and why deleting/re-adding the SR is failing now." I had to remove the NFS storage from XCP-ng, then delete the NFS share from OMV, then add the NFS share back to OMV, and then add it back to XCP-ng. I probably could have resolved this with a reboot, but I didn't wanna. This issue is resolved now.

Fix committed upstream.