El asistente de importación de ESXi copia lo provisionado, no lo que usas

Hay un hilo corto en el foro de Proxmox con tres cifras del mismo caso que explican, mejor que ningún manual, por qué una migración de VMware se come la ventana de mantenimiento. Un disco virtual de 5 TB. Dentro, 255 GB ocupados de verdad. La importación con el asistente de ESXi: ocho horas largas, por un enlace de 1 Gbit. Y en el destino, un ZFS, la máquina acabó ocupando 260 GB. Las tres cifras son compatibles, y juntas dicen lo mismo: el asistente no dimensiona tu migración por tus datos, la dimensiona por tu provisión. Los ceros no ocupan disco en el destino. Ocupan ventana.

La cuarta cifra la ponemos nosotros y va declarada como tal, porque es aritmética de servilleta: un gigabit mueve unos 112 MB/s con suerte, o sea del orden de 0,4 TB por hora. A ese caudal, 255 GB son unos 38 minutos. La ventana real de ese caso fue de ocho horas. Doce veces más larga que el volumen de datos que había que mover, con la máquina apagada todo ese rato.

Por qué pasa: la API no dice qué bloques están escritos

La explicación la da en el mismo hilo Falk R., miembro distinguido del foro y suscriptor de Proxmox, el 29 de enero de 2026, y son dos frases: «Das Problem ist die vSphere API. Die liefert das Storage, aber keine Thin Provisioning Informationen.» El problema es la API de vSphere: entrega el almacenamiento, pero no la información de aprovisionamiento fino. Traducido a lo que significa para ti: el asistente puede preguntar «¿cuánto mide este disco?» y recibe 5 TB; no puede preguntar «¿cuáles de estos bloques tienen algo escrito?». Así que pide el rango lógico entero y por el cable viaja también lo que no hay.

Conviene ser honestos con el límite de la cuenta. Cinco terabytes a 0,4 TB/h serían doce horas y media, y aun a tasa de línea perfecta —125 MB/s— serían once, y el caso tardó ocho, así que por el cable no cruzaron los 5 TB completos: cruzó algo que está entre los 255 GB reales y los 5 TB nominales, del orden de los terabytes y no de los gigabytes. No sabemos el reparto exacto y no lo vamos a inventar. Lo que sí queda establecido con las cifras del propio caso es la dirección del error: quien planificó con el número de «ocupado» se equivocó por un factor largo.

La cuenta que hay que hacer antes de prometer una fecha

La estimación es una división, y lo único que hay que acertar es el numerador: el tamaño provisionado. Para el denominador van estos caudales realistas, que no son tasas de línea —sirven para encuadrar el orden de magnitud, no para firmar un SLA—:

En una migración de discos gordos y vacíos, la ventana la fija el puerto de red del ESXi viejo. Los NVMe recién comprados en el destino no la tocan. Si puedes meter el host de origen en un enlace de 10 Gbit un fin de semana, eso vale más que cualquier ajuste del almacenamiento nuevo.

Dos facturas: una se esquiva y la otra no

Lo provisionado que no existe se cobra dos veces, y las dos facturas son independientes. La factura de capacidad la paga el destino, y se puede esquivar: la documentación de Proxmox lo dice en una línea —«With thin provisioning activated, only the blocks that the guest system actually use will be written to the storage»—, de modo que si el destino es de los que absorben los ceros, los 5 TB aterrizan como 260 GB, que es exactamente lo que le pasó al autor del hilo con ZFS. La factura de tiempo no la absorbe nadie. La paga la ventana de parada, y por tanto la paga el negocio.

Qué destinos absorben los ceros: la regla que da el manual es que todo almacenamiento con instantáneas soporta aprovisionamiento fino, lo que deja dentro a LVM-thin, ZFS, Ceph/RBD, BTRFS y a los almacenamientos de ficheros —directorio local, NFS, CIFS— cuando el disco se guarda en qcow2. El LVM clásico con raw, no: ahí una importación de 5 TB reserva 5 TB. Es el error más caro y el más fácil de cometer, porque raw suena a «sin florituras» y en bloque significa «entero». El manual de migración ofrece el parámetro --format con raw, vmdk y qcow2, pero con una letra pequeña que conviene leer: «If the target storage stores the disk images as files…». Esa opción solo existe si el destino guarda las imágenes como ficheros, o sea nunca en LVM clásico. Ahí la elección se hace antes, eligiendo otro destino.

