bufanda

bufanda

@stormi Tested the new edk package at looks good to me. was able to reboot linux and freebsd VMs without a hitch with UEFI boot mode.

bufanda

Installed on my usual lab pool. No issues so far seen.

bufanda

@gleh installed on my lab pool. Haven’t seen any issues so far.

bufanda

Updated my Lab pool consisting of 2 Nodes this morning
Rebooted master first, then slave. No issues VMs migrated between reboots.
Couldn't see any issue til now.

bufanda

Installed on my usual lab setup works fine so far although I have the "Fell back to full backup" message for qcow2 VMs

bufanda

Upgraded my usual pool. VM migrations during reboot worked without issues. So far everything works

bufanda

@stormi Installed on two node Pool. Both nodes are HP EliteDesk 800 G3 Miini. 10 Linux VMs with Secure Boot enabled and 1 Windows Server 2019 with SecureBoot and vTPM enabled. No issues. Migration between nodes worked flawlessly too.

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

bufanda

Installed on my Test pool with 2 HP EliteDesk 800 G3 mini. Except the no stats in XenOrchestra. Did some VM migragration between hosts, reboot testes (only Linux VMs though) and so far no issues.

bufanda

Upgraded my dev Pool

2 HP EliteDesk 800 G3 Mini
One with i5 6500T and one i7 6700T
Both 32GB RAM, SATA and NVMe Storage
1x Intel NIC
1x RTL8139 NIC

Updated Master first and then the second node. No issues so far.

bufanda

Updated my Lab Pool.
For the Test:

@lmolina said:

Reboot your VMs, starting with Linux VMs that use PCI passthrough (GPU, NVMe, NIC). The new HVM PIRQ default applies to every VM at its next boot. If you set platform:hvm-pirq on a VM yourself, that value is kept. Devices that worked before must still work, with similar performance and CPU usage. If one doesn't, check whether platform:hvm-pirq=true brings it back, and tell us.

-> No such VM on my Lab Pool, not tested

Run your usual Xen Orchestra backups (incremental with NBD, full) and a restore. Every NBD backup now goes through new code (tapdisk's NBD server, parallel requests), so they must complete, and shouldn't get slower.

-> ran a full backup job and an incremental backup job. No issues. No diffrences to previous backups.

Watch the disk performance of your busiest VMs, on VHD and QCOW2 SRs. The locking change in tapdisk applies to every VM disk, not only QCOW2.

-> Didn't notice any performance issues.

After running the snapshot_fixer.py script if necessary, take, revert to and delete snapshots, including on VMs with several disks, and check that the VMs and their disks are as expected afterwards. The fix changes how xapi handles VDIs during reverts and SR scans.

-> Performed test with 3 VMs, 1 with one disk, 2 with 2 discs. -> No issues seen.

bufanda

Installed on my usual lab pool. No issues so far seen.

bufanda

@gduperrey Installed on all pools. No issues so far.

bufanda

@gleh installed on my lab pool. Haven’t seen any issues so far.

bufanda

@gduperrey said:

Thank you everyone for your tests and your feedback!

The updates are live now: https://xcp-ng.org/blog/2026/08/18/august-2026-updates-1-for-xcp-ng-8-3-lts/

Installed on my prod pool and instantly got an SMART error. What a timing But other than that updates working withut issues.

bufanda

@gleh installed on my lab pool. So far no issues.

bufanda

Applied patches yesterday, No issue seen until today.

bufanda

@rzr Installed on my 2 node lab pool, so far no issues.

bufanda

@rzr Installed all currently available patches on my lab pool. No issue so far in normal use.

bufanda

@rzr Installed on my usual lab pool. No immediate issues seen.

bufanda

@bufanda