Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    A
    @gduperrey Rolling pool update worked with released production patches.

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    @dvinni measured the same stalled clock on Intel in the sibling thread, Xeon Gold 6342 and 6348, so I don't think it's an AMD thing, but I could be wrong. Nothing in the upstream fix looked vendor specific to me either, though that's me reading a commit rather than testing on both. Good to hear it's quiet on your side though. The gap I'd still like closed is Rocky 10, the one distro I couldn't settle at post#26. If anyone here runs it and can check whether f24df84cbe05 is in their kernel, I'd rather be corrected than leave a guess sitting in the thread.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    poddingueP
    Nothing from our side that I can pass on, sorry. Two public things I can point at, neither of which I've tested against your case: the updates that went live yesterday list tapdisk crash fixes among the storage changes (https://xcp-ng.org/blog/2026/08/18/august-2026-updates-1-for-xcp-ng-8-3-lts/), and there's an open PR on tapdisk picking up a cbtlog disk during commit and failing early because that driver has no commit action (https://github.com/xcp-ng/blktap/pull/17). I'm reading a changelog and a PR body rather than reproducing anything, so treat both as leads. @msupport, Danp's three questions from 6 August are still open (guest OS, guest tools, VHD or QCOW2), and filling those in is probably worth more than anything I can add here. @dsauce, I don't know the answer to yours about CBT and the leftover veeamsnap VDIs, and I'd rather say so than guess on a thread about data loss.

  • Our hyperconverged storage solution

    50 Topics
    796 Posts
    olivierlambertO
    Great, thanks for the feedback!

  • Non-English speakers

    37 Topics
    135 Posts
    AtaxyaNetworkA
    Pour l'ISO montée deux fois : My bad, j'ai ajouter un truc en trop sur mon précédent fix. Une PR est en cours pour corriger ça. Pour le problème principal : J'ai identifié la cause, mais je n'ai pas encore de solution. Sans les drivers Xen (non initialisés avant l'installation), une VM est limitée à 4 périphériques. La séquence de boot ne peut donc pas détecter le second disque contenant le fichier Kickstart (ks). Côté Packer, on semble être bloqués par cette contrainte XCP-ng. Les seules alternatives actuelles seraient de se limiter à : 2 disques + 2 CD ou 3 disques + 1 CD + HTTP (Note : L'installation manuelle fonctionne car l'installateur démarre directement, avec le driver xen_blkfront, alors qu'avec Packer, l'injection de notre fichier interrompt le flux de démarrage classique). Je vais fouiller encore un peu, mais sans certitude d'un contournement possible. (et je regarde pour ajouter le CDlabel)