Cours Ubuntu 26.04 / Préparer une VM de laboratoire et sa console de récupération

Pour préparer un laboratoire Ubuntu, décidez où installer le système, quels réglages vous allez modifier et comment reprendre la main si l’accès distant échoue. Une VM Ubuntu Server 26.04 avec un disque virtuel neuf, des ressources adaptées et une console accessible constitue le point de départ. Distinguez dès maintenant réseau NAT, réseau de laboratoire, snapshots et sauvegardes indépendantes.

Commencer avec une VM et un objectif précis

Une machine virtuelle (Virtual Machine, VM) utilise une partie des ressources d’un ordinateur hôte pour exécuter un système invité. Si Windows est l’hôte, Ubuntu installé dans la VM est l’invité. Ce laboratoire fournit un espace pour modifier des comptes, services et configurations sans employer votre système de travail comme serveur d’essai.

Commencez avec une VM Ubuntu Server pour les comptes, Secure Shell (SSH), les services et la restauration de fichiers. Une seconde VM Server jouant le rôle de client n’est nécessaire que lorsqu’un exercice compare des accès depuis différentes machines. Il n’est pas utile de faire fonctionner plusieurs invités dès la première installation.

Le guide général d’un environnement Linux en VM couvre création, installation et récupération. Cette leçon prépare la fiche de configuration : vous devez pouvoir expliquer les choix avant d’ouvrir les écrans de création.

Vérifier l’hôte et le logiciel de virtualisation

Le logiciel doit prendre en charge le système hôte, son architecture et le système invité. Les possibilités d’un hôte Intel/AMD x64 et celles d’un hôte ARM64 peuvent différer. Le cours peut suivre les menus de VirtualBox 7.2 pour une VM classique ; ce repère n’implique pas que toutes les fonctions existent sur chaque hôte. Vérifiez d’abord l’architecture et l’image Ubuntu retenues.

  1. Relevez version du système hôte et architecture du processeur. Sous Windows, consultez Paramètres → Système → Informations système ; sous macOS, le menu Pomme → À propos de ce Mac.
  2. Évaluez la mémoire disponible avec vos applications habituelles ouvertes, pas seulement la mémoire totale. Sous Windows, Gestionnaire des tâches → Performances → Mémoire aide à observer l’usage.
  3. Contrôlez l’espace libre du volume qui contiendra les VM. ISO, disques virtuels, snapshots et exports utilisent tous cet espace.
  4. Lisez les conditions officielles de virtualisation matérielle, de prise en charge des invités et de coexistence avec les autres fonctions de virtualisation de votre hôte.

L’introduction officielle de VirtualBox 7.2 décrit l’hôte et l’invité ; le guide de création d’une VM décrit les paramètres proposés. Devant une erreur de démarrage, relevez son texte et comparez les conditions de votre version. Désactiver au hasard une protection Windows ou lancer simultanément des VM de plusieurs hyperviseurs ne constitue pas un diagnostic de compatibilité.

Prévoir CPU, mémoire et espace disque

Les valeurs suivantes sont un exemple de plan de laboratoire, pas les exigences minimales officielles d’Ubuntu ni une mesure de performance. Ajustez-les à vos ressources et à la charge prévue. La mémoire attribuée à une VM en fonctionnement réduit celle qui reste à l’hôte ; réservez aussi de la capacité pour le navigateur et vos autres outils.

Élément Exemple de plan Critère de choix
Ubuntu Server 2 processeurs virtuels, 4 Go de RAM, nouveau disque dynamique de 30 Go. Ressources disponibles sur l’hôte, services simultanés, conteneurs, compilations et données.
Réseau initial Premier adaptateur en NAT, sans redirection de port. Téléchargements depuis l’invité ; chemin d’administration à prévoir séparément.
Récupération Connexion console, snapshot d’un état fonctionnel, copie indépendante des fichiers importants. Accès sans SSH et disponibilité de la sauvegarde hors du stockage de la VM.

