Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    F
    Installed on my test hosts, no issues.
  • Everything related to the virtualization platform

    1k Topics
    16k Posts
    D
    Hello, The hang bug will be fixed in a future release of Xen, but Windows requires enabling all Viridian extensions (currently 6) to ensure optimal performance and reliability. Enabling Viridian extensions also fixes the hang bug via a different way. On Windows guests, please reenable all Viridian extensions using these instructions: https://docs.xcp-ng.org/vms/#enabling-viridian-extensions
  • 3k Topics
    29k Posts
    julien-fJ
    Hello everyone, In today’s cybersecurity landscape, vulnerabilities are an ongoing reality for all software vendors, and open source projects are no exception. We take our responsibility to identify, address and communicate security issues very seriously, including towards our community. We were recently made aware that a vulnerability affecting Xen Orchestra (VSA-2026-062) was being actively exploited by a threat actor. Our teams mobilized immediately. The vulnerability was under embargo; the embargo has now been lifted, and we fast-tracked a patch in line with our vulnerability handling process. The vulnerability is now fixed. Most Xen Orchestra deployments are not exposed to the public Internet, which greatly reduces the likelihood of exploitation. If your Xen Orchestra is reachable from the public Internet, however, urgent action is strongly advised. If you run Xen Orchestra from sources Update to the latest master, which includes the fix from pull request #10748, then rebuild and restart xo-server as usual. Restrict access right away if Xen Orchestra is reachable from the Internet: VPN, dedicated management network or IP allow-list. Revoke all active sessions and API tokens, then rotate the secrets used in your stack: the root password of every XCP-ng host, XO proxy credentials, backup remotes (NFS, S3, etc.), XO user passwords and OTP secrets. Check for compromise: watch for unexpected VMs, imports or sessions, check the indicators of compromise listed in the advisory, and implement the blocking countermeasures it describes. If you use a Xen Orchestra Appliance (XOA): update to 6.10.1 (latest channel) or 6.9.2 (stable channel). In XO 5, go to XOA > Updates and click Upgrade. All instructions are centralized in the advisory, which will be updated as new information becomes available: https://docs.vates.tech/security-advisories/advisories/2026/vates-sa-2026-062/ A reminder that applies to any product: a virtualization management plane should never be exposed to the whole Internet, however up to date it is. A VPN and a dedicated management network remain the best protection against the next unknown vulnerability. If you have questions, feel free to ask in this thread. Please don’t post logs or details that could expose your infrastructure publicly.
  • Our hyperconverged storage solution

    55 Topics
    833 Posts
    Maelstrom96M
    @dthenot For anyone stuck, here is what I ended up doing: I've manually hardcoded the controller_uri in /opt/xensource/sm/linstorvolumemanager.py on the new host, restarted the toolstack using xe-toolstack-restart and ran the xe host-call-plugin host-uuid=NEW_HOST_UUID plugin=linstor-manager fn=addHost args:groupName=linstor_group/thin_device command. def _get_controller_uri() -> str: # TODO: Check that an IP address from the current pool is returned. #addresses = _get_controller_addresses() return "linstor://10.25.254.100" #return "linstor://" + addresses[0] if addresses else "" After that, you should see the addHost command return True. It should be safe to revert the change to the _get_controller_uri() function and restart to make sure everything starts properly. [10:06 van3-pprod-xen01 ~]# linstor --controllers 10.25.254.100 node l ╭───────────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ State ┊ ╞═══════════════════════════════════════════════════════════════════╡ ┊ van3-pprod-xen01 ┊ COMBINED ┊ 10.25.254.100:3366 (PLAIN) ┊ Online ┊ ┊ van3-pprod-xen02 ┊ COMBINED ┊ 10.25.254.101:3366 (PLAIN) ┊ Online ┊ ┊ van3-pprod-xen03 ┊ COMBINED ┊ 10.25.254.102:3366 (PLAIN) ┊ Online ┊ ┊ van3-pprod-xen04 ┊ COMBINED ┊ 10.25.254.103:3366 (PLAIN) ┊ Online ┊ ╰───────────────────────────────────────────────────────────────────╯ [10:06 van3-pprod-xen01 ~]# xe host-call-plugin host-uuid=f9d94f6c-e826-452f-b9b9-638550b209cf plugin=linstor-manager fn=addHost args:groupName=linstor_group/thin_device True [10:08 van3-pprod-xen01 ~]# linstor --controllers 10.25.254.100 node l ╭───────────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ State ┊ ╞═══════════════════════════════════════════════════════════════════╡ ┊ van3-pprod-xen01 ┊ COMBINED ┊ 10.25.254.100:3366 (PLAIN) ┊ Online ┊ ┊ van3-pprod-xen02 ┊ COMBINED ┊ 10.25.254.101:3366 (PLAIN) ┊ Online ┊ ┊ van3-pprod-xen03 ┊ COMBINED ┊ 10.25.254.102:3366 (PLAIN) ┊ Online ┊ ┊ van3-pprod-xen04 ┊ COMBINED ┊ 10.25.254.103:3366 (PLAIN) ┊ Online ┊ ┊ van3-pprod-xen05 ┊ COMBINED ┊ 10.25.254.104:3366 (PLAIN) ┊ Online ┊ ╰───────────────────────────────────────────────────────────────────╯
  • 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.