Conversión V2V de ESXi a Proxmox: mejores métodos y errores comunes

Hechos interesantes y pequeña historia (para entender decisiones)

• OVF fue diseñado para portabilidad, no para perfección. Es un estándar de empaquetado (descriptor + discos), pero a los vendedores les encantan las “extensiones”, y ahí es donde la portabilidad muere.
• VMDK precede al pensamiento moderno de “nube”. Creció en un mundo de discos thick respaldados por SAN, así que los casos límite de thin provisioning son mayormente “funciona hasta que no funciona”.
• KVM se convirtió en un módulo del kernel de Linux en 2007. Ese cambio (virtualización asistida por hardware en el kernel) es la razón por la que Proxmox no es un proyecto de ciencia.
• Virtio es un contrato de rendimiento. No es solo “un controlador”, es una interfaz paravirtualizada que intercambia compatibilidad por velocidad—excelente después de tener los drivers, doloroso antes.
• QCOW2 fue construido para snapshots y flexibilidad. RAW es sencillamente rápido; QCOW2 es convenientemente operativo. Elige según el backend de almacenamiento y las prácticas de operaciones.
• Los snapshots de VMware nunca fueron backups. Son registros de redirección; déjalos ahí y habrás construido una máquina de latencia que eventualmente se queda sin espacio.
• UEFI vs BIOS es una línea de falla en la era de migraciones. Muchas VMs antiguas son BIOS/MBR; las plantillas modernas son UEFI/GPT. Convertir discos es más fácil que convertir supuestos de arranque.
• Las herramientas de ESXi ocultan cierta complejidad de identidad de dispositivo. Cuando te mueves a KVM, las MAC, modelos de NIC y controladores de almacenamiento vuelven a importar.
• “qm importdisk” de Proxmox tiene una opinión. Quiere adjuntar discos importados a una configuración de VM y destino de almacenamiento; no es un convertidor genérico, es una herramienta de flujo de trabajo.

Una idea parafraseada de Gene Kim que se mantiene en toda migración: Mejora el sistema de trabajo, no los héroes; la fiabilidad viene del flujo repetible. (idea parafraseada)

Elige tu método: OVF/OVA vs qemu-img vs Clonezilla

Mi regla de decisión con opinión

• Si puedes apagar la VM y puedes acceder a los VMDKs: usa qemu-img + importación en Proxmox. Obtendrás control, salidas previsibles y menos capas “mágicas”.
• Si necesitas portabilidad estilo vendedor o estás atado a flujos de exportación de vCenter: usa OVF/OVA, pero trátalo como un método de empaquetado, no como una garantía.
• Si la VM es un appliance con bootloaders raros o no confías en los formatos de disco: usa Clonezilla y clona al nivel de filesystem/bloque.

Compensaciones que importan en producción

• Tiempo de inactividad: los tres prefieren tiempo de inactividad. Existen conversiones en caliente; también son donde aprendes nuevos significados de la palabra “inconsistente”.
• Fidelidad: Clonezilla puede ofrecer la mayor fidelidad para “lo que hay en el disco”, pero es ciego a la semántica de virtualización (controladores, tipo de NIC). OVF puede preservar más metadatos, a veces.
• Velocidad: qemu-img a RAW en almacenamiento local rápido suele ser lo más rápido. Las exportaciones OVF pueden ser lentas porque a menudo reempaquetan y a veces comprimen.
• Depurabilidad: qemu-img y archivos raw son fáciles de inspeccionar. OVA es un tar con un descriptor—está bien, pero es otra envoltura cuando ya estás estresado.

Broma #1: V2V es como mudarse de apartamento—empacar es fácil, encontrar la caja con la cafetera es el verdadero tiempo de inactividad.

Prevuelo: inventario, congelación y decisiones de diseño

Qué debes decidir antes de tocar un solo disco

• Modo de arranque: BIOS o UEFI en la VM destino. Haz coincidir la fuente a menos que disfrutes la arqueología del gestor de arranque.
• Bus de disco: VirtIO SCSI suele ser la opción correcta en Proxmox. SATA es el paracaídas de compatibilidad. IDE es para museos.
• Modelo de NIC: VirtIO para rendimiento; E1000 si necesitas “que arranque sin controladores”.
• Backend de almacenamiento: ZFS, LVM-thin o Ceph. Esto cambia si RAW vs QCOW2 es inteligente y afecta el ajuste de rendimiento.
• Red: nombres de bridges, etiquetado VLAN, MTU y si el cambio de MAC desencadenará licencias o reservas DHCP.
• Plan de reversión: Mantén la VM de ESXi apagada pero intacta hasta que la VM de Proxmox sobreviva al menos un reinicio y un ciclo de backup.

Tareas prevuelo (con comandos, salidas y decisiones)

Task 1: Confirmar soporte de virtualización en el nodo Proxmox

cr0x@pve1:~$ egrep -m1 -o 'vmx|svm' /proc/cpuinfo
vmx

