Ceci est une ancienne révision du document !
Table des matières
Module 4 : Configuration de la Virtualisation KVM & Compte Tux — Architecture Titux
Cette page documente la mise en place d'une structure de privilèges asymétriques (RBAC). L'objectif est de séparer l'identité physique de session principale de l'identité technique dédiée au pilotage des environnements virtuels (VMs KVM, conteneurs Podman/Docker).
1. Phase d'Installation : Déploiement de l'Hyperviseur (QEMU/KVM)
Les commandes de ce bloc doivent être exécutées depuis votre session utilisateur principale dans un terminal (Konsole).
Étape 1 : Installation de la pile logicielle KVM
Nous demandons à DNF5 d'installer l'interface graphique de gestion (Virt-Manager), le démon de contrôle d'arrière-plan, et les outils d'authentification client :
sudo dnf install -y virt-manager libvirt-daemon-kvm libvirt-client
Étape 2 : Activation et démarrage du service système
Sous Fedora, les services de virtualisation ne sont pas lancés par défaut. Nous activons le démon pour qu'il s'exécute immédiatement et se relance automatiquement à chaque démarrage de la machine :
sudo systemctl enable --now libvirtd
2. Phase de Configuration : Gestion de l'Identité Technique
Étape 1 : Création du profil technique
Nous initialisons le compte “tux” en forçant la création de son répertoire personnel pour accueillir ses futurs espaces de stockage isolés :
sudo useradd -m -c "Compte Infrastructure Tux" tux
Étape 2 : Sécurisation de l'accès
Définissez un mot de passe robuste dédié à cette identité technique :
sudo passwd tux
Étape 3 : Directives d'attribution du rôle de Virtualisation
Le groupe “libvirt” ayant été créé lors de la phase d'installation de l'hyperviseur, nous pouvons y ajouter l'utilisateur “tux”. Cela lui donne le droit de configurer des serveurs complets (comme YunoHost) dans Virt-Manager sans jamais avoir besoin d'utiliser sudo :
sudo usermod -aG libvirt tux
3. Phase d'Audit : Vérification de la Conformité (Métrologie)
Ce bloc regroupe les commandes de contrôle permettant de valider de manière indiscutable la bonne santé de la structure avant la mise en production.
Contrôle 1 : Rôles et privilèges de Tux
groups tux
* Résultat probant attendu : Le terminal doit retourner : “tux : tux libvirt”.
Contrôle 2 : État du démon de virtualisation
systemctl status libvirtd | grep -E "Active:|Main PID:"
* Résultat probant attendu : La ligne doit indiquer explicitement : “Active: active (running)”.
Contrôle 3 : Accessibilité de l'Hyperviseur
virsh --connect qemu:///system uri
* Résultat probant attendu : Le terminal doit vous renvoyer strictement la chaîne : “qemu:///system”.
4. Évolutivité Matérielle & Performance Disque (Le No_CoW)
Les images disques lourdes (fichiers “.qcow2”) créées dans Virt-Manager génèrent des écritures aléatoires intensives. Pour éviter l'effondrement des performances du SSD dû au mécanisme Copy-on-Write (CoW) natif de Btrfs, le répertoire accueillant les machines de l'utilisateur technique doit impérativement être créé avec l'attribut d'écriture directe No_CoW (+C).
Pour appliquer cet attribut de manière préventive sur le dossier de stockage de l'utilisateur technique :
sudo chattr +C /home/tux/
*Note d'ingénierie : L'attribut +C doit impérativement être appliqué sur un dossier vide ou nouvellement créé pour que les futurs fichiers volumineux en héritent nativement.*
