Migration VMware vers Proxmox VE : Guide Complet Sécurité et Bonnes Pratiques

1. Introduction : pourquoi migrer de VMware vers Proxmox VE ?

Le rachat de VMware par Broadcom fin 2023 a provoqué un séisme dans l'écosystème de la virtualisation d'entreprise. L'abandon des licences perpétuelles au profit d'abonnements groupés, des augmentations tarifaires pouvant atteindre 300 à 1200 %, et la suppression du programme partenaires ont poussé des milliers d'organisations à explorer des alternatives. Proxmox Virtual Environment (VE), solution open source basée sur KVM/QEMU et LXC, s'est imposée comme le candidat le plus crédible pour absorber cet exode.

Mais migrer une infrastructure de virtualisation ne se résume pas à convertir des disques virtuels. C'est un projet d'architecture complet qui engage la continuité de service, la sécurité des workloads et la conformité réglementaire. Les erreurs de migration peuvent exposer des vulnérabilités critiques : interfaces d'administration accessibles sans authentification forte, réseaux plats sans segmentation, stockage non chiffré, ou configurations de pare-feu inexistantes sur l'hyperviseur.

Ce guide couvre l'intégralité du processus de migration avec un prisme sécurité : de l'analyse de l'existant VMware à la validation post-migration, en passant par la conversion des machines virtuelles, la reconfiguration réseau et stockage, et le durcissement complet de Proxmox VE. Chaque section propose des commandes concrètes, des configurations testées en production et des recommandations issues de nos audits de sécurité virtualisation.

Point clé : Une migration mal sécurisée peut transformer un changement d'hyperviseur en incident de sécurité majeur. Plus de 40 % des migrations que nous auditons présentent au moins une vulnérabilité critique liée à la configuration par défaut de Proxmox VE.

2. Le contexte Broadcom/VMware : comprendre les enjeux

2.1 Restructuration tarifaire et impact sur les entreprises

Depuis la finalisation de l'acquisition en novembre 2023, Broadcom a opéré des changements radicaux dans le modèle commercial de VMware. Les licences perpétuelles vSphere, vSAN et NSX ont été remplacées par deux offres d'abonnement : VMware Cloud Foundation (VCF) et VMware vSphere Foundation (VVF). Cette restructuration a eu pour conséquence directe l'augmentation massive des coûts pour les PME et ETI qui n'utilisaient qu'une fraction des fonctionnalités groupées.

Selon les témoignages recueillis auprès de nos clients, les renouvellements de licence ont connu des augmentations de 300 % à 1200 % selon la taille de l'infrastructure et le niveau de négociation. Les éditions gratuites de VMware ESXi ont été supprimées, impactant les environnements de lab, de développement et les petites structures. Le programme partenaires a été restructuré, excluant plus de 80 % des revendeurs historiques.

Au-delà du coût, des préoccupations de souveraineté numérique émergent. La dépendance à un éditeur américain unique pour l'infrastructure critique soulève des questions réglementaires, notamment dans le contexte de NIS 2 et DORA. Proxmox VE, développé par Proxmox Server Solutions GmbH (Autriche, UE), offre une alternative européenne avec un code source auditable -- un argument de poids pour les organisations soumises à des exigences de conformité NIS 2.

2.2 Pourquoi Proxmox VE comme alternative ?

Proxmox VE se distingue par plusieurs avantages structurels :

Critère	VMware vSphere	Proxmox VE
Licence	Abonnement obligatoire (VCF/VVF)	Open source (AGPLv3), support optionnel
Hyperviseur	ESXi (propriétaire)	KVM/QEMU (Linux kernel)
Conteneurs	Non natif (vSphere Pods)	LXC natif
Stockage	VMFS, vSAN (licence)	ZFS, Ceph, LVM, NFS, iSCSI
Réseau SDN	NSX (licence séparée)	SDN intégré (VXLAN, EVPN)
HA Clustering	vSphere HA (licence)	Corosync/HA natif
API	REST API, PowerCLI	REST API complète, CLI pvesh
Communauté	Large écosystème propriétaire	Communauté active, forums, wiki

Du point de vue sécurité, Proxmox VE repose sur un noyau Linux standard bénéficiant des correctifs de sécurité Debian/Ubuntu. Les CVE sont gérés par les canaux standard de la distribution, avec des mises à jour de sécurité automatisées via apt. L'hyperviseur KVM bénéficie d'un historique de sécurité solide avec un ratio CVE/lignes de code favorable par rapport aux hyperviseurs propriétaires.

