Migrar de VMware a Proxmox con el asistente de importación de ESXi: la guía completa

Un vistazo en 33 segundos

• Desde Proxmox VE 8.2 (24 de abril de 2024) el importador de VMware va integrado: el host ESXi se añade como un almacenamiento más, se elige la VM y se pulsa Import. Nada de ovftool, ni de copiar VMDK a mano, ni de qemu-img.
• Proxmox lo tiene probado con ESXi 6.5 a 8.0, y quiere que conectes al host, no al vCenter: a través de vCenter va entre 5 y 10 veces más lento.
• No importa discos en vSAN, discos cifrados ni el estado del vTPM, y con snapshots va mucho más despacio. Todo eso se resuelve en VMware, antes.
• La importación en vivo arranca la VM en Proxmox mientras los discos se copian por detrás. Acorta la parada, pero si falla a medias se pierde lo escrito desde el inicio.
• Windows necesita los drivers VirtIO y un cambio de bus con truco; Linux, revisar el nombre de la interfaz de red. Los dos, el QEMU Guest Agent.
• Para migrar decenas de máquinas está qm import en consola. Y una regla que no aparece en el asistente: no más de cuatro discos a la vez.

---

Hay muchas guías de migración de VMware a Proxmox y casi todas cuentan lo mismo: exporta la máquina a OVF, súbela al nodo, conviértela y cruza los dedos. Ese camino sigue existiendo, pero desde hace más de dos años ya no es el principal. Proxmox VE incorpora un asistente de importación que habla directamente con la API de ESXi, lista las máquinas del host y las trae con su configuración traducida, sin copias intermedias. Fue la novedad estrella de la versión 8.2 y en las 9.x sigue recibiendo arreglos en cada release.

Esta guía va de eso: de cómo se usa el asistente de verdad, botón a botón, qué hay que dejar hecho en VMware antes de tocarlo, qué te vas a encontrar al arrancar la máquina en Proxmox y cómo se pasa de migrar una VM a migrar cincuenta. Si lo que buscas es decidir si migrar y cómo planificar el proyecto, eso ya lo tratamos en la guía de planificación, en la cuenta real de lo que cuesta y en los casos en los que conviene esperar. Aquí damos por hecho que la decisión está tomada.

Qué es el asistente de importación y qué te ahorra

El importador está construido como un plugin de almacenamiento. Al añadir un origen de tipo ESXi, Proxmox instala un servicio (esxi-folder-fuse, del paquete pve-esxi-import-tools) que monta los datastores del host como si fueran carpetas locales. Desde ahí lee el fichero .vmx de cada máquina, traduce la configuración al modelo de Proxmox y copia los discos VMDK al almacenamiento de destino convirtiéndolos al vuelo al formato que toque, qcow2, raw o el que use tu ZFS, LVM o Ceph.

Lo que cambia respecto al método clásico es el número de copias. Con ovftool los datos salían de ESXi a un sitio intermedio y de ahí a Proxmox, con espacio de staging y dos veces el tiempo de transferencia. Con el asistente van del datastore de VMware al almacenamiento de Proxmox en un solo salto.

Lo que el asistente traduce solo y lo que no:

Antes de tocar Proxmox: deja la VM lista en ESXi

Lo que más fallos da después no se arregla en Proxmox, se evita en VMware. La lista, por orden:

1. Documenta la máquina. vCPU, memoria, discos y en qué datastore están, tarjetas de red con su MAC y su port group o VLAN, si arranca en BIOS o UEFI, y la configuración IP del sistema operativo si es estática. Vas a necesitar cada dato al otro lado.
2. Desinstala VMware Tools con la máquina todavía en ESXi. Después se puede, pero el desinstalador se queja de que no está en VMware y toca limpiar a mano. Tenemos el procedimiento completo y un script prudente para Windows. En Linux, apt purge open-vm-tools o su equivalente.
3. Elimina los snapshots. Proxmox avisa de que una VM con snapshots se importa «significativamente más despacio», y en el foro aparecen como causa recurrente de importaciones que fallan. Consolida y deja el disco plano.
4. En Windows, deja instalados los drivers VirtIO. Descarga la ISO virtio-win y ejecuta el instalador virtio-win-guest-tools mientras la máquina sigue en VMware: deja los drivers de disco, red y balloon en el almacén de controladores, más el QEMU Guest Agent. Con eso hecho, bastantes máquinas arrancan en Proxmox directamente con VirtIO SCSI, pero Windows solo activa el driver de arranque de un controlador que ya ha visto, así que no lo des por hecho: pruébalo con una VM de laboratorio y ten a mano el procedimiento del disco temporal.
5. En Linux, asegúrate de que el initramfs lleva los módulos VirtIO. En Debian y Ubuntu van de serie. En la familia RHEL (Rocky, Alma, Oracle) dracut genera el initramfs solo con los drivers del hardware presente, y en VMware eso significa vmw_pvscsi y vmxnet3, no virtio_scsi. Regenéralo antes de apagar: dracut -f --add-drivers "virtio_pci virtio_blk virtio_scsi virtio_net".
6. Red. Si la IP es estática, anótala y, en Windows, valora quitarla antes: al aparecer una tarjeta nueva, Windows protesta si le pones la misma IP que tenía la anterior, aunque ya no exista. Si usas reservas DHCP, o mantienes la MAC en la importación o actualizas la reserva.
7. Cifrado de disco y vTPM. Proxmox no puede traer el estado del TPM virtual. Si la máquina usa BitLocker con las claves en el vTPM, suspende BitLocker o desactívalo, guarda las claves de recuperación y quita el vTPM. Los discos cifrados por política de almacenamiento de vSphere tampoco se importan: quita la política antes.
8. Apaga la VM. El asistente detecta si sigue encendida y avisa de que la importación puede fallar o quedar inconsistente. No lo ignores.

Paso 1: conectar el host ESXi como un almacenamiento más

En la interfaz de Proxmox ve a Datacenter → Storage → Add y elige ESXi, la última opción del desplegable. Es la que ves en la captura de cabecera: el importador se comporta como un tipo de almacenamiento, al lado de NFS, Ceph o Proxmox Backup Server.

El diálogo de conexión, en nuestro laboratorio. Cuatro campos y una casilla.

• ID: un nombre para el origen, con letras, como esxi-lab o pruebas-cvi-esxi. Aparecerá en el árbol de recursos y en la ruta que usarás luego en consola.
• Server: la IP o el nombre del host ESXi, no del vCenter. Proxmox lo permite, pero la propia documentación avisa de que por vCenter el rendimiento «se degrada drásticamente», entre 5 y 10 veces. Si tienes varios hosts, añade cada uno como un origen distinto.
• Username y Password: una cuenta con permisos de administrador en ESXi. root vale; una cuenta dedicada con permisos de administrador, mejor.
• Skip Certificate Verification: márcala si el host usa el certificado autofirmado de fábrica, que es lo habitual. La alternativa es añadir la CA al almacén de confianza del nodo.
• Nodes: a qué nodos del clúster se presenta este origen. Sin restricción, a todos.

Antes de pulsar Add comprueba que el nodo Proxmox llega al puerto 443 del host ESXi; el importador va por la API HTTPS. Si hay un cortafuegos por medio, ábrelo desde la IP del nodo que va a hacer la importación.

Al añadirlo, el origen aparece en el árbol de la izquierda bajo cada nodo, con el contenido de tipo Import. Selecciónalo y verás la lista de máquinas virtuales del host, con su nombre y ruta en el datastore. Si la lista sale vacía, lo primero es mirar los permisos de la cuenta y si hay caracteres raros en el nombre del datastore: un + en el nombre puede hacer que no funcione, y la solución es renombrarlo.

Paso 2: elegir la VM y repasar el asistente

Marca la máquina y pulsa Import (o doble clic). Se abre el asistente con tres pestañas.

General. Es donde se decide lo grueso:

• VM ID y Name. Proxmox propone el siguiente ID libre.
• Sockets, Cores y Memory, leídos del origen.
• CPU Type. El asistente pone el tipo genérico. Si todos los nodos del clúster tienen la misma CPU, host da el máximo rendimiento; si son distintos o vas a ampliar con otros, uno de los modelos x86-64-v2-AES o x86-64-v3, que permiten migración en vivo entre nodos.
• OS Type y Version, para que Proxmox aplique los valores por defecto adecuados.
• Default Storage, el almacenamiento donde caerán los discos, y Default Bridge, el vmbrX al que se conectarán las tarjetas de red. Ambos se pueden afinar disco a disco y tarjeta a tarjeta en la pestaña siguiente.
• Live Import. Lo tratamos en el apartado siguiente.
• Un cuadro de Warnings con lo que el asistente no ha podido traducir. Los avisos que verás más a menudo: que la imagen de CD-ROM no se importa, que un disco NVMe pasa a SCSI, que el estado EFI no se importa y quizá tengas que reconfigurar el orden de arranque, y el de máquina encendida en origen.

