Convertir VMDK a QCOW2 para Proxmox: comandos qemu-img, consejos de rendimiento y errores comunes

Tienes un VMDK exportado desde VMware y un clúster Proxmox que no tiene paciencia con tu nostalgia. La migración es “solo una conversión de disco”, hasta que no lo es: la VM arranca con pantalla negra, la conversión va a 20 MB/s, o qemu-img empieza a recitar poesía sobre “invalid VMDK descriptor”.

Esta es la guía de campo que desearía que más gente usara antes de ejecutar conversiones sobre la única copia de un disco en producción. Es intencionadamente directa. Estás aquí para mover bytes de forma segura, rápida y con menos sorpresas que una ventana de cambios el lunes por la mañana.

El modelo mental: qué estás convirtiendo realmente

“VMDK a QCOW2” suena como un cambio de formato sencillo. En la práctica, estás traduciendo un contenedor de almacenamiento, su estrategia de asignación y, a menudo, su historial de snapshots a algo que QEMU pueda ejecutar de forma eficiente.

VMDK puede ser:

• Single-file monolithicSparse (común en exportaciones y algunas copias de seguridad).
• Dos partes: un pequeño archivo de descriptor en texto más una gran extensión flat (común en datastores ESXi).
• Dividido en fragmentos de 2GB (estilo antiguo/portátil).
• Cadenas de instantáneas (discos delta) donde “el disco” es una pila de archivos que solo tiene sentido juntos.

QCOW2 tampoco es “solo un archivo”. Puede almacenar snapshots, compresión, cifrado, y tiene metadatos que pueden convertirse en un impuesto de rendimiento si lo tratas como un dispositivo bruto. En Proxmox también tienes una segunda decisión: almacenamiento basado en archivos (dir, NFS, CIFS) frente a basado en bloques (LVM-thin, ZFS zvol, Ceph RBD). El destino correcto a menudo no es QCOW2 en absoluto: puede ser raw en un zvol o LVM-thin. Pero a veces QCOW2 es exactamente lo que quieres, especialmente para almacenamiento por archivos y portabilidad.

Aquí está la regla con opinión: convierte una vez, valida dos veces y luego importa. Si estás convirtiendo en un directorio aleatorio con semánticas de sistema de ficheros desconocidas y sin verificación, no estás migrando: estás jugando a la ruleta.

Hechos interesantes y contexto histórico (lo útil)

1. VMDK precede al pensamiento moderno de “imágenes cloud”. Creció en una era donde la virtualización de escritorio y los datastores moldeaban el diseño más que la automatización orientada a API.
2. “Descriptor + flat” en VMDK es una característica, no un bug. El pequeño archivo descriptor es efectivamente metadatos y punteros; pierde eso y todavía puedes rescatar la extensión flat—si conoces la geometría y los detalles del formato.
3. QCOW (v1) vino antes que QCOW2. QCOW2 lo reemplazó para mejorar funciones como snapshots y refcounting; ha sido el predeterminado durante años por buenas razones.
4. qemu-img es anterior a muchos runbooks en producción. Es una herramienta afilada; hará exactamente lo que le pidas, incluidas elecciones irreversibles.
5. “Provisionamiento delgado” significa cosas distintas en distintas capas. Un VMDK thin puede convertirse en un QCOW2 thick si eliges las banderas equivocadas o pasas por la ruta incorrecta.
6. Las snapshots de VMware no son backups. Las cadenas de snapshots pueden ser frágiles; las conversiones que ignoran la estructura de la cadena a menudo producen discos que arrancan pero son sutilmente inconsistentes.
7. El rendimiento de QCOW2 mejoró mucho con el tiempo. QEMU moderno tiene mejores opciones de caching y aio, pero los metadatos de QCOW2 aún cuestan IOPS, especialmente en escrituras aleatorias.
8. Proxmox históricamente favoreció raw para almacenamiento en bloque. En ZFS y LVM-thin, los volúmenes raw suelen ser la opción por rendimiento y cordura; QCOW2 brilla en almacenamiento basado en sistema de archivos.

Checks previos: no conviertas lo que no entiendes

Antes de convertir, necesitas saber qué tienes, dónde vive y qué significa “correcto”. La mayoría de migraciones fallidas no son errores de conversión. Son falta de contexto.

Tarea 1: Identificar el tipo de VMDK y los archivos de respaldo

cr0x@server:~$ ls -lah /mnt/incoming/vmware-export/
total 68G
drwxr-xr-x  2 root root 4.0K Dec 28 10:14 .
drwxr-xr-x 12 root root 4.0K Dec 28 10:10 ..
-rw-------  1 root root  512 Dec 28 10:12 disk.vmdk
-rw-------  1 root root   68G Dec 28 10:12 disk-flat.vmdk

Qué significa: Este es el clásico descriptor + extensión flat. El pequeño disk.vmdk es el descriptor; el archivo grande es los datos. Si solo copiaste el descriptor, copiaste la etiqueta, no el disco.

Decisión: Mantén ambos archivos juntos. No renombres uno sin editar el descriptor. Trátalos como un par.

Tarea 2: Inspeccionar el archivo descriptor (cuando exista)

cr0x@server:~$ sed -n '1,120p' /mnt/incoming/vmware-export/disk.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 142606336 VMFS "disk-flat.vmdk"

