Categories

  • All news regarding Xen and XCP-ng ecosystem

    143 Topics
    4k Posts
    rzrR
    New security and maintenance update candidates for XCP-ng 8.3 LTS (kernel) This release batch contains security fixes on the Linux kernel in dom0, version updates, some bug fixes and a few improvements. What changed Virtualization & System kernel: Update to 4.19.19-8.0.46.5 Fixes multiple vulnerabilities: CVE-2026-46300: A logic error in the network stack could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files that were not supposed to be writable. The modifications are not persistent to a reboot (i.e. no disk corruption). This vulnerability is used by the public exploit Fragnesia. CVE-2026-46333: Incorrect tracking of users privilege level when a task is exiting in the ptrace sub-system could allow an unprivileged local user to escalate its privileges to root by writing to file descriptors they are not supposed to have access to. The changes made to potentially root-owned files are persisted across reboots. This vulnerability is used by the public exploits ssh-keysign-pwn as well as ptrace_may_dream. CVE-2026-43494: A double-free of pinned pages in the RDS kernel module in the transmit error path could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files, allowing them to for example overwrite a SUID binary in page cache with a shellcode. Changes are not persistent across reboots. This vulnerability is used by the public exploit pintheft. qemu: Fix a potential issue in guest memory mapping lookup. edk2: Fix issues while booting from physical CD/DVD drive. Bump UEFI guest vCPU limit to 128 vCPU (was 96 vCPUs) dmidecode: Update to 3.6-3 Version able to read type 42 tables (redfish) varstored: Update to 1.3.2-2.1 Sync with upstream. ipxe: PXE boot support of BIOS VMs on a VLAN with 802.1Q priority tags Control plane xapi: Enable USB passthrough of smartcards Storage blktap: No functional change. Only sync with upstream. Network openssh: Drop support of insecure clients Old OpenSSH clients (version less than 7.2) can no longer connect with ssh-rsa (due to SHA-1 being no longer accepted by the server). The solution is either to update OpenSSH-clients (to a version >= 7.2), or to generate and use ED25519 keys. Others libtasn1: Update to 4.21.0 (hardening) fuse: Rebuild slang: Rebuild systemtap: Rebuild Optional packages libreswan: Rebuild netdata: Rebuild Versions: blktap: 3.55.5-6.7.xcpng8.3 -> 3.55.5-9.1.xcpng8.3 dmidecode: 1:3.0-5.el7 -> 1:3.6-3.xcpng8.3 edk2: 20220801-1.7.10.1.xcpng8.3 -> 20220801-1.7.11.1.xcpng8.3 fuse: 2.9.2-10.xcpng8.3 -> 2.9.2-10.1.xcpng8.3 ipxe: 20121005-1.0.7.xcpng8.3 -> 20121005-1.0.8.xcpng8.3 kernel: 4.19.19-8.0.46.3.xcpng8.3 -> 4.19.19-8.0.46.5.xcpng8.3 libreswam: 4.12-2.3.1.xcpng8.3 -> 4.12-2.3.2.xcpng8.3 libtasn1: 4.10-1.el7 -> 4.21.0-1.xcpng8.3 openssh: 9.8p1-1.2.3.xcpng8.3 -> 9.8p1-1.2.4.xcpng8.3 netdata: 1.47.5-4.2.xcpng8.3 -> 1.47.5-4.3.xcpng8.3 qemu: 2:4.2.1-5.2.17.1.xcpng8.3 -> 2:4.2.1-5.2.18.1.xcpng8.3 slang: 2.3.2-11.xcpng8.3 -> 2.3.2-11.1.xcpng8.3 systemtap: 4.0-5.2.xcpng8.3 -> 4.0-5.3.xcpng8.3 varstored: 1.3.1-2.1.xcpng8.3 -> 1.3.2-2.1.xcpng8.3 xapi: 26.1.4-3.1.xcpng8.3 -> 26.1.4-3.2.xcpng8.3 Test on XCP-ng 8.3 yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates reboot The usual update rules apply: pool coordinator first, etc. What to test As usual, normal use and anything else you want to test. Test window before official release of the updates ~1 day We would like to thank users who reported feedback since our last call for testing: @Andrew, @acebmxer, @flakpyro, @greg_e, @jeffberntsen, @marcoi, @ovicz, @ph7, @probain.
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    Following up since the situation changed: QCOW2 went GA in XO 6.5 (released 2026-05-28), so the old ~2TB VHD ceiling is gone. A disk at exactly 2TB, and well beyond it, is fine now without shrinking to 1.99TB first. When acebmxer and john.c replied, it was still a release candidate; it's the stable story now. I haven't migrated a disk quite that size myself, so I won't promise it's totally painless, but the format limit that was blocking you isn't there anymore. The release blog has the details if you want to read up before the migration: https://xen-orchestra.com/blog/xen-orchestra-6-5/
  • 3k Topics
    28k Posts
    poddingueP
    Pilow's probably right that you're hitting the tapdisk / SMAPIv1 path rather than the network, since you're both landing at roughly the same speed despite very different link capacity. One thing worth trying before assuming it's a hard ceiling: turning on NBD for the transfer, which uses the NBD protocol instead of the VHD handler XAPI generates and generally shows better throughput with less load on the Dom0 (https://docs.xen-orchestra.com/xo5/incremental_backups#nbd-enabled-backups). I haven't benchmarked NBD against CR specifically, so I can't promise how much it'll move the needle, but it's a low-risk toggle and seems like the obvious first lever. If it's still capped after that, it might be worth a mention to @Team-Storage, since the tapdisk/SMAPIv1 transfer path is really their side and they'll have a far better read than me on where the current limits sit.
  • Our hyperconverged storage solution

    47 Topics
    749 Posts
    DAYELAD
    @olivierlambert yes it is a cluster using HA
  • 35 Topics
    113 Posts
    olivierlambertO
    Ah excellente nouvelle Je passe le sujet en résolu !