L'appliance dsoxlab : une machine virtuelle prête à jouer

L'appliance est une machine virtuelle Debian 13 où dsoxlab, Ansible, Terraform et un bureau sont déjà en place : on l'importe, on la démarre, on joue. Elle existe pour Windows et macOS, où uv tool install dsoxlab n'est pas une option confortable, et pour qui préfère une machine jetable à la sienne. Sous Linux, c'est la mauvaise réponse, et cette leçon le dit franchement : télécharger un demi-gigaoctet pour s'épargner une commande n'a aucun sens. Aucune connaissance de la virtualisation n'est supposée.

Ce que vous allez apprendre

• Vérifier que votre ordinateur a la mémoire et le disque que l'appliance demande.
• Choisir le bon fichier de la release, .ova ou .qcow2, et vérifier son empreinte avant l'import.
• Importer l'image dans VirtualBox, et ce qui change pour VMware.
• Activer la virtualisation imbriquée, sans laquelle les labs vm ne démarrent pas.
• Comprendre ce que le premier démarrage installe, et pourquoi il redémarre seul.

Ce qu'il vous faut

L'appliance n'est légère qu'au téléchargement. Une fois démarrée, elle réclame de la mémoire libre en plus de celle que votre système utilise déjà, et le premier démarrage télécharge environ 1,5 Go : dsoxlab, les hyperviseurs et le bureau. C'est voulu, rien n'est figé dans l'image, donc rien n'y est périmé.

	Minimum	Confortable
Mémoire vive	4 Go libres pour la VM	8 Go, obligatoire pour les labs vm
Disque	25 Go libres	40 Go
Processeur	2 cœurs	4 cœurs
Logiciel	VirtualBox (gratuit), ou VMware Workstation et Fusion, voir plus bas
Réseau	une connexion, le temps du premier démarrage

Glissez pour voir

Les chiffres de la colonne « confortable » ne sont pas une estimation : la recette de l'image annonce 4 processeurs et 8 Go parce que les trois machines du catalogue Linux se partagent 5120 Mo, et qu'un invité à 2 vCPU a déjà été vu annoncer un hôte prêt à 181 secondes, une seconde après la fenêtre d'attente. La leçon Dimensionner sa machine pour les labs détaille ces chiffres catalogue par catalogue.

Où l'image est publiée, et quel fichier prendre

Les images sont attachées aux releases du projet sur GitHub, sur la page github.com/stephrobert/dsoxlab/releases, et la règle du projet est qu'elles y sont reconstruites à chaque version publiée, correctifs compris. La release v0.2.5, publiée le 2026-09-26, est la première à les porter, et c'est le format qui décide de l'hyperviseur : l'.ova s'importe dans VirtualBox et VMware, le .qcow2 sert à KVM/libvirt et à Proxmox. Les tailles ci-dessous sont celles que la release déclare, relevées le jour même.

Fichier	Pour	Taille
dsoxlab-appliance-0.2.5.ova	VirtualBox sous Windows, Linux et Mac Intel ; VMware Workstation et Fusion	416 Mio
dsoxlab-appliance-0.2.5.qcow2	QEMU/KVM, libvirt, Proxmox	433 Mio
SHA256SUMS	Vérifier ce qu'on a téléchargé, avant d'importer	194 octets
provenance.intoto.jsonl	L'attestation de provenance SLSA v1 de la release, produite par release.yml : relue le jour même, elle couvre la roue et l'archive source Python, pas les images	11 Kio

Glissez pour voir

Si vous débutez, prenez le .ova. Seuls les deux derniers jeux d'images sont conservés : les releases plus anciennes gardent leur page et leurs distributions Python, sans leurs images, parce qu'une image qui n'épingle rien n'offre aucune reproductibilité, seulement son poids. Le nom du fichier suit toujours le numéro de la release sans son v : la release suivante portera un dsoxlab-appliance-<version>.ova du même modèle.

