Migration infrastructure - VMware / Broadcom
Migrer hors VMware sans réécrire votre architecture.
XCP-ng, Proxmox, ou l'hyperviseur de votre choix. Infrastructure opérée depuis la France, en cours de qualification SecNumCloud et hors Cloud Act. Migration documentée, downtime mesuré, rollback prévu.
ISO 27001
HDS
Qualif. SecNumCloud en cours
Multi-hyperviseur
SLA 99,982%
migration-vmware.ps1
1# Migration V2V : VMware ESXi -> XCP-ng 8.3
3$target_sr = "62cb502e-ffc0-79c2-3b73-9888d9dad60b"
4$target_net = "57802815-7652-6932-4b1a-0e2c5f7a9d3c"
6xo-cli vm.importFromEsxi `
7 host=vcenter.infra.local `
8 user=administrator@vsphere.local `
9 vm=vm-1042 sslVerify=false `
10 sr=$target_sr network=$target_net
Terminal
PowerShell
Output
PS C:\xcpng-migration> xo-cli vm.importFromEsxi ...
VM found : SRV-APP-042 (16 vCPU · 32 GB RAM · 2x VMDK)
Snapshot created — VM still running on ESXi
Transfert VMDK → VHD
0%
[░░░░░░░░░░░░░░░░░░░░]
[ OK ] SRV-APP-042 running on xcpng-prod-01 — downtime : 6 min 14 sec
PS C:\xcpng-migration>
Comparatif technique
VMware, Hyper-V, Proxmox, XCP-ng - différences d'architecture
| Critère |
VMware ESXi / vSphere 8
|
Hyper-V (WS 2025)
|
Proxmox VE 9.2
|
XCP-ng 8.3 LTS
|
|---|---|---|---|---|
| Noyau / base | VMkernel propriétaire | Windows Server (NT) | Debian 13 + KVM / QEMU 11.0 | Xen Project (Linux) |
| Licensing | Abonnement par cœur. 16 cœurs min/CPU, 72 cœurs min/commande depuis avril 2025 | Inclus avec licence Windows Server Datacenter | Open source AGPLv3 - support payant optionnel | Open source GPLv2 - support payant optionnel |
| Format disque | VMDK (VMFS6) | VHDX | qcow2 / raw (ZFS, Ceph RBD) | VHD via SR (legacy) - qcow2 depuis 8.3 (disques jusqu'à 16 To) |
| Cluster filesystem | VMFS6 | CSV (NTFS / ReFS) | ZFS 2.4 natif, Ceph natif | LVM, NFS, XOSTOR (DRBD) |
| Conteneurs natifs | Non - Tanzu option payante | Non - add-on uniquement | Oui - LXC 7.0 intégré | Non |
| API de gestion | vSphere API / vCenter REST | PowerShell / WMI / CIM | API REST native (pvesh) | XAPI - XML-RPC / JSON-RPC |
| Migration à chaud | vMotion - TCP 8000 (mémoire), TCP 902 NFC (disque) | Live Migration - compression SMB disponible | Migration QEMU intégrée - non compressée nativement | Live migration XAPI - compression depuis 8.3 |
| Limites notables | VMFS : 64 To max/vol. NFS : 256 DS/hôte. Chemins NS : 32 depuis 8.0.1 | Cluster : 64 nœuds max. Guest clustering : VHDX partagé, boot exclu | Pas de plafond publié - tuning Ceph (OSD) et ZFS (ARC) critique | RAM VM : 1,5 TiB. VDI/VM : 241 max. VHD : 2 040 GiB - qcow2 : jusqu'à 16 To |
| Sécurité | Secure Boot, vTPM - selon édition bundle | Secure Boot, Shielded VMs (vTPM) | Secure Boot, vTPM via OVMF/UEFI | Secure Boot depuis 8.2.1 - vTPM pour Windows 11 |
Note : le détail exhaustif des ports firewall internes au clustering XCP-ng (HA, corosync) n'est pas entièrement documenté publiquement. Les schémas ci-dessous n'indiquent que les ports confirmés par la documentation officielle du projet.
Schéma 1 - flux de migration
VMware vers XCP-ng : protocoles et séquence réelle
← Faites défiler pour voir le schéma complet
Trafic de données
Trafic management / API
Schéma 2 - architecture cible
Pool XCP-ng en production - datacenters primaire et secondaire
← Faites défiler pour voir le schéma complet
Trafic de données
Trafic management / API (XAPI 443)
VLAN isolé
Questions techniques
Ce que les équipes infra demandent en premier
Mes VM ESXi sont-elles compatibles XCP-ng sans recompilation ?
Pour la grande majorité des OS Linux et Windows Server, oui. Les VM avec des drivers VMware spécifiques (VMware Tools, pilotes paravirtualisés) nécessitent un remplacement par les outils équivalents XCP-ng - opération automatisée dans notre process de migration.
Que devient mon stockage vSAN ?
Le stockage est migré vers une solution distribuée (Ceph) ou vers un SAN répliqué, selon vos besoins de performance et de réplication. La migration des données se fait en parallèle de la bascule des VM, sans rupture de service sur les volumes existants.
Quel est le downtime réel pendant la bascule ?
Pour une VM standard, entre 5 et 15 minutes de coupure pour la bascule finale, après synchronisation à chaud des données. Pour les environnements à haute disponibilité, des stratégies de bascule progressive permettent de réduire ce downtime à quelques secondes par nœud.
Qui gère la migration techniquement ?
Un ingénieur infrastructure dédié pilote la migration de bout en bout, en lien direct avec votre équipe technique. Pas d'intermédiaire commercial dans la boucle opérationnelle.
Contact
Parler directement à un tech
u/DBK42
formulaire_lead_contact_migration_vmware
« * » indique les champs nécessaires