Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    J
    jr-m4 said: Updated two dev-pools successfully! new-xcp-dev: 2x Dell Inc. PowerEdge R650xs old-xcp-dev: 3x Dell Inc. PowerEdge R350 (HA) I even mistankenly did a wrong updating order on old-xcp-dev. And neglected to disable HA before updating, leading to two hosts being updated and promoting the next master. And by chance the last master was the non-updated one. Here I disabled HA, but couldn't promote another master (not unexpected)... Post update, and everything seems to be good anyways. And HA re-enabled successfully Note: No further testing other than the hosts booting and showing good life signs have been done, yet. I'm now also seeing issues with backups being stuck for multiple hours.
  • Everything related to the virtualization platform

    1k Topics
    16k Posts
    poddingueP
    Hello Christof, Swapping the disks between the two VMs shows the problem follows whatever runs inside, not the VM itself. Next I would run xe vm-param-list uuid=<vm-uuid> on the host once with HAOS booted and once with Debian booted, and diff the two outputs. Fields like os-version, PV-drivers-version and networks are reported back by the running OS, so they change with the guest. My guess, and it's only a guess, is that one of them comes back in a shape Commvault's parser doesn't expect: "input string has the wrong format" is what .NET says when it fails to read a number. If you find the field that differs, Commvault support would have something concrete to work with.
  • 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.