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
    Hi, Any detailed error log could maybe pinpoint the problem

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    poddingueP
    From reading the code with bad glasses rather than from knowing (out of my league, by far ) : my partial understanding is that full and incremental backups don't leave the host by the same route. FullXapi.mjs calls VM.export once and gets back a single XVA tar archive for the whole VM, while the incremental runner calls exportIncrementalVm per disk, and it's that per-disk call that carries the preferNbd option. Grep preferNbd across @xen-orchestra/backups and you get five files, all of them on the incremental side. So my guess, and it' a wild one, is that the two shapes just don't fit: NBD hands you one VDI at a time, and a full backup is asking for the whole VM in one archive. I've no idea whether anyone has looked at changing that, so might be worth a mention to @Team-XO-Backend, who would actually know.

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