Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    semarieS
    @flakpyro yes. thanks for your test and to reporting the problem anyway. it is helping us to see what kind of problems users could have.

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    Update on this, and it's better news than what I was about to tell you. I built a 26.04 cloud image VM on a lab host and walked it up the kernels. Stock image is 7.0.0-28 and gave me a 59s sched_clock correction on 6 vCPUs. apt upgrade got me 7.0.0-30 out of resolute-updates, which only landed this morning, and that's still 50 to 59s. Then 7.0.0-31 from resolute-proposed: 0.4s, twice. Wall clock from reboot to sshd went 78s to 31s. The part that matters for you is that I left console=ttyS0 in the cmdline for all of those runs, and never set tsc_mode. So -31 looks like it fixes this without your grub edit and without losing live migration. Canonical did take the patch, it just hasn't come out of proposed yet, and -30 doesn't have it, so upgrading normally today won't get you there. No idea when it promotes, and I wouldn't put a proposed kernel on a production pool on my say-so. Until it does, your ttyS0 change still looks like the cheaper of the two workarounds.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    D
    Hey that sucks after catching up 23 commits. Looks like something broke in the log module during the update. I’d try a clean reinstall of the dependencies first, or drop back to an older Node version for a bit – Node 24 can be fussy with these packages.

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