Dimensionner sa machine pour les labs dsoxlab

Un lab shell ne coûte rien de plus que votre poste ; un lab vm coûte la somme des machines que son catalogue déclare, parce que dsoxlab provision les monte toutes d'un coup. Le catalogue Kubernetes déclare ainsi deux machines, 6656 Mo de mémoire et 4 processeurs virtuels, le catalogue Linux trois machines et 5120 Mo. Cette leçon lit ces chiffres à la source, le fichier meta.yml de chaque catalogue, et explique ce que dsoxlab doctor en fait, en version 0.2.5, avant de vous laisser provisionner. Elle s'adresse à qui veut savoir, avant d'installer un hyperviseur, si sa machine suffira.

Ce que vous allez apprendre

Distinguer les labs shell, gratuits, des labs vm, qui montent des machines.
Relever dans un meta.yml ce qu'un catalogue réclame, et les valeurs par défaut du contrat.
Chiffrer les catalogues Linux, Ansible, Kubernetes et Terraform, tels qu'ils sont publiés.
Comprendre pourquoi le disque déclaré n'est pas le disque consommé.
Prévoir la marge que le processeur impose, et ce que doctor refuse.

Deux sortes de labs, et seule la première est gratuite

Un lab shell se joue dans un répertoire de votre machine : le lab de démonstration en est un, et tout le catalogue Terraform aussi. Il ne réclame ni hyperviseur, ni mémoire réservée. Un lab vm démarre de vraies machines virtuelles à côté de vous, parce que ce qu'il fait prouver, un profil AppArmor, une montée de version kubeadm, un service systemd qui survit au redémarrage, ne se prouve pas dans un conteneur qui partage le noyau de l'hôte.

Une troisième situation existe, à mi-chemin : un lab shell qui déclare des services en conteneur, comme un émulateur de cloud ou une base de données, réclame Docker sans réclamer d'hyperviseur. Onze labs du catalogue Terraform sont dans ce cas, et c'est pour eux que doctor y classe Docker en requis.

Où lire ce qu'un catalogue réclame

Tout est écrit dans le bloc infra: du meta.yml, à la racine du dépôt du catalogue, et nulle part ailleurs : un catalogue ne livre aucun Terraform, il déclare ses hôtes et dsoxlab fait le reste. Chaque entrée de infra.hosts porte quatre chiffres, et le contrat fixe leur valeur par défaut quand l'auteur ne les écrit pas :

Champ	Défaut	Ce qu'il déclare
`ram_mb`	1024	La mémoire de la machine, en Mo
`vcpu`	1	Le nombre de processeurs virtuels
`disk_gb`	10	La taille du disque système, en Go
`extra_disk_gb`	0	Un second disque, pour les labs qui exigent un vrai périphérique bloc : partitionnement, LVM, RAID, quotas

Le catalogue Kubernetes, par exemple, déclare son plan de contrôle ainsi, et commente son choix : kubeadm refuse d'initialiser en dessous de deux processeurs, et le plan de contrôle porte etcd, l'API server et, pendant les labs de diagnostic, des Pods qu'on casse volontairement.

# meta.yml du catalogue kubernetes-dsoxlab-training, extrait
infra:
  provider:
    - kvm
    - incus
  network: lab-k8s
  hosts:
    - name: k8s-cp.lab
      distro: ubuntu24
      role: control-plane
      ram_mb: 4096
      vcpu: 2
      disk_gb: 25
    - name: k8s-w1.lab
      distro: ubuntu24
      role: worker
      ram_mb: 2560
      vcpu: 2
      disk_gb: 20

Deux commandes évitent d'ouvrir le fichier. dsoxlab doctor porte un contrôle Ressources qui additionne ces déclarations et les compare à ce que la machine offre ; dsoxlab show <id> dit, pour un lab donné, son runtime et sa cible. Le premier décide, le second renseigne.

Ce que chaque catalogue déclare

