Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    bleaderB
    @majorp93 no, these updates should not change anything on the MTU behavior. From your screenshots and ip a output, I assume eth4 is the only link used, than your vlan1060 network is indeed your management network. I guess with some confidence that: eth4 is your actual NIC xenbr4 is the pool-wide network without vlan using eth4 xapi1 is the bridge for vlan1060 If that's right indeed on your host side, the MTUs are properly set. As Gaël said, jumbo on management network is not officially supported, because we always end up in situation similar to yours, where something stops working for "some" reason But as you said, when everything is setup properly, it does work. I have test hosts at home up to date but no similar setup to yours for SR. I tried with a pool-wide and a pool-wide + vlan as management with 9000 and the ping -M do -s 8972 does work fine in both cases, so nothing I can see here. When it fails, what do you see? Message too long? mtu=1500 ? something else? Do you have multiple hosts in that pool? Can you try that between the hosts as well and not toward the storage systems? I would also check on ovs with ovs-vsctl list interface that each of eth4, xennbr4 and xapi1 report 9000 mtu. I know you said it was properly setup everywhere, but I would still be tempted to think there is a setup issue somewhere.

  • 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
    poddingueP
    I went and checked a couple of the factual bits here rather than take them on trust, and the xscontainer one holds up: xscontainer-10.0.4-1.xcpng8.3.noarch.rpm is still sitting in the 8.3 base repo, and back in topic 6845 Olivier said it was meant to be removed at some point, which evidently hasn't happened. The wiki page is the bit I couldn't reproduce. There's no Docker or container page in the current docs that I can find, and nothing matching in the docs repo either, so I might be looking in the wrong place. On the proposal, I'm not the right person to say whether a containers collector fits the agent's scope. Two things I can tell you. xen-guest-agent lives on GitLab rather than GitHub, so the design conversation would need to happen there. And there's no Feeder entry for any of this yet, which surprised me given how far back the requests go; worth putting one up so the votes have somewhere to land. That's my read on where it should go rather than on whether it's a good idea, and someone closer to the agent will correct me if I've sent you the wrong way.

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