@gduperrey Rolling pool update worked with released production patches.

Depends which one you mean, because there are two different problems tangled together in this stretch of the thread and they have opposite answers. If you mean @escape222's report at #177, where a VM cloned from XO 6 sits at the TianoCore screen for a couple of minutes, then yes, that was an XO bug and it is fixed. PR #9867, merged 26 May, shipped in XO 6.5.0 on 28 May. The boot order was being rewritten whenever no new disk needed provisioning, so an HVM VM created from a template that already had a disk got network pushed to the front whether or not anyone asked for a network install, and the VM burned the PXE timeout before falling through to the disk. It now follows the install method only. Since you are on sources, anything past 6.5.0 has it. If you mean the slow UEFI boot @MajorP93 described at #182, with the installing Xen timer and spinlock lines, that one is not an XO bug and no XO patch will touch it. It is a regression in the Linux guest kernel introduced in 6.12.5. The cost lands per secondary vCPU, so the wider the VM, the worse it looks. There is a separate thread with the per-vCPU numbers: Ubuntu cloud images on XCP-ng 8.3 UEFI. Worth noting its title blames console=ttyS0, which we now think amplifies the same bug rather than being a second one. I measured that one here this week on a single host, changing only the guest kernel between runs and leaving everything else alone. Ubuntu 7.0.0-30 came in at 50 and 59 seconds across two runs. 7.0.0-31 came in at 0.4. Wall clock reboot to sshd went from 78 seconds to 31. The awkward part is the timing. The upstream fix is f24df84cbe05, in stable 6.12.97 and later, 6.18.y, 7.1.4 and later, and 7.2, but no default channel carries it yet. I re-checked the archives this evening: Debian trixie still ships 6.12.94-1, with 6.12.100-1 sitting in proposed-updates for the next point release, and Ubuntu 26.04 still ships 7.0.0-30 in updates, published today, while 7.0.0-31 has been in proposed since 10 August. Rocky and el10 I could not confirm either way. So keep whatever workaround you are on until a named version lands for your distro. There is arguably a third one at #183, where @Greg_E had Debian 13 and Windows Server 2022 refusing to boot at all when created through XO-lite with UEFI. As far as I know nobody has retested that since. If it is the kernel one you are hitting, this says which version you are waiting for: uname -r dmesg -T | grep -iE "installing Xen timer|spinlock event"

We attempted a similar configuration using Wasabi S3 cloud storage as the target. What we discovered is that the Lifecyle Rule we created wiped out metadata.json and encryption.json in the root of the bucket once those files were outside the retention window. It was a global rule and I'm guessing that we need to be more precise and use scoped rules that target just the xo-vm-backups, xo-config-backups, and xo-pool-metadata-backups folders. Does that sound like it would work? I have a ticket open as well on this.