Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    R
    @vxgmichel I may have found our problem. Looks like an XCP-ng update may have slipped an unwanted site back into our /etc/yum.repos.d/xcp-ng.repo. When I first deployed XCP-ng, I had to remove the "http://mirrors.xcp-ng.org/8/8.3/base/x86_64/" entry for updates to work as it was too troublesome to get it working through our outbound proxy managed by another team. I have re-removed that site and things are working again. It was not fun trying to figure that out in the midst of a vulnerability. diff /etc/yum.repos.d/xcp-ng.repo /etc/yum.repos.d/xcp-ng.repo.orig <- baseurl=http://updates.xcp-ng.org/8/8.3/base/x86_64/ -> baseurl=http://mirrors.xcp-ng.org/8/8.3/base/x86_64/ http://updates.xcp-ng.org/8/8.3/base/x86_64/ <- baseurl=http://updates.xcp-ng.org/8/8.3/updates/x86_64/ -> baseurl=http://mirrors.xcp-ng.org/8/8.3/updates/x86_64/ http://updates.xcp-ng.org/8/8.3/updates/x86_64/

  • Everything related to the virtualization platform

    1k Topics
    16k Posts
    C
    @IgorGlock What do you mean by "okay"? Backing up the VM with Commvault or...?

  • All Xen Orchestra related questions/reports

    3k Topics
    30k Posts
    F
    @acebmxer that is exactley what i was saying before. if you disable the remote before nas shutdown you are good on the XO side and will work indefinitely, but if you don't execute umount -l /run/xo-server/mounts/2ab02323-0d47-43a5-9081-b2454e036c70 you will have the mount stuck on the os side. You will be able to reboot XO vm eventually but you will have to wait for a long timeout during XO shutdown. if you want to simulate my issue just disable the remote 5 minutes after shutting down the synology, get the pid from service xo-server status then ps -T pid after a while you'll have 4 "rpc_wait_bit_killable" and XO will stop responding

  • Our hyperconverged storage solution

    56 Topics
    836 Posts
    R
    Thanks @poddingue, that's helpful. I'll keep the satellites on the management interface then. @Team-Storage could you please have a look at the LinstorSR attach failure, the RPU evacuating the controller host, and the xenopsd leftovers after the failed sync point 4? I have the RPU traces, SMlog, xensource.log and the linstor-controller error reports archived if needed.

  • 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.