@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

@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"

@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

@mnv said in XCP-NG 9, Dom0 considerations:

@olivierlambert said in XCP-NG 9, Dom0 considerations:

@mnv For local SR, just use Local ext SR type and you will be thin already.

Hi Olivier,

Sorry for my late reply.

Yes, I am aware of that, however using LVM (like using ZVOL) would offer the disk as a block device directly, thin ext4 ought to be ext4 + the virtual disk + the VM filesystem, ZVOL/LVM should be block device + VM filesystem. There seems to be way less overhead.

ZVOL doesn't play nice with all SSDs, not mines for sure, LVM Thin seems to play much better, write less and take longer to have the same wear as ext4-thin or ZVOL.

I understand this isn't a problem in an Enterprise environment, though...

Larger issue is the existing block storage code is thick only, so rolls across to local lvm, HBA and iscsi. And fiber channel/SAS multipath HBA and iscsi are what are more commonly used in many enterprises, blocking many from migrating from competing products.
LVM has supported thin provisioning since release 2.02.89 back in 2012, with redhat 6.4 I believe.
This should also solve the initial vhd sparse file growth write performance penalty

@mnv said in XCP-NG 9, Dom0 considerations:

Thanks for your heads up, Olivier, and I hope your internal tests and developements go in the best direction! I can't wait for the next big thing! Only thing I could hope for that is missing (AFAIK) in XCP-NG 8.x is support for LVM Thin storage, that's so good when you have crappy consumer SSDs...

I've actually been puttering with LVM thin patches for awhile as it's always bothered me that we didn't have. I think I finally have my head around the code. , but I'm sure I'm missing something obvious that will be pointed out when I submit.
It's been a very-very-very-side project.

@steff22 said in Gpu passthrough on Asrock rack B650D4U3-2L2Q will not work:

@ravenet Ok I think the pro gpu's work better without so many bugs.

I switched to Nvidia RTX 4070. With the Nvidia gpu and this works as it should and gets an image on the screen on the first try.

So there must be something wrong with the amd drivers plus that error with the amd reset bug

I've setup a test system with a ryzen 7700x and a regular radeon 7600xt, non-pro gpu. Will let you know results. Shouldn't be an issue, it's same hardware and even the drivers work across them. Though they do have different bios on cards

@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

@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.

@steff22
Far as I know, SVM, IOMMU, SR-IOV and POSSIBLY resize bar were enabled.
Can't check the threadripper system until the weekend as it runs production loads.

I'll reboot one of the Ryzen boxes tonight to verify what I enabled there, but was basically defaults other than making sure the 3 or 4 items above were enabled.

I have gpu pcie passthrough working on Asrock rack wrx80d8-2t (Threadripper), and x470d4u2 (Ryzen) to passthrough multiple Radeon Pro 7000 series gpus

Rodney

@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

@Andrew Yes 8.3 will be xen 4.17. They've stated that this will be moved out of lab into the 8.3 official branch once they are happy with their and our feedback.