--- title: "“VMware to Proxmox” en serio: guía ampliada y real para migrar a Proxmox VE en 2025 (paso a paso, sin humo)" description: "El cambio de rumbo de muchas organizaciones hacia Proxmox VE ya no es tendencia: es proyecto en marcha . A 2025, la combinación de costes , simplicidad operativa y madurez técnica está llevando a equi..." url: https://revistacloud.com/vmware-to-proxmox-en-serio-guia-ampliada-y-real-para-migrar-a-proxmox-ve-en-2025-paso-a-paso-sin-humo/ date: 2025-10-28 modified: 2025-10-20 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2025/05/migracion-vmware-proxmox.jpg categories: ["Destacados", "Guías y recursos"] tags: ["ESXi to Proxmox", "live import Proxmox", "migración VMware Proxmox", "migrate to Proxmox VE", "ovftool Proxmox", "proxmox", "vCenter to Proxmox", "VMDK a QCOW2", "vmware", "VMware to Proxmox"] type: post lang: es --- # “VMware to Proxmox” en serio: guía ampliada y real para migrar a Proxmox VE en 2025 (paso a paso, sin humo) El cambio de rumbo de muchas organizaciones hacia **[Proxmox VE](https://revistacloud.com/proxmox-ve-9-nueva-era-virtualizacion/)** ya no es tendencia: es **proyecto en marcha**. A 2025, la combinación de **costes**, **simplicidad operativa** y **madurez técnica** está llevando a equipos de TI a recorrer la ruta **VMware → Proxmox VE** con objetivos claros: reducir complejidad y TCO, mantener (o mejorar) la resiliencia y minimizar el downtime. Este reportaje técnico reúne, de forma estructurada, **lo que de verdad hay que saber y hacer**: arquitectura base de Proxmox, opciones de almacenamiento y red, **métodos de migración reales** (automáticos y manuales), *checklists* previos, configuración óptima de VMs, HA, backup y los **puntos finos** que suelen romper un proyecto si no se anticipan. --- ## Proxmox VE en 5 ideas (lo imprescindible) - **Plataforma**: basado en **Debian GNU/Linux**, kernel Linux, **QEMU/KVM** para VMs y **LXC** para contenedores. Gestión vía **GUI web**, **CLI** y **REST API**. - **Cluster**: multi-máster con **quórum** (Corosync). Recomendado **≥ 3 nodos**; en clúster de 2 nodos, añadir **QDevice**. - **Almacenamiento**: plugins nativos (**Ceph RBD, ZFS, LVM/thin, directorio, NFS/SMB, iSCSI/FC**). Los contenidos (discos, ISOs, backups) se declaran a nivel *Datacenter*. - **Config de Proxmox**: ficheros propios bajo **/etc/pve**, respaldados por **pmxcfs** y replicados a todos los nodos. - **Licencia**: software **FLOSS (AGPLv3)**; las **suscripciones** dan acceso a repositorio **Enterprise** (estable) y **soporte técnico**, pero **todas las funciones** están disponibles sin coste extra. --- ## Red y almacenamiento: decisiones que determinan la migración ### Red - **vmbrX** = *Linux bridges* (conmutadores virtuales del host). - **VLAN**: por NIC de invitado o en cualquier capa (p. ej., `bond0.20` como *bridge-port*). - **Bonds** para LAG/LACP. - **Corosync**: **enlace dedicado y redundante** (latencia baja y sin congestión). - **SDN**: zonas VLAN, VXLAN, etc., si el diseño lo exige. ### Almacenamiento (resumen práctico) - **Ceph RBD (recomendado compartido)**: primera opción para HA/live-migration. - **NFS/SMB**: sencillo y flexible; con **qcow2** hay snapshots para VMs (no para contenedores). - **ZFS local**: excelente en clúster pequeño + **Replicación ZFS** (asíncrona; RPO > 0). - **SAN (FC/iSCSI)**: - **LVM-thick compartido**: simple; snapshots no nativos. - En **Proxmox VE 9.0** (ago-2025) llega **“Snapshots as Volume-Chain”** (vista técnica) que habilita snapshots tipo qcow2 sobre LVM-thick (excepto estado TPM). - **Un LUN por disco**: snapshot en la cabina pero **operación muy costosa** (evitar a escala). - **ZFS over iSCSI**: viable con cabinas compatibles y *tooling* soportado. - **Multipath**: obligatorio si hay caminos redundantes a la SAN. --- ## Checklist previo (pre-flight) — no migres sin esto 1. **Versión**: Proxmox VE **8 o superior**, actualizado. 2. **Inventario**: BIOS/UEFI, discos y controladoras, **vTPM** (si hay cifrado), IPs y reservas DHCP, **vSAN** (si aplica), cadena de snapshots. 3. **Guest tools & drivers**: desinstalar **VMware Tools**; preparar **VirtIO** (Windows) y confirmar **virtio-scsi** en **initramfs** (Linux). 4. **Seguridad**: si hay **full-disk encryption** con claves en **vTPM**, deshabilitar vTPM y **tener claves** a mano (vTPM no migra). 5. **Red/Corosync**: enlaces dedicados, VLANs, bonds; plan para bridges `vmbr` del host. 6. **Almacenamiento**: definir *target* por VM (Ceph/NFS/ZFS/SAN). 7. **Backups**: elegir **Proxmox Backup Server** (dedup+incremental+**live-restore**) o **vzdump**. 8. **Plan de corte y reversión**: pruebas con 1-2 VMs, ventana de mantenimiento, *rollback* escrito. --- ## Mejores prácticas de VM en Proxmox VE (evita sorpresas) - **CPU** - Mismo modelo en todos los nodos → `host`. - Mezcla de CPUs/expansión futura → genérico **`x86-64-v`** (preserva live-migration). - **NIC** - **VirtIO** por defecto (mínima sobrecarga). e1000/rtl8139 solo para SOs antiguos sin VirtIO. - **Memoria** - **Ballooning Device** activado (telemetría útil incluso sin *ballooning*). - **Discos** - Bus **SCSI** + **`virtio-scsi-single`**; **discard/trim** en thin; **IO thread** en I/O intensivo. - **Agente** - Instalar **qemu-guest-agent** para shutdowns limpios, IPs, *hooks*. - **Arranque** - SeaBIOS (legacy) o **OVMF/UEFI** según fuente. Si UEFI no arranca, crear **entrada EFI** y añadir **EFI Disk**. --- ## Métodos de migración (de menor a mayor intervención) ### 1) **Importación automática desde ESXi** (rápida y soportada) Proxmox incorpora un **importador ESXi** (GUI/API): 1. *Datacenter → Storage → Add → ESXi*. Usar credenciales del **host ESXi** (vCenter funciona pero **más lento**). 2. Ver VMs disponibles en el panel de importación. 3. Seleccionar **almacenamiento destino**, **bridge** de red y ajustar hardware (modelo NIC, ISO, almacenamiento por disco, etc.). 4. **Apagar** la VM en ESXi para consistencia. 5. Lanzar **import** en Proxmox y **arrancar**; instalar VirtIO/Agente QEMU; revisar MAC/DHCP/IP. **Cuidado con**: - **vSAN** (discos en vSAN no se importan; mover antes a otro datastore). - **Discos cifrados** por política (retirar cifrado). - **Datastores** con caracteres especiales (p. ej., ‘+’) → renombrar. - **Snapshots** grandes en origen → importación lenta. **Live-import**: reduce **downtime** arrancando la VM mientras se siguen importando bloques. Al inicio hay **I/O más lento**; si falla el proceso, se **pierden los datos** escritos desde el arranque del live-import → **probar en laboratorio**. **Importación masiva**: limitar **concurrencia** (regla general: **≤ 4 discos** a la vez). La API de ESXi **rate-limita**; el servicio *esxi-folder-fuse* ayuda, pero no lances decenas de importaciones en paralelo. Vigila **RAM** (caché *readahead* por disco). --- ### 2) **Exportar OVF/OVA + `qm importovf`** (portable y robusto) Cuando el importador no es viable: ``` # 1) Exportar con ovftool (ESXi) ./ovftool vi://root@ESXI-FQDN/NOMBRE-VM /exports/NOMBRE-VM/ # 1b) o desde vCenter ./ovftool vi://usuario:pass@VCENTER/DC/vm/NOMBRE-VM /exports/NOMBRE-VM/ # 2) Importar en Proxmox qm importovf NOMBRE-VM.ovf # 3) Ajustes recomendados qm set --cpu x86-64-v2-AES --scsihw virtio-scsi-single ``` En **Windows**, arranca temporalmente con **IDE/SATA**, instala drivers **VirtIO** y cambia a **VirtIO SCSI**. --- ### 3) **`qm disk import`** (importación/conversión directa de VMDK) Si Proxmox ve los `*.vmdk` (p. ej., en NFS/SMB): ``` # Crear VM destino (sin disco por defecto) # Importar y convertir al vuelo qm disk import Server.vmdk --format qcow2 # Aparece como "Unused"; adjuntar a SCSI/VirtIO y fijar orden de arranque ``` --- ### 4) **Adjuntar y Mover** (downtime casi cero) Si **ESXi y Proxmox** comparten un **datastore**: 1. Añadir el **share** a Proxmox como *storage* (tipo **Disk Image**). 2. Crear la VM en Proxmox con disco OS en ese *storage* y formato **vmdk** (Proxmox crea el descriptor). 3. **Sobrescribir** el descriptor con el **VMDK origen** y apuntar el *Extent* al **`*-flat.vmdk`** del origen (ruta relativa). 4. **Encender** la VM en Proxmox (arranca desde el flat de origen). 5. **Mover en caliente** el disco a almacenamiento destino (**Disk Action → Move Storage**). 6. Desinstalar VMware Tools, instalar **Agente QEMU**/**VirtIO** y cambiar a **VirtIO SCSI**. --- ## Alta disponibilidad (HA) sin sustos - **Corosync**: latencia baja y enlace dedicado; si se satura (backup/almacenamiento), aumentan *timeouts* y puede haber *self-fence*. - **Fencing**: si un nodo pierde el quórum, se **auto-reinicia** para garantizar consistencia antes de recuperar las VMs en otro nodo. - **Discos**: para *failover* efectivo, las VMs deben estar en **almacenamiento compartido** (o usar **ZFS Replication** asíncrona con su pequeño RPO). - **Sin COLO**: no hay (a 2024/25) ejecución en *lockstep* de 2 VMs simultáneas (función COLO de QEMU aún en desarrollo upstream). --- ## Backup y recuperación: integra Proxmox Backup Server - **Proxmox Backup Server (PBS)**: deduplicación **independiente del FS**, **incrementales** (solo cambios), **backups en caliente** rápidos y **live-restore** (arrancas la VM mientras se restaura). - **vzdump**: opción clásica basada en archivos. - **Estrategia**: programa **diarios** incrementales y **semanales** completos, valida **restores**, etiqueta **SLA** y termina con una **prueba de DR** programada. --- ## Cronogramas y operación: cuánto tiempo de verdad - **VM media (200 GB) en el mismo CPD (10 GbE)** - Preparación/pruebas: **30–60 min** - Importación automática: **15–45 min** - Ajustes post (drivers/red): **10–20 min** - **Downtime típico**: **10–30 min** (o menos con **live-import**) - **Lote de 20 VMs (tamaños mixtos)** - Escalonar (**≤ 4 discos** simultáneos), preferible **ventana nocturna** - Equipo paralelo: 1 vigila API ESXi y *rate-limit*, 1 ajusta drivers/agente, 1 valida aplicaciones --- ## Endurecimiento exprés post-corte (10 minutos) 1. Reasignar **reservas DHCP** o IPs estáticas (cambia la MAC). 2. Activar **discard** y **IO thread** donde toque. 3. Instalar **qemu-guest-agent** y **VirtIO** en todos los invitados. 4. Programar **backups** a PBS (y probar **live-restore**). 5. **Live-migration** de humo entre nodos. 6. Revisar **firewall** (Datacenter/Nodo/VM) y **monitoreo** (CPU steal, balloon, latencias). --- ## Tabla de referencia rápida (decisión técnica y SEO) | Tema | VMware (ESXi/vCenter) | Proxmox VE | | --- | --- | --- | | Licenciamiento | Propietario | **FLOSS (AGPLv3)** + suscripción opcional | | Formato disco | VMDK | **QCOW2/RAW** (importa VMDK) | | Importación ESXi | — | **Integrada** (GUI/API), **live-import** | | Cluster/HA | vSphere HA/DRS | **Corosync + HA**, live-migration | | Backup | Ecosistema VADP | **Proxmox Backup Server** (dedup, incremental, **live-restore**) | | SDN/Red | vDS/NSX | **Linux bridge/Bond/VLAN + SDN** | | Almacenamiento | vSAN/VMFS/NFS | **Ceph/NFS/SMB/iSCSI/FC/ZFS** (plugins) | --- ## Errores típicos (y cómo no pisarlos) - **UEFI sin ruta**: añadir **entrada EFI** y **EFI Disk**. - **No arranca tras cambiar a VirtIO**: arranca con **IDE/SATA**, instala **VirtIO**, vuelve a **virtio-scsi**. - **vSAN**: mover discos a otro datastore antes de importar. - **vTPM**: el estado **no migra**; deshabilita y conserva **claves**. - **Importaciones colgadas**: demasiadas tareas a la vez → baja concurrencia, consolida snapshots, evita vCenter si buscas rendimiento pico. --- ## Conclusión: “VMware to Proxmox” sin sustos es posible (y más fácil en 2025) Con el **importador ESXi** integrado, **live-import**, una pila de **almacenamiento flexible** y **backup** de primer nivel, Proxmox VE ofrece una **ruta realista** para migrar cargas críticas con **downtime controlado**. La clave no es el botón mágico: es el **diseño** (red/almacenamiento), el **pre-flight**, el **pilotaje** con VMs de prueba y un **runbook** claro para cada método de migración. --- ### Preguntas frecuentes (orientadas a SEO) **¿Cuál es la forma más rápida de pasar de VMware a Proxmox VE con poco downtime?** Usar el **importador ESXi** de Proxmox con **live-import** (o el patrón **Adjuntar y Mover** sobre un datastore compartido). Prepara **drivers VirtIO** y **qemu-guest-agent** antes del corte. **¿Cómo convierto un VMDK a QCOW2 en Proxmox?** Con **`qm disk import`**: ``` qm disk import disco.vmdk --format qcow2 ``` Después adjunta el disco (SCSI/VirtIO) y fija el orden de arranque. **¿Puedo importar desde vCenter directamente?** Sí, pero suele **rendir mejor** importar desde el **host ESXi**. Alternativamente, exporta **OVF/OVA** con `ovftool` y usa **`qm importovf`** en Proxmox. **¿Necesito tres nodos para un clúster Proxmox en producción?** Para un **quórum estable**, **sí**: **≥ 3 votos**. En dos nodos, añade **QDevice** para el tercer voto lógico. Aísla **Corosync** en red dedicada. **¿Qué pasa con vTPM y discos cifrados al migrar a Proxmox?** El **estado vTPM no se migra**. Deshabilítalo temporalmente y **conserva las claves**. Los discos **cifrados por política** en VMware deben **descifrarse** antes de importar. --- Si tu objetivo es **migrar a Proxmox VE** sin apagar medio negocio por el camino, esta guía es tu mapa: **prepara, importa, valida y endurece**. A partir de ahí, Proxmox te da margen para crecer: **Ceph** o **NFS** según caso, **HA** bien cableada, **backups deduplicados** con **live-restore**… y un stack **abierto** que reduce la fricción (y la factura) en el día a día. Suscripción boletín dentro post Contact ##### **¡Suscríbete a las últimas noticias sobre cloud y tecnología en tu email!** Suscribir Acepto la [Política de Privacidad](https://colorvivo.com/politica-privacidad/) y poder recibir el boletín e información de nuestros partners.