@stormi Microcode updated on affected Gen11 i7. Running normally.

@gduperrey I jumped in all the way by mistake... I updated a wrong host, so I just did them all. Older AMD, Intel E3/E5, NUC11, etc. So far, so good. Add/migrate/backup/etc VMs are working as usual. Good for guest tools too, but mine are mostly Debian 7-11. Stuff is as usual so far.

I agree and I'll say it again, Thanks! It's not just Linux/Xen stuff. It is XCP-ng and XO that make everything work as a cohesive vertical open-source solution (some nice buzz words). Thanks to the Vates team and community that have built and support it. I look forward to ongoing continuous improvement and innovation!

@bleader Installed and running.

@bleader Updates running on several old and new intel machines (including microcode update). Working fine so far. Rolling Pool Reboot is a helpful feature.

@bleader I installed it on a bunch of busy hosts. All are fine, but none used PCI passthrough. The Rolling Pool Reboot in XO was very helpful.

@dinhngtu On a quick test, the ISO boots and installs. When the VM boots from the HD it crashes (and on reboots).

Updating XCP 8.3 with qemu-4.2.1-5.2.12.2~fixvwc1.1.xcpng8.3.x86_64 solves the issue and the installed windows image boots correctly without any additional changes.

@abudef @olivierlambert @thomas-dkmt I agree. I read block the same way... how about disable or prevent. (French? empêcher)

@julien-f @olivierlambert

Thanks for the ability to delete XO task logs feature! (XO commit f6e6e)

@gduperrey Installed and running on Intel systems, and Zen3 system that sees the microcode update.

@kagbasi-ngc Alma Linux 10 release notes related to older v2 CPUs.

Try a x86_64_v2 boot ISO

@stormi Update (to the update) installed and running. Buggy Windows 2025 boots now with QEMU update.

@stormi Pool source SR is NFS. Destination has local EXT4. It's only around 70 VMs.

@stormi After pool update, XO Continuous Replication times dropped by 50%. Before, the hourly CR took about 14-15 minutes, after the update it takes about 7-8 minutes now. Most of the CR time is spent on setup of the VM for transfer, not the actual data transfer bandwidth. Normal delta backup times did not change (data transfer limited). No change/update in XO/hardware/network, just this XCP update.

@dinhngtu Correct! I was in /etc/ which has a default directory.

@stormi Running.... but...

#  secureboot-certs install
Traceback (most recent call last):
  File "/usr/sbin/secureboot-certs", line 770, in <module>
    install(session, args)
  File "/usr/sbin/secureboot-certs", line 313, in install
    validate_args(args)
  File "/usr/sbin/secureboot-certs", line 288, in validate_args
    if os.path.exists(args.PK) and not is_auth(args.PK) and not getattr(args, "pk_priv", False):
  File "/usr/sbin/secureboot-certs", line 381, in is_auth
    with open(path, "rb") as f:
IOError: [Errno 21] Is a directory: 'default'

Also, can this update also include the fixvwc qemu Windows crash fix?

@dinhngtu Same results with the updated qemu-4.2.1-5.2.12.2~fixvwc2.1.xcpng8.3.x86_64. The Win2025 VM (without Xen tools) fails to boot correctly using stock XCP 8.3 but starts correctly with the fixvwc patch. (no actual performance or other testing done).

@dinhngtu On a quick test, the ISO boots and installs. When the VM boots from the HD it crashes (and on reboots).

Updating XCP 8.3 with qemu-4.2.1-5.2.12.2~fixvwc1.1.xcpng8.3.x86_64 solves the issue and the installed windows image boots correctly without any additional changes.

@olivierlambert @McHenry I have a similar setup... 5 host main pool (N+2) with TrueNAS NFS and a single on-site CR host (stand alone with local RAID storage) that is updated hourly from the main pool. There is also an on-site backup (for quick restore) and an off-site backup to wasabi S3 (nightly).

While CR is not a traditional backup it does allow for a quick restart of a damaged or lost VM. As my CR host is on-site it can share the same network and I can just start a VM immediately and then copy it back to the main pool. The CR also acts a secondary pool where some import redundant VMs run (ie DNS, another XO, etc). These secondary VMs are CR backed up to the main pool. If the main pool were to totally fail then VMs could be started on the CR host (with restricted resources).

S3 backups allow for a long term incremental historical storage but it takes longer to restore a large VM (but you can pick a point in time to restore from).

CR off-site is great DR option, but remember CR is not a true backup, it's just a recent copy...

@flakpyro I see the same issue.