Advanced. Lo que te evita retoques después:

• Disks: para cada disco, almacenamiento y formato de destino, y la casilla para no importarlo. Sirve para dejar fuera un disco de datos que vas a mover por otra vía o para repartir sistema y datos entre un pool NVMe y otro de capacidad.
• Prepare for VirtIO-SCSI. Solo se activa con sistemas Windows, y viene marcada por defecto si la VM es Windows con UEFI. Hace dos cosas: conecta los discos como SATA, para que Windows arranque con un driver que ya tiene, y fija el controlador SCSI en VirtIO SCSI single, para que el cambio posterior a VirtIO sea un movimiento de disco y no una reconfiguración. Si has preinstalado los drivers VirtIO y ya lo has probado, puedes desmarcarla y arrancar directamente en SCSI.
• SCSI Controller: el que se aplicará a la VM. VirtIO SCSI single es el recomendado.
• CD/DVD Drives: aquí puedes asignar una ISO a la unidad que se importa vacía. En Windows, el asistente añade una unidad extra pensada justo para montar la ISO de VirtIO.
• Network Interfaces: modelo (VirtIO para todo lo moderno; e1000e está en la lista porque es habitual en invitados VMware antiguos), bridge, etiqueta VLAN y MAC.
• Unique MAC addresses: si la marcas, Proxmox genera MAC nuevas en lugar de conservar las de VMware. Déjala sin marcar si tienes reservas DHCP o licencias atadas a la MAC; márcala si vas a mantener la VM original encendida un tiempo en la misma red, para evitar duplicados.

Resulting Config. La lista completa de pares clave-valor con los que se creará la máquina, tal cual acabarán en /etc/pve/qemu-server/<id>.conf. Merece un vistazo la primera vez.

Pulsa Import. Verás la tarea en el visor de abajo, con el progreso de copia de cada disco. Al terminar, la máquina aparece en el inventario, apagada (o encendida, si has elegido importación en vivo). Con qm config <id> puedes revisar el resultado desde consola.

Importación en vivo: cuándo compensa y cuándo no

Con Live Import marcado, Proxmox arranca la máquina inmediatamente y va trayendo los bloques que el sistema operativo pide para arrancar, mientras copia el resto del disco en segundo plano. La VM sigue apagada en ESXi, así que parada hay, pero se reduce a lo que tarda en arrancar en Proxmox, no a lo que tarda en copiarse el disco entero. Para una máquina con 2 TB de disco la diferencia es de horas.

El precio es doble. Durante la copia el rendimiento de E/S está limitado por la lectura remota a través de ESXi, así que la máquina va más lenta hasta que termina. Y lo importante, tal cual lo dice Proxmox: si la importación falla, se pierde todo lo escrito desde que empezó. La máquina en ESXi sigue en el estado en que la apagaste, pero lo que hayan hecho los usuarios o las aplicaciones en Proxmox en ese intervalo no está en ningún sitio.

Con eso, la regla práctica:

• Sí a la importación en vivo para máquinas grandes cuyo servicio no puede estar horas parado, siempre con una red estable y rápida entre ESXi y Proxmox, y después de haber probado el mecanismo con una VM sin importancia.
• No para las primeras máquinas del proyecto, para bases de datos con mucha escritura, ni sobre enlaces WAN o redes con errores. Ahí la importación en frío, con la VM apagada hasta que la copia termina, da un resultado que se puede verificar antes de encender.

Un detalle de versiones: la 9.1 corrigió un fallo por el que la importación en vivo desde ESXi fallaba con máquinas de tipo QEMU 10, y la 9.2 volvió a tocar el importador. Si vas a usar Live Import, actualiza el nodo primero.

Después de importar: Windows

Lo normal es que una VM Windows importada con Prepare for VirtIO-SCSI arranque a la primera, con el disco en SATA. A partir de ahí:

1. Monta la ISO de VirtIO en la unidad de CD que el asistente dejó preparada y ejecuta virtio-win-guest-tools.exe. Instala los drivers de disco, red, balloon y el QEMU Guest Agent de una vez. Si lo hiciste ya en VMware, aquí solo comprobarás que están.
2. Pasa el disco de arranque a VirtIO SCSI. No basta con cambiar el bus: Windows solo activa el driver de un controlador de arranque cuando ha visto un disco colgando de él. El procedimiento que documenta Proxmox es añadir un disco temporal de 1 GB en SCSI, arrancar, esperar a que Windows lo detecte e instale el driver vioscsi, apagar, quitar el disco temporal, desconectar el disco de sistema (queda como Unused) y volver a conectarlo como SCSI, y por último revisar el orden de arranque en Options. Si te saltas el disco temporal, pantalla azul con INACCESSIBLE_BOOT_DEVICE; se arregla volviendo a SATA y repitiendo.
3. Tarjeta de red. Windows la ve como un adaptador nuevo. Reconfigura la IP si era estática y, en el Administrador de dispositivos, con «mostrar dispositivos ocultos», elimina el adaptador vmxnet3 fantasma para que no reclame la IP.
4. Activa el agente en Options → QEMU Guest Agent de la VM y reiníciala. Sin él, Proxmox no puede hacer un apagado limpio ni congelar el sistema de ficheros para copias consistentes.
5. Activación. Al cambiar el hardware virtual, Windows puede pedir reactivarse. Con licencias por volumen o KMS es automático; con claves OEM ligadas al hardware original, no.
6. Si arranca en UEFI y no encuentra el sistema, es que la entrada de arranque vivía en las variables EFI que no se importan. Entra en el firmware OVMF y añade a mano la entrada apuntando a \EFI\Microsoft\Boot\bootmgfw.efi; el disco EFI de la VM la guardará.

Sobre el rendimiento de Windows en Proxmox y las licencias de Windows Server, tienes un artículo entero.

Después de importar: Linux

Linux es más agradecido porque el kernel trae los drivers VirtIO de serie. Lo que suele fallar es más tonto:

• El nombre de la interfaz cambia. En VMware la tarjeta vmxnet3 solía llamarse ens192 o ens160; en Proxmox, con VirtIO en la ranura PCI que le toca, será ens18 o similar. Si /etc/network/interfaces, Netplan o NetworkManager tienen el nombre viejo escrito, la máquina arranca sin red. Corrígelo desde la consola noVNC de Proxmox.
• Cambia disco y red a VirtIO ya en la primera edición de hardware: disco en bus SCSI con controlador VirtIO SCSI single, tarjeta con modelo VirtIO. Si el initramfs lleva los módulos (punto 5 de la preparación), arranca sin más.
• /etc/fstab por UUID no se entera del cambio. Si alguna entrada apunta a /dev/sdX a pelo, cámbiala a UUID o a /dev/disk/by-id.
• Instala el agente: apt install qemu-guest-agent en Debian y derivados, dnf install qemu-guest-agent en la familia RHEL, y activa el servicio. Después, la casilla del agente en Options de la VM.
• Quita lo que quedaba de VMware, si no lo hiciste antes: open-vm-tools y cualquier regla de udev que fijara nombres de interfaz por la MAC antigua.

Ajustes finales para dejar la VM como nueva

Estos son los valores que Proxmox recomienda en su propia documentación de migración, y que el asistente no aplica todos porque prioriza que la máquina arranque:

Si vienes de un vSphere con vMotion, DRS y HA, la parte de clúster tiene su propia guía: alta disponibilidad en Proxmox y Ceph como almacenamiento hiperconvergente.

Migrar decenas de VMs: qm import, límites y ritmo

Con cinco máquinas el asistente gráfico es cómodo. Con cincuenta te interesa la consola. El equivalente exacto del asistente es qm import, disponible desde el mismo origen ESXi que ya tienes conectado:

# El siguiente ID libre del clúster
pvesh get /cluster/nextid

# Listar lo que ve el origen ESXi (la ruta es la que necesita qm import)
pvesm list esxi-lab

# Importar en frío al pool ZFS, con los ajustes recomendados
qm import 120 esxi-lab:ha-datacenter/datastore1/web-01/web-01.vmx \
  --storage local-zfs --scsihw virtio-scsi-single --cpu x86-64-v2-AES

# Ver el comando resultante sin ejecutar nada
qm import 120 esxi-lab:ha-datacenter/datastore1/web-01/web-01.vmx \
  --storage local-zfs --dryrun

# Importación en vivo desde consola
qm import 121 esxi-lab:ha-datacenter/datastore1/app-01/app-01.vmx \
  --storage local-zfs --live-import 1

