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...?
  • 3k Topics
    30k Posts
    acebmxerA
    So have disabled the synology device from the remotes page. [image: Screenshot_20261112_162543.png] I then logged into the synology device and did a normal shutdown. (had maintenance work to do anyway). So far the synology device has been powered off for going on 30 min and XO is still responding just fine. So far the only thing i am seeing is you can not see the backups / restore points as the remote is offline. (expected) Will keep it off and see when it stops (if it stops responding). I did migrate xo and it stayed up. I can try a reboot and / or apply the latest commits while the synology device is off. While discussing this with Claude as I was having issues seeing the obvious. That disabling the remote(s) xo does not unmount the remote(s) all the time... As shown above I have two remotes that are disabled and one remote is still mounted, shown below. Also not knowing the need to disable the remote before it goes offline or when an unexpected outage occurs. This is also possibly what I ran into last time and didnt bother to follow up with about it. ❯ findmnt -t nfs,nfs4 TARGET SOURCE FSTYPE OPTIONS /run/xo-server/mounts/2ab02323-0d47-43a5-9081-b2454e036c70 10.100.2.23:/volume1/backup nfs4 rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=
  • 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.
  • 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.