Migration VMware vers Proxmox VE

Migration VMware vers Proxmox VE : démarche

OUTSEED propose une évaluation du parc, une revue de conception de la cible, un pilote puis des vagues de migration avec validation applicative et transfert de connaissances. Les modalités sont convenues après examen du contexte.

Inventoriez versions, systèmes invités, ressources, disques utilisés/provisionnés, firmware, contrôleurs, réseaux, dépendances applicatives et responsables. Convenez du budget, de la fenêtre d’arrêt, du RPO/RTO, des critères de validation et du décideur de retour arrière.

Points bloquants à examiner

Snapshots et chaînes de disques, stockage vSAN, disques chiffrés, vTPM et clés, Secure Boot, RDM/disques partagés, passthrough et licences nécessitent une revue spécifique. L’importabilité dépend de la méthode et des versions.

Préparez les pilotes VirtIO, le démarrage BIOS/UEFI, les entrées EFI, les montages et les noms d’interfaces. Vérifiez les procédures propres à Windows et à la distribution Linux ; ne changez pas le contrôleur de démarrage sans pilote et plan de récupération.

Pilote, bascule et retour arrière

Validez capacité, stockage, réseau/VLAN, quorum/HA, sauvegarde et restauration sur un environnement représentatif. Mesurez le temps réel de transfert et de validation. Aucun arrêt nul n’est garanti.

Arrêtez la source conformément au plan de cohérence applicative. Ne faites jamais fonctionner les deux copies avec la même identité de production. Conservez la source jusqu’à acceptation et définissez comment réconcilier les écritures effectuées sur la cible avant un éventuel retour arrière.

Acceptation et accompagnement

Le démarrage de la VM ne suffit pas : vérifiez applications, données, réseau, performances, monitoring, sauvegardes et une restauration isolée. Consignez résultats observés, limites et responsabilités.

La référence exhaustive ci-dessous est en anglais. Les MCP OUTSEED aident à collecter et comparer les preuves ; ils n’exécutent aucune migration. Demandez une revue de périmètre pour l’intervention humaine.

Scope and decision record

Begin with a workload inventory and business owners. Record vCenter/ESXi and Proxmox versions, VM count, guest OS/support, CPU/memory, used and provisioned disk capacity, firmware, controllers, VLANs, IP/DNS, time synchronization and application dependencies. Agree acceptable downtime, RPO/RTO, maintenance windows and acceptance owners.

Compare keeping VMware, migrating to Proxmox and other options against requirements, support, skills, application certification and licensing. Hardware and subscription savings are not guaranteed; include operational and backup costs. OUTSEED scopes assessment, pilot, wave execution and handover separately.

Source constraints and prerequisites

Review snapshots and disk chains, VMware vSAN-backed disks, encrypted disks, virtual TPM/key dependencies, secure boot, raw device mappings, passthrough/GPU/USB, independent/shared disks, linked clones and application clustering. These can prevent a direct importer path or require a separately validated procedure. Do not assume feature equivalence.

Preserve tested backups and recovery keys under the customer’s approved handling process. Do not delete snapshots, decrypt workloads, remove tools or change drivers merely because a checklist mentions them; first select the method, verify rollback and approve the change. Current vendor import guidance lists version-specific support and limitations.

Proxmox target design

Size CPU, RAM and storage using observed workload peaks and headroom for one host failure where HA is required. Review CPU compatibility across migration nodes, storage IOPS/latency/capacity, thin provisioning, overcommit and storage snapshot support.

Design bridges, VLAN tagging, bonds, MTU, routing, firewall and management isolation. Map source port groups to target networks explicitly. A shared storage label is not proof that every node sees the same data. Validate multipath and supported SAN/NAS plugins when applicable.

Agree cluster quorum/Corosync design, HA behavior, fencing, backup and restore procedures. HA restart after host failure is not lockstep fault tolerance. Do not choose a two-node design without a reviewed quorum strategy or assume asynchronous replication has zero data loss.

Guest readiness: Linux and Windows

