XCP-ng 8.3 public alpha π
-
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 --host
rather than./xtf-runner -aq --host
in 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 / 2498MiB
note: 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 SUCCESS
and
[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 SKIP
and 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
-
Haha that's an interesting little machine, indeed
-
Hello, here my test of version 8.3 in the last weeks:
I tried to put everything I could think of in or on the machine. Different hardware and different versions of Windows and Linux, backup of XO, with and without Xen tools, etc.
So far no crashes or major problems, even if I drove the machine to the limits of its resilience, everything runs smoothly and for days, for this a thumbs up.Hardware:
Dell Poweredge 730, CPU 2x E5-2698 V4, 512GB RAM
2 x Intel I350 1Gb adapters
2 x Intel X540-AT2 10Gb adapters
1 x Dell H730P mono Raid Controller (5 x 8TB Disk in Raid5)
2 x SSD in Raid 1 as Boot Drive
1 x PCie NVMe Adapter (4 x 2TB NVMe Disk in Softraid 5)
( Yummi, over 1 GByte/sec write speed in a VM with 2 TB of Data)
1x Nvidia K80 GPU cardThis is without a doubt the biggest test machine I've ever had.
I have tested so far:
All standard functions (Copy, Move, Migrate, Snapshot etc.)
Use of GPU (Windows VM)
PCI passthrough (Windows, Linux - NetCard, USB, PCI card)
SR-IOV (see comments below)
Backup with XO
Heavy network load (copy 26TB of data via 10 GB netcard)
Heavy CPU and GPU load (8 VM with CPU at maximum for hours)
Fast copying of large data between the different SRs in the system.With the exception of the SR-IOV, no problems were encountered and the performance was excellent in all respects.
What made me very happy was the installation of Xen-Tools under Windows 2022. I have often had the experience that after a Windows update the server no longer wanted to start due to a driver update. The problem seems to have disappeared completely, all drivers were installed automatically when the server was installed and have so far survived all updates from Microsoft without any problems. I only had to manually add the management agent.
SR IOV:
The two Intel I350 1Gb adapters no longer show up as SR-IOV adapters and have lost that functionality. They still worked under 8.2.
The Intel X540-AT2 adapters have the SR-IOV function. But when I use it, the adapter port shuts down after a short time. The Xen server still shows the card as connectet, but the network function is gone. The coupled switch shows the port as deactivated. In between, the network function is there again for a short time and the switch also shows this. The second 10 GB port runs error-free all the time. If I switch off the SR-IOV of the port, it works without any problems. Both as a normal Xen-Nic and in PCI passthrough. I copied TByte over the port, no errors.
It must be somehow due to the SR-IOV that apparently no longer works under 8.3.
I would be interested to know if others have experienced something similar or if everything works there.I would like to test the "VM snapshot with disk exclusion" but somehow I can't do it. Both the snapshot and the XO always back up the entire VM with all disks. I'm sure it's error 50 (50cm in front of the keyboard) . Is there a detailed description of how to set it up somewhere?
Unfortunately I haven't been able to test any pool functions yet, so I have to set up a second machine for that. I can't get a second machine that size. I will probably have to build 2 smaller systems with shared storage and test them there.
If anyone thinks of anything else I could test, let me know
So far everything looks very good, you did a great job.
Greetings Joerg
-
Thanks @jhansen for all your test work done on this alpha release!
- SR IOV: that's interesting, we will probably get that feedback to XS team too, I wonder why it's broken
- VM snap disk exclusion: that should be straight forward, but I'll try to see if I can reproduce it myself.
Thanks again!
-
@olivierlambert said in XCP-ng 8.3 public alpha :
snap disk exclusion
Thank you too.
I use the SR-IOV under 8.2 and it work there on the same netcard. I don't think these are suddenly broken.A description for the snap disk exclusion would be great, I hate error 50
-
In theory
[NOBAK]
in the disk name should be enough but I didn't test it myself -
@olivierlambert
Hmmm. Tried rename the Disk "SRV-File-Debian-10.10" in "[NOBAK] SRV-File-Debian-10.10"
It does not work! -
Okay thanks, I'll take a look in my home lab and see if I can reproduce
-
@jhansen About the disk excluded: I can confirm it's not a PEBKAC. At least, not you or myself, since I can reproduce the problem. I can't find anything in XO code base despite we announced it, so maybe the issue is a PEBKAC elsewhere in the XO team I'll keep you posted!
-
@ajpri1998 said in XCP-ng 8.3 public alpha :
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.I would rather have it symlinked from /usr/sbin or such rather than altering the default PATH. However, it's minor enough for now for me not to want to diverge from XenServer on this, so ideally we should try to push this change upstream. Unfortunately, this is a packaging matter and it's not the most open part of XenServer, so contributing there is hard. Not impossible, but requiring efforts that may be above the gain, here.
If you want, you could still open an enhancement request on XCP-ng's bugtracker. Maybe others will join you and at some point maybe the gain will be bigger than the effort
Sorry, sometimes we must be lazy to keep time for bigger topics.