@gduperrey
Tested on 4 systems in production

Ryzen 1700x, on asrock rack mb w radeon pro GPU pass through
Threadripper 5975wx on asrock rack mb w radeon pro GPU pass through
Epyc 9224 on Asus
Epyc 7313P on Asus

@gduperrey

Tested on Multiple systems. Ryzen 1700x andThreadripper 5975. fine so far

So far fine on an epyc 7002 and a xeon e5 v3

SLES 12.5 (usual warnings of sles12 xe-guest-utilities-xenstore conflicts with SUSE xen-tools)
IP addresses reporting : OK
Management agent detected : OK
Clean shutdown/reboot : OK

SLES 15.1 seems fine
IP addresses reporting : OK
Management agent detected : OK
Clean shutdown/reboot : OK

OpenSUSE LEAP 15.2 - Failed to determine Linux distribution and version

@dthenot said in XCP-ng 8.3 updates announcements and testing:

For people testing the QCOW2 preview, please be informed that you need to update with the QCOW2 repo enabled, if you install the new non QCOW2 version, you risk QCOW2 VDI being dropped from XAPI database until you have installed it and re-scanned the SR.
Dropping from XAPI means losing name-label, description and worse, the links to a VM for these VDI.
There should be a blktap, sm and sm-fairlock update of the same version as above in the QCOW2 repo.

If you have correctly added the QCOW2 repo linked here: https://xcp-ng.org/forum/post/90287

You can update like this:

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-qcow2
yum update --enablerepo=xcp-ng-testing,xcp-ng-qcow2
reboot

Versions:

• blktap: 3.55.4-1.1.0.qcow2.1.xcpng8.3
• sm: 3.2.12-3.1.0.qcow2.1.xcpng8.3

So far so good on Ryzen 1700x host.

@Andrew said in XCP-ng 8.3 beta :

@ravenet I did not have any problems with my Mellanox Connect-4 Lx card during upgrades from 8.2.1 (5.0 driver), to 8.3 (5.4 driver), then update to current 8.3 (5.9 driver), and then update to Xen 4.17.3. My card has the 14.32.1010 firmware. It is not used for the management interface. It is used by VMs and continued to keep the same ethernet name and function for the VMs.

Thanks for testing

I finally got around to updating the firmware on this Mellanox connectx-4 LX adapter. Bit of jumping through hoops to install tools, find proper firmware, but went from FW version14.18.1000 to New FW version: 14.32.1010. Had to do an emergency network reset again, but it's back.

Obviously an incompatibility with the new 5.9 driver with much older mellanox firmware.

@stormi No issues so far on Ryzen 1700x, Xeon e5-2640v3, and 2 Epyc 7313P systems

@gduperrey Seems fine here as well under basic usage.

@JustinTimperio I can test SLES for you, I'm a SUSE partner so have access. Here's output from a sles11.4,12.4, 12.5, 15 and 15.1. Sorry don't have a sles15.2 spun up (only leap15.2) but easy enough to extrapolate.
Best way to get stuff into their official distro is to have it build on OBS

NAME="SLES"
VERSION="11.4"
VERSION_ID="11.4"
PRETTY_NAME="SUSE Linux Enterprise Server 11 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:11:4"

NAME="SLES"
VERSION="12-SP4"
VERSION_ID="12.4"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:12:sp4"

NAME="SLES"
VERSION="12-SP5"
VERSION_ID="12.5"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP5"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:12:sp5"

NAME="SLES"
VERSION="15"
VERSION_ID="15"
PRETTY_NAME="SUSE Linux Enterprise Server 15"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15"

NAME="SLES"
VERSION="15-SP1"
VERSION_ID="15.1"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP1"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp1"

I was seeing similar broken backups in 5.107. Reverting to 5.106.4 seems to have resolved so far. Have a case open with logs submitted

@steff22

I have a Radeon Pro W7500 working fine on Win11 vm, on xcp 8.3. Windows update even installed the pro series driver for me.
Asrock rack x470d4u, Ryzen 1700x.
I know it's older platform and agesa though. I may have access to a ryzen 7700x system for some testing next week.

@stormi
Updated ryzen 1700 late last week, and Threadripper 5975 and Epyc 7313p servers. No issues so far.
Installing fresh on epyc 9224 this week

Testing now on ryzen 1700.

@stormi
Here's a Ryzen 1700 on Asus TUF B550

Combined test results:
test-hvm32-selftest                      SUCCESS
test-hvm32pae-selftest                   SUCCESS
test-hvm32pse-selftest                   SUCCESS
test-hvm64-selftest                      SUCCESS
test-pv64-selftest                       SUCCESS
Combined test results:
test-pv64-cpuid-faulting                 SKIP
test-hvm32-umip                          SKIP
test-hvm64-umip                          SKIP
test-pv64-xsa-167                        SKIP
test-pv64-xsa-182                        SKIP
3

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
0

Reminder, Centos 7 EOL 1 year away

https://www.phoronix.com/news/CentOS-EOL-2023-7-Stream-8

I see movement in the github repo again. Good sign!

@olivierlambert @ronan-a Has there been any update on this development? I do see an update to master in org.xen.xapi.storage.raw-device from feb 2020. is it more safe to test now?

@parallax I'd assume so. You'd just have that combustion iso provided as a disk image with each to provide the initial setup. I've not looked at custom template creation in XO

Otherwise you'd be looking at pxe and tftp, or better, use opensuse build services with kiwiNG to customize your own appliance with preconfigured settings etc.

Provide combustion via an iso mounted. Idea behind combustion/ignition is a usb plugged in, or pass through a usb if you already created one.

follow instructions on building the combustion file, drop in a folder named combustion. use whatever tool you want to move this folder into an iso, and label the iso itself combustion. Basically same steps as creating the combustion usb.

https://en.opensuse.org/SDB:K3s_cluster_deployment_on_MicroOS

@nasheayahu
You can script mount and umount commands as part of jobs or as part of backup jobs.