# The Disk Data Base
ddb.virtualHWVersion = "13"
ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "8874"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.toolsInstallType = "4"

Qué significa: La línea de extent te dice el tamaño (en sectores) y el archivo de respaldo. parentCID y CID insinúan relaciones de snapshots. adapterType es importante para el arranque después de la importación (PVSCSI vs LSI vs SATA).

Decisión: Si parentCID no parece ffffffff y tienes deltas de snapshot, detente y localiza la cadena. Convertir el enlace equivocado es cómo obtienes “arranca bien, datos faltan”.

Tarea 3: Pregunta a qemu-img qué cree que es el archivo

cr0x@server:~$ qemu-img info /mnt/incoming/vmware-export/disk.vmdk
image: /mnt/incoming/vmware-export/disk.vmdk
file format: vmdk
virtual size: 68 GiB (72980889600 bytes)
disk size: 68 GiB
cluster_size: 65536
Format specific information:
    cid: 4294967294
    parent cid: 4294967295
    create type: vmfs
    extents:
        [0]:
            virtual size: 68 GiB
            filename: /mnt/incoming/vmware-export/disk-flat.vmdk
            format: FLAT

Qué significa: qemu-img lo ve como VMDK y encontró la extensión flat. Bien. Si devuelve error aquí, tu conversión también fallará.

Decisión: Si extents falta o el filename apunta a otro lugar, arregla problemas de ruta primero (a menudo un flat movido/renombrado).

Tarea 4: Verificar que no estés tratando una cadena de snapshots por accidente

cr0x@server:~$ find /mnt/incoming/vmware-export -maxdepth 1 -type f -name "*.vmdk" -printf "%f\n" | sort
disk-flat.vmdk
disk.vmdk

Qué significa: Solo dos archivos. Probablemente no haya cadena de snapshots en esta exportación. En una cadena verías archivos como -000001.vmdk y similares.

Decisión: Si ves discos delta, identifica el descriptor “activo” y asegúrate de que todos los padres estén presentes antes de convertir.

Tarea 5: Comprobar espacio libre en el sistema de ficheros donde se ejecutará la conversión

cr0x@server:~$ df -h /mnt/convert
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       1.8T  1.1T  650G  63% /mnt/convert

Qué significa: Tienes 650G libres. Convertir un disco thin de 68G a un formato thick podría expandirse. Incluso QCOW2 puede hincharse durante la conversión dependiendo de las opciones y la disposición del origen.

Decisión: Asegura el espacio en el peor escenario. Si dudas: convierte a raw en almacenamiento de bloques directamente (LVM-thin/ZFS) en vez de crear un archivo intermedio enorme.

Tarea 6: Establecer una línea base del rendimiento de almacenamiento antes de culpar a qemu-img

cr0x@server:~$ fio --name=readtest --filename=/mnt/convert/.fiotest --size=2G --direct=1 --rw=read --bs=1M --iodepth=16 --numjobs=1 --runtime=30 --time_based --group_reporting
readtest: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.33
Starting 1 process
readtest: Laying out IO file (1 file / 2048MiB)
Jobs: 1 (f=1): [R(1)][100.0%][r=965MiB/s][r=965 IOPS][eta 00m:00s]
read: IOPS=952, BW=952MiB/s (998MB/s)(27.9GiB/30001msec)
    clat (usec): min=402, max=10231, avg=1032.11, stdev=210.44

Qué significa: Tienes ~950 MiB/s de lectura secuencial. Si la conversión va a 40 MiB/s, el cuello de botella no es “el disco es lento” en general—está en otro lado (ruta de escritura, CPU, comportamiento single-thread, compresión, red).

Decisión: Registra la línea base de lectura/escritura. La necesitarás cuando alguien diga “Proxmox está lento”.

Broma #1: Una cadena de snapshots VMDK es como un organigrama corporativo: parece estable hasta que preguntas quién realmente es dueño de los datos.

Patrones de conversión con qemu-img (y por qué)

qemu-img es el caballo de batalla para conversiones de formato. La parte crítica es elegir:

• Formato de salida: qcow2 o raw (y a veces raw es la opción más sensata).
• Comportamiento de asignación: sparse vs preallocated.
• Características de E/S: cache y aio que pueden acelerar la conversión sin mentir sobre durabilidad.

Tarea 7: Ensayar tu entendimiento con info en origen y en la salida prevista

cr0x@server:~$ qemu-img info --output=json /mnt/incoming/vmware-export/disk.vmdk
{
    "virtual-size": 72980889600,
    "filename": "/mnt/incoming/vmware-export/disk.vmdk",
    "format": "vmdk",
    "actual-size": 72980889600,
    "format-specific": {
        "type": "vmfs",
        "cid": 4294967294,
        "parent-cid": 4294967295
    }
}

Qué significa: La salida JSON es conveniente para scripts y comprobaciones. virtual-size importa; actual-size te dice cuánto ocupa actualmente el archivo (para extents flat puede coincidir con virtual size).

Decisión: Decide si mantienes el comportamiento sparse (thin) o vas a thick. Para la mayoría de migraciones, mantén thin salvo que tengas un motivo.

Tarea 8: Convertir VMDK a QCOW2 (valores por defecto sensatos)

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk.qcow2
    (0.00/100%)
    (12.34/100%)
    (54.87/100%)
    (100.00/100%)