qm import acepta las mismas opciones que qm create (--net0, --memory, --cores, --bios, --agent…), así que puedes fijar de antemano todo lo que en el asistente tocarías a mano. La forma de la ruta es siempre <id-del-origen>:ha-datacenter/<datastore>/<carpeta-de-la-vm>/<vm>.vmx. Con esto, un bucle de Bash sobre un fichero con la lista de máquinas es una tarde de trabajo, y como corre por la API, lo mismo vale para Ansible o para un runbook en Terraform u OpenTofu que cree después lo que rodea a cada máquina.

Lo que sí hay que respetar es el ritmo, porque el cuello de botella no está en Proxmox:

• La API de ESXi tiene un límite bajo de conexiones. Cuando se alcanza, bloquea a todos los clientes unos 30 segundos, incluidas las importaciones que ya estaban en marcha, y una máquina en importación en vivo se queda con la E/S colgada ese rato. El servicio esxi-folder-fuse limita por su cuenta a cuatro conexiones paralelas y reintenta con calma cuando ESXi le corta.
• Cada disco en importación consume memoria en el nodo: una caché de lectura adelantada de 8 bloques de 128 MiB, así que 1 GiB por disco. Lanzar veinte a la vez puede dejar el nodo sin memoria.
• La recomendación de Proxmox es clara: no más de cuatro discos importándose a la vez. Cuatro máquinas de un disco, o una de cuatro. Y dependiendo del ESXi, puede que solo puedas con una.
• Si aun así ves errores 503 Service Unavailable, en ESXi 7.0 se puede subir Config.HostAgent.vmacore.soap.maxSessionCount desde Host → Manage → System → Advanced Settings; en 6.5 y 6.7, <maxSessionCount> en /etc/vmware/hostd/config.xml y reiniciar hostd.

Y el orden importa tanto como el ritmo. Agrupa las máquinas por aplicación, no por orden alfabético, para que las que se hablan entre sí crucen el mismo día y no pases semanas con tráfico saltando entre las dos plataformas. Lo desarrollamos en las fases de un proyecto que sale bien.

Cuando el asistente no vale: las otras vías

Hay cuatro situaciones en las que el asistente no sirve o no es la mejor opción, y cada una tiene su salida.

Discos en vSAN. El importador no puede leerlos. La solución es mover los discos de la VM a un datastore VMFS o NFS con Storage vMotion y, ya ahí, importar con normalidad.

ESXi anterior a 6.5 o una API que no responde. Queda el camino clásico: exportar con ovftool y traerlo con qm importovf:

./ovftool vi://[email protected]/web-01 /mnt/export/
qm importovf 130 /mnt/export/web-01/web-01.ovf local-zfs --format qcow2

Al terminar hay que añadir la tarjeta de red y, en Windows, dejar el disco en SATA o IDE hasta instalar VirtIO, igual que arriba.

Un NFS que ven los dos. Si el datastore de VMware está en un NAS que Proxmox también puede montar, no hace falta ni ESXi ni exportación: qm disk import 131 web-01.vmdk local-zfs desde la ruta montada convierte el disco directamente. Y hay una variante con parada mínima documentada por Proxmox: crear la VM en Proxmox con un disco vmdk sobre ese mismo NFS, sustituir el descriptor por el de VMware apuntando al -flat.vmdk original, arrancar la máquina en Proxmox leyendo del disco de VMware y mover el disco al almacenamiento definitivo con la máquina encendida. Es más manual, pero la VM solo está apagada lo que tarda en encenderse al otro lado. La única regla es sagrada: nunca la misma VM encendida en VMware y en Proxmox a la vez.

Ya tienes copias con Veeam. Desde Veeam Backup & Replication 12.2 se puede restaurar una copia de una VM de vSphere directamente como VM de Proxmox VE. Si el parque ya está en Veeam, es una forma de migrar sin tocar los hosts ESXi para nada, y de paso de comprobar que las copias restauran. Lo tratamos en nuestro servicio de backup con Veeam.

Y las copias, desde el primer día

Una máquina recién importada no tiene copia en ningún sitio: la de VMware ya no vale y la de Proxmox todavía no existe. Antes de dar la migración de esa VM por cerrada, métela en un trabajo de copia hacia Proxmox Backup Server y restáurala una vez en un ID de prueba. Es el único momento del proyecto en el que tienes las dos plataformas y todo el tiempo del mundo para comprobar que la copia funciona. Si la máquina lleva una base de datos, mira además cómo conseguir copias consistentes con el agente.

Y cuando la última VM esté en Proxmox y verificada, no apagues el ESXi al día siguiente. Déjalo una o dos semanas como red de seguridad, sin máquinas encendidas, y solo entonces desmóntalo.

