En cas d’impossibilité d’importation directe :

# Exporter avec ovftool (ESXi)
./ovftool vi://root@ESXI-FQDN/NOM-VM /exports/NOM-VM/

# Ou depuis vCenter
./ovftool vi://utilisateur:motdepasse@VCENTER/DC/vm/NOM-VM /exports/NOM-VM/

# Importer dans Proxmox
qm importovf  NOM-VM.ovf 

# Ajustements recommandés
qm set  --cpu x86-64-v2-AES --scsihw virtio-scsi-single

Pour Windows, démarrer en mode IDE/SATA, installer virtio drivers, puis passer en VirtIO SCSI.

3) qm disk import (importation/conversion directe VMDK)

Si Proxmox détecte des *.vmdk (en NFS/SMB) :

# Créer une VM sans disque par défaut
# Importer et convertir directement
qm disk import  Server.vmdk  --format qcow2
# La VM apparaît comme "Unused" ; il faut attacher le disque en SCSI/VirtIO et définir l’ordre de boot

4) Attacher et déplacer (downtime quasi nul)

Si ESXi et Proxmox partagent un datastore :

1. Ajouter le partage à Proxmox en tant que storage (type Disk Image).
2. Créer la VM dans Proxmox avec le disque OS dans ce storage, en format vmdk (Proxmox crée le descriptor).
3. Remplacer le descriptor par le VMDK source, et pointer l’Extent vers le *-flat.vmdk originel (chemin relatif).
4. Démarrer la VM en Proxmox (démarre depuis le fichier -flat.vmdk).
5. Déplacer à chaud le disque vers le stockage final (Disk Action → Move Storage).
6. Désinstaller VMware Tools, installer l’agent QEMU/VirtIO et changer en VirtIO SCSI.

Haute disponibilité (HA) sans mauvaises surprises

• Corosync : latence faible et liaison dédiée ; en cas de surcharge (sauvegarde/stockage), les timeouts augmentent et peut se produire un self-fence.
• Fencing : si un nœud perd le quorum, il se re-reboote pour assurer la cohérence avant de redémarrer les VM sur un autre nœud.
• Disques : pour un failover efficace, les VM doivent être sur un stockage partagé ou utiliser la réplication ZFS asynchrone (avec RPO minime).
• Sans COLO : à partir de 2024/25, aucune exécution en lockstep de 2 VM simultanées (fonction COLO de QEMU en cours de développement upstream).

Sauvegarde et récupération : intégrez Proxmox Backup Server

• Proxmox Backup Server (PBS) : déduplication indépendante du FS, incrémentale (juste les changements), sauvegardes à chaud rapides et live-restore (lancer la VM en même temps que la restauration).
• vzdump : méthode classique basée sur des fichiers.
• Stratégie : planifier des sauvegardes quotidiennes incrémentielles et hebdomadaires complètes, valider les restaurations, étiqueter selon le SLA et prévoir une test de reprise après sinistre.

Calendriers et opérations : combien de temps cela prend réellement

• VM moyenne (200 Go) dans le même centre de données (10 GbE)
  • Préparations/tests : 30–60 min
  • Importation automatique : 15–45 min
  • Réglages post-importation (drivers/réseau) : 10–20 min
  • Downtime typique : 10–30 min (ou moins avec live-import)
• Boucle de 20 VM (tailles variées)
  • Planification par lots (≤ 4 disques simultanés), de préférence en nuit
  • Equipe dédiée : 1 surveille API ESXi et limiteur de débit, 1 ajuste drivers/agents, 1 valide applications

Renforcement rapide après coupure (10 minutes)

1. Réattribuer les réservations DHCP ou IP statiques (changer la MAC).
2. Activer discard et IO thread là où nécessaire.
3. Installer qemu-guest-agent et VirtIO sur toutes les VM invitées.
4. Planifier les sauvegardes vers PBS (et tester le live-restore).
5. Migration à chaud entre nœuds (test de migration en direct).
6. Vérifier le firewall (Datacenter/Nœud/VM) et le monitoring (CPU steal, balloon, latences).

Tableau de référence rapide (décision technique & SEO)

Erreurs courantes (et comment ne pas les répéter)

• UEFI sans chemin : ajouter une entrée EFI et un EFI Disk.
• Échec au démarrage après passage en VirtIO : démarrer avec IDE/SATA, installer les pilotes VirtIO, revenir en VirtIO SCSI.
• vSAN : déplacer les disques vers un autre datastore avant importation.
• vTPM : l’état ne migre pas ; désactiver et conserver les clés, en lieu sûr.
• Importations bloquées : surcharge, réduire la concurrence, consolider les snapshots, éviter vCenter si performance maximale voulue ; tester en laboratoire.

Conclusion : migrer de VMware à Proxmox sans stress (et plus simple en 2025)

Avec l’importeur ESXi intégré, le live-import, une architecture de stockage flexible et la sauvegarde avancée, Proxmox VE offre une voie réaliste pour migrer vos charges critiques avec un downtime maîtrisé. La clé ne réside pas dans un bouton magique, mais dans la conception (réseau, stockage), la phase préparatoire, un pilotage avec VM test, et un runbook précis pour chaque méthode de migration.

Questions fréquentes (SEO friendly)

Comment passer rapidement de VMware à Proxmox VE avec peu de downtime ?
Utilisez l’importeur ESXi avec live-import ou la méthode Attacher et Déplacer sur un datastore partagé. Préparez les pilotes VirtIO et le qemu-guest-agent avant l’arrêt.

Comment convertir un VMDK en QCOW2 sous Proxmox ?
Avec qm disk import :

qm disk import  disque.vmdk  --format qcow2

Puis attachez le disque (SCSI/VirtIO) et définissez l’ordre de boot.

Est-il possible d’importer directement depuis vCenter ?
Oui, mais il est souvent plus efficace d’importer via l’hôte ESXi. Alternativement, exportez l’OVF/OVA avec ovftool et utilisez qm importovf dans Proxmox.

Faut-il trois nœuds pour un cluster Proxmox en production ?
Pour un quorum stable, oui: au moins 3 votes. Avec 2 nœuds, ajoutez un QDevice pour le troisième vote logique. Isoler Corosync sur un réseau dédié.

Que faire des vTPM et disques chiffrés lors de la migration vers Proxmox ?
Le vTPM ne se migre pas. Désactivez-le temporairement et sauvegardez les clés. Les disques chiffrés en VMware doivent être déchiffrés avant l’importation.

Si vous souhaitez migrer vers Proxmox VE sans arrêter la moitié de votre infrastructure, cette démarche est votre guide : préparez, importez, validez et sécurisez. Ensuite, Proxmox vous offre la possibilité de croître : Ceph ou NFS selon les cas, HA bien câblée, backups déduplication avec live-restore… et une stack ouverte qui réduit la friction (et la facture) au quotidien.