Qué significa: vmx (Intel VT-x) o svm (AMD-V) debe estar presente.

Decisión: Si falta, detente. No puedes hacer KVM correctamente; tendrás emulación QEMU TCG y tristeza.

Task 2: Comprobar tipos de almacenamiento en Proxmox y espacio libre

cr0x@pve1:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        196473240        5123456       185678912        2.61%
local-zfs         zfspool active       1889785616      934281216       955504400       49.44%

Qué significa: Tienes un almacenamiento de directorio (local) y un pool ZFS (local-zfs) con aproximadamente 955GB libres.

Decisión: Elige el destino. Para ZFS, RAW está bien porque ZFS ya hace copy-on-write y snapshots.

Task 3: Inventariar hardware de la VM fuente en ESXi (desde la config exportada)

cr0x@jump:~$ grep -E 'firmware|scsi|ethernet|nvram|virtualHW' vm1/vm1.vmx
virtualHW.version = "14"
firmware = "efi"
scsi0.virtualDev = "pvscsi"
ethernet0.virtualDev = "vmxnet3"
nvram = "vm1.nvram"

Qué significa: Firmware UEFI, controlador PVSCSI, NIC vmxnet3.

Decisión: En Proxmox, planea OVMF y VirtIO SCSI + VirtIO net (o E1000 temporalmente para Windows si los controladores no están preparados).

Task 4: Detectar snapshots en ESXi antes de exportar

cr0x@esxi1:~$ vim-cmd vmsvc/getallvms | grep -i vm1
12   vm1   [datastore1] vm1/vm1.vmx   ubuntu64Guest   vmx-14

cr0x@esxi1:~$ vim-cmd vmsvc/snapshot.get 12
Get Snapshot:
|--ROOT
   |--Snapshot Name        : pre-upgrade
   |--Snapshot Id          : 1
   |--Snapshot Created On  : 2025-12-01
   |--Snapshot State       : powered off

Qué significa: Existen snapshots. Las exportaciones pueden capturar cadenas delta o consolidar implícitamente.

Decisión: Consolida snapshots antes de la conversión a menos que tengas una razón específica para no hacerlo.

Task 5: Confirmar que la VM está apagada (consistencia sobre heroísmos)

cr0x@esxi1:~$ vim-cmd vmsvc/power.getstate 12
Retrieved runtime info
Powered off

Qué significa: Apagada. Este es el estado limpio que quieres para una conversión a nivel de disco.

Decisión: Procede. Si está encendida, programa tiempo de inactividad o usa quiescing a nivel de guest y acepta más riesgo.

Método 1: exportar OVF/OVA + importar en Proxmox

Cuándo OVF/OVA es lo correcto

• Tienes flujos de trabajo en vCenter y auditores que quieren “un artefacto de exportación”.
• Estás moviendo un pequeño número de VMs y la conveniencia importa más que la máxima velocidad.
• Quieres un único archivo (OVA) que puedas archivar, sumarizar y entregar a otro equipo.

Dónde OVF/OVA duele

• Los metadatos de NIC/controlador no se mapean limpiamente a dispositivos KVM.
• Algunas exportaciones producen VMDKs “streamOptimized”, que son válidos pero añaden un paso de conversión.
• Los descriptores OVF pueden incluir secciones específicas de VMware; Proxmox ignora la mayoría.

Tareas prácticas para OVF/OVA

Task 6: Inspeccionar un OVA antes de confiar en él

cr0x@pve1:~$ tar -tf vm1.ova | head
vm1.ovf
vm1.mf
vm1-disk1.vmdk

Qué significa: OVA es un tar que contiene un descriptor OVF, manifiesto y disco.

Decisión: Si faltan discos o ves múltiples discos que no esperabas, detente y verifica el layout de la VM fuente.

Task 7: Validar sumas de comprobación del manifiesto OVF

cr0x@pve1:~$ sha1sum -c vm1.mf
vm1.ovf: OK
vm1-disk1.vmdk: OK

Qué significa: Las comprobaciones de integridad pasan. Si falla, no “lo intentes de todos modos.” Reexporta o retransfiere.

Decisión: Procede solo cuando las sumas estén OK; la corrupción aquí hace perder horas después.

Task 8: Crear una VM vacía en Proxmox que coincida con el modo de arranque

cr0x@pve1:~$ qm create 120 --name vm1 --memory 8192 --cores 4 --machine q35 --bios ovmf --net0 virtio,bridge=vmbr0
create VM 120: success

Qué significa: La VM 120 existe, firmware UEFI, VirtIO net.

Decisión: Si la fuente era BIOS, usa --bios seabios en su lugar. No “actualices” el firmware durante la migración a menos que lo planifiques.

Task 9: Convertir el VMDK del OVA a RAW o QCOW2 e importar

cr0x@pve1:~$ qemu-img info vm1-disk1.vmdk
image: vm1-disk1.vmdk
file format: vmdk
virtual size: 80G (85899345920 bytes)
disk size: 22G
cluster_size: 65536
Format specific information:
    cid: 2155942229
    parent cid: 4294967295
    create type: streamOptimized