Y el aviso que va pegado a esa ventaja, también literal de la documentación: «If a storage runs full, all guests using volumes on that storage receive IO errors. This can cause file system inconsistencies and may corrupt your data.» Absorber los ceros es un préstamo, no un regalo. Una migración entera de discos sobreprovisionados aterriza en el destino como una sobreventa que hay que vigilar con una alerta de ocupación, no con buena voluntad.

El número con el que se planifica no es el que todo el mundo mira

En el inventario de vSphere hay dos columnas y hacen falta las dos. UsedSpaceGB es lo que la máquina ocupa de verdad en el almacén, y ProvisionedSpaceGB es lo que se le prometió: los VMDK, más las instantáneas, más el fichero de intercambio si la memoria no está reservada, más los registros. En discos gruesos las dos columnas coinciden; la diferencia entre ellas es, literalmente, el tamaño de tu problema. Un inventario de planificación cabe en una línea:

Get-VM | Select-Object Name, ProvisionedSpaceGB, UsedSpaceGB,
  @{N='Ratio';E={if ($_.UsedSpaceGB) { [math]::Round($_.ProvisionedSpaceGB / $_.UsedSpaceGB, 1) }}},
  @{N='Snaps';E={(Get-Snapshot -VM $_).Count}} |
  Sort-Object ProvisionedSpaceGB -Descending

Ordena por provisionado descendente y mira las cinco primeras filas: esas cinco máquinas son tu calendario de migración. Un matiz que conviene no saltarse: UsedSpaceGB es la ocupación observada en el almacén de datos, no la ocupación del sistema de ficheros de dentro; un Windows que borró 300 GB sin recortar sigue contándolos como escritos. Es una medida de lo que hay que mover, no de lo que hay que guardar.

La columna de instantáneas está ahí por dos razones que van juntas: las instantáneas entran en el provisionado y además el manual de Proxmox avisa de que la importación «can be significantly slower if the VM has snapshots». O sea que el mismo delta te penaliza dos veces, por tamaño y por lentitud. Si una máquina lleva seis meses con una instantánea olvidada «por si acaso», ese «por si acaso» ya tiene precio y se paga en la madrugada del sábado.

Lo que no lo arregla

El reflejo natural es vaciar antes: recortar dentro del invitado con fstrim y perforar el VMDK con vmkfstools -K para que el fichero se quede en lo que de verdad ocupa. Es buena higiene y conviene hacerlo de todos modos. Un usuario del hilo largo del asistente lo reportó en abril de 2024, cuando el importador acababa de salir: ni el fstrim dentro del invitado ni el vmkfstools -K sobre el VMDK le acortaron la importación. Encaja con la causa: recortar cambia el fichero, y lo que falta es que la API sepa contarlo. Mientras el interfaz no devuelva el mapa de bloques, ordenar la casa no acorta la mudanza. Falk R. lo cierra en su propio mensaje: «Da gibt es keinen Workaround, außer eine andere Methode zu nutzen.» No hay rodeo; hay otro método. En el hilo largo se pide además que el asistente hable con vCenter para transferir solo el tamaño consumido, como ya hacen algunas herramientas de copia; hoy eso sigue siendo una petición abierta.

La criba que va antes de la división

No todas las máquinas entran en la cuenta de horas, porque no todas pasan por el asistente: discos sobre vSAN, discos cifrados por política de almacenamiento y nombres de almacén con caracteres como el + quedan fuera, y las limitaciones del manual una por una ya las repasamos en el disco llega entero y Windows no arranca. Lo que añade este caso es cuándo se hace esa criba: antes de la división, no después de haber dado una fecha al comité. Una máquina en vSAN necesita otro camino entero y no simplemente más horas, y descubrirlo el día de la migración es la diferencia entre una noche larga y una noche en blanco.

La alternativa para la máquina gorda y vacía

Para esos casos el manual documenta un método distinto, «Attach Disk & Move Disk (minimal downtime)», cuya gracia es que mueve el disco con la máquina ya encendida en Proxmox. El resumen: se crea un almacenamiento en Proxmox que apunte al recurso de red donde vive el VMDK, con el tipo de contenido Disk Image activado; se crea una VM destino lo más parecida posible a la de origen; se hace que el descriptor apunte al -flat.vmdk original por ruta relativa; se apaga la máquina en VMware; se arranca en Proxmox; y con ella funcionando se usa Disk Action → Move Storage para llevarse el disco al almacenamiento definitivo. La parada se reduce al tiempo de arrancar la máquina.

