Ateliers — chapitre 1

Étape 1 — L'ISO dans le stockage local

Dans l'arbre de gauche, déroulez votre nœud, cliquez sur le stockage local, puis sur ISO Images. Le bouton Download from URL ouvre une fenêtre :

• URL : https://enterprise.proxmox.com/iso/proxmox-ve_9.2-1.iso ;
• Query URL : Proxmox interroge le serveur et remplit le nom du fichier et sa taille ;
• Download : le téléchargement se fait directement sur le nœud, sans passer par votre poste.

La tâche apparaît en bas de l'écran ; à la fin, l'ISO figure dans la liste ISO Images. Lancée dès votre première connexion, elle se termine pendant le cours : à l'atelier, l'ISO est déjà là.

Étape 2 — La VM 190

Le bouton Create VM, en haut à droite, ouvre l'assistant. Les valeurs à saisir, onglet par onglet :

• General : VM ID 190, Name pve-essai ;
• OS : Storage local, ISO image proxmox-ve_9.2-1.iso, Type Linux ;
• System : les valeurs proposées ;
• Disks : Storage local-lvm, Disk size 32 ;
• CPU : Cores 2 ;
• Memory : 4096 ;
• Network : Bridge vmbr0, Model VirtIO ;
• Confirm : relisez le résumé, puis Finish.

Étape 3 — L'installation, écran par écran

Sélectionnez la VM 190, Start, puis Console : la console noVNC affiche l'écran de la VM dans le navigateur.

Les valeurs à saisir : système de fichiers ext4 ; Country France, Time zone Europe/Paris, Keyboard Layout French ; mot de passe proxmoxx.

Pour le réseau : Hostname (FQDN) pve-essai.lab.local, IP 10.<site>.<N>.90/24, Gateway 10.<site>.<N>.1. Le DNS est celui de votre nœud, affiché dans Nœud → System → DNS.

1 — Menu de démarrage

La première ligne donne la version exacte de l'ISO : Proxmox VE 9.2 (iso release 1). Graphical est l'assistant à la souris.

Terminal UI est le même assistant en mode texte. On le prend quand la carte graphique du serveur pose problème, ou à travers une console distante qui affiche mal le mode graphique. Advanced Options donne accès aux modes de dépannage et à l'installation automatisée (cours, section 4.3).

2 — Disque cible

Target Harddisk désigne le disque qui sera entièrement effacé : toutes ses partitions et données sont perdues, le texte de droite le rappelle. Sur un serveur à plusieurs disques, on vérifie ici le nom et la taille du disque, pour ne pas installer sur celui qui porte des données.

3 — Système de fichiers

En production, sur deux disques identiques : zfs (RAID1). Proxmox installe son propre système en miroir sur les deux disques ; si l'un tombe en panne, le serveur continue de fonctionner.

Dans la VM d'essai, on garde ext4 : une seule VM, un seul disque virtuel, rien à protéger. Sous la liste, les champs hdsize, swapsize, maxroot, minfree et maxvz règlent le découpage du disque ; laissés vides, ils prennent des valeurs automatiques.

4 — Localisation

Country France, Time zone Europe/Paris, Keyboard Layout French. Le clavier se vérifie avant le mot de passe. Avec une disposition fausse, le mot de passe tapé à l'écran suivant n'est pas celui que l'on croit, et l'on ne peut plus se connecter.

5 — Mot de passe et courriel

Le mot de passe doit faire au moins 8 caractères : c'est pour cela que celui du lab s'écrit proxmoxx, avec deux x. Le courriel reçoit les alertes du nœud : sauvegarde en échec, événement de haute disponibilité. La valeur par défaut, mail@example.invalid, est à remplacer.

6 — Réseau

Management Interface est la carte qui portera l'interface web ; en 9.2, elle s'appelle nic0. La case Pin network interface names, cochée par défaut, fige les noms des cartes : ils ne changeront pas si l'on en ajoute une.

L'hyperviseur a une adresse fixe parce que tout le reste s'y adresse : votre navigateur, les autres nœuds du cluster, le serveur de sauvegarde. Le FQDN (nom.domaine) identifie le nœud dans le cluster et dans ses certificats ; la valeur proposée, pve.home, est à remplacer.

7 — Résumé

Le tableau récapitule tous les choix ; Previous permet encore de corriger. Si l'ISO reste dans le lecteur, la machine redémarre dessus et revient au menu de l'étape 1. On retire donc l'ISO avant le redémarrage : c'est l'étape 4 de la solution.

8 — Premier démarrage

La console donne l'adresse de l'interface, https://<IP>:8006/ : le port 8006 est celui de l'interface web de Proxmox. L'invite reprend le nom court choisi : pve-demo login: sur la capture, pve-essai login: dans votre VM.

La fenêtre Proxmox VE Login est celle que l'on obtient sur un poste qui a une route vers la nouvelle machine. Votre poste n'en a pas : l'étape 5 vérifie la réponse de l'interface depuis le Shell de votre nœud. Le realm proposé par défaut est Linux PAM standard authentication : c'est le compte root du système, avec le mot de passe de l'écran 5.

Votre propre nœud a été installé avec les mêmes choix, mais sans personne devant l'écran : un fichier de réponses les a fournis. La section 4.3 du cours en donne le principe.

Étape 4 — Retirer l'ISO

À la fin de l'installation, l'installateur annonce le redémarrage. Il faut alors vider le lecteur optique virtuel de la VM, celui des CD et des DVD (Digital Versatile Disc).

Avant le redémarrage, ou dès que le menu de démarrage réapparaît : Hardware → CD/DVD Drive → Edit → Do not use any media, puis Reset si le menu est affiché. La VM démarre alors sur son disque, et la console montre l'écran de l'étape 8.

Étape 5 — La vérification, depuis le Shell du nœud

Votre poste n'a pas de route vers 10.<site>.<N>.90 : la vérification se fait depuis le Shell de votre nœud, qui est sur le même réseau.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

ping -c 2 10.<site>.<N>.90                                        # la VM répond-elle ?
curl -k -s -o /dev/null -w "%{http_code}\n" https://10.<site>.<N>.90:8006   # le code HTTP de l'interface web

Résultat attendu (les temps diffèrent) :

PING 10.<site>.<N>.90 (10.<site>.<N>.90) 56(84) bytes of data.
64 bytes from 10.<site>.<N>.90: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 10.<site>.<N>.90: icmp_seq=2 ttl=64 time=0.388 ms
…
200

