Categories

  • All news regarding Xen and XCP-ng ecosystem

    144 Topics
    5k Posts
    rzrR
    @marcoi said: Applied the latest pushed updated to production, no major issues. Thank you for testing The only thing to note is my backup XCP config failed Sunday, (...) This morning the backup ran without issues. Glad it has finally to work, if problem occurs again feel free to ask about this feature in this subforum: https://xcp-ng.org/forum/category/21/backup
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    TeddyAstieT
    @ravenet said: @teddyastie separate from the above, a standing question whenever you have a minute: is it expected that passthrough GPU MSIs are never delivered at all on 8.3? Both my working rig and PessimistTech's broken one show the amdgpu xen-pirq MSI vector at zero on all CPUs, forever — everything survives on driver-side polling. It works, but it means any driver path that hard-depends on an interrupt has no safety net, and I suspect it's why the amdgpu ring resets in his log keep failing. Curious whether that's a known limitation of the pirq MSI path for passthrough devices or something worth a ticket. TL;DR This is likely a known issue, and we're currently discussing on a potential fix. There is a known bug regarding MSI on AMDGPU when using "hvm_pirq" ("use event channels for device interrupts"), see https://lore.kernel.org/xen-devel/20240110095311.61809-1-roger.pau@citrix.com/ https://github.com/QubesOS/qubes-issues/issues/7971 The easy fix is to disable "HVM PIRQ" feature (which has been made disabled by default in Xen 4.19), but on the XCP-ng side, this is configured by XAPI Project which needs to be updated as well to apply this change (which appears to be a bit tricky for various reasons). neowutran created this issue in QubesOS/qubes-issues closed MSI problems with `amdgpu` driver on recent kernels #7971
  • 3k Topics
    29k Posts
    poddingueP
    Thanks for checking. That's useful, even if it points away from where I was looking. Clocks within a second of each other means drift probably isn't your problem, and I'd guess the MST/UTC difference is just how dom0 displays it, though I'm not sure. What I keep coming back to is that your full backups fail while the delta jobs on the same hosts never do. That's the same split in https://github.com/vatesfr/xen-orchestra/issues/9181, where full backups hit BodyTimeoutError on VMs with big disks or a lot of free space and the deltas are fine. If your failing VMs look like that, your dates and the MST/UTC detail would do more good on that issue than buried in here. MajorP93 created this issue in vatesfr/xen-orchestra open Full backup fails on large VMs / VMs with lots of free disk space #9181
  • Our hyperconverged storage solution

    49 Topics
    764 Posts
    J
    OK so that resource was a pain and did not want to give up, so I restarted the host. Migration is running good now.
  • 36 Topics
    117 Posts
    B
    Merci beaucoup pour vos retours ! @nathanael-h : C'est l'étape suivante !!! J'ai découvert cluster API le mois dernier et j'ai déja testé sur d'autres plateforme ! ça déchire !!! Je ne savais pas qu'il y avait un support de XCP-ng ! Je finis ma série d'article pour une installation classique et je bascule sur cluster API ! @ataxyanetwork Merci pour ton repo. Je vais regarder ça