3. Planification de la migration : méthodologie sécurisée

3.1 Inventaire et cartographie de l'existant

Toute migration réussie commence par un inventaire exhaustif de l'infrastructure VMware. Cet inventaire doit couvrir non seulement les machines virtuelles mais aussi les configurations réseau, stockage, sécurité et les dépendances applicatives. Utilisez PowerCLI pour extraire un inventaire structuré :

# Inventaire complet VMware via PowerCLI
Connect-VIServer -Server vcenter.entreprise.local

# Export des VMs avec configuration détaillée
Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB,
    @{N='DiskGB';E={(Get-HardDisk -VM $_ | Measure-Object -Property CapacityGB -Sum).Sum}},
    @{N='GuestOS';E={$_.ExtensionData.Config.GuestFullName}},
    @{N='DiskFormat';E={(Get-HardDisk -VM $_ | Select-Object -First 1).StorageFormat}},
    @{N='Network';E={(Get-NetworkAdapter -VM $_ | Select-Object -ExpandProperty NetworkName) -join ','}},
    @{N='VLAN';E={(Get-VDPortgroup -VM $_ | Select-Object -ExpandProperty VlanConfiguration)}},
    @{N='ToolsStatus';E={$_.ExtensionData.Guest.ToolsStatus}} |
    Export-Csv -Path "C:\migration\inventaire-vmware.csv" -NoTypeInformation

# Export des configurations réseau
Get-VDSwitch | Get-VDPortgroup | Select-Object Name, VlanConfiguration, PortBinding |
    Export-Csv -Path "C:\migration\reseau-vmware.csv" -NoTypeInformation

# Export des datastores
Get-Datastore | Select-Object Name, Type, CapacityGB, FreeSpaceGB |
    Export-Csv -Path "C:\migration\stockage-vmware.csv" -NoTypeInformation

3.2 Évaluation des risques de migration

Avant toute opération de migration, une analyse de risques doit identifier les workloads critiques, les dépendances matérielles (passthrough GPU, USB, SR-IOV) et les contraintes de disponibilité. Classifiez les VMs selon leur criticité :

• Tier 1 (Critique) : Applications de production avec SLA strict (ERP, bases de données, contrôleurs de domaine). Migration avec fenêtre de maintenance planifiée et rollback testé.
• Tier 2 (Important) : Applications métier non critiques (serveurs de fichiers, applicatifs internes). Migration durant les heures creuses.
• Tier 3 (Standard) : Environnements de développement, test, sandbox. Migration en premier pour validation de la procédure.

3.3 Préparation de l'environnement Proxmox VE

L'installation de Proxmox VE doit suivre les bonnes pratiques de durcissement dès le déploiement initial. Voici la procédure recommandée pour un déploiement sécurisé :

# Post-installation Proxmox VE 8.x - Durcissement initial

# 1. Désactiver le dépôt Enterprise si pas de souscription
mv /etc/apt/sources.list.d/pve-enterprise.list /etc/apt/sources.list.d/pve-enterprise.list.disabled

# 2. Ajouter le dépôt no-subscription (production testing)
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > \
    /etc/apt/sources.list.d/pve-no-subscription.list

# 3. Mettre à jour le système
apt update && apt full-upgrade -y

# 4. Configurer le pare-feu Proxmox
pvesh set /cluster/firewall/options --enable 1 --policy_in DROP --policy_out ACCEPT

# 5. Autoriser uniquement SSH et Web UI depuis le réseau d'administration
pvesh create /cluster/firewall/rules --action ACCEPT --type in \
    --source 10.0.1.0/24 --dport 8006 --proto tcp --comment "Proxmox Web UI - Admin VLAN"
pvesh create /cluster/firewall/rules --action ACCEPT --type in \
    --source 10.0.1.0/24 --dport 22 --proto tcp --comment "SSH - Admin VLAN"

# 6. Configurer fail2ban pour la protection brute-force
apt install fail2ban -y
cat > /etc/fail2ban/jail.d/proxmox.conf << EOF
[proxmox]
enabled = true
port = https,8006
filter = proxmox
logpath = /var/log/daemon.log
maxretry = 3
bantime = 3600
findtime = 600
EOF

4. Conversion des machines virtuelles

4.1 Export depuis VMware : formats et méthodes

