Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    J
    @Emmanuel-V Rebooting hosts and/or VMs doesn't solve the problems. As @andrew said. This one got ugly. But this is also why we test stuff Update: Doing a "Rescan all disks" on the SR (lvmohba), seems to help out a little bit. But not everything. Some VMs were able to be started again. But others are still showing problems and erroring out "The VDI is not available [opterr=['MAP_DUPLICATE_KEY', 'VDI', 'sm_config', 'OpaqueRef:7---------2c1b', 'activating']]",
  • Everything related to the virtualization platform

    1k Topics
    16k Posts
    J
    @MrQ said: @jr-m4 thank you so much for testing this updated driver. Just to make sure, I understand now that you confirm the driver is working as expected and the issues you had were not related to it? Or are there any problems still with this new driver? Many thanks again for spending the time to test and report. Hi Yes. I believe I was chasing a red herring of my own doing. I have not found anything actually problematic with this driver at all.
  • 3k Topics
    29k Posts
    R
    Hi, An incremental (delta) backup job fails on a VM that has a 3 TB qcow2 disk. The run is a “full” (base) export, and the transfer fails after about 4 minutes. Environment XCP-ng 8.3.0, sm-3.2.12-25.1.xcpng8.3 Xen Orchestra built from sources (ronivay installer), commit 3923756ff (2026-10-22, latest master at the time of testing) Backup type: incremental / delta (this run: Type: full) Remote: SMB share on a Synology NAS VM: 1 VDI of 3 TB in qcow2 format What happens The snapshot succeeds. The transfer to the remote fails after about 4 minutes. The same error is reported at the transfer, remote and job levels: Error: The value of "value" is out of range. It must be >= 0 and <= 4294967295. Received 4_294_971_137 Stack trace (xo-server) xo:backups:AbstractVmRunner WARN writer step failed { error: RangeError [ERR_OUT_OF_RANGE]: The value of "value" is out of range. It must be >= 0 and <= 4294967295. Received 4_294_971_137 at checkInt (node:internal/buffer:78:11) at writeU_Int32BE (node:internal/buffer:808:3) at Buffer.writeUInt32BE (node:internal/buffer:821:10) at DiskConsumerVhdStream.computeVhdBatAndFileSize (packages/vhd-lib/disk-consumer/BaseVhd.mjs:73:11) at DiskConsumerVhdStream.toStream (packages/vhd-lib/disk-consumer/DiskConsumerVhdStream.mjs:62:36) at toVhdStream (packages/vhd-lib/disk-consumer/index.mjs:31:19) at RemoteAdapter.writeVhd (@xen-orchestra/backups/RemoteAdapter.mjs:695:28) at asyncEach.concurrency (@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:284:45) at next (@vates/async-each/index.js:90:37) { code: 'ERR_OUT_OF_RANGE' }, step: 'writer.transfer()', writer: 'IncrementalRemoteWriter' } This is followed by VDI_IN_USE (destroy) retries on the snapshot cleanup, which look like a side effect of the failed transfer. Analysis The crash happens while computing the VHD BAT. The BAT stores block offsets as 32-bit sector numbers (512-byte units), so a VHD cannot address data beyond ~2 TiB. The qcow2 disk is 3 TB, and the stream’s block offsets go past that limit (4,294,971,137 sectors ≈ 2 TiB + 1.9 MiB). In the meantime, I’m protecting this VM’s data with a file-level backup agent, but I’d like to go back to XO for the whole VM. Thanks!
  • Our hyperconverged storage solution

    55 Topics
    827 Posts
    C
    @poddingue Hi, we have a ticket at Vates regarding this. (Ticket#7765809)
  • 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.