cr0x@pve1:~$ qemu-img convert -p -f vmdk -O raw vm1-disk1.vmdk /var/lib/vz/images/120/vm-120-disk-0.raw
    (progress output omitted)

Qué significa: Es un VMDK streamOptimized. Se requiere conversión; Proxmox no lo “ejecutará” directamente.

Decisión: Usa RAW para backends ZFS/LVM-thin a menos que quieras explícitamente las características de QCOW2 en almacenamiento tipo dir.

Task 10: Adjuntar el disco importado y establecer el orden de arranque

cr0x@pve1:~$ qm set 120 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-120-disk-0
update VM 120: -scsihw virtio-scsi-pci -scsi0 local-zfs:vm-120-disk-0

cr0x@pve1:~$ qm set 120 --boot order=scsi0
update VM 120: -boot order=scsi0

Qué significa: Disco adjuntado como VirtIO SCSI y usado como dispositivo de arranque.

Decisión: Si Windows no arranca, adjunta temporalmente como SATA y corrige drivers, luego vuelve a cambiar.

Método 2: VMDK → QCOW2/RAW con qemu-img (mi opción por defecto)

Por qué este método gana la mayoría de las veces

Si puedes obtener los VMDK(s) desde el datastore (o accederlos por NFS/SSH desde un shell de ESXi), qemu-img te da
determinismo. Controlas formatos, puedes inspeccionar la cadena, elegir objetivos sparse o completamente asignados, y puedes ejecutar la
conversión en el nodo Proxmox justo al lado del almacenamiento destino.

Las dos conversiones que realmente querrás

• VMDK → RAW: mejor cuando el almacenamiento destino ya hace snapshots/COW (ZFS, Ceph RBD). Rápido, simple, menos capas.
• VMDK → QCOW2: útil en almacenamiento de directorio cuando quieres snapshots a nivel de VM (y aceptas la sobrecarga), o por portabilidad.

Tareas prácticas con qemu-img

Task 11: Confirmar que el VMDK no es una cadena de snapshots que olvidaste

cr0x@pve1:~$ qemu-img info -U vm1-flat.vmdk
image: vm1-flat.vmdk
file format: raw
virtual size: 80G (85899345920 bytes)
disk size: 80G

Qué significa: Este es un extent “flat” raw, no una cadena delta. Eso es lo que quieres.

Decisión: Si ves una relación padre/hijo (backing file), detente y consolida en ESXi primero.

Task 12: Convertir con progreso y valores por defecto razonables

cr0x@pve1:~$ qemu-img convert -p -f vmdk -O raw vm1.vmdk /tank/images/120/vm-120-disk-0.raw
    (progress output omitted)

Qué significa: La conversión del disco se ejecuta. El tiempo depende del tamaño del disco, de los bloques realmente usados y de la velocidad del almacenamiento.

Decisión: Si la conversión es lenta, no adivines. Usa el guion de diagnóstico rápido abajo para identificar si estás limitado por CPU, red o disco.

Task 13: Importar el disco en el almacenamiento de Proxmox correctamente (qm importdisk)

cr0x@pve1:~$ qm importdisk 120 /tank/images/120/vm-120-disk-0.raw local-zfs
importing disk '/tank/images/120/vm-120-disk-0.raw' to VM 120 ...
transferred 0.0 B of 80.0 GiB (0.00%)
transferred 80.0 GiB of 80.0 GiB (100.00%)
Successfully imported disk as 'local-zfs:vm-120-disk-0'

Qué significa: Proxmox importó el disco en el almacenamiento destino y creó una referencia de volumen.

Decisión: Prefiere qm importdisk cuando sea posible; mantiene la contabilidad del almacenamiento ordenada.

Task 14: Confirmar que la config de la VM referencia el disco y controlador correctos

cr0x@pve1:~$ qm config 120
bios: ovmf
boot: order=scsi0
cores: 4
memory: 8192
name: vm1
net0: virtio=DE:AD:BE:EF:12:20,bridge=vmbr0
scsi0: local-zfs:vm-120-disk-0
scsihw: virtio-scsi-pci

Qué significa: El disco está en scsi0 con VirtIO SCSI. UEFI está habilitado.

Decisión: Si el disco de arranque no está en el controlador que esperas, arréglalo ahora antes del primer arranque.

Método 3: Clonezilla (cuando necesitas “tonto pero fiable”)

Cuándo Clonezilla es la herramienta adecuada

• VMs appliance con particionado extraño, bootloaders personalizados o kernels proveedor que no quieres tocar.
• Situaciones donde los formatos de disco son un lío (cadenas de snapshots, exportaciones streamOptimized, variantes VMDK desconocidas).
• Cuando necesitas migrar entre layouts de almacenamiento totalmente distintos y prefieres copias a nivel de archivos de los bloques usados.

Qué Clonezilla no hará por ti

