Migration VMware vers Proxmox VE — Tutoriel Technique Complet

100%

GRIMOIRE❦

Grimoire Corpus Dindon Volumes de Synthèse Le Socle du Fer

OPS

GUIDE TUTORIEL TECHNIQUE · JUIN 2026

◆◆◆

MIGRATION VMWARE
VERS PROXMOX VE
Tutoriel d'Exécution Complet · 13 Modules
Stretched Cluster D1 · D2 · Témoin D3

◆

De l'audit initial à l'exploitation continue
Commandes, fichiers de configuration et checklists de validation

◆◆◆

13Modules d'exécution

3Datacenters D1/D2/D3

60+Commandes & configs

4Scénarios de panne

◆

SUITE TECHNIQUE — COMPLÉMENT À L'ÉTUDE D'ARCHITECTURE

Ce guide est la suite opérationnelle de l'étude d'architecture. Là où l'étude formalise les choix techniques et la trajectoire cible, ce tutoriel fournit les commandes, fichiers de configuration et checklists nécessaires à l'exécution réelle de chaque couche de la migration, de l'audit initial jusqu'à l'exploitation continue.

◆◆◆

Toutes les commandes et configurations sont génériques et illustratives.
À adapter à votre environnement réel avant exécution en production. Document public · CC BY-NC-SA 4.0

◆

Amine RAITI · Architecte Infrastructure & SRE
Document public · CC BY-NC-SA 4.0 · AI Powered by Amine

OPS

SOMMAIRE — 13 MODULES D'EXÉCUTION

SOMMAIRE

◆◆◆

◆ Module 0 · Audit et Inventaire Pre-Migration

◆ Module 1 · Dimensionnement et Calcul de Capacité

◆ Module 2 · Préparation et Pre-Flight

◆ Module 3 · Cluster Corosync et QDevice D3

◆ Module 4 · Ceph Stretched de bout en bout

◆ Module 5 · Réseau SDN VXLAN/EVPN

◆ Module 6 · Sécurité, Hardening et IAM

◆ Module 7 · HA, Fencing et Affinité

◆ Module 8 · Migration v2v pas à pas

◆ Module 9 · Sauvegarde PBS et Immuabilité

◆ Module 10 · Observabilité

◆ Module 11 · Exercices de Panne (Chaos Engineering)

◆ Module 12 · Exploitation Continue et Recette

◆◆◆

◆ COMMENT UTILISER CE GUIDE

Chaque module suit la même structure : objectif, commandes d'exécution, fichiers de configuration complets, et une checklist de validation en fin de section. Les modules sont conçus pour être suivis dans l'ordre — chaque module suivant suppose que les validations du module précédent sont acquises. Les blocs de commande sont génériques et doivent être adaptés aux conventions de nommage, plages d'adressage IP et conventions de sécurité de votre organisation avant exécution.

Ce document est la suite opérationnelle de l'étude d'architecture de référence. Il ne remplace pas un accompagnement par un intégrateur ou un architecte sur un projet de migration réel à fort enjeu — il fournit le squelette d'exécution reproductible.

OPS

MODULE 0 · AUDIT ET INVENTAIRE PRE-MIGRATION

AUDIT ET INVENTAIRE PRE-MIGRATION

◆

Avant toute action sur Proxmox, l'inventaire exhaustif de l'environnement VMware existant est la condition de réussite numéro un. La majorité des incidents de migration documentés dans l'industrie proviennent d'une dépendance applicative non identifiée en amont — pas d'un défaut technique de la plateforme cible.

0.1 · Inventaire des VMs via PowerCLI

Script d'export complet de l'inventaire vCenter au format CSV, incluant la configuration matérielle virtuelle, les politiques de stockage SPBM et l'état des outils invités.

Connect-VIServer -Server vcenter.local
Get-VM | Select-Object Name, NumCpu, MemoryGB,
  @{N="Datastore";E={($_ | Get-Datastore).Name -join ","}},
  @{N="SPBMPolicy";E={(Get-SpbmEntityConfiguration -VM $_).StoragePolicy.Name}},
  @{N="ToolsStatus";E={$_.ExtensionData.Guest.ToolsStatus}},
  @{N="OS";E={$_.ExtensionData.Guest.GuestFullName}},
  PowerState | Export-Csv -Path inventaire_vms.csv -NoTypeInformation

0.2 · Classification par criticité (Tier 1/2/3)

1Tier 1 (Critique) · RPO < 15 min, RTO < 1h. Bases de données transactionnelles, ERP, systèmes de paie.

2Tier 2 (Important) · RPO < 1h, RTO < 4h. Applications métier non critiques, intranet.