Comparez également les conditions d’installation d’Ubuntu Server avec celles des services visés. Une petite VM qui démarre ne possède pas nécessairement assez de mémoire et de stockage pour une base de données ou plusieurs conteneurs.

Un disque dynamique commence avec un fichier relativement petit puis peut grandir jusqu’à la capacité configurée. Prévoyez l’espace futur sur l’hôte, y compris celui des snapshots. Agrandir plus tard le disque virtuel ne suffit pas à étendre automatiquement la partition, les volumes logiques et le système de fichiers de l’invité.

Pour la première installation, un seul disque virtuel neuf facilite l’identification de la destination. Évitez le passage direct d’un disque physique de l’hôte. Une VM n’empêche pas les erreurs si vous lui présentez des données réelles à modifier.

Choisir un réseau selon le trajet à vérifier

NAT signifie Network Address Translation, ou traduction d’adresses réseau. Dans le mode NAT simple de VirtualBox, l’invité peut initier des connexions vers l’extérieur, par exemple pour télécharger des paquets. Cela n’offre pas automatiquement un accès entrant direct depuis l’hôte vers l’adresse privée de l’invité. Une redirection de port ou un autre réseau adapté sera nécessaire pour SSH depuis l’hôte.

Mode Usage dans le laboratoire Limite à retenir
NAT simple Sortie de la VM vers les dépôts et Internet. Accès entrant à prévoir ; les NAT simples de deux VM ne créent pas à eux seuls un réseau commun entre ces VM.
Réseau privé hôte, ou host-only Communication entre l’hôte et les VM du même réseau dédié. Pas d’accès Internet fourni par ce seul mode.
Accès par pont, ou bridged VM connectée au réseau physique comme un équipement supplémentaire. Politique du LAN, attribution d’adresses et autorisations à respecter.

Le mode NAT Network est encore une autre option de VirtualBox ; ne le confondez pas avec le NAT simple de chaque VM. La documentation officielle des modes réseau décrit leurs trajets. Sur un réseau d’entreprise, d’école ou public, n’utilisez pas le pont sans connaître les règles applicables.

Le démarrage du cours utilise NAT sans publier à l’avance des ports de services qui ne sont pas encore installés. Une redirection SSH ultérieure peut être limitée à l’adresse de bouclage de l’hôte pour un accès depuis cet hôte. Ce réglage reste distinct d’une redirection sur un routeur Internet ou d’une règle de sécurité cloud.

Pour les exercices distants entre machines, le plan prévoit un adaptateur 1 en NAT pour Internet et un adaptateur 2 dans le même réseau privé hôte. Voici des adresses de planification pour un nouveau sous-réseau 192.168.56.0/24 :

  • Hôte : 192.168.56.1.
  • VM Server à administrer : 192.168.56.20.
  • Seconde VM Server employée comme client : 192.168.56.10, à créer lorsque nécessaire.

Ces adresses ne sont pas déjà configurées. Elles seront appliquées à l’interface host-only, sans remplacer l’adresse de la carte NAT. N’ajoutez pas de passerelle Internet ni de serveur DNS inventé sur cette interface. Avant de fixer les adresses, vérifiez aussi le service DHCP du réseau host-only pour éviter les doublons avec ses allocations.

Si un VPN ou un autre réseau utilise déjà cette plage, choisissez une plage libre autorisée par le logiciel et adaptez ensemble adresses et masques. Certains hôtes imposent des plages ou une forme particulière de réseau host-only : sous macOS récent, VirtualBox distingue notamment Host-Only Network et l’ancien Host-Only Adapter. La console et les réglages propres à votre hôte restent les références pour la création.

Préparer une console indépendante de SSH

SSH dépend du réseau, du pare-feu et de la configuration du serveur. Un seul mauvais réglage peut couper l’accès distant. La fenêtre de la VM montre directement l’écran de l’invité : sa console offre une voie de correction indépendante du réseau de l’invité. Elle ne répare cependant pas une panne de l’hôte ou du logiciel de virtualisation.