Las pegas, que son reales: exige un almacén accesible desde los dos hipervisores, se editan ficheros descriptores a mano y durante un rato la máquina de Proxmox está leyendo de un disco que físicamente sigue en el almacén de VMware. Y lleva pegado el aviso que el manual pone en negrita y que resume la única forma de destrozar datos en este procedimiento: «Make sure that the VM is only powered on in either Proxmox VE or VMware, but never at the same time in both to avoid disk corruption!» Con este método, la lista de comprobación de la migración empieza y acaba con una pregunta tonta: ¿quién ha confirmado que está apagada ahí?

Si tus discos son gruesos, cierra esta pestaña

Si tus discos son gruesos, la ratio entre provisionado y ocupado es uno y aquí no hay nada que optimizar: la ventana es la que es y la cuenta de la tabla ya es correcta. Si tus máquinas son de 80 GB, la diferencia entre lo provisionado y lo usado es ruido y no merece ni una reunión; monta el asistente y a otra cosa. Y dos cosas que no recomendamos aunque acorten la ventana: no reduzcas discos virtuales en caliente para ahorrar horas de copia —cambiar la geometría de un disco con datos es elegir tú mismo la avería que querías evitar—, y no muevas la máquina gorda por el asistente a las tres de la madrugada «porque con las pequeñas funcionó». Las pequeñas funcionaron porque eran pequeñas.

Los cuatro pasos antes de dar la fecha

En este orden, antes de que nadie escriba una fecha en un correo:

1. El inventario con las dos columnas y la ratio, ordenado por provisionado, más el recuento de instantáneas.
2. La criba de las que no pasan por el asistente, con su camino alternativo decidido por escrito.
3. La división, con el caudal medido en una máquina pequeña de prueba en vez de con la tasa de línea del cable.
4. La elección del destino según si tiene que absorber ceros, con la alerta de ocupación puesta antes de empezar.

Una nota sobre el paso cuatro: si el destino es un clúster Ceph, los discos entran finos de serie y el reparto por nodos empieza a trabajar en cuanto aterrizan, así que el mismo rato de copia también coloca la redundancia. La contrapartida es que con réplica 3 cada gigabyte que aterriza se escribe tres veces dentro del clúster: la red de Ceph entra en la cuenta de la ventana igual que la del origen. Decidir eso antes de la migración, y no durante, es parte de lo que hacemos en una migración de VMware a Proxmox. Los otros dos sitios donde este tipo de migración se tuerce los hemos contado en el disco llega entero y Windows no arranca y en el plan de vuelta atrás.

No vendemos licencias de VMware ni de Proxmox, así que lo que hay aquí es una advertencia de planificación. El asistente de importación de ESXi es una herramienta buena y gratuita que ha hecho posibles muchísimas migraciones. Lo que pasa es que te cobra la ventana en una moneda —provisión— distinta de la que miras en el inventario —ocupación—.

Fuentes (verificadas): el caso de las tres cifras —disco de 5 TB, «ca. 255 GB belegt», «gut 8h (1 Gbit)» y 260 GB en el ZFS de destino— y la cita de Falk R. (29-ene-2026) sobre la API de vSphere, hilo ESXi Import thin provision del foro de Proxmox; el reporte de un usuario (abr-2024) de que recortar dentro del invitado y perforar el VMDK no acortaron su importación, y la petición de hablar con vCenter para transferir solo lo consumido, hilo del asistente de importación; limitaciones del asistente (vSAN, discos cifrados por política, caracteres especiales en el nombre del almacén, lentitud con instantáneas, versiones probadas 6.5–8.0), método «Attach Disk & Move Disk (minimal downtime)», el aviso de no encender la VM en los dos sitios y las opciones de --format — wiki Migrate to Proxmox VE; definición de aprovisionamiento fino, lista de almacenamientos que lo soportan y aviso sobre el almacenamiento lleno — documentación de almacenamiento de Proxmox VE; contenido de ProvisionedSpaceGB y UsedSpaceGB — documentación y comunidad de VMware PowerCLI. Los caudales de la tabla, los 38 minutos, las doce horas y media y el factor doce son aritmética nuestra sobre caudales realistas, redondeados a propósito y válidos solo como orden de magnitud: lo que de verdad cruzó el cable en el caso citado está entre los 255 GB y los 5 TB, y no lo sabemos con precisión.