-k accepte le certificat auto-signé de la nouvelle installation ; -o /dev/null jette la page, et -w n'affiche que le code HTTP. 200 : l'interface web de pve-essai répond, l'installation a abouti.

Étape 6 — Le nettoyage

Sélectionnez la VM 190, Shutdown, puis More → Remove : cochez Purge from job configurations et confirmez en tapant 190. Le disque de 32 Go est libéré sur local-lvm.

L'ISO peut rester dans local : elle resservira au chapitre 2.

Votre propre nœud a été installé avec les mêmes choix, mais sans personne devant l'écran : un fichier de réponses les a fournis. La section 4.3 du cours en donne le principe.

Étape 1 — Connexion et exploration

Ouvrez un navigateur à l'URL de votre nœud 1 (https://pxe2<N>1.<ville>.pm.dawan.ovh). Pas d'avertissement de certificat : l'URL Dawan porte un certificat reconnu.

Connectez-vous avec root / proxmoxx, realm Linux PAM standard authentication.

Cliquez sur votre nœud dans l'arborescence de gauche, puis explorez le menu du milieu :

Les stockages n'ont pas d'entrée dans ce menu : ils apparaissent sous le nœud, dans l'arborescence de gauche, et dans Datacenter → Storage.

Résultat attendu (nœud pxe211, Proxmox VE 9.2.2 juste installé) :

L'en-tête donne le nom du nœud et son uptime. Le premier bloc donne la charge : CPU, mémoire, espace disque de /, swap. Le second donne l'identité du système : processeurs, version du noyau (7.0.2-6-pve), mode de démarrage (EFI), version de Proxmox (pve-manager/9.2.2).

La ligne Repository Status est à regarder dès le premier jour : sur un nœud neuf, elle signale un dépôt Enterprise activé qui exige un abonnement valide. C'est l'objet de l'atelier suivant. En bas, le journal des tâches montre déjà un Update package database en erreur, pour la même raison.

Deux cartes réseau (ens18, ens19) et un bridge, vmbr0. Le bridge porte l'adresse du nœud (colonne CIDR) et la passerelle ; sa colonne Ports/Slaves indique la carte physique qui le relie au réseau (ens18).

La colonne Active montre que ens19 n'est pas utilisée.

Un terminal root ouvert directement dans le navigateur. C'est par lui que passeront toutes les commandes de la formation, puisque vous n'avez pas d'accès SSH direct.

Étape 2 — Identifier les stockages par défaut

Naviguez vers Datacenter → Storage :

Les deux stockages créés par l'installation. Lisez les colonnes Type et Content : c'est le type qui décide du contenu accepté.

Réponse à la question de l'énoncé : une ISO est un fichier. Or local-lvm ne stocke que des volumes en mode bloc, utilisés comme disques.

Il n'a pas de système de fichiers où déposer une ISO, et Proxmox ne propose donc pas ce type de contenu. Les ISO vont sur local.

Étape 3 — Un stockage réservé aux ISO

Un stockage Proxmox, c'est un emplacement plus la liste des contenus qu'il accepte. On en crée un de type répertoire, limité aux ISO.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Le dossier qui portera le stockage
mkdir -p /srv/isos

À la souris : Datacenter → Storage → Add → Directory :

En ligne de commande, la même déclaration.

Dans le Shell du nœud :

# Un stockage répertoire, qui n'accepte que des ISO (et crée le dossier s'il manque)
pvesm add dir isos-partage --path /srv/isos --content iso --create-base-path 1
# Les stockages qui acceptent des ISO…
pvesm status --content iso
# … et ceux qui acceptent des disques de VM
pvesm status --content images

Résultat attendu :

Name                Type     Status     Total (KiB)      Used (KiB) Available (KiB)        %
isos-partage         dir     active        14210064         6444344         7022092   45.35%
local                dir     active        14210064         6444344         7022092   45.35%
Name             Type     Status     Total (KiB)      Used (KiB) Available (KiB)        %
local-lvm     lvmthin     active        12439552         1105876        11333675    8.89%

La liste compte maintenant trois stockages. isos-partage est de type Directory, sur /srv/isos, avec pour seul contenu ISO image. La fenêtre Edit (double-clic sur la ligne) montre les mêmes réglages ; Nodes : All veut dire qu'il est déclaré pour tous les nœuds d'un cluster.

Deux constats à retenir :

• Il n'apparaît que là où il sert. Proposé pour les ISO, il est absent de la liste des stockages qui acceptent des disques. Dans l'assistant de création d'une VM, il ne figurera pas parmi les emplacements de disque.
• Il n'ajoute aucun espace. Son total est identique à celui de local : les deux dossiers sont sur le même disque système. Un stockage répertoire organise un disque, il ne l'agrandit pas.

Retirez-le.

Dans le Shell du nœud :

# Retirer la déclaration du stockage
pvesm remove isos-partage
# Le dossier, lui, est toujours là
ls -d /srv/isos

Résultat attendu : pvesm status ne liste plus que local et local-lvm, mais ls répond /srv/isos : retirer un stockage ne supprime pas ses fichiers. Proxmox oublie l'emplacement, le disque garde son contenu. Supprimez le dossier vous-même s'il ne sert plus (rm -r /srv/isos).

Validation finale

Dans le Shell du nœud (interface web → votre nœud → Shell) :

pvesm status   # état des stockages du nœud

Résultat attendu :

Name             Type     Status     Total (KiB)      Used (KiB) Available (KiB)        %
local             dir     active        14210064         4337680         9128756   30.53%
local-lvm     lvmthin     active        12439552               0        12439552    0.00%

local et local-lvm sont tous deux active, de types dir et lvmthin. Les tailles dépendent du disque de votre nœud.

Étape 1 — Lire l'état de départ

Dans le panneau de votre nœud, ouvrez Updates → Repositories.

Le bandeau Status avertit : The enterprise repository is enabled, but there is no active subscription! La liste est groupée par fichier. Deux dépôts Proxmox sont cochés dans la colonne Enabled : ceph-squid (fichier ceph.sources, composant enterprise) et pve (fichier pve-enterprise.sources, composant pve-enterprise).

Les deux pointent vers enterprise.proxmox.com. Les deux dépôts Debian, eux, sont gratuits et restent actifs.

Étape 2 — Désactiver les deux dépôts enterprise

Sélectionnez la ligne https://enterprise.proxmox.com/debian/pve et cliquez Disable.

