# Migrar de VMware a Proxmox: per on es comença i què es trenca - **Publicat el:** 2026-09-07 - **Categoria:** Notícies - **Pàgina original:** https://linuxgratis.com/ca/articles/migrar-de-vmware-a-proxmox Guia pràctica per deixar vSphere i passar a Proxmox VE: inventari, pilot, tandes i tall final. Què s'hi guanya, què costa més del que sembla i els detalls que deixen una VM arrencant lenta si s'obliden. --- D'ençà que Broadcom va refer el catàleg i els preus de VMware, la pregunta ha deixat de ser si convé mirar alternatives i ha passat a ser quant costa moure's. [Proxmox VE](/ca/proxmox-ve) és la que més gent es va trobant pel camí, i val la pena explicar la migració sense adorns: es pot fer, hi ha una manera sensata de fer-la, i hi ha una llista de coses que mosseguen si s'ignoren. ## Què és Proxmox i què no Proxmox VE és Debian amb [KVM](/ca/kvm) i [QEMU](/ca/qemu) a sota, contenidors LXC al costat, i una interfície web i una API que unifiquen les dues coses en un clúster. No és un clon de vSphere: comparteix els conceptes —clúster, alta disponibilitat, migració en calent, emmagatzematge compartit— però no l'arquitectura ni les eines. El que t'emportes de sèrie, sense llicències per sòcol ni subscripció obligatòria: - **Clúster amb corosync**, amb reinici automàtic de les VM d'un node caigut i aïllament del node problemàtic. - **Emmagatzematge integrat**: Ceph repartit entre els mateixos nodes de còmput, o ZFS local per a càrregues sensibles a la latència, amb instantànies i sumes de verificació. - **Còpies de seguretat** amb [Proxmox Backup Server](/ca/proxmox-backup-server): incrementals, deduplicades i xifrades. El que no t'emportes: l'ecosistema d'integracions certificades de vSphere, el mateix comportament del balanceig de càrrega, i la xarxa de partners a la qual potser estàs acostumat. Això no és un defecte del producte, és el preu de canviar de plataforma. ## La migració, per fases La gent de [Cloud Privado](https://cloudprivado.com/migracion) treballa aquest tipus de migracions amb un esquema de quatre fases que coincideix amb el que funciona a la pràctica: 1. **Inventari.** Abans de tocar res, saber què hi ha: màquines, dependències entre elles, qui parla amb qui, quines cabines i quines xarxes. És la fase que més es salta i la que més car surt saltar-se. 2. **Pilot.** Una tanda petita i no crítica, mesurada de debò: rendiment real, no sensacions. 3. **Tandes.** Moure per grups amb l'entorn antic encara dret. Aquí la marxa enrere continua sent possible. 4. **Tall final.** És l'única fase sense marxa enrere, i per això només s'hi entra quan les tres anteriors estan verificades. Amb la màquina apagada el trasllat es mesura en minuts per VM; amb rèplica prèvia de discs, la finestra de tall d'una tanda sol quedar per sota de les dues hores. Les bases de dades són el cas a part: allà el que es fa és mantenir **replicació lògica activa** fins al tall, no copiar un disc i creuar els dits. ## Els detalls que mosseguen - **Controladors VirtIO al Windows, abans de moure.** Si la VM arriba a Proxmox sense ells, arrenca —lenta, amb disc i xarxa emulats— i sembla que "va". És mecànic, però s'oblida. - **Treure les VMware Tools** abans o just després. Conviuen malament amb els agents nous. - **UEFI i arrencada segura**: revisar el microprogramari i el disc EFI de cada VM. És una casella, però és la casella que deixa una màquina sense arrencar. - **Xarxes i VLAN**: els noms dels grups de ports no viatgen sols. Cal reproduir el mapa, i convé fer-ho abans del pilot. - **Emmagatzematge**: decidir Ceph o ZFS **abans** de moure, no després. Canviar d'idea amb 200 VM a sobre és un altre projecte. ## I si Proxmox no és la resposta? No sempre ho és. Si véns de XenServer, [XCP-ng](/ca/xcp-ng) et resultarà més familiar. Si el teu és orquestrar centenars de VM amb un model de núvol, [OpenNebula](/ca/opennebula) té un [camí propi de migració des de VMware](/ca/articles/opennebula-modelo-migracion-cargas-vmware-oneswap). I si el destí és Kubernetes, potser el debat no és quin hipervisor sinó quantes d'aquestes VM haurien de continuar sent VM. Per entendre què hi ha a sota de totes aquestes opcions, la [pila de virtualització de Linux —KVM, QEMU i libvirt—](/ca/articles/kvm-qemu-libvirt-rhel-pila-virtualizacion-linux) explica qui fa què; gairebé tota la resta són capes de gestió a sobre. ## Per on continuar - La [comparativa de plataformes](https://cloudprivado.com/comparativa) de Cloud Privado, per posar Proxmox, VMware i Nutanix a la mateixa taula. - La seva anàlisi de [per què Broadcom prepara un vSphere Standard nou](https://cloudprivado.com/blog/vsphere-standard-broadcom-proxmox), que explica bastant del moment actual. - I si al final la xarxa és el que et preocupa, [com s'escriuen de debò les regles de tallafoc i NAT a Proxmox](https://cloudprivado.com/blog/firewall-nat-sdn-proxmox-reglas-practicas). Sobre on executar-ho: Proxmox va igual de bé en ferro propi que en [servidors bare metal](https://www.stackscale.com/es/bare-metal/) o en un [núvol privat gestionat](https://www.stackscale.com/es/nube-privada/), que és la via habitual quan no vols mantenir tu el maquinari però tampoc vols compartir màquina amb ningú. Les fitxes de [Proxmox VE](/ca/proxmox-ve) i d'[ESXi](/ca/esxi) tenen les seves versions i dates de fi de suport, que convé mirar abans de planificar qualsevol tall: migrar a una versió que caduca d'aquí a sis mesos és començar amb deute. *Qui signa aquest article és cofundador de Stackscale, que apareix entre els enllaços. Ho dic aquí perquè se sàpiga en llegir-lo, no en la lletra petita.*