Qué significa: -p muestra progreso. Esta es la línea base. Sin banderas de cache sofisticadas. Será correcto, pero puede no ser el más rápido.

Decisión: Usa esto si es una operación puntual o no puedes permitirte ocurrencias creativas. “Aburrido y correcto” es una estrategia operativa válida.

Tarea 9: Verificar la integridad del resultado (chequeo solo lectura)

cr0x@server:~$ qemu-img check -r all /mnt/convert/disk.qcow2
No errors were found on the image.
443392/443392 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 72985100288

Qué significa: qemu-img check valida la estructura QCOW2. “No errors” es lo que quieres. Si ves errores de refcount, es una señal de alarma.

Decisión: Si check reporta corrupción, no importes. Reconviértelo desde el origen. Si la corrupción persiste, sospecha problemas en la cadena de origen o errores de almacenamiento.

Tarea 10: Inspeccionar los metadatos QCOW2 para ver qué obtuviste

cr0x@server:~$ qemu-img info /mnt/convert/disk.qcow2
image: /mnt/convert/disk.qcow2
file format: qcow2
virtual size: 68 GiB (72980889600 bytes)
disk size: 12.4 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Qué significa: Virtual size es 68 GiB, pero disk size es 12.4 GiB: resultado sparse/thin. Excelente para ahorrar espacio; no siempre ideal para rendimiento de escrituras secuenciales si tu carga llenará el disco inmediatamente.

Decisión: Si la carga es una base de datos que asignará mucho en el primer arranque, considera estrategias de preallocación o raw en almacenamiento de bloques.

Tarea 11: Conversión más rápida usando knobs de cache seguros

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 -t none -T none /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk-fast.qcow2
    (0.00/100%)
    (33.21/100%)
    (71.09/100%)
    (100.00/100%)

Qué significa: -t es el modo de cache del origen; -T es el modo de cache del destino. none normalmente evita double-caching y puede reducir sobrecarga. No hace que el almacenamiento lento sea rápido; solo reduce el buffering inútil.

Decisión: Usa esto cuando controlas el host y confías en la pila de almacenamiento. Si escribes a almacenamiento de red inestable, quizá prefieras caches más seguros a costa de velocidad.

Tarea 12: Convertir a raw (a menudo mejor para Proxmox en ZFS/LVM-thin)

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw -t none -T none /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk.raw
    (0.00/100%)
    (25.00/100%)
    (62.50/100%)
    (100.00/100%)

Qué significa: Raw es simple. Sin tablas de metadatos. Sobrecarga mínima. En storage respaldado por bloques, raw frecuentemente gana en latencia y previsibilidad.

Decisión: Si tu objetivo en Proxmox es ZFS zvol o LVM-thin, considera fuertemente importar como raw en esos backends en vez de mantener un archivo QCOW2.

Tarea 13: Convertir con subformato explícito cuando qemu-img lo adivine mal

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 -o subformat=qcow2 /mnt/incoming/vmware-export/disk.vmdk /mnt/convert/disk.qcow2
qemu-img: warning: -o subformat=qcow2 is not supported for output format qcow2

Qué significa: Este es un ejemplo deliberado de “no hagas eso”. qemu-img te dirá cuando intentas opciones sin sentido. La gente copia y pega flags de blogs antiguos; la herramienta no es sentimental.

Decisión: Si no sabes qué hace una opción, no la uses en una ventana de migración. Usa banderas que puedas explicar bajo presión.

Importar en Proxmox como Proxmox lo prefiere

La conversión es solo la mitad del trabajo. Aún necesitas adjuntar el disco correctamente: el bus correcto, el orden de arranque, el tipo de almacenamiento adecuado y un sistema invitado que pueda encontrar su dispositivo raíz.

Tarea 14: Inspeccionar tipos de almacenamiento en Proxmox y elegir el destino correcto

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        100.0G           22.3G           72.6G   22.30%
local-lvm     lvmthin     active        800.0G          312.0G          488.0G   39.00%
zfspool          zfs     active          1.7T           840.0G          860.0G   49.41%

Qué significa: Almacenamientos tipo dir como local pueden contener archivos QCOW2. lvmthin y zfs normalmente quieren volúmenes raw (aunque Proxmox puede almacenar qcow2 en algunos backends; usualmente te arrepentirás en almacenamiento en bloque).

Decisión: Si importas a local-lvm o zfspool, planea importarlo como raw o deja que Proxmox convierta durante la importación.

Tarea 15: Crear la VM vacía (sin disco) y luego importar el disco

cr0x@server:~$ qm create 120 --name vm-imported --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0
created VM 120

Qué significa: Ahora tienes una configuración de VM para adjuntar el disco.

Decisión: Elige VirtIO para la NIC salvo que el SO invitado no tenga controladores. Si es Windows sin controladores VirtIO, planifica inyección de controladores o empieza con e1000 y migra después.

Tarea 16: Importar un archivo QCOW2 al almacenamiento de Proxmox

cr0x@server:~$ qm importdisk 120 /mnt/convert/disk.qcow2 local-lvm
importing disk 'unused0:local-lvm:vm-120-disk-0'...
transferred 0.0 B of 68.0 GiB (0.00%)
transferred 10.2 GiB of 68.0 GiB (15.00%)
transferred 68.0 GiB of 68.0 GiB (100.00%)
Successfully imported disk as 'unused0:local-lvm:vm-120-disk-0'

