Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    M
    @anthoineb @gduperrey @bleader Hi! Thank you very much for your responses. I actually found the issue and it was not caused by the XCP-ng patches. Appearently one of my switches had a malfunction and lost it's jumbo frames config on the ports involved... It seems like this happened in the time frame between XCP-ng updates . Last time I used this setup the jumbo frames / storage setup was working fine so I thought it might be related to these patches. Anyways sorry for taking your time in this regard- Best regards
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    olivierlambertO
    Nice! Have you tested the snapshot, revert and so on?
  • 3k Topics
    29k Posts
    T
    It looks like this is identified and solved, I'll test on a new version of XO next week at some point, but I just wanted to confirm that I've been seeing what appears to be the same problem. This hasn't affected any of my full, delta or mirror backups, on any of the NFS targets - but it does affect two different Pool metadata & xo config backups. Both on different NFS targets on different schedules. It's an infrequent failure, sometimes not failing for a couple of days, but sometimes failing up to 3 or 4 times per day - this is on an hourly schedule. [image: 1787394387803-912ddd51-e6c1-4a62-8529-79d6b2fe8ad0-image.jpeg] My most recent failure on the hourly job was yesterday morning, the one before that was almost 24 hours earlier. This is currently on Xen Orchestra, commit 24913 but it was also noticeable on a version from the end of July. From what I've read, I'm guessing the fix will be in the main branch soon enough and an update will solve it, but if there's any useful information I can provide, please let me know.
  • Our hyperconverged storage solution

    50 Topics
    796 Posts
    olivierlambertO
    Great, thanks for the feedback!
  • 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)