• No arreglará controladores VirtIO en Windows.
• No mapeará tu modelo de NIC de VMware a la semántica de Proxmox.
• No hará coincidir tu modo de arranque; aún tendrás que configurar BIOS/UEFI correctamente.

Tareas prácticas con Clonezilla (y el ángulo operativo)

Task 15: Crear la VM destino con dispositivos conservadores para el primer arranque

cr0x@pve1:~$ qm create 130 --name vm1-clone --memory 8192 --cores 4 --machine q35 --bios seabios --net0 e1000,bridge=vmbr0 --sata0 local-zfs:80
create VM 130: success

Qué significa: Una VM BIOS con una NIC E1000 y disco SATA. Valores por defecto aburridos y compatibles.

Decisión: Usa esto si no estás seguro sobre los controladores del invitado. Una vez estable, cambia a VirtIO para rendimiento.

Task 16: Confirmar que el nuevo disco existe y tiene el tamaño correcto antes de clonar

cr0x@pve1:~$ lsblk -o NAME,SIZE,TYPE,MODEL | grep -E 'zd|sd'
sda   447.1G disk  Samsung_SSD
zd0    80G   disk

Qué significa: Proxmox creó un disco virtual (zvol de ZFS aparece como zd0).

Decisión: Si el tamaño es incorrecto, bórralo y recréalo. Clonar en un tamaño equivocado es una excelente forma de conocer a tu yo de guardia.

Con Clonezilla normalmente inicias tanto la fuente como el destino de forma controlada (boot ISO, share de red para imágenes, etc.).
Los comandos son menos “teclea esto” y más “elige este elemento de menú”, así que la tarea operativa es elegir hardware virtual conservador primero.
Una vez que el guest arranque, puedes iterar dispositivos y controladores.

Específicos del SO invitado: Windows, Linux, appliances

Windows: controladores y arranque son el juego entero

Las migraciones de Windows fallan por dos razones: controladores del controlador de almacenamiento y desajuste del modo de arranque. Todo lo demás es secundario.
Si tu Windows usó VMware PVSCSI y vmxnet3, no tendrá automáticamente los controladores VirtIO para almacenamiento y red instalados.
Aún puedes arrancar si eliges dispositivos compatibles primero (SATA + E1000), instalas controladores VirtIO y luego cambias controladores.

Task 17: Añadir ISO de controladores VirtIO y una “NIC segura” para el primer arranque

cr0x@pve1:~$ qm set 120 --ide2 local:iso/virtio-win.iso,media=cdrom
update VM 120: -ide2 local:iso/virtio-win.iso,media=cdrom

cr0x@pve1:~$ qm set 120 --net0 e1000,bridge=vmbr0
update VM 120: -net0 e1000,bridge=vmbr0

Qué significa: Los controladores VirtIO están disponibles para el invitado; la NIC está configurada como E1000 para compatibilidad.

Decisión: Arranca, instala los controladores VirtIO, luego cambia net0 de nuevo a VirtIO.

Task 18: Después de instalar controladores, cambiar disco a VirtIO SCSI (ventana de mantenimiento)

cr0x@pve1:~$ qm set 120 --scsihw virtio-scsi-pci
update VM 120: -scsihw virtio-scsi-pci

Qué significa: Tipo de controlador establecido. Puede que todavía necesites mover el disco de SATA a SCSI en la config si usaste SATA como puente.

Decisión: Cambia una clase de dispositivo a la vez: NIC, luego almacenamiento. No amontones incertidumbre.

Linux: normalmente bien, excepto cuando no lo está

Los kernels Linux modernos incluyen controladores VirtIO. El modo de fallo común es initramfs que no incluye el controlador de almacenamiento adecuado si la VM era antigua,
o que cambió el nombre de la interfaz de red (nombres predecibles) y tu configuración estática apunta a una interfaz inexistente.

Task 19: Si Linux arranca pero la red está muerta, confirma el estado de enlace desde Proxmox

cr0x@pve1:~$ qm monitor 120
Enter QEMU Monitor for VM 120 - type 'help' for help
(qemu) info network
hub 0
  netdev net0, peer=(null)
    virtio-net-pci.0: mac=DE:AD:BE:EF:12:20
    link=up
(qemu) quit

Qué significa: Desde la vista de QEMU, el enlace está up. Si el guest no tiene red, probablemente sea configuración interna del invitado.

Decisión: Revisa cambios en udev/nombres predecibles, configuraciones IP estáticas y reglas de firewall dentro del guest.

Appliances: trátalos como cajas negras

Los appliances de proveedor a menudo fijan módulos del kernel a IDs de dispositivo específicos. Tu mejor estrategia: hardware virtual conservador primero (SATA, E1000),
arranca, confirma servicios y luego intenta VirtIO solo si el proveedor lo soporta.

Almacenamiento en Proxmox: ZFS/LVM-thin/Ceph y por qué importa

ZFS: excelentes valores por defecto, bordes afilados