Qué significa: Proxmox importó en local-lvm y probablemente lo convirtió a un volumen raw internamente. El disco aparece como unused0 hasta que lo adjuntes.

Decisión: Adjúntalo al controlador correcto (VirtIO SCSI para Linux/Windows moderno con controladores; SATA/IDE solo para compatibilidad).

Tarea 17: Adjuntar el disco importado y establecer el orden de arranque

cr0x@server:~$ qm set 120 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-120-disk-0 --boot order=scsi0
update VM 120: -scsihw virtio-scsi-pci -scsi0 local-lvm:vm-120-disk-0 -boot order=scsi0

Qué significa: El disco ahora es el dispositivo de arranque en un controlador VirtIO SCSI, un valor por defecto generalmente bueno para rendimiento y funcionalidades (discard, queueing).

Decisión: Si el invitado no arranca y antes usaba LSI Logic en VMware, prueba --scsihw lsi temporalmente para ponerlo en marcha, luego migra a VirtIO.

Tarea 18: Verificar la configuración de la VM, incluyendo tipo de máquina y BIOS/UEFI

cr0x@server:~$ qm config 120
boot: order=scsi0
cores: 4
memory: 8192
name: vm-imported
net0: virtio=BC:24:11:8A:19:FE,bridge=vmbr0
scsi0: local-lvm:vm-120-disk-0,iothread=1
scsihw: virtio-scsi-pci

Qué significa: Busca bios / efidisk0 faltantes si la VM original usaba UEFI. Si era UEFI en VMware y arrancas con SeaBIOS aquí, espera problemas.

Decisión: Igualar el firmware: si es UEFI, pon --bios ovmf y añade un disco EFI. Si es legacy, mantén SeaBIOS.

Tarea 19: Convertir al vuelo con Proxmox si quieres menos pasos

cr0x@server:~$ qm importdisk 120 /mnt/incoming/vmware-export/disk.vmdk zfspool
importing disk 'unused0:zfspool:vm-120-disk-0'...
transferred 0.0 B of 68.0 GiB (0.00%)
transferred 68.0 GiB of 68.0 GiB (100.00%)
Successfully imported disk as 'unused0:zfspool:vm-120-disk-0'

Qué significa: Proxmox puede importar directamente desde VMDK al almacenamiento elegido, convirtiendo según sea necesario. Esto reduce archivos intermedios y la posibilidad de olvidar limpiar. También concentra el riesgo en el nodo Proxmox que haga el trabajo.

Decisión: Si lo haces, ejecútalo en un nodo con margen y almacenamiento estable. No hagas grandes conversiones en el nodo que ya está al límite con carga de producción.

Ajustes de rendimiento: velocidad sin sabotearte

La velocidad de conversión está determinada por unas pocas y aburridas restricciones: ancho de banda de lectura, ancho de banda de escritura, CPU (para checksums/metadatos) y la disposición del formato de origen. QCOW2 añade sobrecarga de metadatos; las cadenas de snapshots VMDK añaden lecturas aleatorias. Y el almacenamiento en red añade latencia que convierte escrituras secuenciales en una película a cámara lenta.

Sabe qué estás optimizando

• Tiempo de conversión rápido: minimizar overhead de CPU, evitar double caching, escribir secuencialmente en almacenamiento local rápido y luego mover.
• Rendimiento del VM en ejecución: elige el formato final y backend correctos; raw en almacenamiento en bloque normalmente es imbatible.
• Eficiencia de espacio: QCOW2 sparse es bueno; la compresión puede ayudar pero consume CPU y puede perjudicar la latencia después.

Tarea 20: Medir si la CPU es cuello de botella durante la conversión

cr0x@server:~$ pidstat -dru -p $(pgrep -n qemu-img) 1
Linux 6.8.12 (server)  12/28/2025  _x86_64_  (32 CPU)

11:04:12      UID       PID    %usr %system  %CPU   CPU  kB_rd/s kB_wr/s  Command
11:04:13        0     44122   85.00   10.00 95.00     7  980000.00 420000.00 qemu-img

Qué significa: Si %CPU está al máximo y las tasas de I/O están por debajo de lo que el almacenamiento puede, estás limitado por CPU—a menudo debido al manejo de metadatos QCOW2 o la complejidad del formato origen.

Decisión: Si estás saturado de CPU, considera convertir a raw, o convertir en un nodo más potente, o evitar compresión/cifrado. No esperes que flags de cache arreglen un techo de CPU.

Tarea 21: Confirmar espera de I/O cuando la conversión está “lenta”

cr0x@server:~$ iostat -xm 1 3
Linux 6.8.12 (server)  12/28/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.20    0.00    6.11   52.40    0.00   23.29

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         220.0  880000.0     0.0   0.00    1.10  4000.0    160.0  640000.0     0.0   0.00    2.80  4000.0    0.70  78.00

Qué significa: Alto %iowait más alta utilización del dispositivo significa que el almacenamiento es el cuello de botella. Si la util está baja pero iowait alta, sospecha almacenamiento en red o bloqueos/latencia del sistema de ficheros.

Decisión: Mueve la conversión a almacenamiento scratch local más rápido y luego importa. O, si el destino es la parte lenta, elige un backend mejor (local-lvm/zfs en SSD) para la importación.

Tarea 22: Usar una ruta scratch local para evitar escribir QCOW2 sobre NFS