VMware stocke les machines virtuelles dans deux formats principaux : VMDK (Virtual Machine Disk) pour les disques et OVF/OVA pour l'ensemble VM (configuration + disques). La méthode d'export dépend de votre environnement :

# Méthode 1 : Export OVF via ovftool (recommandé pour vCenter)
ovftool --noSSLVerify \
    "vi://admin@vcenter.local/Datacenter/vm/Production/VM-Linux-Web" \
    "/export/vm-linux-web.ovf"

# Méthode 2 : Export OVA (fichier unique)
ovftool --noSSLVerify --diskMode=thin \
    "vi://admin@vcenter.local/Datacenter/vm/Production/VM-Windows-DB" \
    "/export/vm-windows-db.ova"

# Méthode 3 : Copie directe du VMDK depuis le datastore ESXi
scp root@esxi01:/vmfs/volumes/datastore1/vm-linux-web/vm-linux-web-flat.vmdk \
    /export/

# Vérifier l'intégrité du fichier exporté (SHA256)
sha256sum /export/vm-linux-web.ovf > /export/vm-linux-web.sha256

4.2 Import dans Proxmox VE : qm importovf et qm importdisk

Proxmox VE propose deux commandes principales pour l'import de VMs VMware. La commande qm importovf gère l'import complet (configuration + disques), tandis que qm importdisk permet d'importer uniquement le disque dans un stockage spécifique.

# Import OVF complet dans Proxmox VE
# Syntaxe : qm importovf <vmid> <fichier.ovf> <storage> [options]

# Import avec stockage ZFS (recommandé pour la performance)
qm importovf 100 /export/vm-linux-web.ovf local-zfs \
    --format qcow2

# Import avec détection automatique du format
qm importovf 101 /export/vm-windows-db.ovf local-zfs

# Vérifier la configuration importée
qm config 100

# Ajuster les paramètres post-import
qm set 100 --boot order=scsi0 --ostype l26 --agent enabled=1
qm set 100 --cpu host --numa 1 --balloon 0
qm set 100 --net0 virtio,bridge=vmbr0,tag=100

# Pour les VMs Windows : configurer le bus SCSI VirtIO
qm set 101 --scsihw virtio-scsi-single --ostype win11
qm set 101 --machine q35 --bios ovmf
qm set 101 --efidisk0 local-zfs:1,efitype=4m,pre-enrolled-keys=1

4.3 Conversion des formats de disque

Le choix du format de disque impacte directement les performances et les fonctionnalités disponibles. Voici les options :

Format	Avantages	Inconvénients	Cas d'usage
qcow2	Snapshots, thin provisioning, compression	Légère surcharge I/O	Stockage local, NFS
raw	Performance maximale, pas de surcharge	Pas de snapshots au niveau image	ZFS (snapshots gérés par ZFS), Ceph
vmdk	Compatibilité VMware	Support limité dans Proxmox	Migration transitoire uniquement

# Conversion VMDK vers qcow2 avec qemu-img
qemu-img convert -f vmdk -O qcow2 \
    /export/vm-disk.vmdk /var/lib/vz/images/100/vm-100-disk-0.qcow2

# Conversion VMDK vers raw (recommandé pour ZFS)
qemu-img convert -f vmdk -O raw \
    /export/vm-disk.vmdk /dev/zvol/rpool/data/vm-100-disk-0

# Import direct d'un disque VMDK dans un stockage Proxmox
qm importdisk 100 /export/vm-disk.vmdk local-zfs --format raw

# Vérification de l'intégrité post-conversion
qemu-img check /var/lib/vz/images/100/vm-100-disk-0.qcow2
qemu-img info /var/lib/vz/images/100/vm-100-disk-0.qcow2

5. Architecture réseau : bridges, VLANs et SDN

5.1 Mapping des réseaux VMware vers Proxmox

L'architecture réseau constitue la pierre angulaire de la sécurité post-migration. VMware utilise des vSwitches Standard ou des Distributed vSwitches (DVS) pour la virtualisation réseau. Proxmox VE utilise des Linux Bridges natifs et, depuis la version 7, un module SDN (Software-Defined Networking) intégré supportant VXLAN et EVPN.

Le mapping type entre les deux environnements suit cette logique :

# Configuration réseau Proxmox VE (/etc/network/interfaces)

# Interface physique en bonding LACP (redondance)
auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

# Bridge principal - trunk VLAN
auto vmbr0
iface vmbr0 inet manual
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes

# VLAN 10 - Administration Proxmox
auto vmbr0.10
iface vmbr0.10 inet static
    address 10.0.10.1/24
    gateway 10.0.10.254

# Les VMs utilisent des tags VLAN sur vmbr0
# Exemple : net0 virtio,bridge=vmbr0,tag=100 (VLAN Production)
# Exemple : net0 virtio,bridge=vmbr0,tag=200 (VLAN DMZ)

5.2 SDN Proxmox : VXLAN et zones isolées

Pour les environnements plus complexes, le module SDN de Proxmox VE permet de créer des réseaux overlay VXLAN avec isolation complète entre les zones. Cette approche est recommandée pour les infrastructures multi-tenant ou les environnements nécessitant une segmentation fine. Elle remplace fonctionnellement VMware NSX à coût zéro.

# Configuration SDN via CLI Proxmox

# Créer une zone VXLAN
pvesh create /cluster/sdn/zones --zone production --type vxlan \
    --peers 10.0.10.1,10.0.10.2,10.0.10.3 \
    --bridge vmbr0

# Créer un VNet dans la zone
pvesh create /cluster/sdn/vnets --vnet vnet-prod --zone production \
    --tag 100000

# Créer un subnet
pvesh create /cluster/sdn/vnets/vnet-prod/subnets \
    --subnet 10.100.0.0/24 --gateway 10.100.0.1 \
    --type subnet --snat 1

# Appliquer la configuration SDN
pvesh set /cluster/sdn

5.3 Firewall intégré Proxmox VE

Proxmox VE intègre un pare-feu basé sur iptables/nftables configurable à trois niveaux : datacenter (cluster), host (noeud) et VM/conteneur. Cette granularité remplace les fonctionnalités de micro-segmentation de NSX. Pour une sécurité optimale, activez le pare-feu à chaque niveau avec une politique de refus par défaut :

# Activer le firewall au niveau cluster
pvesh set /cluster/firewall/options --enable 1 --policy_in DROP

# Créer un Security Group réutilisable
pvesh create /cluster/firewall/groups --group web-servers \
    --comment "Règles serveurs web production"
pvesh create /cluster/firewall/groups/web-servers \
    --action ACCEPT --type in --dport 80,443 --proto tcp
pvesh create /cluster/firewall/groups/web-servers \
    --action ACCEPT --type in --dport 22 --proto tcp --source 10.0.10.0/24

# Appliquer le Security Group à une VM
pvesh set /nodes/pve01/qemu/100/firewall/options --enable 1
pvesh create /nodes/pve01/qemu/100/firewall/rules \
    --action GROUP --type in --macro web-servers

# Activer la protection IP spoofing
pvesh set /nodes/pve01/qemu/100/firewall/options \
    --ipfilter 1 --macfilter 1

6. Architecture de stockage : ZFS, Ceph et NFS

6.1 ZFS : le choix par défaut pour la sécurité des données

ZFS est le système de fichiers recommandé pour Proxmox VE en raison de ses propriétés de sécurité intrinsèques : checksums bout-en-bout (protection contre la corruption silencieuse), copy-on-write (atomicité des écritures), snapshots instantanés et chiffrement natif. Ces fonctionnalités surpassent celles de VMFS et rivalisent avec vSAN.

# Création d'un pool ZFS en mirror (RAID 1) avec chiffrement
zpool create -o ashift=12 -O compression=lz4 \
    -O encryption=aes-256-gcm -O keyformat=passphrase \
    -O keylocation=prompt \
    rpool mirror /dev/sda /dev/sdb

# Créer un dataset dédié aux VMs
zfs create -o mountpoint=/var/lib/vz rpool/data

# Activer les snapshots automatiques (protection ransomware)
apt install zfs-auto-snapshot -y
# Snapshots : 4 toutes les 15min, 24 horaires, 7 quotidiens, 4 hebdomadaires

# Configuration du scrub hebdomadaire (détection proactive de corruption)
cat > /etc/cron.d/zfs-scrub << EOF
0 2 * * 0 root /sbin/zpool scrub rpool
EOF

# Monitoring de l'état ZFS
zpool status -v
zfs list -t snapshot

6.2 Ceph : stockage distribué pour la haute disponibilité

Pour les clusters multi-noeuds nécessitant un stockage partagé, Ceph est la solution native de Proxmox VE. Intégré directement dans l'interface d'administration, Ceph offre un stockage distribué auto-réparant avec réplication configurable. Il remplace fonctionnellement VMware vSAN.

