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 Hello, no. Let me describe my setup. Esxi + vcenter + veeam. Vcenter wakes up veaam at 9am. Veeam sends wol packet to the synology nas at 9.15. At 9.30 the backup starts and ends more or less at 10.00 Due to inactivity synology stops the hard disks, then after some time it shut itself off. Veeam just see the repo as unavailable. At 12.00 veeam auto shuts down. Migrating to xcpng + xo, veeam is retired. At first i added the remote to XO, believing it's like veeam. If the backend goes down it simply shows unavailable. Then i discovered is not at all like that when i found an inaccessible XO. After some chatgpt-ing i found out this "bug". I thought that the script would be sufficient, but it's not. Waiting for ping to fail and then disable the remote (cron every 5mins) still ends up in ps -T -p 738 -o pid,tid,stat,wchan:32,comm PID TID STAT WCHAN COMMAND 738 738 Ssl do_epoll_wait MainThread 738 753 Ssl do_epoll_wait DelayedTaskSche 738 754 Ssl futex_wait_queue V8Worker 738 755 Ssl futex_wait_queue V8Worker 738 756 Ssl futex_wait_queue V8Worker 738 757 Ssl futex_wait_queue V8Worker 738 758 Ssl futex_wait_queue SignalInspector 738 863 Dsl rpc_wait_bit_killable libuv-worker 738 864 Dsl rpc_wait_bit_killable libuv-worker 738 865 Dsl rpc_wait_bit_killable libuv-worker 738 866 Dsl rpc_wait_bit_killable libuv-worker And it's even worse because not only XO becomes unavailable, but even if i disable manually (or via script) the remote as soon as the backup ends, with the synology still ON, the linux os does not unmount the nfs. Today the remote was disabled before the nas shutdown and correctly XO kept working. But if at this point i want to restart the XO vm i must do this before shutdown umount -l /run/xo-server/mounts/9fc232df-4d0c-4a15-93b5-c0585c1dd9c9 otherwise it stays like this for at least 15 minutes, then finally reboots [image: image.jpeg] The ideal behaviour would be that XO does all by itself, but since we can't have it all, the closest thing i have in mind is Script that sends WOL to the nas, when it pings than enables the remote Script that monitors the backup acrivity. when the last job is done, it must disable the remote and also umount the linux os nfs mount. Then the nas could shut down automatically without issue. Since i'm not a dev i need to take my time with chatgpt and see i what i can do. Having said that, my concern is not about my homelab, it's about production. In my environment i can and want to simulate all kinds of malfuncions. In the previous message i said i still need to try to shut down the main nfs SR for vms and see how the host behaves. But if i decide to deploy XEN at my company, i cant have 1 remote unavailability cause the whole XO (or XOA in that case) fall apart. Hope it helps!!

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