cr0x@server:~$ mount | grep -E 'nfs|cifs'
nas01:/exports/vm-migrations on /mnt/incoming type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

Qué significa: El origen está en NFS. Leer suele estar bien; escribir la salida QCOW2 de vuelta a NFS durante la conversión es donde el rendimiento se jubila prematuramente.

Decisión: Copia el origen localmente primero, convierte localmente y luego importa. Sí, son pasos extra. No, no lo lamentarás.

Tarea 23: Copiar el VMDK localmente preservando sparsidad (cuando aplique)

cr0x@server:~$ rsync -aH --sparse --info=progress2 /mnt/incoming/vmware-export/ /mnt/local-scratch/vmware-export/
         68,000,000,000 100%  720.00MB/s    0:01:30 (xfr#2, to-chk=0/3)

Qué significa: --sparse puede preservar huecos en archivos en sistemas de ficheros que los soportan, lo que importa cuando remuestras imágenes thin.

Decisión: Si el origen es realmente flat/thick, sparse no ayuda. Pero no suele hacer daño; mantenlo en tu memoria muscular de migración estándar.

Tarea 24: Preallocar la salida cuando te importe rendimiento constante de escritura luego

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 -o preallocation=metadata /mnt/local-scratch/vmware-export/disk.vmdk /mnt/convert/disk-prealloc.qcow2
    (0.00/100%)
    (49.00/100%)
    (100.00/100%)

Qué significa: preallocation=metadata asigna metadatos QCOW2 por adelantado, reduciendo cierta churn de asignación más tarde sin preasignar todos los clusters de datos.

Decisión: Usa esto cuando el invitado hará muchas escrituras aleatorias al inicio (bases de datos, servidores de aplicaciones ocupados). Si el espacio es escaso, evita preallocación completa.

Tarea 25: Verificar que no creaste accidentalmente un QCOW2 grueso gigante

cr0x@server:~$ du -h /mnt/convert/disk-prealloc.qcow2
13G	/mnt/convert/disk-prealloc.qcow2

Qué significa: Sigue siendo relativamente pequeño: bien. Si iguala el tamaño virtual, lo hiciste thick.

Decisión: Si lo engrosaste sin querer, vuelve a convertir con las opciones correctas o considera raw en almacenamiento de bloques en su lugar.

Tarea 26: Confirmar expectativas de discard/TRIM (para backends thin)

cr0x@server:~$ qm set 120 --scsi0 local-lvm:vm-120-disk-0,discard=on
update VM 120: -scsi0 local-lvm:vm-120-disk-0,discard=on

Qué significa: Activa discard desde el invitado (cuando es compatible). En backends thin, esto puede devolver bloques liberados. En algunas pilas no hace nada; en otras ayuda a mantener el pool saludable.

Decisión: Actívalo para invitados Linux con fstrim y kernels modernos. Para algunas configuraciones de Windows, valida el comportamiento antes de asumir que funciona.

Broma #2: Activar todas las banderas de “rendimiento” a la vez es como añadir ocho alerones a un sedán—técnicamente modificado, sigue siendo lento, ahora más ruidoso.

Guía de diagnóstico rápido (encuentra el cuello de botella en minutos)

Este es el orden que uso cuando la conversión o el rendimiento al primer arranque se ven mal. Evita madrigueras y te lleva a una respuesta concreta de “es CPU / es almacenamiento / es red / es configuración del invitado” rápidamente.

Primero: prueba que la imagen origen sea coherente

1. qemu-img info sobre el VMDK. Si falla, detente; arregla descriptor/extent/snapshots.
2. Lista del directorio para archivos delta faltantes o extents renombrados.
3. Si existe cadena de snapshots, identifica el descriptor activo (el que usó la VM) y asegúrate de que todos los padres existan.

Segundo: localiza el límite de throughput

1. Haz una línea base de la velocidad de escritura del destino con fio o al menos observa iostat -xm.
2. Comprueba si la conversión está limitada por CPU con pidstat.
3. Si el origen es almacenamiento en red, cópialo localmente y reintenta la conversión para separar la red de la sobrecarga de conversión.

Tercero: valida la salida y la adhesión en Proxmox

1. qemu-img check sobre el QCOW2 (o verifica tamaño raw y checksums si puedes).
2. qm config: controlador correcto, orden de arranque, BIOS/UEFI coincidente.
3. Controladores del invitado: ¿están presentes VirtIO para almacenamiento/NIC? Si no, espera fallos de arranque o NICs faltantes.

Tarea 27: Confirma si estás limitado por CPU o I/O de un vistazo

cr0x@server:~$ top -b -n 1 | head -n 15
top - 11:06:01 up 10 days,  2:14,  2 users,  load average: 9.12, 8.44, 7.90
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s): 61.3 us,  7.2 sy,  0.0 ni,  8.4 id, 23.1 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem : 128000.0 total,  24000.0 free,  12000.0 used,  92000.0 buff/cache
MiB Swap:  16000.0 total,  15950.0 free,     50.0 used. 108000.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
44122 root      20   0  221668  29384   6120 R  298.0   0.0   1:22.19 qemu-img

Qué significa: CPU alta (qemu-img usando múltiples cores) más wa alta significa que estás limitado por ambos; lanzar flags a qemu-img no arreglará un disco lento.

