Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    M
    Hello, so I got access to the test environment back and was able to install this set of patches. I actually installed them on the XCP-ng host before you guys released them to the stable repository. I ran: yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates and rebooted the system. Unfortunately I have to say that this is the first time that patches broke my system. While the XCP-ng host is still able to boot, it is not longer able to mount my SRs. I have 2 SR in this test environment: 1x Linstor vSAN iSCSI configured as QCOW2 1x TrueNAS Core NFSv3 configured as VHD I spent some hours troubleshooting this and appearently it is caused by jumbo frames no longer working after applying these XCP-ng patches. The hypervisor / storage network in this testing environment is using jumbo frames everywhere (all switches involved, all storage systems). Prior to installing the updates everything was working fine. Now I can not ping the storage systems anymore using jumbo frames. (ping -M do -s 8972 ...) Hence the tasks that are meant to mount the SRs are stuck forever: [14:38 xcpng-test01 ~]# xe task-list uuid ( RO) : a6ba1324-bfe1-8aca-c5d1-d7cc57d37cca name-label ( RO): PBD.plug name-description ( RO): status ( RO): pending progress ( RO): 0.000 uuid ( RO) : f9c76606-e516-553f-706c-ff52bc303e2d name-label ( RO): PBD.plug name-description ( RO): status ( RO): pending progress ( RO): 0.000 The interesting thing is that "ip a" is still showing MTU 9000: [14:44 dat-xcpng-test01 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master ovs-system state DOWN group default qlen 1000 link/ether ac:1f:6b:ad:2c:b2 brd ff:ff:ff:ff:ff:ff 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master ovs-system state DOWN group default qlen 1000 link/ether ac:1f:6b:ad:2c:b3 brd ff:ff:ff:ff:ff:ff 4: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 80:61:5f:10:85:87 brd ff:ff:ff:ff:ff:ff 5: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master ovs-system state DOWN group default qlen 1000 link/ether ec:0d:9a:8c:00:fc brd ff:ff:ff:ff:ff:ff 6: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master ovs-system state DOWN group default qlen 1000 link/ether ec:0d:9a:8c:00:fd brd ff:ff:ff:ff:ff:ff 7: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 4a:1c:22:40:4a:d2 brd ff:ff:ff:ff:ff:ff 8: xenbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether ec:0d:9a:8c:00:fc brd ff:ff:ff:ff:ff:ff 9: xenbr3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether ec:0d:9a:8c:00:fd brd ff:ff:ff:ff:ff:ff 10: xenbr4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 80:61:5f:10:85:87 brd ff:ff:ff:ff:ff:ff 11: xenbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether ac:1f:6b:ad:2c:b3 brd ff:ff:ff:ff:ff:ff 12: xenbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether ac:1f:6b:ad:2c:b2 brd ff:ff:ff:ff:ff:ff 13: xapi1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 80:61:5f:10:85:87 brd ff:ff:ff:ff:ff:ff inet 10.10.160.24/24 brd 10.10.160.255 scope global xapi1 valid_lft forever preferred_lft forever Can't start XO VM right now as it lives on one of the SR but XO Lite is also still showing jumbo frames being enabled: [image: 1787143626214-749d3302-73f7-4534-8d57-d8bc4cec47b4-image.jpeg] Was something changed in this set of patches that could cause this issue? Thanks and best regards

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