À l’installation, prévoyez un compte ordinaire avec les droits d’administration nécessaires et un mot de passe conservé de manière sûre. Après avoir configuré les clés SSH, vérifiez toujours que vous pouvez ouvrir une session avec ce compte dans la console. Une clé privée SSH ne remplace pas automatiquement le mot de passe demandé par cette console.

  1. Avant une modification réseau, ouvrez la fenêtre de la VM et vérifiez la connexion locale avec le compte prévu.
  2. Conservez la session SSH existante pendant le changement, si elle est disponible. Vérifiez une nouvelle connexion avant de la fermer.
  3. Relevez le fichier modifié, son état d’origine et la commande d’application. Préparez la correction limitée à ce changement.
  4. Si l’accès réseau échoue, utilisez la console pour vérifier l’état et remettre la configuration précédente. Si la console est elle aussi inaccessible, évaluez le snapshot fonctionnel ou une restauration indépendante au lieu de multiplier les modifications à l’aveugle.

Les chemins de récupération doivent être connus avant l’incident. Une session SSH restée ouverte est utile, mais ne remplace pas le test d’une nouvelle connexion et ne garantit pas la survie à un redémarrage.

Séparer snapshot, sauvegarde et partage de l’hôte

Un snapshot conserve un état de référence de la VM pour y revenir pendant les exercices. Nommez par exemple clean-install l’état d’une installation et de ses mises à jour vérifiées, puis before-network-change l’état précédant une intervention. Dans VirtualBox, sélectionnez la VM et la vue Snapshots pour examiner les états enregistrés ; la documentation de gestion des VM et snapshots précise leur portée.

Revenir à un ancien snapshot peut supprimer les changements ultérieurs des disques virtuels concernés. Sauvegardez donc les travaux à conserver avant un retour. Les disques configurés avec des modes spéciaux peuvent avoir une autre portée ; ne supposez pas que tout ce qui est accessible à la VM sera restauré.

Un snapshot sur le même support physique ne protège pas de la perte de ce support ou de la corruption du dossier de la VM. Prévoyez une copie ou un export cohérent de la VM arrêtée et une sauvegarde indépendante des données importantes. Conserver une copie hors du disque de la VM est utile ; la conserver hors du seul appareil menacé est nécessaire si vous voulez couvrir sa panne.

Les écritures dans un dossier partagé de l’hôte ou sur un serveur externe ne reviennent pas en arrière avec le snapshot de l’invité. Commencez sans dossiers partagés, sans presse-papiers bidirectionnel et sans glisser-déposer. Activez ensuite uniquement le partage nécessaire au transfert prévu. Séparez les fichiers d’exercice jetables et les originaux à préserver.

Compléter la fiche de configuration avant l’installation

Ce modèle rassemble les décisions. Les ressources sont des exemples, à remplacer selon votre ordinateur ; elles ne sont pas des résultats mesurés.

Objectif : SSH, Nginx et restauration de sauvegardes
Invité : Ubuntu Server 26.04 LTS, architecture vérifiée
Hôte et outil : système, processeur et version du logiciel réellement retenus
Exemple de ressources : 2 CPU / 4 Go RAM / nouveau disque dynamique 30 Go
Réseau initial : adaptateur 1 NAT, aucune redirection de port
Exercices distants : adaptateur 2 host-only, plage libre et DHCP vérifiés
Console : connexion avec le compte ordinaire prévu
Snapshot : clean-install après installation et mises à jour vérifiées
Copie indépendante : paramètres, données et notes de récupération hors de la VM
Partages initiaux : dossiers partagés et presse-papiers bidirectionnel désactivés

Une case encore inconnue indique un point à résoudre avant l’installation. Vous devez pouvoir identifier le disque cible, justifier les ressources, décrire le trajet réseau et expliquer comment retrouver la console et les données de récupération. Conservez les modifications ultérieures et leur raison dans cette même fiche.