XCP-ng 8.3 public alpha 🚀
-
@Louis what's the issue with 8.2.1? It's an LTS, so it's normal to use mature versions of Xen and such. It's not a contest on getting latest versions, especially since XCP-ng is very stable. What do you want to achieve?
-
The latest versions tend to have fixes, security updates and probably added features. For those reasons I always prefer to use the latest versions the more at the moment I start a new system.
So, I am not saying 8.2 is bad / not ok, but on the other hand I am surprised to see that 8.2.1 is over a year old. And at the same time I note that there is a xen-server release november 2022.
I assume that XCP-ng is based on xen-server. But on which version !??
Of course there have been security updates, but never the less. But I have no idea what has changed since the original 8.2.1 release. As far as I am aware there is no change log.
-
The latest versions tend to have fixes, security updates
Not true. All security fixes are backported. Do you really think we'll leave an LTS version of XCP-ng without any security fix since 2020?
Probably added features
Which features in Xen 4.17 you need you don't have in 4.13?
I am surprised to see that 8.2.1 is over a year old
This is not a toy project but a serious distro meant to run in a stable fashion in datacenters, at scale. Especially as an LTS version, that is expect to be maintained between 5 and 10 years.
I assume that XCP-ng is based on xen-server. But on which version !??
It's XenServer. Take a guess, XCP-ng 8.2 is based on which XenServer edition?
Of course there have been security updates, but never the less.
Never the less? That's the most important thing, to backport the sec patches.
As far as I am aware there is no change log.
You should really look at the documentation. Each XCP-ng release is covered by a change log, and each update is also documented with at least a dedicated blog post. You can start here: https://docs.xcp-ng.org/releases/ (to read what's an LTS and why we don't add features in an LTS) and there: https://xcp-ng.org/blog/ for all the blog posts on our almost monthly updates.
-
Yep I agree that security fixes are the most important ones. And I know that security patches are provided (as I wrote in my mail).
Since I am new to XCP-ng, and I did not study the changes related to 8.3, I do not know the improvements, but I assume there are!
-
As I said previously, you should really take a look at the doc and the blog...
https://xcp-ng.org/blog/2022/11/18/xcp-ng-8-3-alpha/
And posted very recently: https://xcp-ng.org/blog/2023/02/27/news-about-8-3-alpha/
-
Olivier thanks for the links. But it only confirms my idea that I should go for the latest releases as far as possible!
- IPV6 support is important to me (should work!)
- all security fixes (not only the most important ones)
- better hardware support ( I do have e.g. 2.5 g interfaces)
- newer python
- better update management
-
You should really start to work on 8.2 LTS first and see what you really need in real life. If it's not enterprise production, then go for 8.3.
-
-
Summary: upgrade from 8.3alpha to 8.3alpha2 broke my installation.
Yesterday I tried to upgrade my Intel NUC11 from the original 8.3alpha (very stable so far) to the 8.3alpha2.
The upgrade process concluded without errors, however upon restart while the host was accessible via SSH, all the rest disappeared (no XOALite, no VM and obviously no XOA).
I tried to list the vm with "xe vm-list" resulting in "Error: Connection refused (calling connect)". Then I tried to restart with "xe-toolstack-restart" but without success.
Right now using the installer I reverted to previous installation... indeed a useful function
Your insights is welcome, I can make any test you might be interested in.
Thanks
-
Hi There,
Just to mention, my personal hopes are for the future, that whatever kernel will be used, RPM packages will still be supported to install.Usecase:
I am using Dell / Quest DR-Appliances for Backups. They've implemented RapidCIFS and RapidNFS in order to do kind of CBT enhancement on these protocols. So when backing up - only delta is copied.However, as usual, they provide this driver officially only for Windows and RHEL. Therefore I could install the RPM on the XCP-Hosts, and benefit from this. It's running amazingliy smooth.
I would assume that there might be more of such use cases, and keeping support for RHEL packages could be wise in oder to keep a foot into the "enterprise door".
Thanks, for your work!
Regards,
RaHu -
Thanks for your feedback @RaHu
-
-
Thank you, appreciated
I followed - maybe bluntly - this reassuring sentence but I guess it meant from 8.2!
-
@rRobbie Yes, it meant from 8.2
-
@gskger Thanks! For shorter logs, could you run
./xtf-runner -aqq --hostrather than./xtf-runner -aq --hostin the future? We don't need the full list of successful tests. Only skipped and failed ones. -
@stormi Of course! Picked up that habit from other posts. Should I correct my post to improve readability?
-
@gskger No, only future ones
-
root@lenovo150 -------------- OS: XCP-ng release 8.2.1 (xenenterprise) x86_64 Host: ThinkServer TS150 70LUS00C00 Kernel: 4.19.0+1 Uptime: 7 mins Packages: 551 (rpm) Shell: bash 4.2.46 Terminal: /dev/pts/13 CPU: Intel Xeon E3-1275 v5 (8) @ 3.600GHz GPU: Intel HD Graphics P530 Memory: 560MiB / 2498MiBnote: only on 8.2.1 because I don't feel like even potentially breaking anything right now out of sheer laziness but its been rock solid so far
[19:51 lenovo150 xtf]# ./xtf-runner selftest -q --host Combined test results: test-hvm32-selftest SUCCESS test-hvm32pae-selftest SUCCESS test-hvm32pse-selftest SUCCESS test-hvm64-selftest SUCCESS test-pv64-selftest SUCCESSand
[19:52 lenovo150 xtf]# ./xtf-runner -aqq --host Combined test results: test-hvm32-umip SKIP test-hvm64-umip SKIP test-pv64-xsa-167 SKIP test-pv64-xsa-182 SKIPand of course
[20:00 lenovo150 ~]# /usr/libexec/xen/bin/test-cpu-policy CPU Policy unit tests Testing CPU vendor identification: Testing CPUID serialise success: Testing CPUID deserialise failure: Testing CPUID out-of-range clearing: Testing MSR serialise success: Testing MSR deserialise failure: Testing policy compatibility success: Testing policy compatibility failure: -
I have a minor feature request…
Can we get the xen-cmdline (/opt/xensource/libexec/xen-cmdline) added to the default PATH? I don’t use it too often but having it would save me a google remembering? I’ve also added to my bashrc with the name xcl. -
@stormi
Probably more a fun test than a real world test. I installed XCP-ng 8.3 alpha2 run on aHP T620 PLUS Thin Client
AMD GX-420CA @ 2GHz low power APU SoC (Jaguar)
16 GB RAMAccording to Art of Server on Youtube, this Thin Client supports up to 32GB RAM. It idles around 14-17W with XCP-ng and one Debian VM running. It also features a low profile PCI-e slot that I use with a Intel Pro / 1000 PT quad port LP card.
[21:58 xcp83 xtf]# ./xtf-runner selftest -q --host Combined test results: test-hvm32-selftest SUCCESS test-hvm32pae-selftest SUCCESS test-hvm32pse-selftest SUCCESS test-hvm64-selftest SUCCESS test-pv64-selftest SUCCESS[21:58 xcp83 xtf]# ./xtf-runner -aqq --host Combined test results: test-pv64-cpuid-faulting SKIP test-pv64-pv-fsgsbase SKIP test-hvm32-umip SKIP test-hvm64-umip SKIP test-pv64-xsa-167 SKIP test-pv64-xsa-182 SKIP [21:59 xcp83 xtf]# echo $? 3[21:59 xcp83 xtf]# /usr/libexec/xen/bin/test-cpu-policy CPU Policy unit tests Testing CPU vendor identification: Testing CPUID serialise success: Testing CPUID deserialise failure: Testing CPUID out-of-range clearing: Testing MSR serialise success: Testing MSR deserialise failure: Testing policy compatibility success: Testing policy compatibility failure: Done: all ok [22:00 xcp83 xtf]# echo $? 0