ZFS es fantástico para Proxmox porque snapshots y replicación son nativos, y los scrubs te dicen la verdad sobre tus discos.
Pero ZFS también es muy honesto: si sobreasignas RAM, privas al ARC o eliges recordsize/volblocksize incorrectos para zvols, te lo hará sentir.

Task 20: Comprobar salud del pool ZFS antes de importar discos grandes

cr0x@pve1:~$ zpool status -x
all pools are healthy

Qué significa: No hay errores conocidos. Importar a un pool degradado es convertir la migración en recuperación de datos.

Decisión: Si no está sano, arregla hardware/pool primero.

Task 21: Vigilar síntomas de amplificación de escritura en ZFS durante la conversión

cr0x@pve1:~$ zpool iostat -v 2
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        890G   890G     12    420   3.1M   210M
  mirror    890G   890G     12    420   3.1M   210M
    sda        -      -      6    210   1.6M   105M
    sdb        -      -      6    210   1.5M   105M

Qué significa: Las escrituras dominan durante la conversión. Eso es normal; las conversiones son intensivas en escritura.

Decisión: Si el ancho de banda es mucho menor de lo esperado, probablemente estés limitado por compresión, configuraciones sync o los discos subyacentes.

LVM-thin: simple y rápido, menos funciones

LVM-thin es directo y rinde bien para muchas cargas. Existen snapshots pero no son la misma experiencia operativa que ZFS.
Las imágenes RAW en LVM-thin son típicas; QCOW2 añade sobrecarga sin darte mucho.

Ceph: excelente a escala, punitivo cuando está mal dimensionado

Ceph RBD prefiere RAW. Además, Ceph magnifica errores pequeños: red equivocada, MTU incorrecta, supuestos de replicación erróneos, y tu “migración simple”
se convierte en un seminario sobre latencia de almacenamiento. Si vas a migrar a Ceph, haz benchmark y valida primero.

Broma #2: Ceph es como un trabajo en grupo—cuando funciona es hermoso, y cuando no, todos culpan a la red.

Migración de red: bridges, VLANs, MAC y firewalls sorpresa

Mapeo de bridges: vmbr0 no es una constante universal

En ESXi, los port groups abstraen mucho. En Proxmox, los bridges de Linux y los bridges con awareness de VLAN son explícitos. Eso es bueno. También es donde los errores son visibles.
Una VM puede estar “en ejecución” y aun así estar en la isla L2 equivocada.

Task 22: Confirmar bridge y ajustes VLAN-aware en Proxmox

cr0x@pve1:~$ cat /etc/network/interfaces | sed -n '1,120p'
auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

Qué significa: vmbr0 es VLAN-aware. Esa es la configuración común de “hazlo bien desde el principio”.

Decisión: Si necesitas VLANs etiquetadas por VM, mantén VLAN-aware y configura tags en las NICs de las VMs.

Task 23: Confirmar tag de NIC y MAC en la config de la VM

cr0x@pve1:~$ qm config 120 | grep -E '^net0'
net0: virtio=DE:AD:BE:EF:12:20,bridge=vmbr0,tag=120

Qué significa: La VM está en la VLAN 120 mediante tag.

Decisión: Si el guest no alcanza el gateway, confirma trunking en el switch upstream y la presencia de la VLAN. No asumas que el equipo de red “ya lo hizo”.

Task 24: Ver si el host está descartando paquetes por firewall

cr0x@pve1:~$ pve-firewall status
Status: enabled/running

cr0x@pve1:~$ pve-firewall localnet
allow 10.0.0.0/8
allow 192.168.0.0/16

Qué significa: Firewall encendido. Existen reglas localnet; las reglas de tráfico de VM son separadas, pero el estado del firewall del host importa durante la depuración.

Decisión: Si depurando conectividad, desactiva temporalmente el firewall de host para aislar variables, luego reactívalo con reglas correctas.

Guion de diagnóstico rápido (encuentra el cuello de botella)

Cuando una conversión es lenta o la VM arranca pero rinde como si estuviera en una tostadora, no empieces a “tunear.”
Empieza a medir. El objetivo es decidir si estás limitado por disco, CPU, red o controladores del guest.

Primero: ¿la conversión/arranque está bloqueado por almacenamiento?

• Revisa salud e I/O de ZFS/LVM/Ceph.
• Busca pequeñas escrituras aleatorias causadas por QCOW2 encima de almacenamiento COW.
• Comprueba si por error estás convirtiendo un disco sparse a uno completamente asignado en discos lentos.

Task 25: Identificar latencia y saturación de almacenamiento (nivel host)

