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 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<X> (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 <vmid> NOMBRE-VM.ovf <almacen-destino>

# 3) Ajustes recomendados
qm set <vmid> --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 <vmid> Server.vmdk <almacen> --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 <vmid> disco.vmdk <almacen> --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.