Decisión: Mueve el trabajo a almacenamiento más rápido o prográmalo cuando el almacenamiento esté tranquilo. Si no es posible, convierte a raw y deja que el backend gestione la asignación.

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

Esta sección está escrita en el lenguaje del on-call: qué ves, qué normalmente significa y qué funciona realmente.

1) qemu-img: “Could not open ‘…’: invalid VMDK descriptor”

Síntomas: qemu-img info o convert falla inmediatamente con errores de parsing del descriptor.

Causa raíz: El archivo descriptor está corrupto, editado incorrectamente, problemas de newline/encoding, o referencia una extensión missing/renombrada.

Arreglo:

• Abre el descriptor y verifica que el nombre de extent coincida con lo que hay en disco.
• Asegúrate de que la extensión flat exista y sea legible.
• Si el descriptor se perdió pero tienes *-flat.vmdk, reconstruye un descriptor (con cuidado) o reexporta desde VMware.

2) La conversión “tiene éxito” pero la VM arranca en initramfs / no encuentra el dispositivo raíz

Síntomas: Linux cae a un shell de emergencia; el dispositivo raíz no coincide tras la importación.

Causa raíz: El controlador de disco cambió (p. ej. VMware LSI Logic a Proxmox VirtIO SCSI) y el initramfs no tiene los controladores, o fstab usa nombres de dispositivo que cambiaron (sda vs vda).

Arreglo:

• Cambia temporalmente el controlador a uno más compatible (p. ej. LSI) para arrancar, luego instala controladores VirtIO y reconstruye initramfs.
• Usa UUIDs en fstab y la configuración del bootloader si es posible.

3) Windows hace BSOD después de la importación (INACCESSIBLE_BOOT_DEVICE)

Síntomas: BSOD en el arranque justo después de importar en Proxmox.

Causa raíz: Windows no tiene el controlador del controlador de almacenamiento para el nuevo controlador virtual (VirtIO SCSI), o desajuste en modo de arranque (UEFI vs BIOS).

Arreglo:

• Arranca con un controlador que Windows soporte de serie (SATA, LSI) primero.
• Instala los controladores VirtIO dentro de Windows y luego cambia al controlador VirtIO.
• Asegura que el modo de firmware coincida y el orden de arranque sea correcto.

4) La conversión es dolorosamente lenta en NFS/CIFS

Síntomas: Conversión a decenas de MB/s a pesar de discos locales rápidos.

Causa raíz: Escribir la salida en almacenamiento de red con alta latencia; las actualizaciones de metadatos QCOW2 amplifican pequeñas escrituras.

Arreglo: Escenifica localmente (NVMe scratch), convierte localmente, luego importa al backend final. Si debes escribir sobre la red, prefiere raw y E/S más grandes, y acepta que puede seguir siendo lento.

5) El disco importado aparece como “unused0” y la VM no arranca

Síntomas: El disco existe en el almacenamiento de Proxmox pero no está adjunto como dispositivo de arranque.

Causa raíz: qm importdisk importa pero no adjunta; no se estableció el orden de arranque.

Arreglo: Adjunta el disco con qm set y establece --boot order=....

6) El tamaño del disco se ve mal después de la conversión

Síntomas: El archivo QCOW2 tiene tamaño igual al virtual cuando esperabas thin, o viceversa.

Causa raíz: Opciones de preallocación, el origen era un flat thick, o la ruta de conversión expandió datos (bloques cero escritos como asignados).

Arreglo: Reconvierte con las opciones deseadas; para destinos thin asegúrate de usar métodos de copia que preserven sparsidad y evita herramientas que des-sparsifiquen (algunas copias ingenuas lo hacen).

7) “Failed to get write lock” / “image is in use” durante la conversión

Síntomas: qemu-img se niega a escribir o Proxmox no puede arrancar la VM.

Causa raíz: El disco está abierto por otro proceso (trabajo de backup, otra conversión, una VM que todavía lo referencia).

Arreglo: Identifica el proceso que mantiene el archivo/volumen y detenlo; evita convertir in situ en un datastore activo.

Tarea 28: Encontrar quién tiene un archivo de disco abierto (clásico “¿por qué está bloqueado?”)

cr0x@server:~$ lsof /mnt/convert/disk.qcow2 | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
qemu-img 44122 root    3u   REG   8,17 13314398624 131073 /mnt/convert/disk.qcow2

Qué significa: El archivo está abierto activamente por qemu-img. Si ves qemu-system-x86_64, una VM lo está usando.

Decisión: No luches con locks. Para el consumidor limpiamente, luego procede.

Tres micro-historias corporativas (porque al disco no le importan tus sentimientos)

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

El equipo tenía una exportación de VMware: un bonito server.vmdk en una carpeta compartida. Alguien copió solo ese archivo al nodo Proxmox e inició qemu-img convert. qemu-img se quejó de extents faltantes. Encogieron de hombros y reexportaron, obtuvieron lo mismo, y decidieron que la herramienta era “quisquillosa”.

La suposición equivocada fue simple: pensaron que un VMDK siempre es autocontenible. En su entorno, ESXi guardaba un archivo descriptor más una gigantesca extensión flat, y su flujo de exportación preservaba ambos—pero solo el descriptor parecía “importante”. El gran -flat.vmdk estaba al lado como un cómplice silencioso.

