Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    J
    Now trying to see if pool works with generic operations. Trying to do a RPR on new-xcp-dev. And I'm met with Ofcourse there are no backups being run. They are even disabled right now. And the only active task happening is "Garbage collection" on the main SR. pool.rollingReboot { "pool": "1f16dad2---------------6c8b8b7", "bypassBackupCheck": false, "shutdownPinnedVms": false } { "code": "CANNOT_EVACUATE_HOST", "params": [ "VM_LACKS_FEATURE,OpaqueRef:aa5210c4-a------------1b80-9bca5d0d0f8d|OPERATION_BLOCKED,OpaqueRef:c7a08---------------a0--------------9306,VM migration is blocked during backup" ], "call": { "duration": 23, "method": "host.assert_can_evacuate", "params": [ "* session id *", "OpaqueRef:0145019c-2a32-13bb-5951-3bca9e59e63a" ] }, "message": "CANNOT_EVACUATE_HOST(VM_LACKS_FEATURE,OpaqueRef:aa52-----------------------9bca5d0d0f8d|OPERATION_BLOCKED,OpaqueRef:c7a0------------------------306,VM migration is blocked during backup)", "name": "XapiError", "stack": "XapiError: CANNOT_EVACUATE_HOST(VM_LACKS_FEATURE,OpaqueRef:aa521-------------------8d|OPERATION_BLOCKED,OpaqueRef:c7a08c--------------------------9306,VM migration is blocked during backup) at XapiError.wrap (file:///opt/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12) at file:///opt/xen-orchestra/packages/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:65:5) at processImmediate (node:internal/timers:541:9)" } Update: I believe this might be related due to a VDI being orphaned, and trying to delete it results in VDI_NOT_MANAGED-error. Trying a new rescan of disks on the SR, and hopefully garbage collection will finish until Monday. Otherwise I will somehow try to forcefully destroy this VDI. Update 2: Managed to do a RPR now. Seems that the flag "Prevent Migration" was applied to one of the VMs. My guess is that this is applied when backups are taken. And since the backups broke with the updates. The flag never got cleared. I did a quick visual confirmation to see that my guess of this behaviour seems correct. And it indeed sets the "Prevent migration"-flag whilst the backup runs. Running backups on my pools to see if functionality is working as intended again. Update 3: Maybe related, maybe not. But my backup-tests are piling up with lots of VBD.unplug_force, that have gone on for <=30 minutes. And this is on both pools. And it seems very much so that the backup-jobs doesn't complete properly. This could also be entirely XO-related, since there has been several commits towards backups as well.

  • Everything related to the virtualization platform

    1k Topics
    16k Posts
    TeddyAstieT
    Consider this feature as experimental Many Intel CPUs have support for Intel APICv (APIC Virtualization) features that aims at reducing the number of APIC-related VM-Exits in guests, hence improving performance. This has been introduced circa Intel Ivy Bridge-EP, and is also available on somewhat recent client CPUs as well. But keep in mind that not all SKUs have support for it. Xen has support for it since roughly Xen 4.3, yet XenServer (and XCP-ng) originally disabled by default due to issues at this time around live migration between hardware that supports it and ones that don't. Internal testing on the feature shows performance improvements in various benchmarks (5-10% in I/O benchmarks up to 30% on nginx with a Ice Lake Xeon). We didn't test on other CPUs, but older CPUs (in particular those affected by L1TF/Foreshadow) may observe larger improvements. How to enable This feature exists in the Xen version shipped in XCP-ng, but disabled by default, you can enable support on the host with /opt/xensource/libexec/xen-cmdline --set-xen apicv=1 # then reboot Once enabled, you can check hardware support with xl dmesg | grep -A 25 "VMX: Supported advanced features" And look for APIC Register Virtualization and Virtual Interrupt Delivery. The feature can be disabled with /opt/xensource/libexec/xen-cmdline --delete-xen apicv # then reboot What to test Along with general feedback on the feature (does it work, supported hardware, ...), we're interested on : interactions with live migration, especially with hosts that have different configuration of APICv performance on various workloads (web server, databases, I/O, ...) What about AMD ? AMD counterpart is AVIC (Advanced Virtualized Interrupt Controller) introduced (in practice) with Zen 2 (but also existed on some Carrizo CPUs) then improved with x2AVIC with Zen 4. Xen support for (x2)AVIC is currently work in progress. Refer to Denis Mukhin's presentation on AVIC for Xen (Xen Summit 2026) : https://youtu.be/RhaJsOU_PIA

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    poddingueP
    Hi @Razielh, I think that error may be the 2 TB VHD ceiling, and it should go away if the backup repository is in block mode. The same thing came up in July on GitHub (https://github.com/vatesfr/xen-orchestra/issues/10193, a 6 TB qcow2 disk), where @Florent explained that a repository not in block mode writes each disk as one whole VHD file, which can't go past 2 TB. The reporter made a new share on their NAS, added it as a remote with "Store backup as multiple data blocks instead of a whole VHD file" ticked, and the 6 TB VM backed up after that. The docs say it too, though as a bullet in a list rather than as a hard limit: https://docs.xen-orchestra.com/backups-and-dr/backup-features-and-settings#remotes. While you're in there, incremental backups of qcow2 disks also need NBD on the job, or every run falls back to a full one (https://docs.xen-orchestra.com/backups-and-dr/backup-types/incremental_backups#nbd-enabled-backups); I haven't seen your job settings, so ignore that if it's already on. I'm not sure an existing remote can be switched to block mode in place, so a fresh share like in that issue seems the safer bet. Might also be worth a mention to @Team-XO-Backend that XO could say this up front instead of throwing a RangeError mid-transfer.

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