XCP-ng 8.3 updates announcements and testing

dthenot

There is equivalent sm packages in the qcow2 repo for testing, XAPI will be coming soon.
You can update while enabling the QCOW2 repo to get the sm and blktap QCOW2 version and get the XAPI version letter if you want.

bufanda

@dthenot No worries, just wanted to make sure I understand the expected behavior when I had the qcow2 patches installed.

dthenot

@bufanda You just need to make sure to have a sm and blktap qcow2 version.
Otherwise, having a normal sm version would drop the QCOW2 VDI from the XAPI database and you would lose VBD to VM aswell as name of VDI.
So it could be painful depending on how much you have
But in the case, you would install a non QCOW2 sm version, you would only lose the QCOW2 from DB, those would not be deleted or anything. Reinstalling a QCOW2 version then rescanning the SR would make them re-appear. But then you would have to identify them again (lost name-label) and relink them to VM.
We try to keep our QCOW2 version on top of the testing branch of XCP-ng but we could miss it

bufanda

@dthenot Only have 2 Test VMs currently not running with qcow2. Nothing production and nothing crucial. It's a lab pool. As I said just to understand the behavior when I test the new updates. But thanks for the details. Really appreciated

JeffBerntsen

Installed and working on my lab test machine, HP ProLiant DL165 G7 with AMD Opteron 6136 CPU and 32 GB of RAM.

Andrew

@gduperrey Installed and running on a few hosts. Good so far.

gduperrey

Updates published: https://xcp-ng.org/blog/2025/07/03/july-2025-security-and-maintenance-update-for-xcp-ng-8-3-lts/

Thank you for the tests!

gb.123

Sorry to join the bandwagon late this time, but i got these errors while booting:

[    0.826901] ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.GPP2.WWAN], AE_NOT_FOUND (20180810/dswload2-160)
[    0.826908] ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20180810/psobject-221)
[    0.826910] ACPI Error: Ignore error and continue table load (20180810/psobject-604)
[    0.826912] ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-543)
[    0.827236] ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.GPP2.WWAN], AE_NOT_FOUND (20180810/dswload2-160)
[    0.827239] ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20180810/psobject-221)
[    0.827241] ACPI Error: Ignore error and continue table load (20180810/psobject-604)
[    0.827242] ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-543)
[    0.827245] ACPI BIOS Error (bug): Failure creating [\_SB.PCI0.GPP5.EWPM], AE_ALREADY_EXISTS (20180810/dswload2-316)
[    0.827248] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-221)
[    0.827250] ACPI BIOS Error (bug): Failure creating [\_SB.PCI0.GPP5._PRW], AE_ALREADY_EXISTS (20180810/dswload2-316)
[    0.827252] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-221)
[    0.827254] ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-543)
[    0.827257] ACPI BIOS Error (bug): Failure creating [\_SB.PCI0.GPP5.RTL8._S0W], AE_ALREADY_EXISTS (20180810/dswload2-316)
[    0.827259] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-221)

I think this is after the new update

Processor : AMD Ryzen 7 7840HS

olivierlambert

Hi,

It's just an ACPI error, it shouldn't be a problem.

gb.123

@olivierlambert

I agree. But just thought I should report nevertheless.

Update: This seems to be related to 7840HS motherboard. I tried it on another AMD Ryzen 7945HX but did not get this error.

olivierlambert

It's clearly due to the motherboard, yes. Mostly buggy BIOS/UEFI and ACPI tables. This world is like the far west.

gb.123

@olivierlambert @stormi

Another bug I encountered ( I don't know if this is to be mentioned here or whether I should open this as an issue in github )
Also, this bug may be present in previous versions as the current version is the one I have first tried this on:

Here is the summary:

If USB Keyboard & Mouse is passed-through along-with GPU:
The GPU gets stuck in D3 state (on Shutdown/Restart of VM) (Classic GPU reset problem)

If no vUSB is passed but GPU is passed through:
The GPU works correctly and resets correctly (on Shutdown/Restart of VM)

I will try the workaround of passing the whole usb controller to see how it goes; but in my use case that may not be possible for regular usage (I'll just be doing this for testing only)

Update :
When I run :

$> lspci
Extract of Output (Partial):

07:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15b8

However, this controller does not show up when I run :
xe pci-list

Is it a bug that lspci & xe pci-list have different number of devices ?

How can I pass this controller since xe pci-list does not show it so I can't get the UUID ?
Will kernel parameters (like XCP-ng 8.2) work in this case ?

Is it safe to run on XCP-ng host ?

 echo 1 > /sys/bus/pci/rescan

(I'm trying to find a way where the PCI card is reset by the host without complete reboot, though I am aware that the above command will not reset it.)

Also is it advisable to use :

xl pci-assignable-add 07:00.0

in XCP-ng 8.3 ? or is this method deprecated ?

olivierlambert

Question for @TeddyAstie maybe

TeddyAstie

@gb.123 said in XCP-ng 8.3 updates announcements and testing:

Here is the summary:

If USB Keyboard & Mouse is passed-through along-with GPU:
The GPU gets stuck in D3 state (on Shutdown/Restart of VM) (Classic GPU reset problem)

If no vUSB is passed but GPU is passed through:
The GPU works correctly and resets correctly (on Shutdown/Restart of VM)

I have no clue what vUSB may change regarding GPU passthrough.

When I run :

$> lspci
Extract of Output (Partial):
07:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15b8
However, this controller does not show up when I run :
xe pci-list

Is it a bug that lspci & xe pci-list have different number of devices ?

How can I pass this controller since xe pci-list does not show it so I can't get the UUID ?
Will kernel parameters (like XCP-ng 8.2) work in this case ?

Question for @Team-XAPI-Network regarding the filtering on PCI IDs.
I don't think XAPI allows using arbitrary BDF, but I may be wrong.

Is it safe to run on XCP-ng host ?
 echo 1 > /sys/bus/pci/rescan
(I'm trying to find a way where the PCI card is reset by the host without complete reboot, though I am aware that the above command will not reset it.)

Probably. But it's not going to change anything as the device doesn't completely leave the Dom0 when passed-through.
FYI a function-level-reset is systematically performed by Xen when doing PCI passthrough, thus your device should be reset before entering another guest (aside reset bugs like you may have).

Also is it advisable to use :
xl pci-assignable-add 07:00.0
in XCP-ng 8.3 ? or is this method deprecated ?

I don't think XAPI supports this PCI passthrough approach.
This is a command which allows dynamically to remove a device from Dom0 and put it into "quarantine domain", so that it will be ready to passthrough it.

Current XAPI uses the approach of having a set of "passthrough-able" devices at boot time by modifying the xen-pciback.hide kernel parameter, which does the same but at boot time.