Deux choix de conception expliquent ce poids réduit. L'image n'épingle aucune version de dsoxlab : le premier démarrage installe la dernière publiée, ce qui évite de republier un demi-gigaoctet à chaque correctif. Et elle n'embarque pas les hyperviseurs : ils ne s'installent au premier démarrage que si l'hôte expose la virtualisation imbriquée, vérifiée en direct et jamais supposée.

Étape 1 : installer VirtualBox

VirtualBox est l'hyperviseur de référence de l'appliance, celui sur lequel l'import, le démarrage et le bureau ont été éprouvés. Il se télécharge sur virtualbox.org, et le paquet à prendre dépend du système :

• Windows : Windows hosts. Double-cliquez, suivez l'assistant, acceptez l'installation des pilotes réseau quand Windows la demande.
• macOS Intel : macOS / Intel hosts. Après l'installation, macOS peut bloquer l'extension : ouvrez Réglages Système, Confidentialité et sécurité, puis Autoriser pour Oracle.
• Linux : votre gestionnaire de paquets, ou le paquet de la page.

L'Extension Pack proposé sur la même page n'est pas nécessaire : rien dans l'appliance ne s'en sert.

Étape 2 : télécharger l'image et vérifier son empreinte avant l'import

Téléchargez l'.ova de la release et, à côté, le fichier SHA256SUMS. Un fichier de 416 Mio venu d'Internet se vérifie avant d'être importé, jamais après : c'est la règle de la chaîne d'approvisionnement que ce site enseigne partout, et une image qu'on démarre sans contrôle contredirait tout le propos. Calculez l'empreinte du fichier reçu :

# Windows, dans PowerShell
Get-FileHash .\dsoxlab-appliance-0.2.5.ova -Algorithm SHA256

# macOS et Linux
shasum -a 256 dsoxlab-appliance-0.2.5.ova

La valeur affichée doit être celle que SHA256SUMS donne pour ce fichier. Voici le contenu du fichier publié avec la v0.2.5, relu le jour de la release : l'empreinte de l'.ova commence par aad053dc, celle du .qcow2 par 5b401088.

aad053dc69a7a2960a630828006cc8d5fb51563f8a24565b7a93064c14cdf4cc  ./dsoxlab-appliance-0.2.5.ova
5b40108895850fd40d97a9ec8be9046bcfbc87a3db8df32c83d78b707da5e7f0  ./dsoxlab-appliance-0.2.5.qcow2

Si la valeur diffère, le téléchargement est incomplet ou altéré : recommencez-le plutôt que d'importer une image qui échouera plus loin, sur une erreur d'OVF qui ne nommera pas sa cause. Les deux images sont en x86-64, ce qui compte pour les Mac récents, traités plus bas.

Étape 3 : importer l'image

Dans VirtualBox, Fichier, Importer un appareil virtuel, choisissez le fichier .ova, puis Suivant. Un double-clic sur le .ova ouvre la même fenêtre. L'écran suivant liste ce que la machine annonce, 4 processeurs et 8192 Mo de mémoire, et ces valeurs se modifient ici même. Le moment est bien choisi :

• votre ordinateur a 8 Go de RAM au total : descendez la VM à 4096 Mo. Les labs shell fonctionneront, les labs vm non, et dsoxlab doctor vous le dira au lieu de vous laisser deviner ;
• votre ordinateur a 16 Go ou plus : laissez 8192 Mo.

Cliquez sur Terminer. L'import dure une à trois minutes, le temps que VirtualBox décompresse le disque.

Ce qui change pour VMware Workstation et Fusion

La même image .ova sert pour VMware Workstation et Fusion, avec une nuance qu'il vaut mieux connaître : cet import n'a pas été éprouvé directement sur VMware. Ce qui est garanti à chaque construction, c'est que le descripteur OVF est validé contre le schéma DMTF et déclare ce que VMware attend. VirtualBox importe à peu près n'importe quoi, VMware contrôle : la conformité à la spécification est la seule façon honnête de tenir l'affirmation sans licence.

