Convertir un Template Proxmox OVH de LVM vers ZFS

Les templates Proxmox fournis par OVH sont installés par défaut sur LVM. C'est rapide à provisionner, mais ça ferme la porte à la réplication entre nœuds, aux snapshots atomiques et à l'intégrité native des données. Pour débloquer la haute disponibilité réelle de Proxmox, il faut basculer sur ZFS : voici la procédure complète, testée en production sur un cluster 3 nœuds OVH.

Pourquoi ZFS pour la haute disponibilité #

ZFS permet la réplication native entre nœuds via zfs send/receive, qui est le mécanisme utilisé par le module HA de Proxmox. LVM ne le permet pas. Autres avantages : snapshots atomiques quasi-instantanés, compression native (gratuite en CPU à 2026 avec zstd), et vérification d'intégrité périodique (scrub) qui détecte les corruptions silencieuses avant qu'elles ne se propagent dans les sauvegardes.

Côté inconvénients à connaître : ZFS demande de la RAM (compter 1 Go d'ARC par To de données utiles minimum), ne sait pas étendre un pool de manière aussi souple qu'un LVM (ajouter un disque = nouveau vdev ou remplacement complet), et certaines opérations Linux exotiques (chmod ACL POSIX, NFS root) demandent des réglages spécifiques.

Prérequis #

• Cluster Proxmox 8.x avec au moins 2 nœuds (sur un nœud unique, ZFS reste utile pour les snapshots et l'intégrité).
• Disque dédié à ZFS : un second disque physique, idéalement NVMe sur les gammes OVH High Grade / Scale / Advance. Pas de cohabitation possible avec LVM sur le même disque.
• Accès SSH root sur tous les nœuds du cluster.
• Sauvegarde complète testée AVANT manipulation (PBS, snapshot LVM ou export vzdump selon contexte).
• RAM : prévoir 8 Go minimum sur l'hôte, dont ~4 Go réservés à l'ARC ZFS (cache). Voir étape 3 pour le tuning précis.

Étape 1 : installer ZFS si nécessaire #

Sur les templates Proxmox OVH récents, zfsutils-linux est déjà installé. Sur les images plus anciennes ou sur une installation Debian + Proxmox manuelle, il faut le rajouter explicitement.

apt update && apt install -y zfsutils-linux
modprobe zfs
zfs version

La commande zfs version valide que le module noyau est bien chargé. Si elle échoue, c'est typiquement un signe que le kernel actif n'a pas les headers ZFS : réinstaller pve-headers-$(uname -r) puis recharger le module.

Étape 2 : créer le pool ZFS #

On crée un pool de stockage ZFS nommé rpool (convention Proxmox) sur le disque dédié, avec deux réglages structurants posés dès la création.

# Verifier d'abord le bon device cible
lsblk
parted -l

# Creer le pool sur le second disque
zpool create -o ashift=12 rpool /dev/sdb

# Activer la compression et desactiver atime (perfs)
zfs set compression=zstd rpool
zfs set atime=off rpool

# Creer le dataset dedie aux VMs et CT
zfs create rpool/data

Pourquoi ashift=12 #

ashift=12 aligne les blocs ZFS sur 4 Ko (2^12 octets), valeur native des SSD et NVMe modernes. Sans ce paramètre, ZFS pourrait s'aligner sur 512 octets, soit une division par 4 à 8 de la performance d'écriture sur les disques flash. Le paramètre est figé à la création du pool, impossible à modifier après, d'où la criticité de le poser dès le départ.

Compression : zstd plutôt que lz4 #

La documentation historique de Proxmox recommandait lz4. Sur les kernels 6.5+ avec ZFS 2.2+ (standard depuis Proxmox 8.1), zstd au niveau 3 par défaut offre un meilleur ratio de compression pour un coût CPU à peine supérieur, et reste plus rapide que lz4 en lecture grâce au multi-threading. Sauf raison spécifique (CPU très faible, charge synchrone extrême), partir directement sur zstd.

Étape 3 : tuner l'ARC ZFS (RAM) #

Par défaut, ZFS s'alloue jusqu'à 50 % de la RAM totale de l'hôte pour son cache ARC (Adaptive Replacement Cache). Sur un serveur OVH avec 32 Go de RAM destinés à 8 VMs, ZFS confisquerait 16 Go au démarrage, laissant 16 Go pour les VMs et l'hyperviseur lui-même. C'est presque toujours trop, surtout si les VMs ont leur propre cache filesystem côté guest.

Règle pragmatique : fixer l'ARC à 1 Go par To de données ZFS effectivement utilisées, plafonné à 25 % de la RAM totale de l'hôte. Sur 32 Go de RAM, cela donne 4 à 8 Go d'ARC selon la taille du pool.

# Plafonner l'ARC a 4 Go (valeur en octets : 4 * 1024^3)
echo 'options zfs zfs_arc_max=4294967296' > /etc/modprobe.d/zfs.conf
update-initramfs -u
systemctl reboot

# Apres reboot, verifier les valeurs effectives
awk '/^c_max|^size/ {print $1, $3}' /proc/spl/kstat/zfs/arcstats

Étape 4 : ajouter le storage dans Proxmox #

Via l'interface web : Datacenter → Storage → Add → ZFS. Sélectionner le pool rpool/data, donner un ID lisible (ex: local-zfs), cocher Thin provision pour économiser l'espace. Ne PAS cocher Shared sauf si vous avez un pool synchrone entre nœuds (cas rare, type Ceph posé sur ZFS). Pour la réplication asynchrone Proxmox classique, laisser cette case décochée.

Étape 5 : migrer les VMs existantes #

Hypothèse : le template OVH a créé un storage local-lvm sur LVM qui héberge actuellement vos VMs. Les commandes ci-dessous migrent une VM (VMID 100) du LVM vers le nouveau pool ZFS, à chaud ou à froid selon le contexte.

# Identifier les disques actuels de la VM 100
qm config 100 | grep -E '^(scsi|virtio|sata|ide)[0-9]'

# Migration online (VM allumee, copie sans coupure ~ 1 a 3 Go/min)
qm move-disk 100 scsi0 local-zfs --delete

# Migration offline (VM eteinte, beaucoup plus rapide)
qm shutdown 100 && qm move-disk 100 scsi0 local-zfs --delete && qm start 100

Étape 6 : activer la réplication entre nœuds #

Une fois la VM sur ZFS, la réplication devient triviale. Dans l'interface web, ouvrir la VM → Replication → Add → choisir le nœud cible et la fréquence (cron au format Proxmox : */15 = toutes les 15 minutes, 0 */6 = toutes les 6 heures pleines).

Vérifier dans les logs (/var/log/pve/replicate-*) que la première réplication aboutit. La première synchronisation transfère l'intégralité du dataset, les suivantes ne poussent que les blocs modifiés (delta zfs send -i), typiquement 50 à 500 Mo par cycle sur une VM modérément active.

Monitoring et maintenance du pool #

Un pool ZFS sans monitoring est un piège silencieux : la corruption d'un disque peut rester invisible des semaines avant de se manifester dans une réplication ou un backup, à un moment où il est trop tard pour récupérer puisque les sauvegardes contiennent déjà les blocs corrompus.

Vérification de l'état au quotidien #

# Etat du pool, des disques, et detection des corruptions
zpool status -v rpool

# Tout va bien si la sortie affiche :
#   state: ONLINE
#   errors: No known data errors

Scrub mensuel automatique #

Un scrub lit l'intégralité du pool et compare les checksums : c'est le seul moyen de détecter les corruptions silencieuses (bit rot) avant qu'elles ne se propagent. Sur Proxmox 8, un timer systemd zfs-scrub-monthly@rpool.timer est fourni : vérifier qu'il est activé.

# Activer le scrub mensuel automatique sur le pool rpool
systemctl enable --now zfs-scrub-monthly@rpool.timer

# Lancer un scrub manuel a la demande (durera plusieurs heures sur gros pool)
zpool scrub rpool

# Suivre la progression
zpool status rpool

Alertes par mail sur dégradation #

Le pool peut passer en état DEGRADED (un disque en panne dans un mirror) ou FAULTED (perte de redondance, données potentiellement inaccessibles) sans qu'on s'en rende compte. Configurer le démon zed (ZFS Event Daemon) pour envoyer un mail à chaque changement d'état critique.

# Configurer zed avec l'adresse mail destinataire des alertes
sed -i 's|^#ZED_EMAIL_ADDR=.*|ZED_EMAIL_ADDR="admin@exemple.fr"|' /etc/zfs/zed.d/zed.rc
sed -i 's|^#ZED_NOTIFY_INTERVAL_SECS=.*|ZED_NOTIFY_INTERVAL_SECS=3600|' /etc/zfs/zed.d/zed.rc
systemctl restart zfs-zed

# Tester en simulant un evenement (sans casser le pool)
zpool events rpool

Pièges classiques à éviter #

• ashift trop bas : pool créé sans ashift=12 sur SSD/NVMe. Performance d'écriture divisée par 4 à 8, impossible à corriger sans recréer le pool.
• ARC dévorant la RAM : sans zfs_arc_max, l'ARC peut empêcher les VMs de démarrer faute de RAM disponible. Symptôme : VMs OOM-killées sans cause applicative.
• Disque ajouté sans planification : zpool add ajoute un nouveau vdev (= élargit le pool). Si le disque ajouté n'est pas en miroir, la panne d'un seul disque détruit l'intégralité du pool. Toujours répliquer la topologie du vdev existant.
• Pas de scrub : sans scrub, les corruptions silencieuses ne sont détectées qu'au moment de la restauration d'un backup… qui contient désormais lui aussi les blocs corrompus.
• Réplication sans monitoring : la réplication peut échouer silencieusement (réseau, espace disque cible, divergence de datasets). Surveiller /var/log/pve/replicate-*.log et alerter sur erreur.

Conclusion #

Convertir un template OVH de LVM vers ZFS débloque trois fonctionnalités qui rendent la promesse de haute disponibilité de Proxmox réellement utilisable : réplication entre nœuds, snapshots atomiques et vérification d'intégrité périodique. L'investissement initial (1 à 2 heures par nœud) est largement rentabilisé dès la première panne disque évitée, ou la première corruption silencieuse détectée par un scrub avant qu'elle ne contamine les sauvegardes.

Pour aller plus loin sur la stratégie de sauvegarde qui complète la réplication ZFS, le guide PBS détaille la déduplication à la source, la rétention multi-niveaux et la protection anti-ransomware. Et pour reproduire ce setup sur un serveur Hetzner plutôt qu'OVH, l'installation Proxmox 8 sur Hetzner s'enchaîne naturellement avec ce guide.