[P1] Images de VM prêtes à l'emploi : démarrer sans installer l'environnement à la main

[stephrobert]

Contexte

La proposition ne vient pas de nous : un contributeur a déjà produit deux images et ouvert deux issues sur le catalogue Linux, en attente de réponse depuis le 27 juillet 2026.

• linux-dsoxlab-training#28 : image VirtualBox (OVA + README), publiée sur son fork.
• linux-dsoxlab-training#29 : équivalent VMware.

Sa motivation, citée : « en suivant les labs l1, l'installation manuelle (Python, uv, dsoxlab, pytest...) peut être un frein pour un vrai débutant ». Il propose d'ouvrir une PR et demande où héberger les artefacts, sur son fork ou ici.

Sa question est restée sans réponse, et c'est le vrai coût aujourd'hui : quelqu'un a fait le travail et attend qu'on lui dise sous quelle forme le reprendre.

Pourquoi l'issue est ici et pas dans le catalogue

L'image embarque le moteur et ses prérequis (Python, uv, dsoxlab, l'hyperviseur, Terraform, ansible-runner), pas des labs. Elle est donc agnostique du domaine, au même titre que les templates Terraform et cloud-init déjà packagés ici.

Corollaire à tenir : l'image ne doit embarquer aucun catalogue. Y figer linux-dsoxlab-training en ferait une image Linux, et rejouerait l'anti-pattern « embarquer des templates de labs ». Le catalogue se choisit au premier démarrage, ce qui en fait le premier consommateur naturel de #78 (dsoxlab init).

Ce qui justifie vraiment l'image, et ce qui ne la justifie pas

À trancher explicitement, parce que le périmètre en dépend entièrement.

Pour un utilisateur Linux, l'image n'est pas la bonne réponse : uv tool install dsoxlab l'est (#70), et #72 lui donne un premier lab sans rien cloner. Fabriquer une image pour lui, c'est distribuer plusieurs gigaoctets pour éviter une commande.

Pour un utilisateur Windows ou macOS, l'image est la seule voie : pyproject.toml classe le projet en Operating System :: POSIX :: Linux, et ni KVM ni Incus n'existent sur ces systèmes. C'est là que se trouve la valeur, et probablement la majorité des apprenants d'une formation Linux, qui par définition n'ont pas encore de poste Linux.

Le périmètre proposé découle de ce constat : l'image cible d'abord Windows et macOS, et son README doit dire à un utilisateur Linux d'installer le paquet plutôt que de télécharger 5 Go.

Le point dur : la virtualisation imbriquée

C'est la question à instruire avant de produire quoi que ce soit, parce qu'elle décide de ce que l'image sait faire.

Les labs vm du catalogue Linux montent de vraies VMs via KVM ou Incus. Les faire tourner dans une VM VirtualBox ou VMware exige la virtualisation imbriquée, qui n'est ni universelle ni active par défaut :

• VirtualBox : nested VT-x/AMD-V, dépend du CPU, et indisponible sur un Windows où Hyper-V ou WSL2 tient déjà l'hyperviseur.
• VMware Workstation / Fusion : case « Virtualize Intel VT-x/EPT » à cocher, machine éteinte.
• macOS Apple Silicon : ni VirtualBox ni KVM. Voie distincte (UTM/QEMU aarch64), et les images cloud x86 du catalogue n'y tournent pas nativement.

Deux issues de terrain rappellent que la marge est déjà mince même sans imbrication : linux-dsoxlab-training#36 rapporte un provisionnement qui expire sur un hôte à 2 vCPU / 4 Go, avec un hôte prêt à 181 secondes pour un délai de 180. Sous une couche de virtualisation supplémentaire, cette marge disparaît.

Il faut donc décider, et l'écrire dans le README de l'image :

1. soit l'image ne sert que les labs shell, ce qui est honnête, immédiatement livrable, et couvre déjà les 87 labs de terraform-training et les 20 labs shell du catalogue Linux ;
2. soit elle sert aussi les labs vm, et alors elle doit documenter l'activation de l'imbrication par hyperviseur, annoncer des prérequis matériels mesurés (pas estimés), et dsoxlab doctor doit détecter l'absence d'imbrication et le dire clairement au lieu de laisser un provision expirer.

Le point 2 impose au minimum un contrôle nouveau dans doctor : « virtualisation imbriquée indisponible, les labs vm ne peuvent pas tourner ici ».