cr0x@pve1:~$ iostat -xm 2 3
Linux 6.8.12-4-pve (pve1) 	12/28/2025 	_x86_64_	(16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  %util
sda              2.1   210.5    92.4  105432.0   998.3     2.41   11.5   92.3
sdb              2.0   209.8    88.7  105120.4   995.1     2.38   11.3   91.9

Qué significa: ~92% de utilización y ~11ms de await. El almacenamiento está ocupado; la conversión estará limitada por disco.

Decisión: Reduce concurrencia (una conversión a la vez), convierte primero en NVMe local rápido o programa durante ventanas de baja I/O.

Segundo: ¿estás limitado por CPU durante la conversión (compresión, checksums, cifrado)?

Task 26: Comprobar saturación CPU durante qemu-img convert

cr0x@pve1:~$ mpstat -P ALL 2 2
Linux 6.8.12-4-pve (pve1) 	12/28/2025 	_x86_64_	(16 CPU)

12:02:10 PM  CPU   %usr  %nice  %sys  %iowait  %irq  %soft  %idle
12:02:12 PM  all   42.1   0.0   8.3    18.7    0.0   0.7   30.2

Qué significa: Importante iowait; no está puramente CPU-bound. La CPU tiene margen pero el almacenamiento es la puerta de entrada.

Decisión: Enfócate en la ruta de almacenamiento, no en tunear CPU.

Tercero: si la VM rinde mal, ¿son controladores (VirtIO) o layout de almacenamiento?

• Windows sin controladores VirtIO cojea en IDE/SATA y E1000, y pensarás que Proxmox es lento. No lo es. Tú lo estás.
• Linux con planificador IO incorrecto o sin TRIM en almacenamiento SSD thin puede degradarse con el tiempo.

Task 27: Confirmar que la VM usa cache y ajustes discard previstos

cr0x@pve1:~$ qm config 120 | grep -E 'scsi0|sata0|cache|discard|iothread'
scsi0: local-zfs:vm-120-disk-0

Qué significa: No se muestran ajustes explícitos de cache/discard; aplican los valores por defecto.

Decisión: Para almacenamiento SSD con thin provisioning, considera habilitar discard=on y un IO thread para discos pesados tras confirmar soporte TRIM en el guest.

Errores comunes: síntoma → causa raíz → solución

1) La VM no arranca: “No bootable device”

Síntoma: La consola de Proxmox muestra shell UEFI o fallo de arranque BIOS.

Causa raíz: Desajuste BIOS/UEFI (la fuente era BIOS y el destino es OVMF, o viceversa). O el orden de arranque apunta al disco equivocado.

Solución: Haz coincidir el firmware con la fuente. Establece el orden de arranque correcto. Si es necesario, añade disco EFI para invitados UEFI y verifica la entrada de arranque.

2) Windows hace bluescreen temprano (INACCESSIBLE_BOOT_DEVICE)

Síntoma: BSOD de Windows justo después del logo de arranque.

Causa raíz: El controlador del almacenamiento cambió a VirtIO sin drivers presentes.

Solución: Reviértelo a SATA temporalmente, arranca, instala el driver VirtIO desde la ISO y luego cambia a VirtIO SCSI.

3) La VM arranca pero la red está muerta

Síntoma: El guest no tiene IP, no hace ping al gateway o DHCP no responde.

Causa raíz: Falta/valor de tag VLAN incorrecto, mismatch de bridge, cambio de MAC y reservas DHCP lo rechazan, o el SO renombró la interfaz (Linux).

Solución: Confirma bridge y tag en qm config. Confirma trunking upstream y presencia de la VLAN. Mantén la MAC si licencias/DHCP lo esperan. Arregla la configuración del guest.

4) La conversión es dolorosamente lenta

Síntoma: qemu-img convert avanza a paso de tortuga, el host se siente lento.

Causa raíz: Cuello de botella en almacenamiento, conversión a RAW completamente asignado en discos lentos, o I/O competidor (otras VMs, scrub, backups).

Solución: Ejecuta una conversión a la vez; mueve la carga de conversión a SSD/NVMe local rápido; evita QCOW2 sobre ZFS si no lo necesitas.

5) La VM va rápido un día y luego empeora

Síntoma: La latencia aumenta, especialmente en cargas intensivas de escritura.

Causa raíz: Aprovisionamiento delgado sin discard/TRIM, acumulación de snapshots, o caché de escritura del guest interactuando mal con configuraciones de sync del almacenamiento.

Solución: Habilita discard cuando sea apropiado, mantén higiene de snapshots y alinea la política de caché con tu modelo de durabilidad del almacenamiento.

6) El disco aparece “más grande” o “más pequeño” de lo esperado

Síntoma: El guest ve una capacidad equivocada o errores de filesystem.

Causa raíz: Disco equivocado seleccionado en VMs con múltiples discos, conversión de delta en vez de base, o tamaños de sector/geometry desajustados en SOs antiguos.

Solución: Verifica el mapeo de cada VMDK a cada disco de Proxmox. Consolida snapshots. Para guests antiguos, prefiere Clonezilla o mantén controladores conservadores.

7) El disco importado consume tamaño completo en ZFS aunque fuera thin en ESXi

Síntoma: Un disco thin de 2TB se vuelve una asignación aterradora.

Causa raíz: Convertiste a RAW de forma que se escribieron bloques cero, o importaste en un tipo de almacenamiento que no preserva la esparcidad como asumías.