La ligne passe en grisé, et un tiret remplace la coche dans Enabled. Le bandeau devient rouge : No Proxmox VE repository is enabled, you do not get any updates! C'est normal : aucun dépôt Proxmox n'est actif tant que le no-subscription n'est pas ajouté.

Faites de même pour la ligne https://enterprise.proxmox.com/debian/ceph-squid. C'est l'oubli le plus fréquent. Sur le lab, avec seulement le dépôt PVE désactivé, apt update échouait encore.

Dans le Shell du nœud :

# Relire la liste des paquets
apt update

Err:6 https://enterprise.proxmox.com/debian/ceph-squid trixie InRelease
  401  Unauthorized [IP: 51.91.38.34 443]
Error: Failed to fetch https://enterprise.proxmox.com/debian/ceph-squid/dists/trixie/InRelease  401  Unauthorized [IP: 51.91.38.34 443]
Error: The repository 'https://enterprise.proxmox.com/debian/ceph-squid trixie InRelease' is not signed.

Le bon dépôt Ceph sera écrit par la commande d'installation de Ceph elle-même.

Ouvrez ensuite le Shell du nœud et relisez ce que le bouton Disable a modifié :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

cat /etc/apt/sources.list.d/pve-enterprise.sources   # lire le fichier du dépôt enterprise

Résultat attendu :

Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
Enabled: false

La dernière ligne, Enabled: false, est tout ce que fait Disable : le dépôt reste décrit, apt l'ignore. C'est plus sûr qu'une suppression.

Le jour où l'entreprise prend un abonnement, il suffit de retirer cette ligne. ceph.sources a reçu la même ligne.

Étape 3 — Ajouter le dépôt no-subscription

Déclarez le dépôt no-subscription dans son propre fichier. Le bouton Add de la page Repositories écrirait le même contenu.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Dépôt no-subscription de PVE 9, au format DEB822
nano /etc/apt/sources.list.d/proxmox.sources          # un fichier neuf

Le contenu de proxmox.sources, à taper dans nano, puis Ctrl + O, Entrée et Ctrl + X :

Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Dans le Shell du nœud :

cat /etc/apt/sources.list.d/proxmox.sources           # relire le fichier créé

Résultat attendu : les cinq lignes du dépôt, Components: pve-no-subscription en quatrième position. La relecture prouve que le fichier est bien enregistré.

Étape 4 — Mettre à jour le système

Dans le Shell du nœud (interface web → votre nœud → Shell) :

apt update   # relire la liste des paquets

Résultat attendu (fin de la sortie) :

Get:4 http://download.proxmox.com/debian/pve trixie InRelease [4,357 B]
Get:5 http://download.proxmox.com/debian/pve trixie/pve-no-subscription amd64 Packages [390 kB]
...
181 packages can be upgraded. Run 'apt list --upgradable' to see them.

Plus aucune ligne vers enterprise.proxmox.com, plus d'erreur 401. Le nombre de paquets dépend de la date de votre ISO.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

apt full-upgrade -y   # appliquer toutes les mises à jour

Sur le lab, la mise à jour a notamment installé pve-manager (9.2.20) et un nouveau noyau, proxmox-kernel-7.0.14-19-pve-signed. Or le nœud tournait encore sur l'ancien :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

pveversion   # version de Proxmox VE et noyau en cours

pve-manager/9.2.20/49318c671b82f31e (running kernel: 7.0.2-6-pve)

Comment reconnaître qu'un redémarrage est nécessaire : pveversion affiche un running kernel plus ancien que le dernier noyau installé (ls /boot/vmlinuz-*). Redémarrez avec le bouton Reboot de l'interface, ou :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

reboot   # redémarrer sur le nouveau noyau

Résultat attendu après le redémarrage : pve-manager/9.2.20/49318c671b82f31e (running kernel: 7.0.14-19-pve).

Les deux dépôts enterprise sont grisés. Le nouveau fichier proxmox.sources porte le dépôt pve-no-subscription, coché. Le bandeau confirme You get updates for Proxmox VE.

Il ajoute un avertissement jaune : The no-subscription repository is not recommended for production use! Ce dépôt reçoit les paquets avant le dépôt enterprise. Il convient à un lab ; en production, on prend un abonnement.

Le Summary confirme le nouvel état : noyau 7.0.14-19-pve, pve-manager/9.2.20, et une ligne Repository Status qui annonce Proxmox VE updates.

Validation finale

Dans le Shell du nœud (interface web → votre nœud → Shell) :

grep -r "Enabled\|Components" /etc/apt/sources.list.d/   # état des dépôts : Enabled et Components
apt update 2>&1 | grep -i "401\|error"   # ne doit rien retourner

Résultat attendu : Enabled: false dans pve-enterprise.sources et dans ceph.sources, Components: pve-no-subscription dans proxmox.sources, et aucune ligne pour la seconde commande.

Étape 1 — Scénario comptable : accès limité à une seule VM

Une personne du service comptabilité doit pouvoir démarrer sa VM de travail, l'arrêter et ouvrir sa console — et rien d'autre.

Via l'interface : Datacenter → Permissions → Users → Add — Login comptable, Realm Proxmox VE authentication server, Password proxmoxx, Comment Service comptabilité.

Équivalent CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Compte interne Proxmox (realm pve) : il n'existe pas sous Linux
pveum user add comptable@pve --password 'proxmoxx' --comment "Service comptabilité"
# Relire la liste des comptes
pveum user list

Résultat attendu (nœud pxe211, PVE 9.2.20 ; colonnes vides retirées pour la lisibilité) :

┌───────────────┬──────────────────────┬───────────────────┬────────┬────────┬────────┬────────────┐
│ userid        │ comment              │ email             │ enable │ expire │ groups │ realm-type │
╞═══════════════╪══════════════════════╪═══════════════════╪════════╪════════╪════════╪════════════╡
│ comptable@pve │ Service comptabilité │                   │ 1      │      0 │        │ pve        │
├───────────────┼──────────────────────┼───────────────────┼────────┼────────┼────────┼────────────┤
│ root@pam      │                      │ admin@dawan.local │ 1      │      0 │        │ pam        │
└───────────────┴──────────────────────┴───────────────────┴────────┴────────┴────────┴────────────┘

Lisez la colonne realm-type : comptable est un compte du realm pve, qui n'existe que dans Proxmox ; root est un compte pam, c'est-à-dire un vrai compte Linux du nœud. Le courriel de root est celui saisi à l'installation.