Preguntas frecuentes

¿Se puede migrar de VMware a Proxmox sin exportar a OVF? Sí. Desde Proxmox VE 8.2 (abril de 2024) el asistente de importación conecta con la API del host ESXi, lista sus máquinas y las importa con la configuración traducida y los discos convertidos al vuelo. No hace falta ovftool, ni copiar VMDK a mano, ni qemu-img. El método OVF sigue disponible para hosts antiguos o sin acceso a la API.

¿Qué versiones de ESXi soporta el asistente de importación de Proxmox? Proxmox lo tiene probado con ESXi 6.5, 6.7, 7.0 y 8.0. Se conecta al host directamente; a través de vCenter funciona, pero entre 5 y 10 veces más lento. Si vienes de vSphere 9, prueba antes con una VM de laboratorio, porque no está en la lista oficial de versiones probadas.

¿Hay que desinstalar VMware Tools antes de migrar a Proxmox? Sí, y con la máquina todavía en ESXi. Una vez en Proxmox el desinstalador falla porque no detecta el hipervisor de VMware, y hay que limpiar drivers y servicios a mano. En Linux basta con quitar open-vm-tools.

¿Por qué mi Windows migrado a Proxmox da pantalla azul INACCESSIBLE_BOOT_DEVICE? Porque el disco de arranque está en un bus VirtIO cuyo driver Windows no ha activado todavía. Windows solo carga el driver de un controlador de arranque cuando ha visto un disco en él. Vuelve a conectar el disco como SATA, añade un disco temporal de 1 GB en SCSI, arranca, deja que instale el driver vioscsi, apaga, quita el temporal y reconecta el disco de sistema como SCSI.

¿Qué es la importación en vivo (live import) de Proxmox? Una opción del asistente que arranca la VM en Proxmox nada más empezar, leyendo del ESXi los bloques que el sistema necesita y copiando el resto del disco en segundo plano. Reduce la parada al tiempo de arranque, pero si la importación falla se pierde todo lo escrito en la VM desde que empezó. Proxmox recomienda probarla antes y no usarla sobre redes lentas o con errores.

¿Cuántas máquinas puedo importar a la vez desde ESXi? Proxmox aconseja que no haya más de cuatro discos importándose al mismo tiempo, por el límite de conexiones de la API de ESXi (que bloquea a todos los clientes unos 30 segundos cuando se supera) y por la memoria que consume cada disco en el nodo, 1 GiB de caché de lectura adelantada. Es mejor encadenar importaciones que lanzarlas en paralelo.

¿Se pueden importar máquinas que están en vSAN? No directamente. El asistente no puede leer discos en vSAN. Hay que moverlos antes con Storage vMotion a un datastore VMFS o NFS y después importar. Lo mismo pasa con los discos cifrados por política de almacenamiento: primero se quita la política.

¿Existe un comando para importar desde ESXi sin la interfaz gráfica? Sí, qm import <id> <origen>:ha-datacenter/<datastore>/<vm>/<vm>.vmx --storage <destino>, con las mismas opciones que qm create, y --dryrun para ver el comando resultante sin ejecutarlo. Es lo que permite automatizar una migración de decenas de máquinas.

Fuentes

• Proxmox, Migrate to Proxmox VE, wiki oficial: requisitos, pasos del asistente, importación en vivo, consideraciones para importaciones masivas y métodos manuales.
• Proxmox, Proxmox VE Administration Guide, capítulo de máquinas virtuales, apartado Importing Virtual Machines.
• Proxmox, referencia del comando qm, subcomando qm import y sus opciones --dryrun y --live-import.
• Proxmox, Roadmap y notas de versión: asistente de importación en la 8.2 (24 de abril de 2024) y correcciones del importador ESXi en 8.3, 9.1 y 9.2.
• Proxmox, anuncio del asistente de importación en el foro oficial, 27 de marzo de 2024.
• Proxmox, Paravirtualized Block Drivers for Windows: el procedimiento del disco temporal para pasar el arranque a VirtIO SCSI.
• Proxmox, Windows VirtIO Drivers y OVMF/UEFI Boot Entries.
• Veeam, Restore to Proxmox VE, guía de usuario de Veeam Backup & Replication.

---

¿Tienes un vSphere que renovar y un parque de máquinas que no puede parar? Migramos de VMware a Proxmox por olas, con el asistente cuando vale y con las otras vías cuando no, y operamos el clúster después. Mira cómo hacemos las migraciones o cuéntanos tu caso.