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
    It doesn't appear that XO provides any granularity when adding users to XO. There are just a User or an Admin? And a User basically can't do anything? Will this be changing with XO6? Will there be RBAC & granularity coming in the future? Some RBAC roles that would be nice to have: A Read-Only account for all XO Objects would be nice Various Roles, aside from full admin access, like below: VM Managment --> user can only manage any VM configs Ability to create VMs Ability to remove VMs Host Management --> ability to add & manage Hosts in XO Network Management --> user can only manage Host or VM storage Storage Management --> user can only manage Host or VM networking Folders --> XO doesn't have these 'objects', but adding ability to create folders in the XO webUI then abiltiy to grant user access to those folders would be great. Would be nice to be able to add VMs to VM folders; or, ability to create Network Folders and assign permissions to manage 'vm networks'; or Storage Folders...again, to grant users ability to add then manage storage for only SRs added to those Folders. Those are just examples. But, my main reason for this post is to verify I'm not overlooking anything -- there is no role/permissions granularity currently in XO correct? Thanks!
  • 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.