Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    A
    @gduperrey Updates installed. RPU mostly worked... Every host was updated. All VMs moved and returned. Waiting before re-enabling the load balancer task is stuck waiting...

  • Everything related to the virtualization platform

    1k Topics
    16k Posts
    C
    Hey Poddingue! I very much assume to have found the troublemaker. I compared the outputs of xe vm-param-list and what triggered my eyes the most was: Debian: PV-drivers-version (MRO): HA: PV-drivers-version (MRO): major: @PRODUCT_MAJOR_VERSION@; minor: @PRODUCT_MINOR_VERSION@; micro: @PRODUCT_MICRO_VERSION@; build: @NUMERIC_BUILD_NUMBER@ Ofc what's reported after a HomeAssistant boot is completely nuts and should be "nothing"/empty. As the errorlog of Commvault says something about XenSDKWrapper, I'm unsure if the errorhandling of the SDK or Commault sucks (should I be happy that it was caught at all and didn't crash the whole application? ). The German translation, to me, indicateds Commvault at faul though. Neither XCP-ng nor the XenSDK will be able to speak english, nor is it likely that they translate a "try-catch"-errormessage, I assume. BUT: XCP-ng should never report back such nonsense and by that probably hit Commvault unexpected. So I also suggest to catch nonsense/unclear responses before XAPI (which is what xe triggers?) output/response.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    nathanael-hN
    @jr-m4 I did not took time to test Podman yet. But we expect this to work. You'd have to expose a socket, like the docker daemon does. Probably systemctl enable --now podman.socket would be enough. More in this page https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/building_running_and_managing_containers/using-the-container-tools-api and this one https://docs.podman.io/en/latest/markdown/podman-system-service.1.html

  • 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 ┊ ╰───────────────────────────────────────────────────────────────────╯

  • Non-English speakers

    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.