Las migraciones son para muchos equipos de TI un medio para reducir costes y recuperar el control. En este artículo muestro cómo migrar de VMware a Proxmox — con foco en conversión de disco, mapeo de red y ajuste de rendimiento. El objetivo es una ruta operativa reproducible para administradores, ingenieros de sistemas y operadores, incluyendo estrategias de verificación, seguridad y reversión.
Kurzüberblick und Voraussetzungen
Antes de empezar, defina objetivos, presupuesto de downtime, capacidad de almacenamiento y funciones necesarias (p. ej. snapshots, Thin Provisioning, VLAN‑Tagging). Términos: VMDK es el formato de disco de VMware; Proxmox utiliza KVM/QEMU como hypervisor (KVM = Kernel Virtual Machine), las VMs de Proxmox se gestionan con „qm“. Los backends de almacenamiento como local‑lvm (LVM‑Thin) o ZFS tienen propiedades distintas que afectan la elección de raw vs. qcow2, el modo de caché y las estrategias de snapshots.
Risiken, Vorbedingungen und Vorchecks
Principales riesgos y verificaciones previas al inicio:
- Controladores: Windows‑VMs requieren controladores VirtIO para red y SCSI; si faltan, la VM no arrancará.
- Consistencia de datos: las bases de datos requieren quiesce (pausa dirigida) o backups consistentes; sin comprobación existe riesgo de datos inconsistentes.
- Mapeo de red: los conceptos DVSwitch/Portgroup deben mapearse a bridges de Proxmox/etiquetas VLAN.
- Especificidades de almacenamiento: ZFS, local‑lvm, NFS o iSCSI se comportan de forma diferente respecto a snapshots y al aprovisionamiento insuficiente.
- Monitorización: desplegar agentes de monitorización, alertas y líneas base antes de la migración.
Migrations‑Workflow: Analyse bis Produktion
Un procedimiento robusto se divide en inventariado, migración de prueba, conversión de disco, mapeo de red, pruebas funcionales y conmutación a producción. Cada VM necesita una estrategia de reversión documentada—esto minimiza la presión decisional durante el cutover.
Inventarisierung und Priorisierung
Registre CPU, RAM, diseño de disco, número de NICs, afiliaciones VLAN, estado de VMware Tools y sistema operativo invitado. Priorice según relevancia empresarial y riesgo: servidores de control, bases de datos y controladores de dominio primero en un entorno de pruebas.
Backup, Quiesce und Snapshot‑Strategie
Haga copias de seguridad completas y valide los procesos de RESTauración. Para bases de datos relacionales utilice mecanismos de backup nativos o snapshots basados en VSS (Windows Volume Shadow Copy Service). Las bases de datos Linux deberían idealmente respaldarse con fsfreeze o volcados seguros respecto a transacciones.
Disk‑Conversion: Methoden, Vor‑ und Nachteile
Al convertir VMDK a Proxmox hay varios métodos establecidos. Elija según requisitos operativos, exigencias de rendimiento y capacidad de automatización.
qm importdisk — pragmatisch und Proxmox‑nah
qm importdisk importa una VMDK directamente a un volumen de almacenamiento de Proxmox (p. ej. local‑lvm o ZFS) y crea el volumen con nombres conformes a Proxmox. Ventaja: los metadatos de Proxmox se establecen correctamente y evita operaciones manuales de almacenamiento. Desventaja: en discos Split‑VMDK o controladores VMware especiales se requiere preprocesamiento.
qemu-img — flexibel und kontrolliert
qemu‑img puede leer y convertir casi cualquier formato de disco (vmdk → raw/qcow2). Es ideal si necesita qcow2 para snapshots o raw para dispositivos de bloque directos. qemu‑img puede implicar tiempos de ejecución mayores y mayor uso de CPU; planifique ventanas de transferencia en consecuencia.
Typische Fallen bei Disk‑Conversion
- Split‑VMDKs: en la exportación de VMware los discos pueden dividirse en varios archivos (.vmdk, -s001.vmdk); estos deben consolidarse en vCenter o transferirse por completo.
- Archivos bloqueados: las exportaciones basadas en snapshots pueden bloquear archivos; realice las exportaciones cuando los snapshots de la VM sean coherentes.
- Thin Provisioning: los discos virtuales pueden tener un tamaño virtual mayor que la ocupación real—preste atención a la capacidad del almacenamiento de destino.
Ejemplos prácticos: conversión e importación
Ejemplo: transferir VMDK por SCP y usar qm importdisk:
# Auf Quell‑Host: VMDK exportieren/packen
scp /tmp/source.vmdk root@proxmox:/tmp/
# Auf Proxmox: Import in Storage local-lvm für VMID 100
qm importdisk 100 /tmp/source.vmdk local-lvm
# Anschließend VM konfigurieren
qm set 100 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-100-disk-0
Alternativ qemu‑img nutzen, um raw zu erzeugen:
qemu-img convert -p -O raw source.vmdk /var/lib/vz/images/100/vm-100-disk-0.raw
# dann qm set mit format raw
qm set 100 --virtio0 /var/lib/vz/images/100/vm-100-disk-0.raw
Mapeo de red: VMware vSwitch → Proxmox Bridges
VMware suele distinguir entre Standard‑vSwitch y Distributed vSwitch (DVSwitch). Las portgroups y las políticas definen el etiquetado VLAN y la asignación de uplinks. En Proxmox, Linux‑Bridges (vmbrX) representan el mecanismo principal. Conceptos importantes: trunk (varias VLANs sobre un uplink), access port (una VLAN por uplink) y bridge_vlan_aware (bridge que deja pasar las etiquetas VLAN a las VMs).
Configuración de bridge y etiquetado VLAN
Si varias VLANs circulan por el mismo uplink, active bridge_vlan_aware y etiquete las interfaces de la VM. Ejemplo: VM con VLAN 200 en vmbr0:
# Setzt eine VM-Netzkarte mit VLAN-Tag
qm set 100 --net0 virtio,bridge=vmbr0,tag=200
Si su interfaz física usa bonding o LACP, verifique la configuración del switch y la MTU (p. ej. Jumbo Frames). En caso de incidencias, tcpdump, ethtool y la visualización del tráfico VLAN ayudan.
Ajuste de rendimiento: E/S y red
Tras la migración, a menudo se hacen visibles cuellos de botella de E/S o de red. Aquí medidas concretas, por qué ayudan y cuándo no funcionan.
Ajuste de E/S: caché, iothreads y virtio-scsi
Parámetros importantes en Proxmox/QEMU son el modo de caché (p. ej. none, writeback), iothreads (hilos de E/S separados) y el controlador utilizado (virtio-scsi vs. ide). Por qué: cache=none provoca Direct I/O y evita el caché del sistema de archivos del host, lo que en combinación con un almacenamiento bien configurado (p. ej. ZFS con SLOG) aporta consistencia y baja latencia. Inconveniente: aumenta la carga de CPU y el rendimiento de escritura puede disminuir si el almacenamiento no dispone de aceleradores.
# Beispiel: VM 100 mit iothreads aktivieren und virtio-scsi
qm set 100 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-100-disk-0,cache=none
qm set 100 --iothread 1
Los iothreads son útiles en VMs con alta carga de E/S paralela (p. ej. bases de datos). Pueden fallar si el sistema de scheduler del host está bajo presión de CPU—en ese caso controle el CPU‑Pinning o limite el número de iothreads.
Ajuste de red: multiqueue, offloads y MTU
Virtio‑Net ofrece multiqueue (varias colas Rx/Tx), lo que reduce la latencia con altas tasas de paquetes. Active en la VM los controladores adecuados y aplique las opciones de qm:
# Beispiel: VM-Netzkarte mit 4 Queues
qm set 100 --net0 virtio,model=virtio,bridge=vmbr0,queues=4
Los offloads (TSO, GSO, GRO) reducen la sobrecarga de CPU, pero pueden provocar problemas si el hardware del switch es defectuoso. Pruebe con ethtool e iperf3; si aparece pérdida de paquetes o reordenamiento, desactive los offloads problemáticos.
# Comprobar/desactivar offloads
ettool -k eth0
ethtool -K eth0 tso off gso off gro off
iPerf3 Test (Server auf Proxmox, Client remote):
iperf3 -s
iperf3 -c -P 8 -t 60
Validación, monitorización y control de SLA
Realice líneas base antes/después con fio (I/O) e iperf3 (red) para detectar regresiones de rendimiento. Documente latencias P50/P95/P99 e IOPS por VM. Automatice métricas vía Prometheus/Telegraf y configure alertas ante desviaciones.
Solución de problemas: casos concretos y secuencia de comprobación
Windows no arranca después del cambio a VirtIO
Causa: controladores VirtIO ausentes en el sistema invitado. Solución: use temporalmente una NIC emulada (e1000) y controladores IDE/LSI, arranque, instale localmente los controladores VirtIO (VirtIO‑ISO) y luego vuelva a cambiar. Si está offline, monte la VirtIO‑ISO e instale los controladores mediante DISM o por GUI.
# Ejemplo: controladores VirtIO mediante DISM (Windows-PE/Offline)
Dism /Image:C:mount /Add-Driver /Driver:D:viostor /Recurse
iSCSI se bloquea tras la importación
Compruebe el estado de multipath, las sesiones iSCSI y la autenticación CHAP. Causas frecuentes son desajustes de MTU o ACLs en el SAN.
iscsiadm -m session -P 3
multipath -ll
journalctl -u iscsid
Migración masiva: automatización y control de tasa
Para decenas de VMs, automatice inventario, transferencia, importación y configuración. Conceptos clave: scripts idempotentes, logging, mecanismos de reintento y rate‑limiting para no saturar los backends de almacenamiento. Pruebe con una muestra y realice cutovers escalonados.
# Ejemplo: SCP con limitación de tasa simplificada en Bash (pseudo)
for f in /exports/*.vmdk; do
scp "$f" root@proxmox:/tmp/
sleep 10 # Rate limiting
done
Estrategia de rollback y runbook
Defina opciones claras de retroceso: mantener la fuente como fallback offline hasta la aprobación, probar procedimientos de RESTauración, planificar failover de DNS o gateway. Establezca responsabilidades, ventanas temporales y criterios de abortado (p. ej. desviación de rendimiento > X% o servicios no disponibles tras Y minutos).
Lista de verificación final de cutover
- Copia de seguridad disponible y RESTauración probada
- Red: VLANs, MTU, enrutamiento y reglas de firewall verificadas
- Rendimiento: líneas base fio/iperf3 documentadas
- Seguridad: CHAP/ACLs y permisos verificados
- Monitorización: agentes activos, paneles ajustados
- Plan de rollback documentado y probado
Conclusión
El objetivo, VMware a Proxmox migrar, es manejable con una planificación estructurada. qm importdisk reduce errores manuales, bridge_vlan_aware permite un mapeo de VLAN limpio, y el ajuste dirigido de almacenamiento y red garantiza el rendimiento. Más importante que una cadena de herramientas concreta es la validación: medir, probar y contar con un runbook claro con opciones de retroceso. Así mantiene el control y minimiza riesgos en el cambio a producción.
FAQ
Consulte la sección de FAQ más abajo para respuestas rápidas sobre OVA vs. qm importdisk, problemas de arranque con VirtIO, qcow2 vs. raw y otras preguntas prácticas.
Migrar VMware a Proxmox: aspectos operativos y de arquitectura
Además de la conversión de discos y el mapeo de redes, la arquitectura objetivo determina en gran medida la confiabilidad operativa y los costes a largo plazo. Aquí esbozo decisiones clave de arquitectura y operación, riesgos típicos en la operación de clúster y pasos de verificación concretos que le ayudarán a hacer las migraciones reproducibles y reversibles.
Cluster‑Quorum, segregación de red y Fencing
Los clústeres Proxmox usan corosync para la coordinación. Planifique al menos tres nodos para HA en producción; con dos nodos necesita un Quorum‑Tie‑Breaker (p. ej. QDevice). Sin suficiente quórum corre el riesgo de: detenciones automáticas de servicios, split‑brain o failovers no deseados.
# Quorum‑Status prüfen
pvecm status
# Cluster‑Logs ansehen
journalctl -u corosync -n 200
El fencing (STONITH) evita que dos nodos escriban simultáneamente en la misma LUN de almacenamiento. En entornos de almacenamiento compartido (iSCSI, FC) un fencing operativo es esencial. Implemente fencing fuera de banda mediante IPMI/Redfish o el controlador SAN, y pruebe escenarios de fencing en laboratorio.
Arquitectura de almacenamiento: alineación, caché y consistencia
PRESTe atención al block‑alignment y a la combinación de modos de caché en el host con las funcionalidades del almacenamiento (dedup, compresión). Ejemplo: la compresión de ZFS y los snapshots qcow2 pueden influirse mutuamente; con I/O intensivo raw sobre local‑lvm suele ser más estable. Valide si su almacenamiento utiliza cachés write‑back y si dispone de unidades con respaldo de batería (BBU) — de lo contrario existen riesgos de pérdida de datos ante cortes eléctricos.
Integración de backups y validación de RESTauración
La última línea de seguridad es la comprobación de RESTauración: automatice ejecuciones de RESTauración en un entorno aislado y verifique la consistencia de las aplicaciones (integridad de bases de datos, arranque de servicios, validez de certificados). Use Proxmox Backup Server (PBS) o soluciones externas, y verifique la compatibilidad de los backups con sus objetivos de retención y RTO.
Monitoring, alerts y SLI/SLO
Configure métricas para CPU‑Steal, IOWait, latencias P95/P99 y pérdidas en la red. Establecer líneas base antes de la migración es obligatorio: documente P50/P95‑IOPS y latencias para que las desviaciones tras el cutover sean medibles. Las alertas no deben limitarse a umbrales; deben enlazar runbooks claramente definidos.
Integración con el equipo de operaciones: secretos, acceso API y automatización
Gestione claves SSH, Proxmox‑API‑Tokens y credenciales de almacenamiento de forma centralizada y versionada (Vault, HashiCorp, Ansible Vault). Los playbooks automatizados deben ser idempotentes, producir registros claros y contener lógicas de retry/timeout para amortiguar picos de transferencia.
# Beispiel‑Pattern (Ansible): idempotente Task‑Struktur
- name: Importiere VMDK nach Proxmox
community.general.proxmox:
api_host: pve1.example.local
vmid: 100
state: present
register: result
Criterios de aceptación y rollback de emergencia
Defina criterios de aceptación claros: arranques de servicios exitosos, métricas dentro de desviaciones aceptables y pruebas de RESTauración exitosas. Mantenga las VM originales disponibles en modo read‑only como fallback hasta que un SLA diario o semanal se verifique sin incidentes. Documente responsabilidades, ventanas temporales y canales de comunicación en el Cutover‑Runbook.
Estas medidas operativas y arquitectónicas reducen las sorpresas tras el cambio y hacen que migrar de VMware a Proxmox sea planificable y auditable — crucial para una operación productiva fiable y para la integración en los procesos de TI y los SLAs existentes.
Para este tema, la conversión de VMDK también es importante. El artículo contextualiza estos aspectos de forma comprensible y muestra en qué debe pRESTarse atención en el día a día.