Pour les labs vm, VMware a son propre réglage de virtualisation imbriquée, Virtualize Intel VT-x/EPT, dans les réglages processeur de la machine, machine éteinte. Le reste des étapes, démarrage, connexion et premier lab, est identique.

Étape 4 : activer la virtualisation imbriquée pour les labs vm

Cette étape se saute si vous ne visez que les labs shell. Un lab de type vm démarre de vraies machines dans l'appliance ; il faut donc que votre ordinateur autorise une machine virtuelle à en lancer d'autres. Ce réglage se fait en dehors de l'appliance, celle-ci étant éteinte, parce que l'imbrication est une caractéristique de l'hôte, pas de l'invité : rien d'installé dans l'appliance ne peut la produire.

Dans VirtualBox, sélectionnez la machine, puis Configuration, Système, Processeur, et cochez Activer VT-x/AMD-V imbriqué. En ligne de commande, le nom de la machine est celui affiché dans VirtualBox après l'import :

VBoxManage modifyvm "dsoxlab-appliance-<version>" --nested-hw-virt on

Si la case est grisée, votre processeur ou votre BIOS ne l'expose pas, et les labs shell restent entièrement jouables. Un cas fréquent sous Windows mérite d'être nommé : l'imbrication est indisponible dans VirtualBox quand Hyper-V ou WSL2 tient déjà l'hyperviseur de la machine.

Étape 5 : démarrer, et laisser faire

Sélectionnez la machine et cliquez sur Démarrer. Ce que vous allez voir se joue en trois temps, sans rien avoir à taper :

1. quelques secondes de texte blanc sur fond noir, le démarrage de Debian ;
2. plusieurs minutes où la machine semble attendre sur une invite de connexion. Elle ne dort pas : elle installe dsoxlab, les hyperviseurs et le bureau. Comptez cinq à quinze minutes selon votre connexion ;
3. la machine redémarre d'elle-même, et affiche l'écran de connexion.

Ce redémarrage n'est pas un incident : l'appartenance aux groupes et le bureau ne prennent effet qu'au démarrage suivant. Si quelque chose échoue, la machine le dit et recommence au démarrage suivant : elle ne se marque jamais configurée à tort. La cause habituelle est l'absence de réseau dans la machine virtuelle ; vérifiez sa carte réseau dans Configuration, Réseau, puis redémarrez-la.

Étape 6 : se connecter

L'utilisateur est student et le mot de passe dsoxlab. La machine exige de changer ce mot de passe tout de suite, et c'est voulu : un mot de passe livré avec une image publique n'est secret pour personne. Elle demande l'ancien, puis le nouveau deux fois. Vous arrivez sur un bureau XFCE ; le terminal est dans la barre du bas, deuxième icône.

Étape 7 : jouer un premier lab

Dans le terminal, le lab de démonstration confirme que tout fonctionne avant d'investir dans un catalogue complet. Il ne demande ni VM ni conteneur :

dsoxlab demo                 # installe un catalogue de démonstration d'un lab
cd ~/.local/share/dsoxlab/demo

dsoxlab course premiers-pas     # la leçon
dsoxlab run premiers-pas        # vous dépose dans le répertoire de travail
dsoxlab challenge premiers-pas  # la mission
dsoxlab check premiers-pas      # les tests, et la note

Ensuite, installez un vrai catalogue. doctor dit ce que cette machine peut faire et ce qui manque, et nomme le seul choix qui reste quand le catalogue propose plusieurs hyperviseurs :

dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training
dsoxlab doctor                  # ce que cette machine peut faire, et ce qui manque
dsoxlab list-labs               # les 86 labs du catalogue
dsoxlab use --provider kvm      # le choix que doctor nomme
dsoxlab start <identifiant-du-lab>   # contexte, prérequis, infra, session

