Categories

  • All news regarding Xen and XCP-ng ecosystem

    142 Topics
    4k Posts
    rzrR
    Thank you every visitors and for those who did not had the chance to visit fosdem check this report: https://xcp-ng.org/blog/2026/02/19/fosdem-2026-follow-up/ [image: vates-xcp-ng-at-fosdem-2026-1.webp] One question, I promised to forward to the forum, how many VM are you running on XCP-ng ? Dozen, hundreds, thousands or more ?

  • Everything related to the virtualization platform

    1k Topics
    14k Posts
    olivierlambertO
    Check the disk scheduler on the Dom0 for this drive.

  • All Xen Orchestra related questions/reports

    3k Topics
    27k Posts
    T
    @jmara Thank you for the input. All pods are running with caveats. Prior to executing the installation, I updated the image name to ghcr.io/vatesfr/xenorchestra-csi:edge in the manifests. After executing the install, I had to manually edit the image name in the DaemonSet, from ghcr.io/vatesfr/xenorchestra-csi-driver:edge to ghcr.io/vatesfr/xenorchestra-csi:edge. After editing the DaemonSet, the node pods restarted and transitioned to running. However, the controller pod was still attempting to pull this image: ghcr.io/vatesfr/xenorchestra-csi-driver:edge and never transitioned to running. To correct that, I edited the image name in the Deployment, from ghcr.io/vatesfr/xenorchestra-csi-driver:edge to ghcr.io/vatesfr/xenorchestra-csi:edge. Thus after editing the DaemonSet and Deployment, the pods transitioned to running. kgp -nkube-system | grep csi* csi-xenorchestra-controller-b5b695fb-ts4b9 3/3 Running 0 4m8s csi-xenorchestra-node-27qzg 3/3 Running 0 6m21s csi-xenorchestra-node-4bflf 3/3 Running 0 6m20s csi-xenorchestra-node-8tb5m 3/3 Running 0 6m20s csi-xenorchestra-node-t9m78 3/3 Running 0 6m20s

  • Our hyperconverged storage solution

    40 Topics
    715 Posts
    I
    @ronan-a Thanks

  • Non-English speakers

    32 Topics
    92 Posts
    olivierlambertO
    @jsajous26 said in Avis et retour sur utilisation de stockage NetAPP: Bonjour, 1798MB/s en lecture, fait environ 15Gbits/s 1196MB/s en écriture fait environ 10Gbits/s C'est tout à fait dans la norme pour un benchmark sur un seul disque. À noter que cela passe à l'échelle avec le nombre de VHD, ce qui fait que dans un contexte de production réaliste (des dizaines de VHD qui écrivent/lisent en même temps), on arrive à saturer un lien 25G. Nous travaillons en parallèle sur 2 axes : amélioration (multiqueue) de tapdisk pour la performance sur un seul disque utilisation de l'équivalent de Vvols en parlant directement à la baie pour éviter des conversion de format et bénéficier des performances natives (ou proche) de la baie de stockage.