Solución: Usa conversiones que respeten sparse y verifica bloques realmente usados. Para discos grandes sparse, considera QCOW2 en almacenamiento dir o importes RAW cuidadosos en zvols thin-provisioned.

Listas de verificación / plan paso a paso

Plan A (recomendado): conversión con qemu-img y cambios de hardware controlados

1. Inventariar la VM fuente: firmware (BIOS/UEFI), discos, controladores, tipo de NIC, snapshots.
2. Consolidar snapshots: no migres cadenas delta a menos que disfrutes la ambigüedad.
3. Apagar la VM: la consistencia vence a la astucia.
4. Copiar VMDKs al host de conversión: idealmente el nodo Proxmox o una caja de staging cercana.
5. Inspeccionar con qemu-img: confirmar formato y detectar backing files.
6. Convertir a RAW (ZFS/Ceph) o QCOW2 (dir): elige formato según backend, no por sensaciones.
7. Crear la VM en Proxmox: haz coincidir firmware, empieza con dispositivos compatibles si es Windows.
8. Importar el disco: qm importdisk cuando sea posible; adjunta en el bus deseado.
9. Primer arranque en hardware “seguro”: E1000 + SATA si los controladores son desconocidos.
10. Instalar controladores VirtIO: luego cambia NIC a VirtIO y después el disco a VirtIO SCSI.
11. Validación: prueba de reinicio, salud de servicios, comprobaciones de la aplicación, ejecución de backup.
12. Corte: cambios DNS/IP, actualizaciones de monitorización, desmantela la copia ESXi solo tras estabilidad.

Plan B: OVF/OVA cuando necesitas un artefacto portátil

1. Exporta OVA/OVF desde vCenter/ESXi.
2. Verifica sumas en el archivo manifiesto.
3. Extrae discos e inspecciónalos con qemu-img info.
4. Convierte a RAW/QCOW2; no intentes “adjuntar” VMDKs streamOptimized tal cual.
5. Crea la VM en Proxmox con firmware coincidente, adjunta disco y corrige dispositivos/controladores.

Plan C: Clonezilla para appliances y rarezas

1. Crea la VM destino con dispositivos conservadores (BIOS + SATA + E1000).
2. Arranca Clonezilla y clona desde la imagen/compartido de la fuente al disco destino.
3. Arranca destino, valida salud de la aplicación.
4. Sólo entonces intenta mejoras VirtIO si son soportadas.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición errónea

Un equipo cercano a finanzas migró unos cuantos servidores de aplicaciones Windows de ESXi a Proxmox. Hicieron lo que parecía razonable:
convertir discos, crear VMs y “modernizar” cambiando todo a VirtIO de inmediato. El primer arranque no funcionó, así que alternaron algunas configuraciones,
intentaron de nuevo y finalmente consiguieron que un servidor arrancara. Declararon victoria y programaron el resto.

La noche del corte llegó. Tres VMs entraron en boot-loop con INACCESSIBLE_BOOT_DEVICE. La que había arrancado no tenía red porque también cambiaron las NICs a VirtIO,
y el SO no tenía el controlador. Su suposición fue simple: “Windows descubrirá controladores como lo hace Linux”. No lo hace.

La solución inmediata fue desordenada pero efectiva: revertir almacenamiento a SATA para el arranque, adjuntar la ISO de controladores VirtIO, instalar drivers en el guest y luego migrar
controladores uno a la vez. La solución cultural fue mayor: tratar los cambios de dispositivo como migraciones de esquema. Etápalos, verifica y luego pasa al siguiente paso.

El postmortem fue corto y útil: no tenían un “perfil de primer arranque” estándar. Después de eso, todas las V2V de Windows empezaron con SATA + E1000,
y solo pasaban a VirtIO una vez confirmados los controladores. Fue más lento. También repetible. A producción le gusta lo repetible.

Micro-historia 2: La optimización que salió mal

Otra organización intentó ser lista con el almacenamiento. Migraban una flota de VMs Linux y decidieron QCOW2 en todas partes porque “los snapshots son buenos.”
Su almacenamiento Proxmox era ZFS. Habían apilado efectivamente copy-on-write sobre copy-on-write. Funcionó en pruebas, porque las pruebas fueron cortas y educadas.
Producción no lo fue.

La primera señal fue aumento de latencia de escritura en horas pico. Las bases de datos se quejaron. Los runners de CI se ralentizaron. Luego las ventanas de backup empezaron a retrasarse.
El equipo respondió con más tuning: modos de cache, profundidades de cola y un puñado de cambios sysctl. Algunos ayudaron brevemente, mayormente moviendo el dolor.

Finalmente hicieron la medición aburrida: iostat en host, zpool iostat y latencia a nivel VM. El patrón quedó claro—amplificación de escrituras aleatorias y churn de metadatos.
QCOW2 hacía su trabajo; ZFS también; juntos estaban haciendo demasiado trabajo.

