Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    acebmxerA
    @anthoineb Since I had to physical power cycle to clear the I/O block and recover the host, the live kernel state and any active blocked PIDs from the window of the deadlock were cleared upon reboot. Checking the host right now, there are currently no processes sitting in an uninterruptible sleep (D) state, and tap-ctl list shows the standard operational mappings for the running VMs: # tap-ctl list 5175 0 0 vhd /var/run/sr-mount/4991d4aa-ed84-599b-7d19-97f2f943a366/8d3ce0d6-7d4d-40b0-a99f-09daab8d55e1.vhd 5720 1 0 vhd /var/run/sr-mount/4991d4aa-ed84-599b-7d19-97f2f943a366/1c200822-5a23-4afa-93cd-d0d89c076191.vhd 6941 2 0 vhd /var/run/sr-mount/4991d4aa-ed84-599b-7d19-97f2f943a366/0fac203e-4740-4f95-a78c-a3630e591e76.vhd # ps aux | awk '$8 ~ /D/' (Returned empty) Got it regarding the lock retry behavior in SMlog—thanks for clarifying that component. I am pulling the full un-truncated kern.log.1 from yesterday to add to the Google Drive folder so you can inspect the historical kernel call traces right when the backup stream hit the wall. I have uploaded the raw kern.log.1 file directly to the shared folder. Let me know if you want to add the exact file name context anywhere else in the message.

  • Everything related to the virtualization platform

    1k Topics
    16k Posts
    dicode-nlD
    @nick.lloyd I guess you haven't installed the newer kernel modules then? Those would fix the new auth method and the msrg2 protocol. Also, the SMAPIv3 is better then the SMAPIv1, then you don;t need qcow2. All snapshots, cbt etc are then ceph-native.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    poddingueP
    Hi, @Velocity1192 . On v6 first: creating and editing backup jobs still happens in XO 5 for now, XO 6 shows the jobs but doesn't create them yet (https://docs.xen-orchestra.com/backups-and-dr/backups-in-xo6). For the schedule, @abudef asked almost the same question earlier this year. @Pilow's answer there is clearer than anything I'd write: https://xcp-ng.org/forum/post/104108. As I read it, you either use one daily schedule plus the "Full backup interval" setting (the full lands N runs after the chain starts), or two schedules on the same job with "Force full backup" ticked on the Sunday one. That second way is how you get to pick the day, and he says not to mix the two. One thing to expect, from @Danp in another thread (https://xcp-ng.org/forum/post/91943) : the oldest backup is always a full and old deltas get merged into it, so for a while you'll see two fulls on the remote rather than weeks 1 and 2 being deleted. I don't think the scheduler can say "every other Sunday". I might be wrong there; someone who runs this kind of plan may know a trick.

  • Our hyperconverged storage solution

    55 Topics
    827 Posts
    C
    @poddingue Hi, we have a ticket at Vates regarding this. (Ticket#7765809)

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