# Installation de Ceph via Proxmox VE (sur chaque noeud)
pveceph install --repository no-subscription

# Initialisation du cluster Ceph
pveceph init --network 10.0.20.0/24

# Créer les monitors (3 minimum pour le quorum)
pveceph mon create

# Créer les managers
pveceph mgr create

# Ajouter des OSD (Object Storage Daemons)
pveceph osd create /dev/sdc --encrypted 1
pveceph osd create /dev/sdd --encrypted 1

# Créer un pool pour les VMs
pveceph pool create vm-pool --size 3 --min_size 2 \
    --pg_autoscale_mode on

# Sécuriser Ceph : restreindre l'accès réseau
ceph config set global ms_cluster_mode secure
ceph config set global ms_service_mode secure
ceph config set global ms_client_mode secure

6.3 Stockage NFS/iSCSI : migration du SAN existant

Si votre infrastructure VMware utilise un SAN NFS ou iSCSI, celui-ci peut être directement réutilisé dans Proxmox VE. Cette approche minimise les changements et permet une migration plus rapide. Cependant, assurez-vous de sécuriser les connexions de stockage, car une surface d'attaque réseau sur le stockage représente un risque critique comme détaillé dans notre analyse des escalades de privilèges Linux.

# Ajout d'un stockage NFS dans Proxmox VE
pvesm add nfs san-nfs --server 10.0.20.100 --export /vol/proxmox \
    --content images,iso,vztmpl,backup \
    --options vers=4.1,sec=krb5p

# Ajout d'un stockage iSCSI
pvesm add iscsi san-iscsi --portal 10.0.20.100 \
    --target iqn.2026-01.com.storage:proxmox

# Sécurité : utiliser CHAP pour l'authentification iSCSI
iscsiadm -m node -T iqn.2026-01.com.storage:proxmox \
    -p 10.0.20.100 --op update \
    -n node.session.auth.authmethod -v CHAP \
    -n node.session.auth.username -v proxmox-node01 \
    -n node.session.auth.password -v "MotDePasseComplexe32Chars!"

7. Sécurité post-migration : durcissement complet

7.1 Authentification et contrôle d'accès

La sécurisation de l'accès à l'hyperviseur est la première priorité post-migration. Proxmox VE supporte plusieurs backends d'authentification : PAM (local), LDAP/Active Directory et OpenID Connect. L'authentification à deux facteurs (2FA) doit être imposée pour tous les comptes administrateurs, une pratique que nous recommandons systématiquement dans nos guides de sécurité identité.

# Configurer l'authentification LDAP/AD
pveum realm add entreprise.local --type ldap \
    --server dc01.entreprise.local --base-dn "DC=entreprise,DC=local" \
    --user-attr sAMAccountName --secure 1 \
    --bind-dn "CN=svc-proxmox,OU=Services,DC=entreprise,DC=local" \
    --comment "Active Directory Enterprise"

# Activer TOTP 2FA pour un utilisateur
pveum user modify admin@pam --enable 1
# L'utilisateur configurera le TOTP lors de la prochaine connexion Web

# Créer des rôles granulaires (principe du moindre privilège)
pveum role add VMOperator --privs "VM.Console VM.Monitor VM.PowerMgmt"
pveum role add VMAdmin --privs "VM.Allocate VM.Clone VM.Config.CDROM \
    VM.Config.CPU VM.Config.Disk VM.Config.HWType VM.Config.Memory \
    VM.Config.Network VM.Config.Options VM.Console VM.Migrate \
    VM.Monitor VM.PowerMgmt VM.Snapshot VM.Snapshot.Rollback"
pveum role add StorageAdmin --privs "Datastore.Allocate \
    Datastore.AllocateSpace Datastore.Audit"

# Assigner un rôle à un groupe AD
pveum acl modify /vms --group "IT-VirtAdmins@entreprise.local" \
    --role VMAdmin
pveum acl modify /storage --group "IT-StorageAdmins@entreprise.local" \
    --role StorageAdmin

7.2 Certificats TLS et chiffrement des communications