Migraron VMs calientes a RAW en zvols y reservaron QCOW2 para casos donde la portabilidad importaba más que el rendimiento. La latencia de escritura se normalizó.
La lección no fue “QCOW2 es malo”. La lección fue: no apiles funciones a menos que estés dispuesto a pagarlas en latencia y complejidad.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía del sector salud tuvo que migrar una mezcla de VMs bajo ventanas de cambio ajustadas. No fueron sofisticados. Fueron disciplinados.
Cada VM recibió la misma lista de verificación previa: estado de snapshots, verificación de apagado, validación de checksum de exportación y un paso documentado de reversión.
Cada VM migrada tenía que pasar “dos reinicios y un backup” antes de que la copia de ESXi pudiera ser eliminada.

A mitad del proyecto, un switch de almacenamiento empezó a descartar paquetes intermitentemente en la red de migración. Nada falló totalmente.
En su lugar, algunas transferencias OVA llegaron corruptas. El equipo no lo notó de inmediato—hasta que la verificación del manifiesto empezó a fallar.
Ese único paso aburrido les evitó importar discos corruptos y luego depurar errores fantasma de filesystem.

Retransfirieron las exportaciones afectadas tras aislar la ruta de red. El calendario de migración se retrasó un poco, pero la producción se mantuvo estable.
Nadie tuvo que inventar un ritual nuevo. Simplemente siguieron la checklist y dejaron que detectara el problema temprano.

Si buscas la moraleja: las sumas de comprobación cuestan menos que los puentes de incidentes. Además, la herramienta más “enterprise” en la sala suele ser un archivo de texto
donde consistentemente anotas lo que hiciste.

Preguntas frecuentes

1) ¿Puede Proxmox importar directamente un OVF y recrear el hardware de la VM?

No en el sentido “como lo hace vSphere”. Normalmente creas la VM shell tú mismo y importas/convviertes discos. Espera mapear dispositivos manualmente.

2) ¿Debo usar QCOW2 o RAW en Proxmox?

RAW en ZFS y Ceph suele ser la opción correcta. QCOW2 está bien en almacenamiento de directorio cuando quieres snapshots a nivel de imagen o portabilidad.
No apiles QCOW2 sobre ZFS a menos que sepas por qué estás pagando esa sobrecarga.

3) ¿Cuál es el modelo de NIC más seguro para el primer arranque?

E1000 es la elección común de compatibilidad, especialmente para Windows. Tras instalar controladores, cambia a VirtIO para rendimiento.

4) ¿Cuál es el controlador de disco más seguro para el primer arranque en Windows?

SATA. Arranca con SATA, instala controladores VirtIO y luego cambia el disco a VirtIO SCSI (un cambio a la vez).

5) Mi VM de ESXi usaba UEFI. ¿Qué hago en Proxmox?

Usa OVMF (--bios ovmf) y típicamente añade un disco EFI si es necesario. Mantén el modo de arranque consistente o acabarás en un shell EFI.

6) ¿Puedo migrar una VM con snapshots?

Puedes, pero probablemente no deberías. Consolida snapshots primero para convertir un único disco coherente. Las cadenas de snapshots son donde las conversiones se vuelven “creativas”.

7) ¿Por qué mi disco importado consume más espacio que el VMDK thin?

Puede que hayas convertido de forma que se escribieron bloques que antes eran sparse, o que tu almacenamiento destino asigne diferente.
Verifica expectativas de esparcidad y mide la asignación real en el destino.

8) ¿Cómo sé si el cuello de botella es red, disco o CPU durante la conversión?

Mide en el nodo Proxmox: iostat para saturación de disco, mpstat para iowait vs CPU, y herramientas específicas de almacenamiento (como zpool iostat).
No “tunées” hasta saber qué está saturado.

9) ¿Es necesario preservar direcciones MAC?

A veces. Reservas DHCP, sistemas de licencias y políticas de firewall pueden depender de la MAC. Si no sabes, preserva las MACs y cámbialas después con intención.

Siguientes pasos que realmente puedes hacer

1. Elige tu método por VM: por defecto qemu-img; usa OVA cuando necesites un artefacto; usa Clonezilla para appliances y bootloaders raros.
2. Estandariza un “perfil de primer arranque”: coincidir BIOS/UEFI, SATA + E1000 para Windows si no hay controladores preparados, luego graduar a VirtIO.
3. Haz la conversión medible: ejecuta iostat/mpstat/zpool iostat durante las primeras conversiones y anota cómo es lo “normal”.
4. Requiere dos reinicios y un backup antes de desmantelar el original en ESXi. Si lo omites, el universo te enseñará por qué existe.
5. Documenta mapeos de dispositivos (disk1 → scsi0, disk2 → scsi1, etiquetas VLAN, MACs). Los fallos de migración aman la ambigüedad.

Si haces las partes aburridas—higiene de snapshots, coincidencia de firmware, preparación de controladores, verificación de checksum—la mayoría de las conversiones V2V se vuelven rutinarias.
No son glamurosas. Predecibles. Lo cual es lo más agradable que puedes decir sobre cambios en producción.