We are very well aware about all of this. But we are not a distro entirely based on RHEL at all (again, all the network, kernel, storage and compute plus many other things are NOT coming from RHEL).
On a personal point of view, I'm a strong proponent of Copyleft licenses and the greater good, in the original spirit of free software. To me, there's a real moral contract between the software editors and the users. You can read my detailed opinion in this blog post: https://virtualize.sh/blog/the-moral-contract/
Due to those personal opinions, I'm really unhappy with RedHat move (and behind Alma and Rocky), but this is NOT clashing with our position for the next major release. So no, we won't be directly disrupted by this move.
Thanks for all the feedback already provided here, and see you on this new thread!
In order not to miss anything (and, let's be honest, for me to be sure that messages on the new thread reach you all), the best course of action is: open the new thread right now and use the "watch" button.
And let's answer this common and legitimate question: how to upgrade from alpha to beta ? Well, there's nothing to do, just update as usual. In fact, you might already be in beta state. However, as indicated in the blog post, we need a lot of testing of the installer, so it's also an option to start from the installation ISO again.
CentOS 7 will continue to be supported with patches and so on up to June the 30th 2024, so it's not really a priority as we speak. But I'm sure the topic will be discussed during the next Xen summit in June 🙂
Better not install security patches that require a reboot without rebooting. All you create is a discrepancy between what resides in memory and what is on disk, and in rare cases things may break, for no added security.
Isn't this only true with specific patches? I'm no expert here so really just curious. Regardless I ALWAYS plan to reboot with ANY patches coming out and think others should do the same.
We want to provide better metadata associated with updates, for XO to display. This is not ready yet, so for the time being, check the instructions for each update on the official blog. The update tag will list only update announcement: https://xcp-ng.org/blog/tag/update/
I've set up a test-environment and indeed it worked. Commvault was (is?) checking for specific version/agent string when connecting to XS/CHV/XCP-ng and in older versions refused to connect to XCP-ng.
I successfully installed the agent on a proxy-vm (it uses a proxy to ro-mount the VM-VHDs and backup the content), connected the pool, delivered the VM-inventory and also ran a successful backup:
In other words: If you're using Commvault (11.28+) you're not any longer locked on Citrix.
Don't get me wrong: constructive feedback is ALWAYS welcome 🙂
This is just the pricing "cards", but there's already the information that you have initial setup assistance, upgrade help and direct access to XCP-ng devs. Sounds more than just "send us an email when you need". What would you have wrote then?
Also, regarding not paying the project but hire people to contribute on it: I'm very fine with it!