3Tier 3 (Non-critique) · RPO < 24h, RTO < 24h. Environnements de dev/test, sandbox.

0.3 · Cartographie des dépendances réseau NSX-T

Avant de remplacer NSX-T par le SDN Proxmox, documenter la topologie exacte : segments logiques, règles DFW actives, passerelles T0/T1, tables anti-spoofing.

curl -k -u admin:password -X GET \
  "https://nsx-manager.local/policy/api/v1/infra/segments" \
  -H "Content-Type: application/json" > segments_nsx.json

curl -k -u admin:password -X GET \
  "https://nsx-manager.local/policy/api/v1/infra/domains/default/security-policies" \
  -H "Content-Type: application/json" > dfw_rules.json

0.4 · Audit des politiques de stockage SPBM

Lister les politiques SPBM en usage et leur correspondance future en CRUSH rules Ceph — cette étape conditionne la complexité du Module 4.

Get-SpbmStoragePolicy | Select-Object Name, AnyOfRuleSets, Description

0.5 · Audit des licences Windows Server

Pour chaque VM Windows Server, vérifier le mode de licensing (cœur physique, Datacenter, mobilité de licence) avant la migration vers KVM — point de non-conformité fréquent et coûteux s'il est découvert après la migration.

Inventaire CSV complet généré et vérifié manuellement sur 10% des VMs

Classification Tier 1/2/3 validée avec les équipes métier

Export NSX-T (segments + DFW) archivé et documenté

Table de correspondance SPBM → CRUSH rules ébauchée

Audit de conformité licences Windows Server effectué

OPS

MODULE 1 · DIMENSIONNEMENT ET CALCUL DE CAPACITÉ

DIMENSIONNEMENT ET CALCUL DE CAPACITÉ

◆

1.1 · Formule de sizing Ceph — capacité utile

La capacité utile dépend du facteur de réplication choisi. Pour une architecture stretched avec size=4 (2 copies par site) et min_size=2 :

Capacité_utile = Capacité_brute_totale / facteur_réplication
Capacité_utile = Capacité_brute_totale / 4

Exemple : 24 OSD de 4 To chacun = 96 To bruts → Capacité utile réelle = 96 / 4 = 24 To exploitables

1.2 · Calcul de la RAM nécessaire par nœud Ceph

Règle de dimensionnement : prévoir environ 1 Go de RAM par To d'OSD géré, plus une marge de 30% pour les pics de reconstruction (recovery).

RAM_Ceph_minimale = (Volume_OSD_par_nœud_en_To × 1 Go) × 1.3

Exemple : un nœud avec 4 OSD de 4 To = 16 To par nœud → RAM_Ceph_minimale = (16 × 1) × 1.3 = 20.8 Go dédiés à Ceph

1.3 · Calcul de la capacité de calcul (vCPU/vRAM)