Sur un lab vm, start affiche ses contrôles requis au vert, puis Terraform monte les machines du lab : des VM dans la VM, ce qui est exactement ce que l'étape 4 a rendu possible.

Ce qu'il y a dedans

L'image est une Debian 13 minimale, plus ce qu'un poste de lab demande : git, curl, vim, python3, man, Ansible et Terraform. Après le premier démarrage s'y ajoutent dsoxlab, les hyperviseurs et le bureau. La documentation et les locales autres qu'anglaise et française sont exclues des paquets, ce qui fait l'essentiel du demi-gigaoctet qu'on ne télécharge pas.

Limites connues

Trois limites méritent d'être connues avant de bâtir dessus. Un utilisateur, une machine : l'appliance n'est pas un serveur de classe partagé, et un formateur qui sert plusieurs apprenants regarde plutôt la leçon Monter l'infrastructure des labs vm. Le disque fait 20 Go : de quoi loger un catalogue et quelques VM de lab, pas un cluster Kubernetes ; il s'agrandit dans votre hyperviseur au besoin. Aucune mise à jour automatique : uv tool upgrade dsoxlab met l'outil à jour dans une appliance déjà installée, et réimporter une image plus récente n'apporte que le système mis à jour, puisque dsoxlab s'installe à neuf au premier démarrage de chaque machine.

Dépannage

Chaque ligne nomme la cause la plus fréquente et le geste qui la règle. Quand aucune ne correspond, dsoxlab support --issue remplit un rapport de diagnostic anonymisé et ouvre l'issue au bon endroit : un rapport vaut mieux qu'un contournement.

Symptôme	Cause la plus fréquente	Geste
La machine reste sur une console, pas de bureau	Le premier démarrage n'a pas abouti	Il recommence au démarrage suivant : redémarrez la VM après avoir vérifié son réseau
« Temporary failure in name resolution »	La VM n'a pas de réseau	Configuration, Réseau, carte 1 activée en NAT
dsoxlab doctor dit qu'il manque la virtualisation imbriquée	Elle s'active sur votre ordinateur, pas dans la VM	Étape 4, appliance éteinte
doctor dit « RAM : … disponibles pour … déclarés »	La VM est trop petite pour ce catalogue	Augmentez sa mémoire, ou jouez les labs shell
L'import échoue sur une erreur d'OVF	Téléchargement incomplet	Revérifiez l'empreinte SHA256

Glissez pour voir

À retenir

• L'appliance sert Windows et macOS Intel ; sous Linux, uv tool install dsoxlab reste la bonne réponse.
• L'image est publiée avec la release, depuis la v0.2.5 : l'.ova pour VirtualBox et VMware, le .qcow2 pour KVM et Proxmox, SHA256SUMS à côté.
• L'empreinte se vérifie avant l'import, jamais après : une image de 416 Mio démarrée sans contrôle contredit tout ce que le site enseigne.
• Elle n'épingle rien : le premier démarrage installe le dernier dsoxlab et, si l'hôte le permet, les hyperviseurs.
• 4 processeurs et 8 Go sont mesurés, pas estimés ; avec 8 Go au total sur l'hôte, descendre à 4096 Mo et se limiter aux labs shell.
• La virtualisation imbriquée s'active sur l'hôte, appliance éteinte, et reste indisponible dans VirtualBox sous Windows si Hyper-V ou WSL2 est actif.
• Le premier démarrage dure cinq à quinze minutes et redémarre seul ; un échec se rejoue au démarrage suivant.

Pour aller plus loin

• Les principales commandes de dsoxlab : Ce que start enchaîne dans l'appliance, et chaque commande prise seule.
• Fichiers, variables d'environnement et codes de sortie : Où l'appliance range la progression et le journal, pour les sauvegarder avant de la jeter.
• Monter l'infrastructure des labs vm : La virtualisation imbriquée vue du formateur, avec les réglages KVM, VMware et VirtualBox côte à côte.

×

📖 Voir la documentation →