Finalmente copiaron también la extensión flat, y la conversión funcionó. Pero luego la VM arrancó con errores de sistema de ficheros. El daño real ocurrió antes: durante el primer intento, intentaron “arreglar” el descriptor editando el tamaño y el nombre del extent basados en conjeturas, luego convirtieron desde un descriptor que apuntaba a una extensión flat diferente de una exportación anterior. La conversión fue precisa—precisa sobre la fuente equivocada.

La solución no fue heroica. Reempezaron desde la exportación original, verificaron la referencia de extent en el descriptor, comprobaron los checksums de ambos archivos y solo entonces hicieron la conversión. El downtime fue mayor del necesario, y la lección fue vergonzosamente barata: nunca edites metadatos de imagen salvo que puedas probar lo que haces.

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

Un grupo distinto ejecutaba migraciones nocturnas para refrescar un laboratorio. Querían velocidad. Encontraron un puñado de flags online y construyeron un wrapper “turbo convert”: modos de cache agresivos, jobs paralelos y escribir directamente a un share de red para “evitar copias extra”.

Era rápido—hasta que dejó de serlo. Algunas conversiones produjeron QCOW2 que pasaban un qemu-img info superficial pero luego fallaban bajo carga con advertencias de corrupción. Otras arrancaban bien pero tenían errores sutiles en las aplicaciones que parecían bugs. Las migraciones se convirtieron en una pesadilla de soporte: cada VM importada era sospechosa.

El problema fue sobre todo la semántica de durabilidad. Mezclaron opciones de caching con el comportamiento de almacenamiento en red y trataron “conversión terminada” como “bytes seguros en disco”. Hicieron falta fallos de red y caches servidor-side para que el trabajo pudiera completar mientras el almacenamiento no había comprometido todo lo que el equipo asumía.

Hicieron rollback del wrapper. El nuevo proceso parecía más lento en papel pero terminó más rápido de extremo a extremo porque dejó de producir artefactos rotos: escenificar localmente, convertir localmente con cache conservador, validar con qemu-img check y luego importar. La mejor optimización fue eliminar el re-trabajo.

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

Un sistema cercano a finanzas se migraba de VMware a Proxmox con una ventana ajustada. El equipo hizo algo profundamente poco fashion: escribieron una checklist y la siguieron. No una lista “agradable de tener”. Una checklist con puertas que se negaban a avanzar hasta que cada paso produjo la salida esperada.

Capturaron qemu-img info en JSON para cada origen, lo guardaron con el ticket de migración y registraron la configuración de VM en Proxmox tras la importación. También ejecutaron qemu-img check en cada artefacto QCOW2 y conservaron el log. Fue tedioso, como suelen ser las buenas operaciones.

Durante el corte, una VM no arrancó. Sin pánico. Compararon el tipo de adaptador VMware en el descriptor (lsilogic) con la configuración de Proxmox (VirtIO SCSI). Cambiaron el controlador a LSI, arrancaron, instalaron controladores VirtIO, cambiaron de nuevo y siguieron. La checklist no evitó el problema, pero evitó el caos.

Lo que salvó el día no fue un comando ingenioso. Fue observabilidad disciplinada: cada paso dejó evidencia. Cuando algo falló, no adivinaron—compararon.

Listas de verificación / plan paso a paso

Usa uno de estos según tu backend de almacenamiento y apetito por archivos intermedios.

Plan A: Seguro y portable (VMDK → QCOW2 archivo → import)

1. Inventario de archivos: asegúrate de tener descriptor + extensión flat (o un VMDK monolítico).
2. Ejecuta qemu-img info en el origen; confirma virtual size y extents.
3. Comprueba espacio libre en el filesystem de conversión (planificación peor caso).
4. Escenifica localmente si origen/destino es almacenamiento en red.
5. Convierte con flags conservadores: qemu-img convert -p -f vmdk -O qcow2.
6. Ejecuta qemu-img check -r all sobre el QCOW2.
7. Crea la VM vacía en Proxmox: qm create.
8. Importa el disco: qm importdisk al almacenamiento elegido.
9. Adjunta el disco y establece orden de arranque: qm set.
10. Validación primer arranque: confirma que el SO ve el disco, la NIC funciona, sincronización horaria y servicios arrancan.

Plan B: Centrado en Proxmox (importar directamente desde VMDK)

1. Verifica el VMDK origen con qemu-img info.
2. Crea la VM vacía con la expectativa correcta de firmware (UEFI vs BIOS según lo que sepas).
3. Ejecuta qm importdisk VMID disk.vmdk STORAGE.
4. Adjunta el disco con el controlador correcto y establece orden de arranque.
5. Arranca, valida y luego ajusta opciones de rendimiento (iothread, discard, cache) con cuidado.

Plan B está bien para migraciones rutinarias cuando confías en la salud del nodo Proxmox y quieres menos artefactos que gestionar. Plan A es mejor cuando necesitas un QCOW2 portable y un rastro de auditoría repetible.

Tarea 29: Capturar un “registro de conversión” reproducible (rastro de auditoría barato)

cr0x@server:~$ qemu-img info --output=json /mnt/incoming/vmware-export/disk.vmdk | tee /mnt/convert/disk.vmdk.info.json
{
    "virtual-size": 72980889600,
    "filename": "/mnt/incoming/vmware-export/disk.vmdk",
    "format": "vmdk",
    "actual-size": 72980889600,
    "format-specific": {
        "type": "vmfs",
        "cid": 4294967294,
        "parent-cid": 4294967295
    }
}

