Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    gduperreyG
    Hello @MajorP93, Several things in your message raise questions for me. First, this SR: 1x Linstor vSAN iSCSI configured as QCOW2 What is this storage and how is it configured? Currently, we do not support QCOW2 on Linstor/Xostor. So, is it simply an iSCSI device to which you have applied the QCOW2 format, or is it a Xostor on the XCP-ng pool? Regarding jumbo frames, we do not use them internally and are not currently testing them. It is often recommended not to use them for the management interface, as indicated in the XCP-ng documentation: https://docs.xcp-ng.org/networking/ Non-standard MTUs (such as jumbo frames) are not supported on management interfaces. Using them can lead to serious issues, including failed pool member joins or unexpected network outages. Is that the case here?

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    Rocky 10 is affected and has no fix in it. I pulled the source RPM for kernel-6.12.0-211.16.1.el10_2.0.1, which is your -211: jiffies.c still ends on core_initcall(init_jiffies_clocksource) with no cs_jiffies_registered, so f24df84cbe05 hasn't landed, and max_raw_delta sits in clocksource.h with nothing setting it early, so the regression is still there. So tsc_mode=2 and nomigrate stay the answer on Rocky until Red Hat picks it up. One more thing, because this thread reads like an AMD problem if you skim it. @dvinni measured the same stalled clock on Intel Xeon Gold in the sibling thread, and the upstream fix came from @teddyastie bisecting it on a Xen HVM guest. I read source rather than booting a Rocky VM, so if you have one behaving differently I'd like to hear it.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    C
    @poddingue said: Depends which one you mean Thanks for the update! I meant the one where the VM was hanging because of incorrect boot order; but, good to know about the other issues. I'm moderately ok on Linux, but not so much so to where I fully understand the long boot time you go into (& divinni in the other thread) I had an issue in XO-Lite myself last yr. That sounds a bit like I had; or, I believe the issue was BIOS vs UEFI. If I created the VM with BIOS, I could boot/set it up...but not able to with UEFI. Thanks!

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