Méthode de calcul du taux de consolidation cible en tenant compte de la marge HA (perte d'un site).

vCPU_disponibles_par_site = (Cœurs_physiques × Nb_nœuds_par_site) × ratio_survcharge
Marge_HA_requise = Charge_totale_VMs / Nb_sites_actifs_après_perte

Avec 2 sites actifs et perte tolérée d'1 site : chaque site doit pouvoir absorber 100% de la charge totale seul.

1.4 · Calculateur de TCO réutilisable

Poste

Formule

Variable à renseigner

CAPEX Matériel

Nb_nœuds × Coût_unitaire

Devis fournisseur

Support éditeur annuel

Nb_nœuds × Coût_support

~1400€/an/nœud (ordre de grandeur)

Double-run transition

Coût_VMware × Durée_mois

Variable selon contrat existant

Économie annuelle nette

Coût_VMware - Support_Proxmox

Calcul de capacité utile Ceph documenté et validé par site

RAM Ceph calculée et comparée aux specs matérielles commandées

Marge HA testée sur papier : un site seul absorbe 100% de la charge

Tableau TCO rempli avec les chiffres réels du projet

OPS

MODULE 2 · PRÉPARATION ET PRE-FLIGHT

PRÉPARATION ET PRE-FLIGHT

◆

2.1 · Installation Proxmox VE — déploiement reproductible

Utiliser l'ISO officielle en mode graphique ou via fichier de réponse pour un déploiement automatisé et reproductible sur plusieurs nœuds.

[global]
keyboard = "fr"
country = "fr"
fqdn = "pve-d1-node1.lan.local"
timezone = "Europe/Paris"
root_password = "CHANGER_MOI"

[network]
source = "from-dhcp"

[disk-setup]
filesystem = "zfs"
zfs.raid = "raid10"

2.2 · Configuration réseau — bonding et VLANs

Chaque nœud doit disposer d'au minimum 2 interfaces réseau en bonding actif-actif (LACP) pour le trafic Ceph back-end, séparées du réseau de management.

auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 10.10.1.11/24
    bridge-ports bond0
    bridge-stp off

2.3 · Benchmark réseau inter-site — iperf3

Valider la latence et bande passante réelles entre D1 et D2. Ceph stretché tolère jusqu'à 10ms RTT.

# Sur D2 (serveur)
iperf3 -s -p 5201

# Sur D1 (client) — 60 secondes, 4 flux parallèles
iperf3 -c 10.20.1.11 -p 5201 -t 60 -P 4

# Test latence/jitter
ping -c 100 10.20.1.11 | tail -5

Débit mesuré ≥ 25 Gbps sur le lien dédié inter-site

Latence RTT moyenne < 10ms, jitter stable

2.4 · Benchmark stockage brut — FIO

Test de performance brute des disques NVMe avant intégration Ceph, pour détecter tout disque sous-performant.

fio --name=test_baseline --ioengine=libaio --rw=randwrite \
  --bs=4k --direct=1 --size=10G --numjobs=4 --iodepth=64 \
  --runtime=60 --group_reporting --filename=/dev/nvme0n1

IOPS écriture aléatoire 4k conformes aux specs constructeur

Latence moyenne d'écriture inférieure à 1ms sur le disque seul

OPS

MODULE 2 · PRÉPARATION ET PRE-FLIGHT (Suite)

PRÉPARATION ET PRE-FLIGHT

◆

2.5 · Checklist matérielle pre-flight

Contrôleurs HBA en mode IT/Pass-through (pas de RAID matériel actif)

Power Loss Protection (PLP) vérifiée sur chaque SSD destiné à Ceph

Watchdog matériel actif et testé (/dev/watchdog accessible)

BIOS en mode performance, C-States désactivés sur nœuds de calcul

OPS

MODULE 3 · CLUSTER COROSYNC ET QDEVICE D3

CLUSTER COROSYNC ET QDEVICE D3

◆

3.1 · Formation du cluster Proxmox

Le premier nœud initialise le cluster, les nœuds suivants le rejoignent — création de la base de configuration distribuée pmxcfs partagée entre tous les nœuds.

# Sur pve-d1-node1, initialisation
pvecm create cluster-stretched --link0 10.10.1.11

# Sur chaque nœud suivant, jonction
pvecm add 10.10.1.11 --link0 10.10.1.12

pvecm status affiche le nombre total de nœuds attendus avec quorum OK

3.2 · Déploiement du QDevice sur D3

Le QDevice tourne sur une machine indépendante hébergée sur D3, totalement séparée du chemin réseau D1-D2.

# Sur la machine D3
apt install corosync-qnetd -y

# Sur un nœud du cluster Proxmox
apt install corosync-qdevice -y
pvecm qdevice setup 10.30.1.5 -f

pvecm status affiche le QDevice comme membre votant actif

3.3 · Vérification de la répartition des votes

Avec 3 nœuds par site (D1 + D2) plus le QDevice, le total est de 7 voix. Le quorum est calculé à la majorité absolue.

pvecm status
# Sortie attendue : Expected votes: 7, Total votes: 7, Quorum: 4

3.4 · Test de simulation — perte du lien inter-site

Avant mise en production, simuler la coupure du lien D1-D2 pour valider le comportement de bascule (le site avec le QDevice obtient la majorité).

# Simulation de coupure réseau sur un nœud de test
iptables -A INPUT -s 10.20.0.0/24 -j DROP
iptables -A OUTPUT -d 10.20.0.0/24 -j DROP

Le site prioritaire (avec accord QDevice) conserve le quorum

Le site isolé déclenche son auto-clôture (watchdog) sans intervention manuelle

Rétablissement du lien restaure automatiquement le cluster complet

3.5 · Checklist de fin de module

Cluster à 7 voix opérationnel et stable depuis plus de 24h

Test de coupure réseau effectué et documenté avec horodatage

Procédure de reconnexion post-incident validée pour les équipes ops

OPS

MODULE 4 · CEPH STRETCHED DE BOUT EN BOUT · 1/2

CEPH STRETCHED DE BOUT EN BOUT

◆

4.1 · Déploiement initial via cephadm

cephadm est l'outil de déploiement recommandé pour les versions récentes de Ceph. Il s'exécute en conteneur et orchestre l'installation sur l'ensemble des nœuds.

# Bootstrap du premier moniteur
cephadm bootstrap --mon-ip 10.10.1.11 --cluster-network 10.10.2.0/24

# Ajout des hôtes au cluster Ceph
ceph orch host add pve-d1-node2 10.10.1.12
ceph orch host add pve-d1-node3 10.10.1.13
ceph orch host add pve-d2-node1 10.20.1.11
ceph orch host add pve-d2-node2 10.20.1.12
ceph orch host add pve-d2-node3 10.20.1.13

4.2 · Construction de la hiérarchie CRUSH par datacenter

Créer les buckets logiques de type datacenter pour encapsuler les hôtes de chaque site — condition préalable à l'activation du stretch mode.

ceph osd crush add-bucket D1 datacenter
ceph osd crush add-bucket D2 datacenter
ceph osd crush move D1 root=default
ceph osd crush move D2 root=default
ceph osd crush move pve-d1-node1 datacenter=D1
ceph osd crush move pve-d1-node2 datacenter=D1
ceph osd crush move pve-d1-node3 datacenter=D1
ceph osd crush move pve-d2-node1 datacenter=D2
ceph osd crush move pve-d2-node2 datacenter=D2
ceph osd crush move pve-d2-node3 datacenter=D2

ceph osd tree affiche la hiérarchie D1/D2 correctement peuplée

4.3 · Définition de la règle CRUSH stretched

La règle impose 2 copies sur D1 et 2 copies sur D2, garantissant la survie complète des données en cas de perte d'un site.

ceph osd crush rule create-replicated stretched_rule default datacenter
ceph osd crush rule dump stretched_rule

4.4 · Activation du mode stretch natif

Le mode stretch natif lie explicitement le moniteur arbitre D3 et active le comportement de bascule automatique.

ceph mon set election_strategy connectivity
ceph mon enable_stretch_mode pve-d3-mon stretched_rule datacenter

ceph -s affiche le cluster en mode "stretched" actif sans warning

OPS

MODULE 4 · CEPH STRETCHED DE BOUT EN BOUT · 2/2

CEPH STRETCHED — POOL RBD ET TEST DE BASCULE

◆

4.5 · Création du pool RBD pour Proxmox

# Création du pool de stockage VM
ceph osd pool create vm-storage 128 128 replicated stretched_rule
ceph osd pool set vm-storage size 4
ceph osd pool set vm-storage min_size 2
rbd pool init vm-storage

# Intégration dans Proxmox
pvesm add rbd ceph-stretched --pool vm-storage \
  --monhost "10.10.1.11 10.20.1.11 10.30.1.5"

4.6 · Test de bascule réel — perte simulée du site D1

Arrêt contrôlé des services Ceph sur D1 pour valider le comportement de bascule en conditions réalistes.

systemctl stop ceph-osd.target
systemctl stop ceph-mon.target

ceph -s depuis D2 affiche HEALTH_WARN avec pool en mode dégradé mais accessible en écriture

Les VMs sur D2 continuent de fonctionner sans interruption d'écriture

Au redémarrage des services D1, la resynchronisation (recovery) démarre automatiquement

4.7 · Checklist de fin de module

Pool vm-storage opérationnel avec size=4, min_size=2 vérifié

Test de coupure D1 effectué avec succès, VMs D2 ininterrompues

Temps de resynchronisation post-incident mesuré et documenté

⚠ POINT D'ATTENTION SRE — LATENCE RÉSEAU INTER-SITE

La réplication synchrone Ceph implique qu'une opération d'écriture subisse la latence aller-retour inter-site (RTT). Une latence RTT de 2ms ajoute de facto un coût de transaction fixe d'environ 2ms. L'usage de fibres dédiées et de disques NVMe classe entreprise est impératif pour ne pas dégrader les performances applicatives perçues.

OPS

MODULE 5 · RÉSEAU SDN VXLAN/EVPN

RÉSEAU SDN VXLAN/EVPN

◆

5.1 · Activation du module SDN Proxmox

apt install frr frr-pythontools -y
systemctl enable frr --now

5.2 · Configuration de la zone EVPN

Zone SDN de type EVPN qui encapsule le trafic en VXLAN avec un plan de contrôle BGP pour la diffusion des routes entre D1, D2 et D3.

# /etc/pve/sdn/zones.cfg
evpn: zone-stretched
    controller bgp-controller
    vrf-vxlan 10000
    exitnodes pve-d1-node1,pve-d2-node1

# /etc/pve/sdn/controllers.cfg
bgp: bgp-controller
    asn 65000
    node pve-d1-node1
    peers 10.20.1.11,10.30.1.5

5.3 · Définition des VNets applicatifs

Chaque VNet correspond à un segment logique équivalent à un segment NSX-T, avec passerelle anycast distribuée sur tous les hyperviseurs.

# /etc/pve/sdn/vnets.cfg
vnet: vnet-web
    zone zone-stretched
    tag 100

vnet: vnet-db
    zone zone-stretched
    tag 200

5.4 · Pare-feu distribué (équivalent DFW)

# /etc/pve/firewall/cluster.fw
[group sec-web-servers]
IN SSH(ACCEPT) -log info
IN HTTP(ACCEPT)
IN HTTPS(ACCEPT)
OUT DB_PORT(ACCEPT) -dest +db-servers-ipset

[ipset web-servers-ipset]
10.100.10.0/24
[ipset db-servers-ipset]
10.100.20.0/24

5.5 · Anti-spoofing

pvesh set /nodes/pve-d1-node1/qemu/101/firewall/options --ipfilter 1 --macfilter 1

5.6 · Test de connectivité inter-site

vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show evpn vni"

Routes EVPN apprises sur les trois nœuds exitnodes (D1, D2, D3)

VM sur vnet-web en D1 ping avec succès une VM sur vnet-web en D2

Trafic inter-VNet non autorisé bloqué par le pare-feu

OPS

MODULE 5 · RÉSEAU SDN VXLAN/EVPN

RÉSEAU SDN VXLAN/EVPN

◆

5.7 · Checklist de fin de module

Zone EVPN stable, BGP établi entre D1/D2/D3

Règles de microsegmentation testées positif et négatif

Anti-spoofing actif et vérifié sur toutes les VMs critiques

OPS

MODULE 6 · SÉCURITÉ, HARDENING ET IAM

SÉCURITÉ, HARDENING ET IAM

◆

6.1 · Hardening de l'accès SSH au cluster

# /etc/ssh/sshd_config
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers admin@10.0.0.0/8

6.2 · Activation 2FA (TOTP) sur l'interface web

Proxmox VE supporte TOTP nativement pour l'accès à l'interface de gestion, indépendamment de l'authentification SSH. Configuration via Datacenter > Permissions > Two Factor.

6.3 · Intégration LDAP/Active Directory

Intégrer le cluster à l'annuaire d'entreprise existant pour centraliser la gestion des accès et la traçabilité.

pveum realm add ad-entreprise --type ad \
  --server1 ad.entreprise.local \
  --domain entreprise.local \
  --base-dn "DC=entreprise,DC=local" \
  --bind-dn "CN=svc-proxmox,OU=Service,DC=entreprise,DC=local"

6.4 · Gestion des secrets Ceph et PBS

Les clés d'authentification Ceph (cephx) et de chiffrement PBS doivent être stockées hors du cluster, dans un coffre-fort de secrets dédié.

ceph auth get client.admin -o /root/ceph-admin-key.backup
chmod 600 /root/ceph-admin-key.backup

6.5 · Permissions et rôles (RBAC) par équipe

pveum role add VM-Operator -privs "VM.PowerMgmt,VM.Console,VM.Monitor"
pveum acl modify /vms/101 --roles VM-Operator --users ops-team@ad-entreprise

6.6 · Audit des journaux et conformité

echo "*.* @@siem.entreprise.local:514" >> /etc/rsyslog.conf
systemctl restart rsyslog

6.7 · Checklist de fin de module

Authentification par mot de passe SSH désactivée et clés déployées

2FA actif pour tous les comptes à privilège administrateur

Intégration AD/LDAP fonctionnelle, testée avec un compte non-admin

Clés Ceph et PBS sauvegardées hors cluster dans un coffre-fort dédié

RBAC appliqué : aucun compte applicatif ne dispose du rôle Administrateur complet

OPS

MODULE 7 · HA, FENCING ET AFFINITÉ

HA, FENCING ET AFFINITÉ

◆

7.1 · Configuration des groupes HA

Un groupe HA définit l'ensemble des nœuds éligibles à l'hébergement d'une VM en cas de bascule, avec une priorité optionnelle par nœud.

ha-manager groupadd groupe-tier1 \
  --nodes "pve-d1-node1:2,pve-d1-node2:2,pve-d2-node1:1,pve-d2-node2:1"

7.2 · Ajout d'une VM à la gestion HA

ha-manager add vm:101 --group groupe-tier1 --max_restart 3 --max_relocate 2

ha-manager status affiche la VM 101 comme "started" avec son groupe correctement assigné

7.3 · Règles d'anti-affinité

Empêcher deux VMs redondantes (ex. deux contrôleurs de domaine) de se retrouver sur le même nœud physique après une bascule automatique.

affinity_rules:
  - type: anti-affinity
    name: isolation-ad-controllers
    vms: [101, 102]
    action_on_violation: migrate

7.4 · Watchdog matériel et auto-clôture

ls -la /dev/watchdog
wdctl /dev/watchdog

Le périphérique /dev/watchdog est présent et accessible par le service Proxmox HA

7.5 · Script d'équilibrage dynamique de charge (DRS-like)

En l'absence d'ordonnanceur dynamique natif équivalent à DRS, un script planifié interroge l'API REST de Proxmox pour évaluer la charge et déclencher des migrations à chaud.

import requests

def get_node_load(node):
    r = requests.get(f"https://cluster:8006/api2/json/nodes/{node}/status",
                      verify=False, headers={"Authorization": "PVEAPIToken=..."})
    return r.json()["data"]["cpu"]

nodes = ["pve-d1-node1", "pve-d1-node2", "pve-d2-node1", "pve-d2-node2"]
loads = {n: get_node_load(n) for n in nodes}
overloaded = max(loads, key=loads.get)
underloaded = min(loads, key=loads.get)
if loads[overloaded] - loads[underloaded] > 0.3:
    print(f"Migration recommandée : {overloaded} → {underloaded}")

7.6 · Test de bascule HA réelle

echo c > /proc/sysrq-trigger
# Provoque un crash kernel immédiat pour simuler une panne matérielle brutale

La VM redémarre automatiquement sur un nœud du groupe HA en moins de 120 secondes

Les règles d'anti-affinité sont respectées après la bascule

7.7 · Checklist de fin de module

Tous les groupes HA créés et VMs Tier 1/2 assignées correctement

Watchdog testé et confirmé fonctionnel sur chaque nœud

Test de crash nœud effectué avec RTO mesuré et documenté

OPS

MODULE 8 · MIGRATION V2V PAS À PAS

MIGRATION V2V PAS À PAS

◆

8.1 · Préparation de la connexion vCenter dans Proxmox

L'assistant d'importation natif Proxmox se connecte directement à vCenter pour lister les VMs disponibles, sans étape de conversion manuelle préalable.

pvesh create /nodes/pve-d1-node1/import/vmware \
  --vcenter vcenter.entreprise.local --username svc-migration@vsphere.local

8.2 · Migration d'une VM Linux — cas d'école

pvesh create /nodes/pve-d1-node1/import/vmware/import \
  --vm-id 201 --source-vm "app-linux-01" \
  --storage vm-storage --bridge vnet-web

La VM démarre sous Proxmox avec les disques accessibles en RBD

L'adresse IP et les services applicatifs répondent normalement après démarrage

8.3 · Optimisation post-migration — drivers VirtIO sur Linux

lsmod | grep virtio
# Doit afficher virtio_net, virtio_blk ou virtio_scsi selon la config du disque

8.4 · Migration d'une VM Windows Server — cas d'école

La procédure Windows nécessite l'injection des pilotes VirtIO avant le premier démarrage sous Proxmox, sous peine d'écran bleu au boot.

# Exécuté sur la VM Windows source, avant la coupure finale
pnputil -i -a "E:\viostor\2k22\amd64\viostor.inf"
pnputil -i -a "E:\NetKVM\2k22\amd64\netkvm.inf"

pvesh create /nodes/pve-d1-node1/import/vmware/import \
  --vm-id 202 --source-vm "app-windows-01" \
  --storage vm-storage --bridge vnet-web --scsihw virtio-scsi-pci

Démarrage réussi sans erreur INACCESSIBLE_BOOT_DEVICE

Gestionnaire de périphériques Windows ne signale aucun pilote manquant

8.5 · Configuration du vTPM pour BitLocker

qm set 202 --tpmstate0 vm-storage:1,version=v2.0

La VM Windows détecte le module TPM 2.0 dans le gestionnaire de périphériques

8.6 · Déclaration de conformité licence Windows

Documenter dans le portail SAM (Software Asset Management) de l'entreprise le changement d'infrastructure physique sous-jacente — condition de conformité contractuelle Microsoft.

8.7 · Checklist de fin de module

VM Linux pilote migrée et validée en production sur un cycle complet

VM Windows pilote migrée, VirtIO injecté, vTPM actif si applicable

Déclaration SAM effectuée pour toutes les VMs Windows Server migrées

OPS

MODULE 9 · SAUVEGARDE PBS ET IMMUABILITÉ

SAUVEGARDE PBS ET IMMUABILITÉ

◆

9.1 · Installation de Proxmox Backup Server

PBS s'installe en standalone, idéalement sur une infrastructure physiquement distincte du cluster de production pour garantir l'isolement en cas de compromission.

wget http://download.proxmox.com/debian/pbs/proxmox-release-bookworm.gpg \
  -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" \
  > /etc/apt/sources.list.d/pbs.list
apt update && apt install proxmox-backup-server -y

9.2 · Création du datastore de sauvegarde

proxmox-backup-manager datastore create pbs-backup-pool /mnt/backup/pbs-store

9.3 · Connexion de Proxmox VE au datastore PBS

pvesm add pbs pbs-storage --server pbs.entreprise.local \
  --datastore pbs-backup-pool --username backup@pbs --fingerprint "XX:XX:XX..."

9.4 · Politique de rétention GFS

# /etc/proxmox-backup/datastore.cfg
datastore: pbs-backup-pool
    path /mnt/backup/pbs-store
    keep-last 14
    keep-daily 7
    keep-weekly 4
    keep-monthly 12
    keep-yearly 1
    verify-new true

9.5 · Activation de l'immuabilité WORM

Verrouillage temporel sur les sauvegardes critiques pour empêcher toute suppression ou modification, y compris par un compte administrateur compromis.

proxmox-backup-client protected-set <SNAPSHOT_ID> true \
  --repository pbs.entreprise.local:pbs-backup-pool

9.6 · Réplication vers D3 (Pull Sync)

proxmox-backup-manager remote create pbs-d1 --host pbs.entreprise.local --auth-id sync@pbs
proxmox-backup-manager sync-job create job-d3-sync \
  --remote pbs-d1 --remote-store pbs-backup-pool \
  --store pbs-backup-pool-d3 --schedule "daily"

9.7 · Test de restauration complète

qmrestore <BACKUP_ID> 301 --storage vm-storage

Restauration complète effectuée en moins du RTO cible défini pour le Tier de la VM

VM restaurée démarre et les données sont intègres

9.8 · Checklist de fin de module

Politique GFS appliquée et vérifiée sur le datastore principal

Immuabilité WORM activée sur les sauvegardes Tier 1

Réplication D3 fonctionnelle, testée avec un job de synchronisation complet

Test de restauration complète documenté avec temps mesuré

OPS

MODULE 10 · OBSERVABILITÉ

OBSERVABILITÉ

◆

10.1 · Installation de la stack de collecte

VictoriaMetrics ou Prometheus collectent les métriques exposées nativement par Proxmox VE et Ceph, sans agent additionnel sur les hôtes.

# /etc/pve/status.cfg
influxdb: metrics-server
    server metrics.entreprise.local
    port 8089
    mtu 1450

10.2 · Exportateur Ceph

ceph mgr module enable prometheus
ceph config set mgr mgr/prometheus/server_addr 0.0.0.0
ceph config set mgr mgr/prometheus/server_port 9283

curl http://localhost:9283/metrics retourne les métriques Ceph au format Prometheus

10.3 · Configuration des cibles de scraping

# /etc/prometheus/prometheus.yml
scrape_configs:
  - job_name: 'ceph'
    static_configs:
      - targets: ['pve-d1-node1:9283', 'pve-d2-node1:9283']
  - job_name: 'proxmox'
    static_configs:
      - targets: ['pve-d1-node1:9221', 'pve-d2-node1:9221']

10.4 · Indicateurs SLI/SLO de référence

Indicateur

Seuil cible

Action de remédiation

Latence WAN inter-site

< 10ms (p99)

Alerte P1, suspension migrations

Latence écriture Ceph

< 15ms (p99)

Vérif disques NVMe et réseau back-end

Usure SSD

< 85%

Alerte P3, remplacement préventif

Quorum Corosync

100% dispo

Alerte P1 immédiate

10.5 · Règles d'alerte Prometheus

groups:
  - name: ceph_alerts
    rules:
      - alert: CephOSDWearoutWarning
        expr: ceph_disk_wearout_ratio > 0.85
        for: 2h
        labels: {severity: warning}
        annotations: {summary: "Usure SSD OSD critique détectée"}

10.6 · Checklist de fin de module

Stack Prometheus/VictoriaMetrics opérationnelle et collectant depuis tous les nœuds

Toutes les règles d'alerte SLI/SLO actives et testées

Dashboard Grafana validé avec les équipes ops comme outil quotidien

OPS

MODULE 11 · EXERCICES DE PANNE (CHAOS ENGINEERING)

EXERCICES DE PANNE — CHAOS ENGINEERING LÉGER

◆

Les scénarios ci-dessous doivent être exécutés en pré-production puis répétés en production lors de fenêtres de maintenance planifiées, à raison d'un cycle complet tous les 6 mois minimum.

11.1 · Scénario A — Perte totale du datacenter D1

for node in pve-d1-node1 pve-d1-node2 pve-d1-node3; do
  ssh $node "systemctl stop pve-cluster corosync ceph.target"
done

D2 conserve le quorum (3 voix + 1 QDevice = 4 voix sur 7)

Ceph passe en mode dégradé monoplace sur D2 sans perte d'écriture

VMs Tier 1 D1 redémarrent automatiquement sur D2 en moins de 120 secondes

Resynchronisation Ceph automatique sans intervention manuelle au retour

11.2 · Scénario B — Rupture du lien inter-site D1-D2

# Blocage du trafic vers le site distant uniquement
iptables -A INPUT -s 10.20.0.0/24 -j DROP
iptables -A OUTPUT -d 10.20.0.0/24 -j DROP

Le QDevice attribue sa voix au site prioritaire (D1 obtient 4 voix)

D2 isolé s'auto-clôture via watchdog sans démarrage concurrent de VMs

Aucune corruption de données détectée après rétablissement du lien

11.3 · Scénario C — Défaillance d'un disque OSD unique

ceph osd out osd.5
ceph osd down osd.5

Ceph déclenche automatiquement le rebalancing vers les OSD restants

Aucune interruption de service applicatif pendant le rebalancing

Alerte Prometheus déclenchée conformément aux règles du Module 10

11.4 · Scénario D — Restauration complète après sinistre majeur

Combinaison des scénarios précédents : perte complète de D1 ET échec de bascule automatique, pour valider la procédure de restauration manuelle de dernier recours.

Procédure manuelle exécutable en moins de 4 heures (RTO Tier 1)

Équipe ops capable d'exécuter la procédure sans l'architecte ayant conçu le cluster

◆ RAPPORT POST-EXERCICE

Chaque exercice doit produire un rapport court : durée réelle de bascule, écarts par rapport au comportement attendu, actions correctives identifiées.

11.5 · Checklist de fin de module

Les 4 scénarios exécutés au moins une fois en pré-production

Rapport post-exercice rédigé et actions correctives suivies

Calendrier des exercices récurrents validé par la direction des opérations

OPS

MODULE 12 · EXPLOITATION CONTINUE ET RECETTE

EXPLOITATION CONTINUE ET RECETTE

◆

12.1 · Mise à jour du cluster Proxmox VE

Les mises à jour s'effectuent nœud par nœud, jamais simultanément, pour maintenir le quorum à tout moment pendant l'opération.

pve6to7 --full
# Si OK :
apt update && apt dist-upgrade -y
# Vérifier le retour en cluster avant de passer au nœud suivant
pvecm status

Chaque nœud rejoint le cluster avec quorum intact avant le nœud suivant

12.2 · Mise à jour Ceph

Ordre strict : moniteurs (MON) d'abord, gestionnaires (MGR) ensuite, puis OSD un par un avec vérification de santé entre chaque étape.

ceph orch upgrade start --image quay.io/ceph/ceph:v18

ceph -s affiche HEALTH_OK avant de passer à l'étape suivante de l'upgrade

12.3 · Remplacement d'un nœud défaillant

# Retrait propre
ceph osd out osd.{id}
ceph osd crush remove osd.{id}
ceph auth del osd.{id}
ceph osd rm osd.{id}
pvecm delnode pve-d1-node3-defaillant

# Intégration du remplacement
pvecm add 10.10.1.11
ceph orch host add pve-d1-node3-remplacement 10.10.1.14

Le nouveau nœud rejoint le cluster avec quorum, OSD réintégrés et rebalancing terminé

12.4 · Checklist de recette finale par VM migrée

1Performance I/O comparable ou supérieure à VMware (test FIO comparatif)

2Tous les services applicatifs fonctionnels après redémarrage à froid

3Sauvegarde PBS exécutée avec succès au moins une fois

4Test de bascule HA effectué sur cette VM sans erreur

5Surveillance Prometheus/Grafana active et alertes configurées

6Documentation technique mise à jour (CMDB, schéma réseau)

7Sign-off du propriétaire métier obtenu formellement

12.5 · Runbooks de transfert aux équipes d'exploitation

Structure type : symptôme observé · vérifications de diagnostic · décision automatique vs intervention manuelle · procédure d'escalade · contact architecte de référence.

12.6 · Checklist de fin de module

Procédure d'upgrade cluster documentée et testée en pré-production

Procédure de remplacement de nœud testée au moins une fois en conditions réelles

Grille de recette appliquée à 100% des VMs Tier 1 avant bascule finale

Runbooks rédigés pour les 5 scénarios d'incident les plus probables