Les totaux ci-dessous viennent des meta.yml publiés, relevés le 2026-09-26. Ils comptent toutes les machines du catalogue, parce que dsoxlab provision applique tout le plan par défaut : un catalogue à trois hôtes monte trois machines, même si le lab du jour n'en cible qu'une. Le disque est la somme des disk_gb et des extra_disk_gb, et il se lit comme un plafond, pour la raison expliquée juste après.

Catalogue	Labs	Machines	Mémoire	vCPU	Disque déclaré	Providers
Linux (`linux`)	86, dont 66 `vm`	3 : deux AlmaLinux 10, un Ubuntu 24.04	5120 Mo	4	65 Go, dont 15 Go de disques additionnels	kvm, incus, outscale
Ansible (`ansible`)	113, dont 88 `vm`	4 : un nœud de contrôle et trois nœuds gérés, tous AlmaLinux 9	5632 Mo	5	60 Go, dont 5 Go additionnels	kvm
Kubernetes (par URL)	64, tous `vm`	2 : un plan de contrôle et un nœud de travail, Ubuntu 24.04	6656 Mo	4	45 Go	kvm, incus
Terraform (`terraform`)	88, tous `shell`	aucune	aucune	aucun	aucun	sans bloc `infra:`

Le catalogue Terraform n'a aucun bloc infra:, par conception : Terraform s'exécute sur la machine de l'apprenant, donc tous ses labs sont shell et dsoxlab provision n'y est jamais appelé. Ses prérequis sont d'une autre nature, et son meta.yml les nomme : terraform sur le PATH pour tous les labs, libvirt et le provider dmacvicar/libvirt pour la seule section des premières infrastructures, et floci, un émulateur AWS local, pour la section AWS.

Le disque déclaré n'est pas le disque consommé

Le template KVM empaqueté dans dsoxlab crée des volumes qcow2 adossés à une image de base, et un volume qcow2 s'alloue à la demande : les 25 Go déclarés pour le plan de contrôle Kubernetes sont un plafond que la machine n'atteint que si elle les remplit. La mesure qui a fixé cette règle vient d'un utilisateur du catalogue Linux : 65 Go déclarés pour 3,2 Go réellement occupés, sur une machine qui provisionnait sans le moindre accroc.

Ce qui occupe réellement l'espace, c'est d'abord l'image de base de chaque distribution, téléchargée une fois dans le pool de stockage et partagée par toutes les machines qui l'utilisent, puis les écritures de chaque lab. Un lab qui formate un disque additionnel de 10 Go ou qui installe un cluster consomme davantage qu'un lab qui édite trois fichiers, mais aucun n'atteint le plafond déclaré.

dsoxlab doctor en tient compte, et c'est utile à savoir pour lire son rapport : il additionne les tailles déclarées et l'annonce comme un plafond alloué à la demande, mais il n'en fait pas un verdict. Une installation saine n'est donc pas peinte en rouge parce que ses volumes pourraient théoriquement remplir le pool. La mémoire, elle, garde le sien : MemAvailable d'un côté, la somme des ram_mb de l'autre, et le contrôle sort en échec si la seconde dépasse la première.

Le processeur décide du délai, pas seulement de la vitesse

La mémoire se calcule, le processeur se mesure. Après terraform apply, dsoxlab provision attend que chaque hôte réponde en SSH, dans une fenêtre de 180 secondes par défaut, réglable par la variable DSOXLAB_HOST_READY_TIMEOUT. Un hôte qui ne répond pas dans ce délai fait sortir la commande en code 8 : l'infrastructure existe, mais elle n'est pas utilisable en l'état, et dsoxlab status dit lequel et pourquoi.

C'est là que le nombre de processeurs compte. L'appliance est taillée pour 4 vCPU et 8 Go, et ce n'est pas une marge de confort : les trois hôtes du catalogue Linux se partagent 5120 Mo de mémoire, mais c'est le processeur qui décide s'ils répondent tous dans la fenêtre impartie. Un invité à 2 vCPU a déjà été vu annoncer un hôte prêt à 181 secondes, une seconde après la fermeture de la fenêtre. Le remède, quand le code 8 apparaît, est souvent plus de temps ou plus de vCPU, jamais une réinstallation.

Prévoir sa machine, selon ce qu'on joue