L'utilisateur existe mais n'a encore aucun droit. Créez maintenant un rôle personnalisé.

Via l'interface : Datacenter → Permissions → Roles → Create — Name RoleComptable, Privileges cocher VM.Audit, VM.Console, VM.PowerMgmt.

Équivalent CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# VM.Audit     = voir la VM dans la liste (sans ça, elle est invisible)
# VM.Console   = ouvrir la console noVNC dans le navigateur
# VM.PowerMgmt = démarrer, arrêter, redémarrer, mettre en pause
pveum role add RoleComptable --privs "VM.Audit,VM.Console,VM.PowerMgmt"

Il faut maintenant la VM du comptable. Créez une VM vide, sans disque : elle ne sert qu'à porter le droit.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

qm create 290 --name compta --memory 128   # VM vide 290 : un nom, 128 Mo de mémoire, rien d'autre

Assignez le rôle uniquement sur cette VM, pas sur l'ensemble du datacenter. C'est la différence entre / (tout) et /vms/290 (uniquement cette VM).

Via l'interface : Datacenter → Permissions → Add → User Permission — Path /vms/290, User comptable@pve, Role RoleComptable, Propagate décoché.

Équivalent CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Le rôle sur UN SEUL objet : la VM 290, et rien au-dessus
pveum acl modify /vms/290 --users comptable@pve --roles RoleComptable
# Relire les permissions
pveum acl list

Résultat attendu :

┌──────────┬───────────────┬──────┬───────────────┬───────────┐
│ path     │ roleid        │ type │ ugid          │ propagate │
╞══════════╪═══════════════╪══════╪═══════════════╪═══════════╡
│ /vms/290 │ RoleComptable │ user │ comptable@pve │ 1         │
└──────────┴───────────────┴──────┴───────────────┴───────────┘

Chaque ligne se lit de gauche à droite : sur /vms/290, le rôle RoleComptable est donné à comptable@pve, qui est un utilisateur (type user — ce serait group pour un groupe). propagate à 1 est la valeur par défaut en ligne de commande ; sur un objet sans enfants comme une VM, elle ne change rien.

Testez : ouvrez un onglet de navigation privée, connectez-vous avec comptable / proxmoxx, realm Proxmox VE authentication server. Vous devez voir uniquement la VM 290 dans l'arborescence — les onglets Network, Shell ou Repositories du nœud ne doivent pas être accessibles.

Résultat attendu (nœud pxe211) :

L'arborescence ne contient que le nœud et la VM 290 (compta) : ni stockage, ni autre machine. En haut, Create VM et Create CT sont grisés.

Le comptable dispose des boutons Start, Shutdown et Console de la VM : ce sont exactement VM.PowerMgmt et VM.Console. VM.Audit lui donne la vue Summary, en lecture seule. Ici, Shutdown est grisé parce que la VM est arrêtée.

Étape 2 — Scénario équipes : groupes avec rôles différents

Créez deux équipes : dev (peut créer des VMs de test) et support (consulte et redémarre uniquement).

Via l'interface : Datacenter → Permissions → Groups → Create — deux groupes : dev (Équipe développeurs), support (Équipe support utilisateur).

Équivalent CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Les deux groupes d'abord : un utilisateur ne peut rejoindre qu'un groupe existant
pveum group add dev     --comment "Équipe développeurs"
pveum group add support --comment "Équipe support utilisateur"   # le second groupe

# Un membre dans chaque groupe, rattaché dès la création
pveum user add alice@pve --password 'proxmoxx' --groups dev
pveum user add bob@pve   --password 'proxmoxx' --groups support   # le second membre, dans support

# Vérifier les membres de chaque groupe
pveum group list

Résultat attendu :

┌─────────┬────────────────────────────┬───────────┐
│ groupid │ comment                    │ users     │
╞═════════╪════════════════════════════╪═══════════╡
│ dev     │ Équipe développeurs        │ alice@pve │
├─────────┼────────────────────────────┼───────────┤
│ support │ Équipe support utilisateur │ bob@pve   │
└─────────┴────────────────────────────┴───────────┘

Via l'interface : Datacenter → Permissions → Add → Group Permission — Path /vms, Group dev, Role PVEVMAdmin ; puis Path /vms, Group support, Role PVEVMUser.

Équivalent CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# PVEVMAdmin = créer, modifier, supprimer, cloner des VMs
pveum acl modify /vms --groups dev --roles PVEVMAdmin

# PVEVMUser = voir, accéder à la console, démarrer/arrêter — mais pas créer ni supprimer
pveum acl modify /vms --groups support --roles PVEVMUser

Sur le lab, en se connectant avec alice@pve (realm Proxmox VE authentication server) pendant que les deux VM de l'étape 4 existaient :

alice voit les deux VM, 301 (app-a1) et 302 (app-b1), alors qu'elles appartiennent à deux projets différents. C'est exactement l'effet de /vms décrit ci-dessus.

Le menu du nœud est réduit à Search, Task History et Subscription. Les boutons Reboot, Shutdown et Shell sont grisés : le rôle ne donne aucun droit sur le nœud lui-même. Comparez avec dev-a, à l'étape 4.

Étape 3 — Scénario admin restreint : accès sans shell système

Un administrateur junior doit gérer toute l'infrastructure Proxmox : VMs, stockage, sauvegardes. Mais sans jamais pouvoir ouvrir un shell sur le nœud lui-même. Il s'agit de séparer les droits de virtualisation des droits d'accès au système hôte.

Via l'interface : Datacenter → Permissions → Users → Add — Login admin-jr, Realm Proxmox VE authentication server, Password proxmoxx.

Équivalent CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Compte de l'administrateur junior, sans aucun droit pour l'instant
pveum user add admin-jr@pve --password 'proxmoxx' --comment "Administrateur junior"

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Reprend les droits d'administrateur Proxmox SAUF Sys.Console (shell sur le nœud)
# et Sys.Syslog (lecture des logs système bas niveau)
pveum role add AdminSansShell --privs \
  "VM.Allocate,VM.Audit,VM.Clone,VM.Config.CDROM,VM.Config.CPU,\
VM.Config.Cloudinit,VM.Config.Disk,VM.Config.HWType,VM.Config.Memory,\
VM.Config.Network,VM.Config.Options,VM.Console,VM.Migrate,\
VM.PowerMgmt,VM.Snapshot,VM.Snapshot.Rollback,\
Datastore.Audit,Datastore.AllocateSpace,Datastore.AllocateTemplate,\
Pool.Audit,SDN.Audit,\
Sys.Audit,Sys.Modify"

