# FIO en conteneur : tester les performances I/O sur VMs distantes

_Publié le 3 novembre 2026 — https://ip73.fr/2026/11/03/fio-en-conteneur-tester-les-performances-i-o-sur-vms-distantes/_

Le lancement de tests de performance en I/O à l'échelle est notoirement complexe : il faut coordonner les démarrages, attendre les résultats sur plusieurs hôtes et analyser l'ensemble. Pour simplifier ce processus, github.com annonce la mise à disposition d'un conteneur dédié pour exécuter FIO (Flexible I/O Tester) contre des machines virtuelles distantes. L'outil permet, au lieu de jongler avec des sessions SSH manuelles, de configurer une matrice de tests FIO unique qui s'exécute en parallèle sur différents invités OpenShift Virtualization.

Ce conteneur, basé sur l'image `quay.io/ekuric/fio-benchmark:latest`, est conçu pour être modulaire. On peut lui fournir une configuration détaillée via un fichier YAML monté, ce qui est idéal pour des scénarios complexes, ou bien on peut tout paramétrer directement en utilisant des variables d'environnement.

Il existe plusieurs manières d'amorcer ces tests. Si vous pré-provisionnez vos VMs, vous pouvez pointer le conteneur vers des noms d'hôtes spécifiques, en utilisant des motifs comme `vm-{1..10}` pour cibler une plage définie. Si, par contre, vous ne voulez pas créer les machines à l'avance, le conteneur prend en charge le provisionnement « sur demande » (`CREATE_VMS=true`). Ce mode automatique gère la génération de clés SSH éphémères, la création des DataVolumes et des VMs, avant de lancer les tests en un seul bloc.

Cette automatisation permet de couvrir différents types de charge. Le système supporte les tests sur le disque système de la VM (en mode `--testdir`) ou sur des disques de données dédiés (en mode `--raw-disk`). Les options de configuration sont nombreuses : on peut spécifier la taille du fichier de test (`TEST_SIZE`), la durée de l'exécution (`RUNTIME`), les tailles de blocs à tester (`BLOCK_SIZES`) ou encore les types d'opérations I/O (`IO_PATTERNS`). Les utilisateurs peuvent même mélanger des environnements Linux et Windows en définissant des variables spécifiques pour chaque OS.

L'intégration de cet outil s'inscrit dans une logique d'industrialisation des benchmarks. D'après Red Hat Developer, cette approche transforme un flux de travail auparavant artisanal en une séquence reproductible, ce qui est essentiel pour les systèmes d'intégration continue (CI) ou les laboratoires de tests. En fournissant une sortie centralisée dans un répertoire monté, la comparaison des configurations de `StorageClass` ou des changements d'images devient beaucoup plus directe.

Pour les utilisateurs souhaitant un contrôle maximal, l'alternative consiste à utiliser des scripts comme `multivm.sh` pour créer les VMs avec des spécifications précises (nombre de cœurs, mémoire, classe de stockage), puis de faire pointer le conteneur vers ces hôtes existants. Si l'on se fie à la documentation de github.com, l'utilisation des variables d'environnement est privilégiée lorsque l'on ne monte pas de fichier de configuration YAML, permettant une configuration rapide et dynamique, notamment pour les tests mixtes Linux/Windows.

## Sources

- [ioscale/io-generic/fio-container/fio\_README-container.md at main · ekuric/ioscale](https://github.com/ekuric/ioscale/blob/main/io-generic/fio-container/fio_README-container.md), github.com
- [ioscale/templates/multivm.sh at main · ekuric/ioscale](https://github.com/ekuric/ioscale/blob/main/templates/multivm.sh), github.com
- [How to run I/O workloads on OpenShift Virtualization VMs](https://developers.redhat.com/articles/2026/11/03/how-run-io-workloads-openshift-virtualization-vms), Red Hat Developer, 3 novembre 2026