Match BIOS/SeaBIOS or UEFI/OVMF and plan EFI variables/boot entries. Verify VirtIO storage/network drivers and boot initramfs, filesystem/mount identifiers, network naming, static addresses, DHCP reservations and time synchronization. Preserve the application’s identity and reactivation/licensing requirements.

For Windows, stage vendor-supported VirtIO drivers and follow the documented boot-controller transition; an immediate controller switch can make the guest unbootable. For Linux, verify that required drivers are in the installed kernel/initramfs rather than assuming all distributions behave alike.

Decide when to remove VMware-specific guest tools and install the QEMU guest agent with the rollback path in mind. Guest-agent presence aids management but is not proof that backups are application-consistent.

Select an import method and pilot

Options include the supported Proxmox ESXi importer, OVF/OVA or disk import, and backup restore/application-level migration where supported. Verify exact installed versions, source datastore types and target storage support. Direct vCenter/ESXi discovery in OUTSEED is not the Proxmox importer itself.

Use a representative non-production pilot including one Linux and one Windows workload when those platforms exist. Test a recovery from your actual backup product. Measure shutdown, copy/import, first boot and application-validation time; large disks and bandwidth/API limits affect the window.

Live-import still involves source shutdown and can have additional recovery/data-loss considerations if the import fails. Do not advertise cross-hypervisor live migration or zero downtime. Prefer a controlled cold pilot until the chosen method and recovery path are demonstrated.

Plan migration waves and dependencies

Group workloads around dependencies, business criticality, data consistency and operational ownership—not merely VM count. Identify databases, identity, DNS, load balancers, firewall rules, storage and external integrations. Agree a freeze point and stakeholder communications.

A wave checklist names source VM, target VMID/node/storage/bridge, version-specific method, backup reference, driver/boot prerequisites, operator, approver, expected duration, abort thresholds, validation checks and evidence location. Keep source and target inventories separate to avoid selecting the wrong workload.

Cutover and rollback decision points

Confirm a recoverable backup and capacity before the approved window. Quiesce applications where required, capture a final baseline and stop the source according to the application consistency plan. Import/restore with the reviewed method, confirm mappings and boot the isolated target before enabling production traffic.

Never run source and target with the same production identity/IP/storage access simultaneously. Do not attach both hypervisors to the same writable guest disk without a supported design. Preserve source rollback materials until formal acceptance.

Define when rollback is still possible and who approves it. Once the target accepts writes, powering the source back on can lose or fork data. Plan how to reconcile target-side changes; a snapshot is not automatically a safe database rollback. Record an unresolved state if the final data owner cannot verify consistency.

Validation and acceptance evidence

Check firmware/boot, guest drivers, services, disk/filesystem state, network/VLAN/DNS/routes, time, authentication, scheduled jobs and monitoring. Application owners execute agreed synthetic transactions, data-consistency checks and integration tests.

Compare baseline and target performance under a representative workload; distinguish cache warm-up, CPU model and storage differences. Confirm backup schedules and perform an isolated restore test. HA/live migration tests require separate approved scope and adequate capacity.

Document pass/fail/unknown for each acceptance criterion, observed timings, versions, access scope and evidence references. A successful import or running VM is not application acceptance. Obtain owner sign-off before source decommission and coordinate disposal of backups/keys according to retention policy.

Deliverables and operational handover

Deliver the source-to-target inventory/mapping, readiness findings, target design, pilot results, approved wave/cutover/rollback plans, completed validation record, known exceptions, backup/restore evidence and operating runbooks.

Define ownership of Proxmox subscriptions, guest OS/application support, monitoring, patching, credentials, certificate renewal and capacity. Provide operator training and a support escalation path. Do not imply vendor partnerships or certifications that have not been established.

Using the OUTSEED MCPs

Use VMware inventory.read for VM discovery, Proxmox inventory.read for VM/storage/cluster status and Linux inventory.read on authorized guests for baseline evidence. Supplement with manual disk/controller/encryption/snapshot review because this preview does not collect all migration constraints.

Use migration.assess only with explicit reviewed records; it flags blockers, remediation and unknowns. evidence.compare reports changed top-level fields. These tools generate assessment evidence, not an automated migration plan accepted by a vendor or application owner. No tools here execute disk conversion, shutdown, import or infrastructure writes.