@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

@planedrop I was getting a lot of NBD errors as well. so I'm not positive on if it was fully just ignoring the concurrency, or just moving onto next backup because of nbd communication error then just leaving the previous backups under active attempt. Either way, there's a bug if it leaves backup 'active' and then starts another one beyond set concurrent limit.

@olivierlambert

@florent already jumped in on our case and submitted a fix for "_removeUnusedSnapshots don t handle vdi related to multiple VMs" that we were seeing.
We have a vdi that won't coalesce, so I need to reopen that case. I think this above error was triggered from this angry vdi and my previous attempt to fix it.

It was also noted that 5.107 was ignoring our backup setting for concurrent backups and was running all 24vms at once instead of the 3 we had set. Reverting to 5.106.4 resolved this. Waiting for an update on what's broken in 5.107 to ignore this setting. Different timezone so assume I'll hear tonight.

I'm on 8.3 as well and fully updated with latest patches

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

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

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