Le total à prévoir se compose de trois parts : les machines du catalogue, le système qui les héberge, et ce que vous gardez ouvert à côté. Dans l'appliance, importée avec 8192 Mo, les 6656 Mo du catalogue Kubernetes en laissent 1536 au système de l'appliance elle-même : c'est jouable, mais sans marge, et doctor le dira si MemAvailable passe sous la demande. Sur un poste Linux avec KVM, la même arithmétique s'applique à la mémoire libre du poste entier.

Ce que vous voulez jouer	Ce que la machine qui héberge dsoxlab doit offrir
Le lab de démonstration, le catalogue Terraform, les labs `shell` des autres catalogues	Aucun hyperviseur ; Docker pour les onze labs Terraform qui déclarent un service
Le catalogue Linux ou Ansible en labs `vm`	4 vCPU et 8 Go pour l'invité qui provisionne ; 5120 Mo ou 5632 Mo de mémoire libre pour les machines elles-mêmes
Le catalogue Kubernetes	Les mêmes 4 vCPU, et 6656 Mo de mémoire libre pour les deux machines, donc une appliance ou un poste qui en dispose après son propre système
Plusieurs catalogues en même temps	Les mémoires s'additionnent : Linux et Kubernetes ensemble, c'est 11776 Mo de machines. Chaque catalogue a son propre réseau libvirt et son propre state Terraform, donc ils cohabitent, mais `dsoxlab destroy` sur l'un avant de provisionner l'autre reste l'habitude la moins coûteuse

Sur un ordinateur à 8 Go au total, la documentation de l'appliance est sans détour : descendre la VM à 4096 Mo, jouer les labs shell, et laisser les labs vm à une machine mieux dotée. Sur 16 Go ou plus, tous les catalogues publiés tiennent, un à la fois.

Dépannage

Les trois cas ci-dessous sont ceux où la machine, et non le lab, est en cause. Chacun porte un message qui nomme le geste, et aucun ne se règle en réinstallant dsoxlab.

Symptôme	Cause	Solution
`doctor` dit « RAM : … disponibles pour … déclarés » en contrôle requis	La mémoire libre est inférieure à la somme des `ram_mb` du catalogue	Fermer ce qui consomme, agrandir la VM qui héberge dsoxlab, ou jouer les labs `shell`
`provision` sort en code 8, un hôte n'a pas répondu	Le processeur n'a pas suffi à démarrer tous les hôtes dans les 180 secondes	Relancer `provision`, donner plus de vCPU à la machine, ou allonger `DSOXLAB_HOST_READY_TIMEOUT`
`provision` échoue sur `Pool Not Found`	Sur une installation neuve de libvirt, aucun pool de stockage `default` n'existe	`dsoxlab doctor` affiche les commandes qui le créent ; ou déclarer `storage_pool` sous `infra.providers.kvm` dans le `meta.yml`

À retenir

Un lab shell ne coûte rien ; un lab vm coûte toutes les machines du catalogue, montées d'un coup par provision.
Les chiffres vivent dans infra.hosts du meta.yml, avec 1024 Mo, 1 vCPU et 10 Go par défaut quand l'auteur ne dit rien.
Relevé le 2026-09-26 : Linux 5120 Mo et 4 vCPU sur 3 machines, Ansible 5632 Mo et 5 vCPU sur 4, Kubernetes 6656 Mo et 4 vCPU sur 2, Terraform rien du tout.
Le disque déclaré est un plafond : volumes qcow2 alloués à la demande, 65 Go déclarés pour 3,2 Go occupés sur le catalogue Linux.
La mémoire décide du verdict de doctor, le processeur décide si les hôtes répondent dans les 180 secondes.
Une appliance à 8192 Mo joue Kubernetes sans marge ; un poste à 8 Go se limite aux labs shell.

Pour aller plus loin

Fichiers, variables d'environnement et codes de sortie : Le code 8, la variable DSOXLAB_HOST_READY_TIMEOUT et l'emplacement du state Terraform, expliqués un par un.
Monter l'infrastructure des labs vm : Le bloc infra: côté auteur, le choix du provider et le pool de stockage libvirt.