400 Parameter verification failed.
privs: invalid format - invalid privilege 'VM.Monitor'

# Tous les roles existants et les privileges que chacun contient
pveum role list

# S'inspirer de PVEAdmin, le role le plus large hors Administrator,
# puis retirer les privileges qu'on ne veut pas accorder
pveum role list | grep PVEAdmin

Via l'interface : Datacenter → Permissions → Add → User Permission — Path /, User admin-jr@pve, Role AdminSansShell, Propagate coché.

Équivalent CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Rôle donné sur / avec propagation : il couvre tout le datacenter
pveum acl modify / --users admin-jr@pve --roles AdminSansShell

Vérification : connexion privée avec admin-jr@pve / proxmoxx, realm Proxmox VE authentication server.

Résultat attendu : admin-jr voit tout le datacenter : le nœud, les VM et les stockages. Le menu du nœud donne accès à Network, DNS, Disks, Firewall… Mais les boutons Reboot, Shutdown et Shell sont grisés, et l'entrée Shell a disparu du menu : il manque Sys.PowerMgmt et Sys.Console.

Updates et System Log ont aussi disparu. Il administre la virtualisation, pas le système hôte.

Retirer un droit

Une permission se révoque avec une sous-commande dédiée, pveum acl delete :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Retirer exactement le triplet chemin / utilisateur / rôle posé à l'étape 1
pveum acl delete /vms/290 --users comptable@pve --roles RoleComptable
pveum acl list   # vérifier que la ligne a disparu

Résultat attendu : la ligne /vms/290 disparaît de pveum acl list, et l'utilisateur retrouve une interface vide à sa prochaine connexion. Remettez la permission (pveum acl modify /vms/290 --users comptable@pve --roles RoleComptable) : la validation finale en a besoin.

Il n'existe pas d'option --delete sur pveum acl modify. Sur le lab :

Unknown option: delete
400 unable to parse option

Validation finale

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Les comptes, les groupes, les deux rôles personnalisés, puis toutes les ACL
pveum user list
pveum group list   # les groupes
pveum role list   # les deux rôles personnalisés ; à lire : RoleComptable, AdminSansShell
pveum acl list   # toutes les ACL

Résultat attendu (les lignes qui comptent) : comptable@pve, alice@pve, bob@pve et admin-jr@pve dans la liste des comptes. Les groupes dev et support avec chacun leur membre, et les deux rôles avec leurs privilèges.

Dans les ACL, quatre lignes seulement : /vms/290 pour le comptable, /vms pour chacun des deux groupes, / pour admin-jr@pve. Une cinquième ligne serait un droit oublié.

Résultat attendu de pveum acl list :

┌──────────┬────────────────┬───────┬───────────────┬───────────┐
│ path     │ roleid         │ type  │ ugid          │ propagate │
╞══════════╪════════════════╪═══════╪═══════════════╪═══════════╡
│ /        │ AdminSansShell │ user  │ admin-jr@pve  │ 1         │
├──────────┼────────────────┼───────┼───────────────┼───────────┤
│ /vms     │ PVEVMUser      │ group │ support       │ 1         │
├──────────┼────────────────┼───────┼───────────────┼───────────┤
│ /vms     │ PVEVMAdmin     │ group │ dev           │ 1         │
├──────────┼────────────────┼───────┼───────────────┼───────────┤
│ /vms/290 │ RoleComptable  │ user  │ comptable@pve │ 1         │
└──────────┴────────────────┴───────┴───────────────┴───────────┘

La même liste dans l'interface, Datacenter → Permissions :

Chaque ligne est un triplet chemin / compte / rôle. Un groupe se reconnaît au @ placé devant son nom (@dev, @support). La colonne Propagate à true signifie que le droit descend aux objets enfants du chemin.

Les comptes et les rôles se relisent de la même façon, sous Permissions → Users et Permissions → Roles :

La colonne Realm sépare les comptes Proxmox (pve) du compte système root (pam). La colonne Groups montre l'appartenance d'alice et de bob. TFA à No : aucun second facteur n'est encore configuré ; c'est l'objet de l'atelier 5.

Les rôles fournis par Proxmox portent Built-In: Yes ; AdminSansShell et RoleComptable portent No. Comparez AdminSansShell à PVEAdmin : ce dernier contient Sys.Console et Sys.Syslog, que le rôle personnalisé n'a pas.

Étape 1 — Le compte d'administration

Via l'interface, en root : Datacenter → Permissions → Users → Add — User name adm-<prénom>, Realm Proxmox VE authentication server, Password proxmoxx. Puis Datacenter → Permissions → Add → User Permission — Path /, User adm-<prénom>@pve, Role PVEAuditor.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

pveum user add adm-<prénom>@pve --password 'proxmoxx' --comment "Atelier TOTP"   # le compte de l'atelier
pveum acl modify / --users adm-<prénom>@pve --roles PVEAuditor   # lecture seule sur tout le datacenter

Étape 2 — Ajouter le TOTP, par le compte lui-même

Ouvrez une fenêtre de navigation privée, connectez-vous avec adm-<prénom> / proxmoxx, realm Proxmox VE authentication server.

Menu du compte, en haut à droite (adm-<prénom>@pve) → TFA. L'interface ouvre Datacenter → Permissions → Two Factor. Puis Add → TOTP :

→ Add.

La fenêtre Add a TOTP login factor sur le lab. Le QR code contient le Secret et l'Issuer Name (Proxmox VE - pxe211) : c'est ce que l'application enregistre.

Deux contrôles avant d'accepter. Verify Code prouve que le téléphone calcule les mêmes codes que le serveur.

Verify Password, encadré en rouge tant qu'il est vide, prouve que c'est bien le titulaire du compte qui ajoute le facteur. Sans ces deux champs, le bouton Add reste grisé.

Étape 3 — Se reconnecter

Menu du compte → Logout, puis reconnexion avec le même compte. Après le mot de passe, une seconde fenêtre s'ouvre.

Second login factor required : le mot de passe a été accepté, mais il ne suffit plus. L'onglet TOTP App attend le code du téléphone. L'onglet Recovery Key servira si le téléphone est perdu.

Un faux code d'abord (000000), puis Confirm Second Factor :

