Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    B
    Updated my Lab Pool. For the Test: @lmolina said: Reboot your VMs, starting with Linux VMs that use PCI passthrough (GPU, NVMe, NIC). The new HVM PIRQ default applies to every VM at its next boot. If you set platform:hvm-pirq on a VM yourself, that value is kept. Devices that worked before must still work, with similar performance and CPU usage. If one doesn't, check whether platform:hvm-pirq=true brings it back, and tell us. -> No such VM on my Lab Pool, not tested Run your usual Xen Orchestra backups (incremental with NBD, full) and a restore. Every NBD backup now goes through new code (tapdisk's NBD server, parallel requests), so they must complete, and shouldn't get slower. -> ran a full backup job and an incremental backup job. No issues. No diffrences to previous backups. Watch the disk performance of your busiest VMs, on VHD and QCOW2 SRs. The locking change in tapdisk applies to every VM disk, not only QCOW2. -> Didn't notice any performance issues. After running the snapshot_fixer.py script if necessary, take, revert to and delete snapshots, including on VMs with several disks, and check that the VMs and their disks are as expected afterwards. The fix changes how xapi handles VDIs during reverts and SR scans. -> Performed test with 3 VMs, 1 with one disk, 2 with 2 discs. -> No issues seen.

  • Everything related to the virtualization platform

    1k Topics
    16k Posts
    D
    @Tristis-Oris said: @DustinB said: 14 year old controller it supported and has a driver. Whats wrong? I can't find that storage adapter on the HCL, were you able to? But the summary I have here is replace the old really old adapter. How reliable can't this card still be after working for so long?

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    G
    Pretty sure I figured this out. I went to update the Xenserver tools, and the updater said the installer was busy. That meant the machine was in a "dirty condition" and couldn't work right. The dirty condition was the newest Xenserver tools needing a couple more reboots to get fully insatalled. testing now and will have to wait on the DC until the network use get lighter this afternoon. Running the second VM right now, but pretty sure it will now pass the health check. I'll update after I check the DC in a few hours.

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