Formats à produire

Par ordre de couverture décroissante, pas tous d'un coup :

Format	Cible	Remarque
OVA (OVF)	VirtualBox et VMware	Un seul artefact pour les deux écosystèmes : c'est le point de départ
qcow2	KVM/libvirt, Proxmox	Utile aux formateurs qui hébergent des postes
VHDX	Hyper-V	Le cas Windows où VirtualBox est justement inutilisable
UTM / QEMU aarch64	macOS Apple Silicon	Voie séparée, à évaluer avant de promettre
Vagrant box	postes scriptés	Optionnel

Construction et distribution

Construction reproductible, versionnée dans ce dépôt. Une image fabriquée à la main n'est régénérable par personne d'autre et pourrit à la première mise à jour. Une définition Packer en HCL, construite en CI, est la forme attendue.

Ne pas régresser sur la chaîne d'approvisionnement. Ce projet publie avec Trusted Publishing, attestations et provenance : distribuer plusieurs gigaoctets de binaire opaque sans preuve serait le maillon faible de tout l'édifice. Il faut donc SHA256SUMS, une attestation de build GitHub, et la publication sur les Releases du dépôt plutôt que sur un fork personnel.

Taille. Une OVA complète pèse facilement 2 à 6 Go, or une release GitHub plafonne à 2 Go par fichier. À trancher : compression, découpage, ou hébergement externe avec empreintes publiées ici.

Obsolescence. Une image figée sur une version de dsoxlab est périmée à la release suivante. Proposition : l'image embarque l'outillage, et met dsoxlab à jour au premier démarrage ; elle n'est republiée que lorsque sa base change (OS, hyperviseur, Terraform), pas à chaque version du moteur.

Critères d'acceptation

• Une décision écrite sur le périmètre : labs shell seulement, ou labs vm inclus avec imbrication documentée.
• Une définition de build reproductible versionnée dans ce dépôt, jouable par un tiers.
• La construction tourne en CI et publie sur les Releases GitHub, pas sur un fork personnel.
• Au moins le format OVA, importable dans VirtualBox et dans VMware, vérifié dans les deux.
• SHA256SUMS publié et attestation de build attachée à la release.
• L'image n'embarque aucun catalogue : le choix se fait au premier démarrage.
• Un README d'image qui indique aux utilisateurs Linux d'installer le paquet plutôt que de télécharger l'image.
• Des prérequis matériels mesurés (vCPU, RAM, disque), pas estimés, et vérifiés jusqu'à un dsoxlab check vert.
• Si le périmètre inclut les labs vm : doctor détecte l'absence de virtualisation imbriquée et le nomme explicitement.
• Une réponse apportée au contributeur sur les deux issues d'origine, quelle que soit la décision.

Lot

P1, lot 0.2.x. À instruire après #70 (installation en une commande), #72 (dsoxlab demo) et #78 (dsoxlab init) : ces trois-là réduisent le besoin sans le supprimer, et l'image doit s'appuyer sur init pour rester agnostique.

Dépend de : #70, #72, #78. Touche : #66 (parcours produit).

[stephrobert]

Cette issue demande des prérequis matériels mesurés, pas estimés. Un audit du setup à froid vient de les produire, sur une VM Ubuntu 24.04.4 LTS neuve, avec dsoxlab 0.1.40 depuis PyPI et le catalogue Linux, les trois hôtes du meta.yml en fonctionnement sous KVM.

Ressource	Mesure
RAM allouée aux 3 VM	5120 Mio (2048 + 1536 + 1536)
RAM réellement utilisée, hôte compris	3893 Mo sur 11959
Disque, pool libvirt	3,2 Go (2 images de base + 3 overlays)
Disque, state Terraform	26 Mo
Disque total / (OS + outils + labs)	5,9 Go
Durée d'un provision KVM réussi	122 s
Durée d'un provision Incus réussi	119 s
Durée d'un destroy	3 s

Ce qu'on peut en tirer pour dimensionner l'image :