Login failed: authentication failure (401). Le message ne dit pas lequel des deux facteurs est faux : c'est voulu, il ne renseigne pas un attaquant. Recommencez avec le bon code : l'interface s'ouvre normalement.

Étape 4 — Les clés de récupération

Menu du compte → TFA → Add → Recovery Keys → Add.

Dix clés, numérotées de 0 à 9, chacune utilisable une seule fois à la place du code. Le bandeau jaune le dit : they will only be displayed now.

Elles ne seront plus jamais affichées : on les copie ou on les imprime tout de suite (Copy Recovery Keys, Print Recovery Keys). Derrière la fenêtre, la liste montre les deux facteurs du compte, de type totp et recovery.

Étape 5 — Scénario de secours : root retire le second facteur

Dans votre session root, dans le Shell du nœud :

# Les facteurs enregistrés pour le compte
pveum user tfa list adm-<prénom>@pve

# Retirer tous ses facteurs (téléphone perdu)
pveum user tfa delete adm-<prénom>@pve
pveum user tfa list adm-<prénom>@pve   # vérifier : plus aucun facteur

Résultat attendu, avant le retrait :

recovery: recovery

totp:     bb06b50d-41e5-4ed0-ab22-84b531815761
    Téléphone de l'administratrice

Après pveum user tfa delete, la liste est vide : le compte se connecte de nouveau avec son seul mot de passe. C'est la procédure quand un administrateur a perdu son téléphone et ses clés. Elle se fait en root, ou avec un compte qui a les droits sur les utilisateurs.

Validation finale

Nettoyage (le compte ne sert plus) :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

pveum user delete adm-<prénom>@pve   # supprimer le compte

La suppression du compte retire aussi sa permission sur /. Supprimez l'entrée Proxmox VE - pxe2<N>1 de l'application de votre téléphone.

Étape 1 — Télécharger une ISO pour les VMs

Méthode 1 — Via l'interface web : pxe2<N>1 → local → ISO Images → Download from URL, URL https://cdimage.debian.org/cdimage/archive/13.6.0/amd64/iso-cd/debian-13.6.0-amd64-netinst.iso, puis Query URL et Download.

Query URL interroge le serveur avant de télécharger : il remplit le nom du fichier, sa taille (755.00 MiB) et son type MIME (application/x-iso9660-image). C'est la vérification qu'on a la bonne URL, avant de lancer 750 Mo de téléchargement.

Résultat attendu (fin du journal de la tâche) :

La progression par tranches, puis saved [791674880/791674880] et TASK OK. Aucune ligne de somme de contrôle : Proxmox ne vérifie l'intégrité que si on lui fournit la somme publiée par Debian. Cela se fait via la case Advanced de la fenêtre précédente (algorithme et valeur de la somme).

Méthode 2 — Via le shell :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

cd /var/lib/vz/template/iso/   # le dossier des ISO du stockage local
wget https://cdimage.debian.org/cdimage/archive/13.6.0/amd64/iso-cd/debian-13.6.0-amd64-netinst.iso   # télécharger l'ISO Debian 13
ls -lh /var/lib/vz/template/iso/   # vérifier la présence du fichier

Méthode 3 — Upload : local → ISO Images → Upload depuis votre poste, si pas d'accès internet depuis le lab.

Étape 2 — Télécharger un template LXC

Un template LXC est un OS préinstallé compressé, prêt à déployer en quelques secondes — l'équivalent d'une image Docker pour des conteneurs système complets.

Méthode 1 — Via l'interface : local → CT Templates → Templates, recherchez debian-13, sélectionnez debian-13-standard_... → Download.

En fond, local → CT Templates contient déjà debian-13-standard_13.6-1_amd64.tar.zst (123.93 MiB). Au premier plan, le catalogue Templates : les modèles standard maintenus par Proxmox (Debian, Ubuntu) et les images default d'autres distributions (Rocky, Alma, Alpine, Fedora…), plus deux modèles Proxmox Mail Gateway.

La barre du haut montre aussi un bouton lié à l'OCI (Open Container Initiative, format standard des images de conteneurs) : Pull from OCI Registry. Il récupère une image de conteneur applicatif.

Méthode 2 — Via le shell :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Rafraîchir l'index, puis repérer le nom exact du modèle Debian 13
pveam update
pveam available --section system | grep debian   # repérer le modèle Debian
# Télécharger ce modèle sur le stockage « local », puis vérifier sa présence
pveam download local debian-13-standard_13.6-1_amd64.tar.zst
pveam list local   # vérifier sa présence

Résultat attendu :

NAME                                                         SIZE
local:vztmpl/debian-13-standard_13.6-1_amd64.tar.zst         123.93MB

Étape 3 — Créer un conteneur LXC depuis l'interface

Create CT en haut à droite :

L'adresse est fixe, comme toute ressource créée sur le lab : 10.<site>.<N>.50. <site> vaut 44 (Nantes), 75 (Paris) ou 67 (Strasbourg) ; <N> est votre numéro de stagiaire (celui de pxe2<N>1).

