Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    rzrR
    XCP-ng 8.3 LTS Updated installer ISO The installer ISO has been refreshed with up date packages already published. The image can be downloaded from: https://repo.vates.tech/tmp/xcp-ng-8.3.0-20260709.testing.iso The procedure to install XCP-ng 8.3 remains the same. The refreshed installer ships updated Xen, Linux kernel and some drivers/firmware, which help with deploying XCP-ng 8.3 on hardware that needs changes introduced by updates not present in previous ISO image releases. This refreshed ISO has been validated on a subset of supported hardware. Additional testing on any hardware from the community would be greatly appreciated. As with previous installer releases, it can be used to upgrade XCP-ng from a previous major release (8.0, 8.1 or 8.2). Refer to the Upgrade documentation. For existing XCP-ng 8.3 installations, there’s no need to use this ISO image. Regular yum updates achieve the same results as a fresh installation with that ISO image. Installer improvements include minor enhancements related to software RAID1 support for the system disks, including support for more than 2 disks in the RAID1 array if anyone really wants that. New maintenance update candidates for XCP-ng 8.3 LTS This release batch includes a VBD leak regression fix in XAPI and minor changes needed to build the installer ISO. A regression was introduced to the VM.revert operation in xapi-26.1.4-3.3, which left VBDs attached to the VM when they are not present in the reverted-to snapshot (instead of destroying such VBDs, as was done before). VMs that were reverted to their snapshots after xapi-26.1.4-3.3 may have such "leftover" VBDs. Advanced users can use the leaked_vbds script to detect possible cases in your pools. Sadly, there is no way to automatically distinguish a VBD that was created after a VM.revert from a VBD that survived the VM.revert, so this script relies on the user to determine if the suspicious VBDs are indeed affected or not. What changed Control Plane xapi: Fix non-snapshotted VBDs staying attached after VM.revert Versions xapi: 26.1.11-1.2.xcpng8.3 -> 26.1.11-1.3.xcpng8.3 xcp-ng-release: 8.3.0-37 -> 8.3.0-38 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 ~5 days We would like to thank users who shared feedback since our last call for testing: @Andrew, @XCP-ng-JustGreat, @acebmxer, @bufanda, @flakpyro , @marcoi.
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    henri9813H
    Hello. Problem Solved. My case: i have a pool of many hypervisors with only local storage, no shared SR ( yes it's not recommanded, i stopped doing this and i'm currently migrating everything to pool with Shared storage ). Yesterday, i removed two hosts ( host 3 & host 4 ) whith local storages SR attached ( LVM ). In XCP-NG, i "forgot" Host 3 & host 4, the hosts from the pool, but it doesn't forge the associated SR ! But Live migrating a VM from host 1 to host 2 ( of the same pool ) bot with local SR, FAIL because there is no SR plugin attached of Local Storage 4 ( hosts 4 ) neither Local storage 3 ( host 3 ). So, i also forget theses 2 SRs and now it's ok. i don't understand why SR not connected to anyone can prevent migration about vm from other to other sr.
  • 3k Topics
    29k Posts
    poddingueP
    Thanks for checking. That's useful, even if it points away from where I was looking. Clocks within a second of each other means drift probably isn't your problem, and I'd guess the MST/UTC difference is just how dom0 displays it, though I'm not sure. What I keep coming back to is that your full backups fail while the delta jobs on the same hosts never do. That's the same split in https://github.com/vatesfr/xen-orchestra/issues/9181, where full backups hit BodyTimeoutError on VMs with big disks or a lot of free space and the deltas are fine. If your failing VMs look like that, your dates and the MST/UTC detail would do more good on that issue than buried in here. MajorP93 created this issue in vatesfr/xen-orchestra open Full backup fails on large VMs / VMs with lots of free disk space #9181
  • Our hyperconverged storage solution

    49 Topics
    764 Posts
    J
    OK so that resource was a pain and did not want to give up, so I restarted the host. Migration is running good now.
  • 36 Topics
    117 Posts
    B
    Merci beaucoup pour vos retours ! @nathanael-h : C'est l'étape suivante !!! J'ai découvert cluster API le mois dernier et j'ai déja testé sur d'autres plateforme ! ça déchire !!! Je ne savais pas qu'il y avait un support de XCP-ng ! Je finis ma série d'article pour une installation classique et je bascule sur cluster API ! @ataxyanetwork Merci pour ton repo. Je vais regarder ça