Par défaut, Proxmox VE génère un certificat auto-signé pour l'interface Web. En production, remplacez-le par un certificat d'une autorité de confiance (interne ou Let's Encrypt). Le chiffrement des communications inter-noeuds est également critique pour les clusters.

# Option 1 : Let's Encrypt via ACME (recommandé)
pvenode acme account register default \
    admin@entreprise.com --directory \
    https://acme-v02.api.letsencrypt.org/directory

pvenode acme cert order --force

# Option 2 : Certificat PKI interne
# Copier le certificat et la clé privée
cp /path/to/pve01.entreprise.local.crt /etc/pve/local/pve-ssl.pem
cp /path/to/pve01.entreprise.local.key /etc/pve/local/pve-ssl.key
cp /path/to/ca-chain.pem /etc/pve/pve-root-ca.pem
systemctl restart pveproxy

# Forcer TLS 1.3 minimum pour l'interface Web
cat >> /etc/default/pveproxy << EOF
CIPHERS="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
HONOR_CIPHER_ORDER=yes
MIN_TLS_VERSION=1.3
EOF
systemctl restart pveproxy

# Vérifier la configuration TLS
openssl s_client -connect localhost:8006 -tls1_3

7.3 Hardening SSH et accès console

L'accès SSH à l'hyperviseur doit être restreint et durci. Les bonnes pratiques de sécurité SSH s'appliquent avec d'autant plus de rigueur qu'un accès root à l'hyperviseur compromet l'ensemble des VMs hébergées. Ce type de compromission est comparable aux attaques de container escape dans les environnements conteneurisés.

# Durcissement SSH (/etc/ssh/sshd_config.d/hardening.conf)
cat > /etc/ssh/sshd_config.d/hardening.conf << EOF
# Authentification
PermitRootLogin prohibit-password
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
AuthenticationMethods publickey

# Restrictions d'accès
AllowGroups pve-admins
MaxAuthTries 3
MaxSessions 3
LoginGraceTime 30

# Chiffrement
KexAlgorithms curve25519-sha256@libssh.org,curve25519-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Divers
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
Banner /etc/ssh/banner
EOF

systemctl restart sshd

8. Haute disponibilité et continuité de service

8.1 Cluster Proxmox VE : Corosync et quorum

La haute disponibilité dans Proxmox VE repose sur Corosync pour la communication cluster et le vote de quorum, et sur le service HA Manager pour la gestion du failover des VMs. Un cluster de production nécessite au minimum 3 noeuds pour maintenir le quorum en cas de perte d'un noeud.

# Création du cluster (sur le premier noeud)
pvecm create production-cluster

# Ajout des noeuds (sur chaque noeud supplémentaire)
pvecm add 10.0.10.1  # IP du premier noeud

# Vérifier l'état du cluster
pvecm status
pvecm nodes

# Configurer le réseau Corosync dédié (recommandé)
# Utiliser un VLAN dédié ou un réseau séparé pour le heartbeat
pvecm updatecerts

# Configurer la HA pour les VMs critiques
ha-manager add vm:100 --group ha-group-1 --state started --max_restart 3
ha-manager add vm:101 --group ha-group-1 --state started --max_restart 3

# Créer un groupe HA avec priorité par noeud
ha-manager groupadd ha-group-1 --nodes "pve01:2,pve02:2,pve03:1" \
    --nofailback 0 --restricted 1

8.2 Sauvegardes et plan de reprise

Proxmox VE intègre un système de sauvegarde natif (vzdump) et supporte Proxmox Backup Server (PBS) pour une gestion avancée des sauvegardes avec déduplication, chiffrement et vérification d'intégrité. La stratégie de sauvegarde doit couvrir la règle 3-2-1 : 3 copies, 2 supports différents, 1 hors site.

# Sauvegarde manuelle d'une VM
vzdump 100 --compress zstd --mode snapshot \
    --storage backup-nfs --notes "Pre-migration backup"

# Planifier des sauvegardes automatiques
# Via l'interface Web : Datacenter > Backup > Add

# Configuration Proxmox Backup Server (cible)
proxmox-backup-manager datastore create vm-backups \
    /mnt/backup-storage --gc-schedule "daily 03:00"

# Chiffrement des sauvegardes (côté client)
proxmox-backup-client backup vm-100.pxar:/var/lib/vz/dump/vzdump-qemu-100.vma \
    --repository pbs@pbs01.local:vm-backups \
    --keyfile /etc/pve/priv/backup-encryption-key.json

# Vérification automatique des sauvegardes
pvesh create /cluster/backup-info/not-backed-up  # VMs sans sauvegarde

9. Monitoring et détection d'incidents

9.1 Collecte et centralisation des logs

La supervision de l'infrastructure Proxmox VE post-migration est essentielle pour détecter les anomalies de sécurité. Intégrez les logs de l'hyperviseur dans votre SIEM existant. Les événements critiques à surveiller incluent les tentatives d'authentification échouées, les modifications de configuration cluster et les accès console aux VMs, des indicateurs que nous détaillons dans notre guide de post-exploitation et détection.

# Configuration rsyslog pour export vers un SIEM
cat > /etc/rsyslog.d/proxmox-siem.conf << EOF
# Envoyer les logs d'authentification Proxmox au SIEM
:programname, isequal, "pvedaemon" @@siem.entreprise.local:514
:programname, isequal, "pveproxy" @@siem.entreprise.local:514
:programname, isequal, "pvestatd" @@siem.entreprise.local:514
:programname, isequal, "pmxcfs" @@siem.entreprise.local:514

# Format RFC 5424 pour le SIEM
template(name="ProxmoxFormat" type="string"
    string="<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% \
    %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n")
EOF
systemctl restart rsyslog

# Alertes sur les événements critiques
# Intégration avec Prometheus + Alertmanager
apt install prometheus-pve-exporter -y
# Métriques disponibles sur :9221/pve

10. Checklist complète de migration sécurisée

10.1 Phase pré-migration

• Inventaire VMware complet : VMs, réseaux, stockage, dépendances, licences tiers
• Cartographie des flux réseau : règles de pare-feu VMware NSX/DFW à reproduire
• Audit de sécurité de l'existant : identifier les vulnérabilités VMware actuelles (cf. notre guide durcissement ESXi)
• Pilotes VirtIO : installer les pilotes Windows VirtIO dans toutes les VMs Windows avant export
• Sauvegardes validées : backup complet de toutes les VMs avec test de restauration
• Documentation des accès : mapper les permissions vSphere vers les rôles Proxmox VE
• Plan de rollback : procédure documentée pour revenir sur VMware en cas d'échec

10.2 Phase de migration

• Installation Proxmox sécurisée : dépôts configurés, mises à jour appliquées, pare-feu activé
• Export OVF/OVA : vérification d'intégrité SHA256 de chaque export
• Import et conversion : qm importovf avec format adapté (raw pour ZFS, qcow2 pour NFS)
• Reconfiguration réseau : bridges, VLANs, tags réseau, Security Groups
• Tests fonctionnels : validation applicative de chaque VM migrée
• Tests de sécurité : scan de vulnérabilités, vérification des règles de firewall

10.3 Phase post-migration

• Durcissement complet : 2FA, SSH hardening, certificats TLS, fail2ban
• Monitoring opérationnel : Prometheus, alertes, intégration SIEM
• Sauvegardes configurées : PBS avec chiffrement, vérification automatique
• Documentation mise à jour : architecture réseau, procédures de recovery, contacts
• Formation des équipes : familiarisation avec l'interface Proxmox VE et les procédures d'urgence
• Audit de sécurité final : pentest de l'infrastructure Proxmox VE par une équipe indépendante, comme nous le proposons dans nos prestations d'audit

11. Conclusion : une migration réussie est une migration sécurisée

La migration de VMware vers Proxmox VE représente bien plus qu'un changement d'hyperviseur. C'est une opportunité de moderniser et de renforcer la sécurité de l'infrastructure de virtualisation. Les fonctionnalités natives de Proxmox VE -- ZFS chiffré, pare-feu intégré, SDN, Ceph -- offrent un niveau de sécurité comparable voire supérieur à VMware vSphere, à condition d'être correctement configurées.

Les erreurs les plus fréquentes que nous observons en audit sont : l'interface Web exposée sans VLAN dédié, l'absence de 2FA, le pare-feu Proxmox désactivé, et les sauvegardes non chiffrées. Chacune de ces failles peut être exploitée pour compromettre l'intégralité de l'infrastructure virtualisée, comme le démontrent les techniques de compromission d'hyperviseur documentées par la communauté offensive.

L'investissement dans une migration sécurisée se rentabilise rapidement : réduction des coûts de licences de 70 à 90 %, indépendance vis-à-vis des éditeurs propriétaires, conformité réglementaire renforcée, et une infrastructure auditable car open source. Le retour sur investissement typique que nous observons chez nos clients se situe entre 6 et 18 mois.