Qué significa: Has guardado un registro legible por máquina de lo que convertiste. Así evitas “¿qué importamos exactamente?” dos semanas después.

Decisión: Guarda estos registros con los tickets de cambio. Es aburrido. Funciona.

Tarea 30: Confirmar que el disco importado existe en el almacenamiento objetivo

cr0x@server:~$ pvesm list local-lvm | grep vm-120-disk-0
local-lvm:vm-120-disk-0  vm-120-disk-0  68.00G

Qué significa: El volumen está presente y con el tamaño correcto.

Decisión: Si el tamaño es incorrecto, detente e investiga antes de arrancar. Un tamaño erróneo puede indicar que importaste el archivo equivocado o que hay truncado de datos.

Tarea 31: Arranca la VM y observa el arranque temprano desde el host

cr0x@server:~$ qm start 120
started VM 120

Qué significa: VM lanzada. Ahora necesitas visibilidad de consola.

Decisión: Si falla instantáneamente, revisa logs de tareas de Proxmox y errores de almacenamiento. Si arranca pero no bootea, verifica desajuste de firmware/controlador.

Una cita que pertenece a todo runbook de migración

La esperanza no es una estrategia. — General Gordon R. Sullivan

Preguntas frecuentes

1) ¿Debo convertir a QCOW2 o raw para Proxmox?

Si tu almacenamiento objetivo es dir/NFS y quieres un archivo portable, QCOW2 está bien. Si tu objetivo es LVM-thin o ZFS, raw suele ser más rápido y sencillo. Si insistes en QCOW2 sobre almacenamiento en bloque, pagarás sobrecarga por funciones que probablemente no uses.

2) ¿Proxmox puede importar un VMDK directamente?

Sí, qm importdisk puede importar desde VMDK a un destino de almacenamiento de Proxmox, convirtiendo según sea necesario. Es cómodo, pero no elimina la necesidad de validar el origen y adjuntar el disco correctamente.

3) ¿Por qué qemu-img dice “invalid VMDK descriptor”?

Con frecuencia el descriptor referencia una extensión flat que falta, fue renombrada o está en otra ruta. A veces el descriptor está corrupto o fue editado incorrectamente. Valida el nombre del extent y asegúrate de que el archivo flat esté presente.

4) Mi disco convertido arranca pero faltan datos. ¿Cómo puede ser?

Probablemente convertiste la capa equivocada de una cadena de snapshots (un padre en lugar del hijo activo), o no incluiste todos los archivos delta. Las cadenas de snapshots de VMware deben estar completas y consistentes para que la conversión represente el estado actual.

5) ¿Por qué la conversión es más lenta que copiar el archivo?

La conversión puede implicar actualizaciones de metadatos (QCOW2), lecturas aleatorias (cadenas de snapshots) o amplificación de latencia de red (escribir QCOW2 en NFS). Copiar suele ser secuencial y más simple.

6) ¿Debo preocuparme por UEFI vs BIOS durante la importación?

Sí. Si la VM era UEFI en VMware y la arrancas con BIOS legacy en Proxmox, puedes obtener un sistema no arrancable que parezca “problemas de disco” cuando no lo es. Igualar el firmware desde el principio.

7) ¿Cuál es el paso de verificación más seguro tras la conversión?

Ejecuta qemu-img check -r all para integridad estructural de QCOW2 y luego haz un arranque de prueba en una red aislada. Las comprobaciones de integridad no detectarán todas las inconsistencias a nivel de sistema de ficheros, pero sí corrupción a nivel de imagen.

8) ¿Puedo acelerar la conversión usando compresión en QCOW2?

Puedes, pero es un trade-off. La compresión consume CPU y puede perjudicar la latencia de I/O aleatorio después. Para VMs de producción, prefiero comprar almacenamiento antes que asumir latencia misteriosa.

9) Mi VM Windows no arranca con VirtIO. ¿Cuál es el camino menos doloroso?

Arranca con un controlador que Windows soporte de serie (a menudo SATA/LSI), instala los controladores VirtIO y luego cambia a VirtIO SCSI. Hazlo en pasos controlados, no todo de una vez.

10) ¿Debo convertir en el nodo Proxmox o en otro sitio?

Convierte donde tengas I/O estable y margen. Si los nodos Proxmox están ocupados, usa un host de conversión dedicado y luego importa. La mejor migración es la que no compite con cargas de producción.

Siguientes pasos prácticos

Haz la migración como harías un cambio de almacenamiento en producción: identifica lo que tienes, elige el formato correcto para el backend, ejecuta la conversión con flags que entiendas y valida antes de arrancar. Evita los “atajos de velocidad” hasta que hayas probado dónde está el cuello de botella.

Pasos siguientes que rinden inmediatamente:

• Ejecuta qemu-img info en cada VMDK que planees migrar y guarda la salida JSON con el ticket.
• Elige primero tu almacenamiento final (dir vs LVM-thin vs ZFS), luego decide QCOW2 vs raw en consecuencia.
• Adopta la guía de diagnóstico rápido: coherencia del origen → límite de throughput → adhesión en Proxmox.
• Estandariza un patrón de conversión por backend y deja de improvisar durante las ventanas de cambio.