• CPU : 4 vCPU est un plancher, 8 vCPU confortable. C'est le facteur qui décide du respect du délai de 180 s au démarrage parallèle des trois VM.
• RAM : 8 Go strict minimum (5,1 Go pour les VM, plus l'hôte), 12 Go confortable. 4 Go ne peuvent pas fonctionner, les VM seules n'y tiennent pas.
• Disque : 20 Go suffisent, 40 Go confortables. La consommation réelle est modeste, le reste est de la marge de croissance des overlays.

Sur la virtualisation imbriquée, un point qui pèse directement sur l'arbitrage de périmètre. L'audit a tourné avec l'imbrication active sur l'hôte (/sys/module/kvm_intel/parameters/nested à Y, vmx exposé dans la VM, /dev/kvm présent), et de vraies VM ont bien été provisionnées dans la VM d'audit, sur les deux providers locaux, jusqu'à un dsoxlab check vert. La voie « labs vm depuis une image » n'est donc pas théorique : elle marche, à condition que l'imbrication soit disponible.

Mais la marge invoquée plus haut se confirme dans l'autre sens : mes hôtes AlmaLinux étaient prêts en 45 s sur 8 vCPU, là où linux-dsoxlab-training#36 décrit 181 s sur 2 vCPU pour un délai de 180. Le facteur limitant est bien le CPU au démarrage parallèle, pas l'agent Incus : sur 8 vCPU, l'agent AlmaLinux est arrivé sans le correctif de l'issue #36, et le provisionnement Incus a réussi en 119 s.

Deux conséquences pour cette issue :

1. si l'image cible les labs vm, elle doit annoncer 4 vCPU et 8 Go pour la VM elle-même, ce qui suppose un hôte à 8 vCPU et 16 Go. C'est un prérequis lourd à assumer explicitement dans le README de l'image ;
2. le contrôle doctor évoqué dans les critères d'acceptation (« virtualisation imbriquée indisponible ») est bien le bon geste : c'est le seul prérequis matériel irréductible, et son absence produit aujourd'hui un provision qui expire sans rien expliquer.

Le rapport complet a par ailleurs donné lieu à dix issues sur ce dépôt (#93, #94, #98, #99, #101, #102, #105, #106, #107, #108) et deux sur le catalogue (linux-dsoxlab-training#40 et #41).

[cedric-ribier]

Merci d'avoir consolidé la réponse ici plutôt que de la disperser sur les
deux issues — ça donne un cadre net pour la suite, et je préfère
répondre en un seul endroit aussi.

Sur ce qui existe déjà

Les images publiées sur mon fork (#28, #29) ont été construites
manuellement, sans Packer ni CI — donc, en l'état, elles ne répondent
pas à l'essentiel de vos critères d'acceptation : pas reproductibles,
pas de SHA256SUMS, pas d'attestation de build, dépôt linux-dsoxlab-training copié. Je
préfère le dire clairement plutôt que de laisser croire qu'elles sont
prêtes à intégrer telles quelles — elles ont surtout servi à valider que
l'idée avait du sens et que la virtualisation imbriquée fonctionnait
dans mon setup, pas comme livrable final.

Sur le périmètre (shell vs vm)

Mes deux images actuelles couvrent aussi les labs vm (KVM/Incus
fonctionnels dans mon setup). Vu votre lecture de #36 et la marge déjà
fragile sans imbrication, je suis d'accord pour repartir sur un
périmètre shell-only en v1 — quitte à réutiliser ce que j'ai déjà
validé sur le volet vm pour une itération suivante, une fois le
contrôle doctor en place pour détecter l'absence d'imbrication.

Sur le format (OVA, VirtualBox et VMware)

J'ai déjà les deux versions construites manuellement (VirtualBox et
VMware), donc la virtualisation imbriquée est confirmée fonctionnelle
dans les deux écosystèmes sur mon setup (Intel i9). Pour la version
reproductible en CI : je propose un builder virtualbox-iso comme
source unique (export OVA natif, CI GitHub-hosted directement
utilisable), avec validation manuelle de l'import de cette même OVA
dans VMware avant chaque publication, plutôt qu'une double chaîne de
build. VMware nécessite ovftool (propriétaire, compte Broadcom) que
les runners GitHub-hosted n'ont pas, donc dupliquer la build ajouterait
une dépendance CI lourde pour un gain marginal si l'OVA VirtualBox
s'importe proprement dans VMware (Pour autant, j'ai de forte réserve sur ce point).

Sur la taille (limite 2 Go des Releases)

Pas de mesure exacte sur mes images actuelles à donner ici tout de
suite, je vérifie et je reviens avec un chiffre réel plutôt que
d'avancer une estimation. Une image shell-only sans hyperviseur
interne devrait être nettement plus légère que mes versions actuelles
(qui embarquent KVM/Incus) pour comparaison les images construite
manuellement sur mon fork pèsent, VMWare 1,67 Go et Virtualbox 1,74 Go.

Sur la distribution de base

Mes images actuelles sont en Debian — je proposerais de rester dessus
(Debian 13/trixie minimal, sans snapd) pour la version reconstruite,
sauf préférence contraire de votre part pour cohérence avec de futurs
artefacts terraform-training/ansible-training.

Sur la séquence (#70, #72, #78)

Je note la dépendance et le lot P1/0.2.x. Je peux commencer à convertir
ce que j'ai déjà (scripts de provisioning, config réseau/hyperviseur
validée manuellement) en définition Packer versionnée, sans rien
publier avant que dsoxlab init (#78) existe, pour arriver prêt une
fois la dépendance résolue plutôt que de tout découvrir à ce moment-là.
Dites-moi si ça vous convient ou si vous préférez que j'attende
complètement avant de commencer cette conversion.

[stephrobert]

Position révisée : en fin de file, et pour une raison précise

Un second audit recommande de garder cette issue pour la fin de la milestone, voire au-delà. L'argument n'est pas que l'idée soit moins bonne : elle reste la seule voie pour un utilisateur Windows ou macOS, ce que cette issue établissait déjà.

L'argument est le coût récurrent. Publier une image, ce n'est pas livrer un artefact, c'est ouvrir une chaîne d'approvisionnement à tenir :

• la construction, à garder reproductible quand la distribution de base change ;
• la publication et son hébergement, plusieurs gigaoctets par format ;
• la provenance et les empreintes, sur des artefacts qui ne passent pas par PyPI ;
• les mises à jour, dès qu'une vulnérabilité touche la base ou l'un des outils embarqués ;
• la compatibilité, à chaque version de VirtualBox, VMware, Hyper-V ou UTM.

Rien de cela n'est bloquant, et tout cela est permanent. Un projet dont la 0.2.0 vise « qu'un inconnu puisse installer, comprendre et diagnostiquer » a plus à gagner à d'abord geler son contrat (#76, #77) et à rendre le provisionnement récupérable (#107).

Ce qui reste vrai

La demande d'origine ne disparaît pas : deux issues du catalogue Linux (#28 et #29) viennent d'un contributeur qui a déjà produit les images et attend une réponse sur l'hébergement. Cette réponse lui a été donnée : le sujet vit ici, et les artefacts iront sur les Releases de ce dépôt.

Le périmètre à trancher reste celui décrit plus haut : la virtualisation imbriquée décide si ces images servent les labs vm ou seulement les labs shell. Trancher cette question ne coûte rien et peut se faire dès maintenant, indépendamment de la construction. C'est même le préalable : une image qui ne ferait tourner que les labs shell est un artefact bien plus léger à produire et à maintenir.

[cedric-ribier]

Je prends note de la réorientation, le raisonnement sur le coût récurrent tient, et reporter le sujet plutôt que de trancher dans l'urgence a du sens.

Un point sur lequel je maintiens ma position, pour qu'elle reste tracée ici : la virtualisation imbriquée est une caractéristique de l'hôte, pas du contenu de l'image, l'exclure des providers ne la rend disponible nulle part où elle ne l'était pas, elle retire juste l'option à ceux dont l'hôte la supporterait. Je comprends que ce n'est pas l'argument qui motive le report (c'est bien le coût de maintenance, pas le fonctionnement), donc je ne le pousse pas plus loin pour l'instant, mais je voulais que ce soit écrit plutôt que silencieusement abandonné.

Un brouillon reste disponible ici : https://github.com/cedric-ribier/dsoxlab-runtime. Je vais le mettre à jour pour refléter les points déjà tranchés, notamment l'hébergement : les artefacts vivront sur les Releases de ce dépôt.

Pendant que le sujet est en pause, je vais construire une variante embarquant les providers (libvirt/QEMU/Incus) pour mesurer son poids réel plutôt que de l'estimer. Ça donnera une donnée concrète sur la question du poids le jour où le périmètre revient à l'ordre du jour, dans un sens comme dans l'autre.