La passerelle est en .1 (introduction générale, règle d'adressage). Un service que d'autres machines doivent joindre n'a de toute façon pas d'autre choix : son adresse ne doit jamais changer.

CT ID et Hostname identifient le conteneur. Deux cases sont cochées par défaut : Unprivileged container (le root du conteneur n'est pas le root de l'hôte, cours §10) et Nesting (utile à systemd dans les distributions récentes). Le mot de passe est celui du root du conteneur, pas celui du nœud.

IPv4 : Static, avec l'adresse en notation CIDR (/24) et la passerelle. La carte s'appelle eth0 dans le conteneur et se branche sur le bridge vmbr0. La case Firewall est cochée par défaut : elle ne filtre rien tant que le pare-feu n'est pas activé.

Le résumé liste les paramètres réellement envoyés : cores 1, hostname cache-apt, memory 512, swap 512, rootfs local-lvm:8, net0 …ip=…/24,gw=…, et les valeurs par défaut unprivileged 1 et features nesting=1. La case Start after created est décochée par défaut : le conteneur sera créé, mais pas démarré.

Cliquez Finish.

Résultat attendu :

Proxmox crée le volume vm-200-disk-0 sur local-lvm, le formate, y extrait le modèle, puis génère les clés SSH propres au conteneur (root@cache-apt). TASK OK : deux secondes sur le lab.

En ligne de commande, le même conteneur en une commande (à la place de l'assistant, pas en plus) :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Chaque option reprend un champ de l'assistant
pct create 200 local:vztmpl/debian-13-standard_13.6-1_amd64.tar.zst \
  --hostname cache-apt --password dawan \
  --rootfs local-lvm:8 --cores 1 --memory 512 --swap 512 \
  --net0 name=eth0,bridge=vmbr0,ip=10.<site>.<N>.50/24,gw=10.<site>.<N>.1,firewall=1 \
  --unprivileged 1 --features nesting=1

La commande affiche le même journal que la tâche de l'assistant, et la configuration obtenue est identique (pct config 200, étape 4). Comme dans l'assistant, le conteneur est créé arrêté ; --start 1 le démarrerait aussitôt.

Étape 4 — Démarrer et vérifier le conteneur

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Démarrer le conteneur, puis contrôler son état et sa configuration
pct start 200
pct status 200   # son état
pct config 200   # sa configuration

# Ouvrir un shell root dans le conteneur, sans mot de passe ni réseau
pct enter 200

Résultat attendu (pct config 200) :

arch: amd64
cores: 1
features: nesting=1
hostname: cache-apt
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=10.59.1.1,hwaddr=BC:24:11:FE:44:FB,ip=10.59.1.50/24,type=veth
ostype: debian
rootfs: local-lvm:vm-200-disk-0,size=8G
swap: 512
unprivileged: 1

status: running avant cela ; avec pct enter 200, le prompt devient root@cache-apt:~#.

Dans le conteneur (le prompt root@cache-apt:~# ouvert par pct enter 200) :

# L'adresse fixe est-elle bien portée par eth0 ?
ip -4 addr show eth0
# La route par défaut doit passer par la passerelle déclarée
ip route
# Le serveur qui l'héberge, sur le même réseau
ping -c 3 -q <ip-de-votre-noeud>
# Quelle distribution tourne dans le conteneur ?
grep PRETTY /etc/os-release
exit   # revenir au Shell du nœud

Résultat attendu :

2: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netnsid 0
    inet 10.59.1.50/24 scope global eth0
       valid_lft forever preferred_lft forever
default via 10.59.1.1 dev eth0 proto kernel onlink
10.59.1.0/24 dev eth0 proto kernel scope link src 10.59.1.50
3 packets transmitted, 3 received, 0% packet loss, time 2075ms
rtt min/avg/max/mdev = 0.039/0.061/0.074/0.015 ms
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"

valid_lft forever signe une adresse fixe (une adresse DHCP aurait une durée de bail).

Étape 5 — Installer le cache de paquets

apt-cacher-ng pose une question à l'installation. Lancé par pct exec, sans clavier pour y répondre, il resterait bloqué : DEBIAN_FRONTEND=noninteractive lui fait prendre la réponse par défaut.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Depuis le shell Proxmox (pas dans le conteneur) : « -- » sépare pct de la commande
pct exec 200 -- apt update
# Installation sans question ; le service démarre et s'active tout seul
pct exec 200 -- env DEBIAN_FRONTEND=noninteractive apt install -y apt-cacher-ng
# Actif au démarrage du conteneur ? Actif maintenant ?
pct exec 200 -- systemctl is-enabled apt-cacher-ng
pct exec 200 -- systemctl is-active apt-cacher-ng   # le service tourne-t-il ?

# Interroger le service depuis le nœud, sur son port 3142
curl -s -o /dev/null -w "rapport -> HTTP %{http_code}\n" http://10.<site>.<N>.50:3142/acng-report.html

Résultat attendu (fin de l'installation, puis les trois vérifications) :

Created symlink '/etc/systemd/system/multi-user.target.wants/apt-cacher-ng.service' → '/usr/lib/systemd/system/apt-cacher-ng.service'.
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for libc-bin (2.41-12+deb13u3) ...
enabled
active
rapport -> HTTP 200

L'installation affiche aussi plusieurs lignes locale: Cannot set LC_CTYPE to default locale : la langue du nœud n'est pas installée dans le conteneur. C'est sans conséquence.

La ligne Created symlink est la preuve que le service démarrera avec le conteneur. acng-report.html est la page de rapport du cache ; interrogée à la racine (/), le service répond 406 Usage Information, ce qui est normal : il attend des demandes de paquets, pas une visite.

Étape 5 bis — Prouver que le cache sert

Un service qui répond ne prouve pas qu'il fait son travail. On demande deux fois le même paquet Debian à travers le cache (curl -x, qui passe par un proxy), sans rien modifier sur le nœud.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Un vrai paquet du dépôt Debian 13
# Deux demandes identiques, à travers le cache : taille et durée de chacune
curl -x http://10.<site>.<N>.50:3142 -s -o /dev/null -w "essai 1 : HTTP %{http_code}, %{size_download} octets, %{time_total} s\n" http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-5_amd64.deb   # la première
curl -x http://10.<site>.<N>.50:3142 -s -o /dev/null -w "essai 2 : HTTP %{http_code}, %{size_download} octets, %{time_total} s\n" http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-5_amd64.deb   # la même, de nouveau
# Le journal du cache, dans le conteneur
pct exec 200 -- tail -3 /var/log/apt-cacher-ng/apt-cacher.log

Résultat attendu :

essai 1 : HTTP 200, 53228 octets, 0.051535 s
essai 2 : HTTP 200, 53228 octets, 0.000364 s
1791380405|I|54762|10.59.1.11|debrep/pool/main/h/hello/hello_2.10-5_amd64.deb
1791380405|O|53507|10.59.1.11|debrep/pool/main/h/hello/hello_2.10-5_amd64.deb
1791380405|O|53507|10.59.1.11|debrep/pool/main/h/hello/hello_2.10-5_amd64.deb

Sur le lab (lab 10.59.1.x). Le premier essai a pris 52 ms, le second 0,4 ms : plus de cent fois moins. Le journal dit pourquoi.

La ligne I (in) est le fichier reçu d'Internet, une seule fois. Les deux lignes O (out) sont les deux envois vers le nœud (10.59.1.11 sur le lab, votre nœud chez vous). Le paquet est désormais rangé dans le conteneur, sous /var/cache/apt-cacher-ng/debrep/pool/main/h/hello/.

Pour qu'une machine fasse passer tout son apt par ce cache, une ligne suffit dans /etc/apt/apt.conf.d/ : Acquire::http::Proxy "http://10.<site>.<N>.50:3142";. Ne la posez pas sur votre nœud : le jour où le conteneur serait arrêté, les mises à jour du nœud échoueraient.

Étape 6 — Modifier les ressources à chaud

Les ressources d'un conteneur LXC se modifient sans arrêt — les cgroups appliquent les limites immédiatement.

Via l'interface : CT 200 → Resources → double-clic Memory (768 Mo / Swap 512 Mo) → OK, puis Processors → 2 cœurs → OK.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Deux ressources modifiées d'un coup, conteneur en marche
pct set 200 --memory 768 --cores 2

# Vérifier depuis l'intérieur : lxcfs fait voir au conteneur ses propres limites
pct exec 200 -- free -h
pct exec 200 -- nproc   # nombre de cœurs vus par le conteneur

Résultat attendu : free -h passe de 512Mi à 768Mi sur la ligne Mem: immédiatement — la limite du conteneur, et non la mémoire de l'hôte. nproc, lui, répondait encore 1 juste après la commande, puis 2 une vingtaine de secondes plus tard. Aucun redémarrage n'a eu lieu : pct status 200 n'a jamais cessé d'afficher running.

Pourquoi ce délai sur les cœurs ? La mémoire est appliquée tout de suite par les cgroups.

Le nombre de cœurs, lui, est traduit en une liste de processeurs (cpuset) par le service pvestatd du nœud, qui répartit les conteneurs à chaque cycle de 10 secondes. Si nproc affiche l'ancienne valeur, attendez un cycle et relancez-le.

Le CT 200 (cache-apt) tourne (icône verte dans l'arborescence) avec 768.00 MiB de mémoire et 2 cœurs : les nouvelles valeurs sont en place sans arrêt. Pour les modifier à la souris : double-clic sur la ligne.

Étape 7 — Snapshot et restauration

Créer le snapshot : CT 200 → Snapshots → Take Snapshot, Name cache-ok.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Snapshot nommé, avec une description qui dit POURQUOI il a été pris
pct snapshot 200 cache-ok --description "apt-cacher-ng installe et fonctionnel"
pct listsnapshot 200   # vérifier que le snapshot existe

Résultat attendu :

`-> cache-ok                    2026-09-28 07:58:43     apt-cacher-ng installe et fonctionnel
 `-> current                                            You are here!

Deux lignes : cache-ok avec sa date et sa description, puis current, l'état présent du conteneur, « posé » sur ce snapshot.

Simuler une erreur :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# La « bêtise » : désinstaller le service et sa configuration
pct exec 200 -- env DEBIAN_FRONTEND=noninteractive apt purge -y apt-cacher-ng
# Le service a disparu, et le port 3142 ne répond plus
pct exec 200 -- systemctl is-active apt-cacher-ng
curl -s -m 5 -o /dev/null -w "curl -> %{http_code} (code retour %{exitcode})\n" http://10.<site>.<N>.50:3142/acng-report.html   # interroger le port 3142

Résultat attendu :

Removing apt-cacher-ng (3.7.5-1) ...
Purging configuration files for apt-cacher-ng (3.7.5-1) ...
inactive
curl -> 000 (code retour 7)

000 et le code retour 7 de curl signifient « connexion impossible » : plus rien n'écoute sur le port.

Restaurer (le conteneur doit être arrêté avant le retour arrière) :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Arrêter, revenir au snapshot, redémarrer
pct stop 200
pct rollback 200 cache-ok   # revenir au snapshot
pct start 200   # redémarrer le conteneur

# Le service est revenu… et son cache aussi : le paquet de l'étape 5 bis sort directement du cache
pct exec 200 -- systemctl is-active apt-cacher-ng
curl -x http://10.<site>.<N>.50:3142 -s -o /dev/null -w "après retour : HTTP %{http_code}, %{time_total} s\n" $U   # nouveau téléchargement à travers le cache
pct exec 200 -- tail -1 /var/log/apt-cacher-ng/apt-cacher.log   # dernière ligne du journal du cache

Résultat attendu :

active
après retour : HTTP 200, 0.003473 s
1791380522|O|53507|10.59.1.11|debrep/pool/main/h/hello/hello_2.10-5_amd64.deb

Une seule ligne O, aucune ligne I : le fichier n'a pas été retéléchargé. Le snapshot avait figé tout le système de fichiers, cache compris. (Si votre Shell a été rouvert entre-temps, redéfinissez U comme à l'étape 5 bis.)

Pendant pct rollback, LVM affiche des avertissements WARNING: Sum of all thin volume sizes … exceeds the size of thin pool : c'est le sur-provisionnement du pool thin : les volumes promis dépassent la place réelle. Il n'empêche rien ici, mais il se surveille.

L'arbre des snapshots : cache-ok, avec sa date et sa description, et NOW juste en dessous — l'état courant repart de ce snapshot. Rollback ramène le conteneur à cache-ok ; il faut sélectionner le snapshot avant de cliquer.

Étape 8 — Sauvegarde vzdump

Via l'interface : CT 200 → Backup → Backup Now — Storage local, Mode Snapshot, Compression ZSTD.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Sauvegarde à chaud (mode snapshot), compressée en zstd, sur le stockage local
vzdump 200 --storage local --compress zstd --mode snapshot

# Lister les sauvegardes du stockage local, via l'API
pvesh get /nodes/$(hostname)/storage/local/content --content backup

Résultat attendu (fin de vzdump) :

INFO: Total bytes written: 730071040 (697MiB, 189MiB/s)
INFO: archive file size: 206MB
INFO: Finished Backup of VM 200 (00:00:04)
INFO: Backup job finished successfully

L'archive vzdump-lxc-200-2026_09_28-07_59_48.tar.zst, au format tar.zst, sur le stockage local. Le nom contient la date et l'heure de la sauvegarde.

Les 697 Mio du conteneur sont devenus environ 206 Mo après compression zstd (l'interface affiche 216.96 MB, en millions d'octets). Restore recrée le conteneur à partir de cette archive.

Validation finale

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# État du conteneur, du service, du snapshot et de la sauvegarde
pct status 200
pct exec 200 -- systemctl is-active apt-cacher-ng   # le service
pct listsnapshot 200   # les snapshots
pvesh get /nodes/$(hostname)/storage/local/content --content backup   # les sauvegardes du stockage local

Résultat attendu : status: running, active, le snapshot cache-ok listé, et une ligne vzdump-lxc-200-…tar.zst dans les sauvegardes.