Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    vxgmichelV
    New kernel version in xcp-ng-testing for the next XCP-ng 8.3 LTS security update We're adding a new kernel version to the security update we're planning for tomorrow. What changed kernel: Security fixes in the Xen netback and blkback drivers, XSA-526, XSA-527 and XSA-528. Synchronization with XenServer release 4.19.19-8.0.49. In this release, the XCP-ng patches for CVE-2026-98432 (possible race condition occurring during concurrent processing of re-transmitted TCP connection requests) have been removed as they are now part of the XenServer release. Also included are patches for CVE-2026-31431, a vulnerability in the Linux kernel's cryptographic interface known as "Copy Fail" that could allow unprivileged accounts to gain root privileges. As a mitigation, the authencesn module was disabled in the previous XCP-ng kernel release. It is now re-enabled. Finally, it includes patches for CVE-2021-47103, a use-after-free vulnerability in the TCP IP protocol. Fixes for the following CVEs are also included: CVE-2026-31659 CVE-2026-31678 CVE-2026-43502 CVE-2026-52912 CVE-2026-52923 CVE-2026-52924 CVE-2026-68376 CVE-2026-74480 CVE-2026-74957 CVE-2026-80714 CVE-2026-52929 CVE-2026-63834 CVE-2026-43042 CVE-2026-72255 Versions kernel: 4.19.19-8.0.46.14.xcpng8.3 -> 4.19.19-8.0.49.3.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 shared feedback since our last call for testing: @acebmxer, @Andrew, @XCP-ng-JustGreat
  • Everything related to the virtualization platform

    1k Topics
    16k Posts
    C
    @poddingue Yes, reads pretty much like the same error / root cause.
  • 3k Topics
    29k Posts
    C
    Hey everyone - Thought I'd post this in case others are looking for a resolution to the error I received. In my testing of XO/XCP thus far, I hadn't yet implemented AD-integratin (LDAP)....until today. I wanted to test this out. I was entering the parameters as I found in the KB: https://docs.vates.tech/kb/vkb-1166/ as well as the User Guide: https://docs.xen-orchestra.com/users-and-access/users#ldap ...but was still running into "Could Not Authenticate User" error when I went to 'test' the plugin. I knew the pwd was correct as I logged into other systems with this acct. I tried other accts, and multiple LDAP servers (DCs), and even took DNS out of the equation (used IP)...as well as not checking for certificates. Nothing. I ended up changing one of the parameters that finally got me a successful test ---> the "User Filter" parameter. I had "(sAMAccountName={{name}})" in the configuration box and decided to change it to "(userPrincipalName={{name}})" which ended up being the the change that got me going. Aside from helping others who may experience this issue, I'm also posting for Olivier and the Vates team to see if there's a way to have a more precise log event pinpointing to the problem section in the plugin to help troublehshoot? Not sure if it's possible...but thought I'd put my feedback here as well. Thanks Community!
  • Our hyperconverged storage solution

    55 Topics
    830 Posts
    dthenotD
    @Maelstrom96 Hello, There is indeed an identified bug with addHost that we are investigating at the moment.
  • 37 Topics
    137 Posts
    S
    @jqueiroz said: Bom dia a todos, Estou com um problema em uma VM, ela está ligando/desligando sozinha, repetidamente. Não encontro nenhuma mensagem de erro explicando o motivo. Alguém pode me dar alguma dica sobre como solucionar isso? Uso o XCP-NG 8.0 em um cluster de dois servidores HP Proliant DL-360, com o HA-Lizard. Tudo vinha funcionando bem até alguns dias atrás, quando houve uma queda de energia no datacenter da localidade. Tenho o mesmo arranjo de VMs/servidores em mais seis localidades, nenhuma apresenta esse problema. Analisar esse comportamento instável do cluster é quase como prever resultados complexos, parecendo a análise de riscos que a malta faz ao dar palpites no https://mostbetbrasil.lat. Grato. Como o problema começou depois da queda de energia e só acontece nessa localidade, eu começaria verificando os logs do XCP-ng e do HA-Lizard para entender quem está disparando os reinícios. Pode ser alguma política de HA tentando recuperar a VM repetidamente, algum problema de armazenamento ou até inconsistência no estado do host após a interrupção. Também vale conferir o estado do pool e os logs do Xen Orchestra, se estiver usando. Se possível, desative temporariamente a automação de recuperação dessa VM, com cuidado para não comprometer a disponibilidade, e veja se ela continua reiniciando sozinha. Isso ajuda a isolar a causa.