Importar una VM de ESXi a Proxmox: Windows/Linux, controladores VirtIO, mapeo de NIC y soluciones de arranque

Hechos e historia que realmente importan

Algo de contexto hace que los modos de fallo sean menos misteriosos y más previsibles. Aquí están las cosas que he visto que funcionan en migraciones reales:

1. VMDK es anterior a la mayoría de las estrategias “cloud-first”. VMware introdujo VMDK a principios de los 2000; tiene variantes sparse/thick y una bolsa de subtipos con los que las herramientas de conversión no siempre coinciden.
2. KVM está en el kernel de Linux desde 2007. Proxmox se apoya en esa base, lo que significa que los cambios del kernel de Linux (controladores, nombres, initramfs) pueden ser más relevantes que “ajustes de Proxmox”.
3. VirtIO surgió del ecosistema KVM/QEMU para evitar la sobrecarga de emulación de hardware. Excelente para rendimiento, terrible si tu sistema invitado no tiene el controlador al arrancar.
4. UEFI vs BIOS no es un interruptor cosmético. Si ESXi instaló el invitado en modo UEFI y lo arrancas en BIOS (o al revés), a menudo obtienes una situación de “el disco parece vacío”.
5. El SCSI paravirtual de VMware (PVSCSI) no es VirtIO. Suenan ambos “paravirtual”, pero las pilas de controladores son distintas. Windows castigará las suposiciones aquí.
6. Los “nombres predecibles” de NIC cambiaron el modelo mental humano. Linux pasó de eth0/eth1 a nombres como ens18/enp0s3; la migración hace visible ese cambio dolorosamente.
7. qcow2 no es “solo otro formato de disco”. Soporta snapshots y compresión pero añade indirectos. En algunos backends de almacenamiento, raw es más rápido y simple.
8. OVA es un tarball, no magia. Usualmente contiene un descriptor OVF más uno o más VMDKs. Trátalo como un archivo que puedes inspeccionar, no como un artefacto sagrado.
9. La activación y los IDs de hardware de Windows siempre han sido volátiles. Cambiar de hipervisor cambia suficiente hardware virtual como para que planifiques avisos de activación y comprobaciones de cumplimiento de licencias.

Y una cita de fiabilidad, porque sigue siendo la mentalidad correcta cuando estás a punto de cambiar una carga de trabajo de hardware virtual:

Werner Vogels (idea parafraseada): “Todo falla, todo el tiempo—diseña y opera como si eso fuera lo normal.”

Árbol de decisiones: elige tu camino de importación

Hay tres caminos comunes. Elige uno, comprométete y evita mezclar “atajos rápidos” a mitad de vuelo.

Camino A: Tienes una exportación OVA/OVF

Mejor cuando puedes exportar limpiamente desde vCenter/ESXi y quieres un paquete portátil. Extraerás los VMDK(s) y convertirás con qemu-img o dejarás que Proxmox importe el disco.

Camino B: Tienes los archivos VMDK desde un datastore

Mejor cuando puedes SCP desde ESXi o explorar el datastore. Copiarás los VMDK(s) y los convertirás/importarás.

Camino C: No tienes ninguno, solo una VM en ejecución que no puedes apagar

Entonces estás haciendo replicación, restauración de backup o espejo a nivel de bloque. Esta guía asume que puedes obtener una exportación en frío o al menos un snapshot consistente. Si no puedes, tu “migración” es un evento de fiabilidad disfrazado.

Preparación en ESXi: exportar limpiamente y capturar la verdad

Tu objetivo en ESXi es simple: congelar los hechos sobre la VM antes de moverla. ¿Qué controlador de disco? ¿BIOS o UEFI? ¿Qué tipo de NIC? ¿Qué VLANs? ¿Qué IPs? Una vez en Proxmox, esos detalles se convierten en conjeturas, y las conjeturas son cómo acabas con una VM que “arranca bien” pero no puede comunicarse con nada.

Tarea 1: Registrar firmware, discos y tipos de NIC de la VM (desde shell de ESXi)

cr0x@server:~$ ssh root@esxi01 'vim-cmd vmsvc/getallvms | head'
Vmid   Name                 File                               Guest OS      Version   Annotation
1      dc01                 [datastore1] dc01/dc01.vmx          windows9Server64Guest   vmx-13
2      web01                [datastore1] web01/web01.vmx        ubuntu64Guest  vmx-14

Qué significa la salida: tienes VMIDs y rutas VMX. Usarás el VMX para confirmar firmware y dispositivos.

Decisión: identifica el VMID que vas a migrar y guarda la ruta VMX en tus notas.

Tarea 2: Extraer el VMX y comprobar firmware y modelo de dispositivo

cr0x@server:~$ ssh root@esxi01 'grep -E "firmware|scsi|nvme|ethernet.*virtualDev" /vmfs/volumes/datastore1/web01/web01.vmx'
firmware = "efi"
scsi0.virtualDev = "pvscsi"
ethernet0.virtualDev = "vmxnet3"

Qué significa: invitado UEFI, SCSI paravirtual de VMware y NIC vmxnet3.

Decisión: planifica Proxmox UEFI (OVMF) y entiende que el invitado actualmente depende de controladores PVSCSI y vmxnet3—no de VirtIO.

Tarea 3: Apagar limpiamente (o tomar un snapshot que puedas justificar)

cr0x@server:~$ ssh root@esxi01 'vim-cmd vmsvc/power.getstate 2'
Retrieved runtime info
Powered on

Decisión: si puedes programar downtime, apaga. Si no puedes, toma un snapshot quiescent solo si tus tools y aplicación invitados lo soportan. Si no, acepta que exportas datos “posiblemente consistentes”.

cr0x@server:~$ ssh root@esxi01 'vim-cmd vmsvc/power.shutdown 2; sleep 5; vim-cmd vmsvc/power.getstate 2'
Retrieved runtime info
Powered off

Qué significa: el apagado limpio tuvo éxito. Ese es el estándar de oro para la conversión de discos.

Tarea 4: Exportar/copiar los discos (ejemplo: scp desde ESXi)

cr0x@server:~$ scp root@esxi01:/vmfs/volumes/datastore1/web01/web01.vmdk .
web01.vmdk                                      100%  512B   2.1KB/s   00:00

Qué significa: ese archivo diminuto es el descriptor. Los datos suelen estar en -flat.vmdk o similar.

Decisión: siempre copia también el flat/las extensiones, o usa un método de exportación que produzca un solo flujo (OVA) para evitar partes perdidas.

cr0x@server:~$ scp root@esxi01:/vmfs/volumes/datastore1/web01/web01-flat.vmdk .
web01-flat.vmdk                                 100%   40G  110.2MB/s   06:12

Preparación en Proxmox: almacenamiento, red y salvaguardas

En el lado de Proxmox, los dos grandes riesgos son: (1) volcar grandes imágenes raw en el almacenamiento equivocado y luego descubrir que no puedes snapshot/replicar como asumiste, y (2) enchufar la VM al puente equivocado/VLAN y “aislarla exitosamente” del mundo.

Tarea 5: Verificar destinos de almacenamiento y espacio libre

cr0x@server:~$ pvesm status
Name            =reqtype  Status     Total     Used    Avail   %  Content
local             dir     active    98.0G    11.2G    81.6G  11  iso,vztmpl,backup
local-lvm         lvmthin active   900.0G   612.4G   287.6G  68  rootdir,images
zfspool           zfspool active     2.7T     1.1T     1.6T  40  images,rootdir

Qué significa: tienes múltiples destinos. El pool ZFS tiene espacio y soporta snapshots; LVM-thin también soporta snapshots pero se comporta distinto bajo presión.

Decisión: elige el backend de almacenamiento intencionalmente. Si planeas snapshots/replicación intensos, ZFS suele ser lo menos sorprendente.

Tarea 6: Confirmar puentes y conciencia de VLAN

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:ec:ef:11:22:33
vmbr0            UP             3c:ec:ef:11:22:33
vmbr1            UP             3c:ec:ef:aa:bb:cc

Decisión: iguala la intención del portgroup/VLAN de ESXi con un puente de Proxmox y etiqueta. Si no puedes describir la red en una frase, para y mapea antes de importar.

Tarea 7: Revisar la salud del host Proxmox antes de culpar a la VM

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2.2 (running kernel: 6.8.12-4-pve)
pve-manager: 8.2.4 (running version: 8.2.4/2a1b7d2c)

Decisión: un kernel moderno y QEMU reducen rarezas de compatibilidad, especialmente con UEFI y almacenamiento. Si estás en algo antiguo, espera fricción adicional.

Chiste #1: La virtualización es simplemente fingir con mucha convicción, y de alguna manera la nómina depende de ello.

Convertir discos: VMDK/OVA a almacenamiento de Proxmox

La conversión es donde puedes arruinar tu día silenciosamente. Las reglas son simples:

• Confirma que tienes los extents reales de datos (flat/sesparse/etc.).
• Convierte usando una herramienta que entienda los subformatos VMDK.
• Elige raw para simplicidad/rendimiento en ZFS/LVM-thin a menos que tengas una razón para qcow2.
• Valida el tamaño resultante de la imagen y la integridad básica antes de adjuntarla.

Tarea 8: Inspeccionar el descriptor VMDK (atrapa sorpresas de multi-extent)

cr0x@server:~$ head -n 20 web01.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 83886080 VMFS "web01-flat.vmdk"

Qué significa: un archivo extent, sectores de ~40GiB. Bien. Si ves múltiples extents, debes copiar todos y mantener las rutas relativas intactas.

Decisión: si es multi-extent y no tienes todas las partes, para. Re-exporta como OVA o recopia correctamente.

Tarea 9: Convertir VMDK a raw (preferido en ZFS para menos capas)

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw web01.vmdk web01.raw
    (0.00/100%)
    (12.50/100%)
    (25.00/100%)
    (37.50/100%)
    (50.00/100%)
    (62.50/100%)
    (75.00/100%)
    (87.50/100%)
    (100.00/100%)

Qué significa: conversión completada. Sin errores. Buen comienzo, no prueba final.

Decisión: si apuntas a LVM-thin o ZFS, raw está bien. Si necesitas almacenamiento basado en ficheros con snapshots y no tienes ZFS/LVM-thin, qcow2 puede ser útil.

Tarea 10: Verificar la información de la imagen (chequeo de cordura antes de importar)

cr0x@server:~$ qemu-img info web01.raw
image: web01.raw
file format: raw
virtual size: 40 GiB (42949672960 bytes)
disk size: 40 GiB

Qué significa: raw está completamente asignado; eso es esperado. Si esperabas aprovisionamiento delgado, lo verás solo con qcow2 o con el almacenamiento de destino (como ZVOL/LVM-thin) manejando sparsidad.

Decisión: si el tamaño del disco es claramente incorrecto (p. ej., 4 GiB en lugar de 40 GiB), convertiste la cosa equivocada o perdiste extents.

Tarea 11: Importar el disco al almacenamiento de Proxmox con qm importdisk

cr0x@server:~$ qm create 120 --name web01 --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0
create VM 120: success

cr0x@server:~$ qm importdisk 120 web01.raw zfspool
importing disk 'web01.raw' to VM 120 ...
transferred 40.0 GiB of 40.0 GiB (100.00%)
Successfully imported disk as 'zfspool:vm-120-disk-0'

Qué significa: el disco ahora es un volumen gestionado por Proxmox.

Decisión: desde aquí, trata el volumen importado como la fuente de la verdad; guarda el VMDK/raw original en un lugar seguro hasta que la VM esté estable y respaldada.

Crear la VM en Proxmox: controladores, firmware, CPU y RAM

Aquí es donde la mayoría de las suposiciones “arranca en ESXi” mueren. Los valores por defecto de hardware virtual de ESXi no son los de Proxmox. Tu trabajo es replicar lo que importa para el arranque y luego mejorar el rendimiento después de que esté estable.

Adjuntar el disco importado correctamente

Después de qm importdisk, todavía necesitas adjuntar el disco a un controlador y establecer el orden de arranque.

Tarea 12: Adjuntar el disco como SATA primero (enfoque estabilidad-primero)

cr0x@server:~$ qm set 120 --sata0 zfspool:vm-120-disk-0
update VM 120: -sata0 zfspool:vm-120-disk-0

Qué significa: el disco está adjunto a un controlador SATA. Casi todos los OS pueden arrancar desde SATA sin controladores extra.

Decisión: usa SATA (o IDE para sistemas antiguos) para el primer arranque exitoso. Cambia a VirtIO SCSI después para rendimiento.

Tarea 13: Igualar el modo de firmware (UEFI vs BIOS)

cr0x@server:~$ qm set 120 --bios ovmf --efidisk0 zfspool:0,pre-enrolled-keys=1
update VM 120: -bios ovmf -efidisk0 zfspool:vm-120-disk-1,pre-enrolled-keys=1

Qué significa: has activado OVMF (UEFI) y creado un disco de variables EFI. Si el VMX de ESXi decía firmware="efi", esto es el equivalente.

Decisión: si el invitado era BIOS en ESXi, no actives OVMF. Si no sabes, revisa el VMX y el particionado (EFI System Partition vs MBR).

Tarea 14: Establecer el orden de arranque explícitamente

cr0x@server:~$ qm set 120 --boot order=sata0
update VM 120: -boot order=sata0

Decisión: no confíes en los valores por defecto. Haz que la VM arranque desde el disco que importaste, no desde una unidad virtual de CD-ROM vacía.

Tarea 15: Iniciar y observar la salida de la consola (no hagas reinicios a ciegas)

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

cr0x@server:~$ qm status 120
status: running

Decisión: abre la consola de Proxmox y observa. Si falla, quieres la cadena exacta de error. “No arranca” no es un síntoma; es una confesión.

Importaciones Windows: controladores VirtIO, arreglos de arranque y secuencia sensata

Windows no te odia personalmente. Simplemente espera que los controladores de almacenamiento y red se mantengan consistentes entre arranques, y espera que los controladores necesarios existan antes de intentar montar el volumen de arranque.

La secuencia más segura para Windows es:

1. Arrancar en un controlador “universal” (SATA) y un modelo de NIC “universal” (E1000) si es necesario.
2. Instalar los controladores VirtIO dentro de Windows.
3. Cambiar el controlador de disco a VirtIO SCSI (o VirtIO Block) y la NIC a VirtIO.
4. Reiniciar y validar.

Estrategia de controladores VirtIO que realmente funciona

Monta la ISO de controladores VirtIO en Proxmox, luego instala los controladores desde el Administrador de dispositivos o ejecuta el instalador si está disponible. La clave es: el controlador de almacenamiento debe estar presente y habilitado al arrancar.

Tarea 16: Añadir la ISO de controladores VirtIO (ejemplo asume ISO ya subida)

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

Decisión: si Windows arranca pero no tiene red, está bien. No entres en pánico y “optimices” nada todavía. Instala controladores primero.

Tarea 17: Cambiar la NIC a un modelo de compatibilidad temporalmente (si es necesario)

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

Qué significa: estás usando una NIC emulada Intel. Más lenta, pero Windows la entiende sin controladores extra.

Decisión: si no puedes acceder a la máquina para instalar VirtIO, usa E1000 para recuperar la red el tiempo suficiente para terminar el trabajo de controladores.

Después de los controladores: pasa a VirtIO SCSI

VirtIO SCSI es el punto óptimo para la mayoría de cargas de trabajo. Soporta mejor TRIM/UNMAP en muchas configuraciones y está ampliamente probado.

Tarea 18: Añadir controlador VirtIO SCSI y mover el disco

cr0x@server:~$ qm set 120 --scsihw virtio-scsi-single
update VM 120: -scsihw virtio-scsi-single

cr0x@server:~$ qm set 120 --scsi0 zfspool:vm-120-disk-0
update VM 120: -scsi0 zfspool:vm-120-disk-0

cr0x@server:~$ qm set 120 --delete sata0
update VM 120: delete sata0

Decisión: elimina la conexión SATA solo después de que los controladores VirtIO estén instalados y tengas confianza de que el próximo arranque encontrará el disco.

Tarea 19: Cambiar la NIC a VirtIO después de que Windows tenga el controlador

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

Qué significa: Windows verá una nueva NIC. La configuración IP podría no seguirse automáticamente si estaba ligada al adaptador antiguo.

Decisión: planifica reconfiguración de IP o scripting. Para servidores con IPs estáticas, espera una corta ventana de “¿dónde está mi IP?”.

Fallos de arranque de Windows que verás realmente

• INACCESSIBLE_BOOT_DEVICE (BSOD): incompatibilidad de controlador de almacenamiento. Arrancó bien en SATA, falló al cambiar a VirtIO antes de instalar controladores.
• Se queda en puntos girando: a veces problemas de controladores, a veces mismatch de firmware, a veces un BCD corrupto tras la conversión.
• No hay dispositivo de arranque: orden de arranque equivocado o mismatch UEFI/BIOS.

Chiste #2: Los controladores de Windows son como los paraguas—solo te das cuenta de que los necesitabas después de que ya estás empapado.

Importaciones Linux: initramfs, nombres de NIC y trampas de UUID de sistema de archivos

Las migraciones Linux suelen ser más sencillas que Windows, hasta que no lo son. Los puntos comunes de fallo son:

• initramfs no incluye el controlador para el nuevo controlador de disco (VirtIO) por lo que el sistema raíz nunca aparece.
• El nombre de la interfaz de red cambia (ens160 en VMware pasa a ens18 en Proxmox) y tu configuración de red apunta a un dispositivo fantasma.
• Las entradas del bootloader referencian UUIDs antiguos, o la conversión cambió algo lo suficiente como para que la línea de comando del kernel no encuentre root.

Tarea 20: Obtener el mapa de particiones del disco de la VM desde el host Proxmox (sin arrancar)

cr0x@server:~$ ls -l /dev/zvol/zfspool/vm-120-disk-0
lrwxrwxrwx 1 root root 13 Dec 28 10:12 /dev/zvol/zfspool/vm-120-disk-0 -> ../../zd0

cr0x@server:~$ partprobe /dev/zd0 && lsblk -f /dev/zd0
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zd0
├─zd0p1 vfat   FAT32       1A2B-3C4D
└─zd0p2 ext4   1.0         11111111-2222-3333-4444-555555555555

Qué significa: probablemente UEFI (ESP vfat) más root ext4. Eso respalda tu decisión de firmware anterior.

Decisión: si esperabas BIOS/MBR pero ves un ESP, cambia la VM a OVMF y añade un disco EFI.

Tarea 21: Si Linux arranca pero no tiene red, identifica el nuevo nombre de NIC

cr0x@server:~$ qm guest exec 120 -- ip -br a
{
  "exitcode": 0,
  "out-data": "lo               UNKNOWN        127.0.0.1/8 ::1/128\nens18            DOWN           \n",
  "err-data": ""
}

Qué significa: la VM ve ens18 pero está abajo/no configurada.

Decisión: actualiza tu netplan/systemd-networkd/ifcfg para referenciar el nuevo nombre de interfaz, o usa emparejamiento por MAC.

Tarea 22: Validar que la VM ve el disco en VirtIO tras cambiar controladores

cr0x@server:~$ qm guest exec 120 -- lsblk
{
  "exitcode": 0,
  "out-data": "NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS\nvda    252:0    0   40G  0 disk \nvda1   252:1    0  512M  0 part /boot/efi\nvda2   252:2    0 39.5G  0 part /\n",
  "err-data": ""
}

Qué significa: el disco aparece como /dev/vda (VirtIO). Bien.

Decisión: si tu /etc/fstab referencia /dev/sda2 en lugar de UUIDs, arréglalo antes del próximo reinicio.

Tarea 23: Comprobar que initramfs incluye módulos VirtIO (dentro del invitado)

cr0x@server:~$ qm guest exec 120 -- bash -lc 'lsinitramfs /boot/initrd.img-$(uname -r) | grep -E "virtio|vda|scsi" | head'
{
  "exitcode": 0,
  "out-data": "usr/lib/modules/6.5.0-28-generic/kernel/drivers/block/virtio_blk.ko\nusr/lib/modules/6.5.0-28-generic/kernel/drivers/scsi/virtio_scsi.ko\n",
  "err-data": ""
}

Decisión: si faltan módulos VirtIO, reconstruye initramfs antes de cambiar los controladores permanentemente (update-initramfs -u en Debian/Ubuntu, dracut -f en RHEL-like).

Mapeo de NIC: de vSwitches a puentes Linux

La red de ESXi son portgroups en vSwitches (standard o distributed). La red de Proxmox son puentes Linux (a menudo vmbr0) y etiquetado VLAN opcional. La trampa es pensar “mismo ID VLAN” equivale a “misma conectividad”. No lo es si el trunk upstream o la conciencia de VLAN del puente difieren.

Mapéalo deliberadamente

• ESXi portgroup VLAN 0/none → puente Proxmox sin etiquetar en la misma red física.
• ESXi portgroup VLAN X → NIC de VM en Proxmox etiquetada con VLAN X (tag=X) en un puente con soporte VLAN, o usa una subinterfaz/puente VLAN dedicado.
• Múltiples NICs → mapea cada una al puente correcto, no “coloques todo en vmbr0” a menos que quieras movimiento lateral accidental.

Tarea 24: Mostrar la conciencia VLAN del puente en Proxmox (lado host)

cr0x@server:~$ grep -A4 -B2 -n "vmbr0" /etc/network/interfaces
7:auto vmbr0
8:iface vmbr0 inet static
9:        address 10.10.10.5/24
10:       gateway 10.10.10.1
11:       bridge-ports eno1
12:       bridge-stp off
13:       bridge-fd 0
14:       bridge-vlan-aware yes

Qué significa: puente con conciencia VLAN. Puedes etiquetar NICs de VM sin interfaces VLAN Linux adicionales.

Decisión: si bridge-vlan-aware no está habilitado pero necesitas tags, o bien actívalo (con cuidado) o construye el diseño alternativo. No improvises en un host de producción durante horas laborales.

Tarea 25: Poner una VLAN etiquetada en una NIC de VM

cr0x@server:~$ qm set 120 --net0 virtio,bridge=vmbr0,tag=30
update VM 120: -net0 virtio,bridge=vmbr0,tag=30

Decisión: si el invitado aún no alcanza su gateway, confirma que el switch upstream está trunking VLAN 30 y que el puente host está en la interfaz física correcta.

Guion de diagnóstico rápido

Cuando la VM importada “no funciona”, necesitas encontrar el cuello de botella rápido. Aquí está el orden que ahorra tiempo.

Primero: ¿Arranca y qué fallo exacto ves?

• No hay dispositivo de arranque / cae al shell UEFI → modo de firmware u orden de arranque equivocado, o disco no adjunto.
• GRUB rescue / kernel panic: unable to mount root → incompatibilidad controlador/driver del controlador de disco o mismatch de fstab/UUID de root.
• Windows BSOD INACCESSIBLE_BOOT_DEVICE → controlador de almacenamiento inexistente para el controlador que seleccionaste.

Segundo: ¿El disco está presente y dónde?

Revisa en el host Proxmox: ¿se importó el disco correctamente y está adjunto a la VM en el bus previsto?

cr0x@server:~$ qm config 120 | egrep "boot|bios|efidisk|scsi|sata|ide"
bios: ovmf
boot: order=scsi0
efidisk0: zfspool:vm-120-disk-1,pre-enrolled-keys=1,size=4M
ide2: local:iso/virtio-win.iso,media=cdrom
scsi0: zfspool:vm-120-disk-0
scsihw: virtio-scsi-single

Decisión: si el disco está en el bus equivocado (p. ej., querías SATA para el primer arranque), corrígelo antes de tocar nada dentro del invitado.

Tercero: ¿Está rota la red o solo cambió la identidad de la NIC?

• El invitado arranca pero no responde ping → probablemente mismatch VLAN/puente o controladores faltantes/renombrado de NIC.
• Ping funciona pero servicios caídos → problema de aplicación, firewall o cambio de configuración IP.

Cuarto: ¿Es el rendimiento el “problema” o el host está saturado?

No optimices la VM hasta saber si el host es el cuello de botella.

cr0x@server:~$ pvesh get /nodes/$(hostname)/status | egrep '"cpu"|mem|swap'
  "cpu": 0.23,
  "memory": {
    "free": 5826394112,
    "total": 34359738368,
    "used": 28533344256
  },
  "swap": {
    "free": 8589934592,
    "total": 8589934592,
    "used": 0
  }

Decisión: si la memoria está justo o la CPU saturada, la “VM lenta” podría ser un host sobrecargado. Arregla la plataforma primero.

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

1) Síntoma: “No bootable device” después de la importación

Causa raíz: mismatch de firmware (UEFI vs BIOS) u orden de arranque equivocado, o disco no adjunto en ningún bus.

Solución: confirma el firmware en el VMX, luego empareja en Proxmox (--bios seabios o --bios ovmf + efidisk). Establece el orden de arranque explícitamente.

2) Síntoma: Windows BSOD INACCESSIBLE_BOOT_DEVICE

Causa raíz: adjuntaste el disco de arranque en VirtIO SCSI/Block antes de que Windows tuviera el controlador VirtIO habilitado.

Solución: revierte el bus del disco a SATA, arranca, instala controladores VirtIO, luego vuelve a VirtIO SCSI.

3) Síntoma: Linux cae a initramfs o kernel panic “unable to mount root”

Causa raíz: initramfs no incluye módulos VirtIO, o root= referencia un nombre de dispositivo que cambió (sda → vda), o fstab usa rutas de dispositivo.

Solución: arranca vía SATA temporalmente, reconstruye initramfs, actualiza fstab a UUIDs, luego cambia a VirtIO.

4) Síntoma: VM arranca pero no tiene red

Causa raíz: modelo de NIC cambiado y controlador faltante (Windows) o nombre de interfaz cambiado (Linux), o etiquetado/puente VLAN equivocado.

Solución: usa E1000 temporalmente en Windows para recuperar acceso; en Linux, actualiza la configuración de red para el nuevo nombre de NIC. Valida el puente y etiquetado VLAN en el host.

5) Síntoma: La red funciona pero los servicios son inaccesibles desde fuera

Causa raíz: perfil de firewall cambiado, Windows piensa que está en una red “Pública”, o la IP quedó ligada a un adaptador oculto/antiguo.

Solución: reasigna la IP al adaptador activo, revisa el perfil del firewall de Windows, verifica rutas y sockets en escucha.

6) Síntoma: El rendimiento del disco es terrible después de la importación

Causa raíz: mantuviste un controlador emulado (IDE/SATA) o usaste qcow2 encima de un almacenamiento que ya hace copy-on-write mal, o el host está I/O bound.

Solución: cambia a VirtIO SCSI y habilita iothreads donde corresponda; prefiere raw en ZFS/LVM-thin; verifica latencia del host y salud del almacenamiento primero.

7) Síntoma: Deriva de tiempo o saltos extraños en el reloj

Causa raíz: cambios en guest tools (VMware tools eliminado, QEMU guest agent no instalado), fuente de sincronización de tiempo incorrecta, o servicio de tiempo de Windows re-evaluando hardware.

Solución: instala y habilita QEMU guest agent; configura NTP/chrony/systemd-timesyncd; verifica servicio de tiempo de Windows y jerarquía de dominio.

8) Síntoma: La VM no arranca, Proxmox informa bloqueo o errores de configuración

Causa raíz: bloqueo residual, almacenamiento no disponible, ID de volumen incorrecto, o ediciones de configuración erróneas.

Solución: inspecciona qm config, verifica estado del almacenamiento, elimina el bloqueo solo cuando estés seguro de que no hay nada en ejecución.

cr0x@server:~$ qm unlock 120
unlock VM 120

Listas de verificación / plan paso a paso

Lista A: Antes de tocar nada

• Confirma ventana de mantenimiento y plan de retroceso (mantén la VM original apagada pero intacta).
• Registra el VMX de ESXi: firmware, controlador de disco, modelo de NIC, número de discos y direcciones MAC.
• Registra IPs, rutas y cualquier requisito de VLAN.
• Confirma que el destino de almacenamiento en Proxmox tiene espacio y soporta las características que necesitas (snapshots/replicación).

Lista B: Exportación y conversión de disco

1. Apaga la VM (preferible).
2. Copiar descriptor VMDK y extents (o exportar OVA).
3. Inspeccionar descriptor: single vs multi-extent, notas sobre tipo de adaptador.
4. Convertir con qemu-img a raw (o qcow2 si necesitas almacenamiento basado en ficheros).
5. Verificar con qemu-img info.

Lista C: Primer arranque en Proxmox (estabilidad-primero)

1. Crear VM con ajustes conservadores (disco SATA, NIC E1000 si es Windows).
2. Igualar firmware (OVMF vs SeaBIOS).
3. Establecer orden de arranque explícitamente.
4. Arrancar y confirmar que el OS carga.
5. Arreglar red dentro del invitado si cambió el nombre/modelo de NIC.

Lista D: Pase de rendimiento (después de que arranque limpio)

1. Instalar QEMU guest agent.
2. Instalar controladores VirtIO (Windows).
3. Cambiar disco a VirtIO SCSI y NIC a VirtIO.
4. Reiniciar y validar disco + red + aplicación.
5. Hacer un backup o snapshot en Proxmox solo después de la validación.

Tarea 26: Habilitar QEMU guest agent en la configuración de Proxmox

cr0x@server:~$ qm set 120 --agent enabled=1
update VM 120: -agent enabled=1

Decisión: si dependes de apagados limpios, reporte de IPs y acciones scriptadas, habilita el agente e instálalo dentro del invitado.

Tarea 27: Confirmar que el guest agent responde

cr0x@server:~$ qm guest ping 120
qemu-agent is running

Decisión: si no está corriendo, no asumas que Proxmox está equivocado—instala/inicia el servicio en el invitado y revisa firewall/SELinux donde aplique.

Tarea 28: Hacer un backup tras la validación

cr0x@server:~$ vzdump 120 --storage local --mode snapshot --compress zstd
INFO: starting new backup job: vzdump 120 --storage local --mode snapshot --compress zstd
INFO: VM 120: starting backup
INFO: VM 120: backup finished
INFO: Finished Backup of VM 120 (00:02:41)

Qué significa: ahora tienes un backup nativo de Proxmox que puedes restaurar rápidamente si el siguiente cambio rompe el arranque.

Decisión: haz esto antes de empezar a “tunear”. Los backups son más baratos que las heroicidades.

Tres mini-historias corporativas desde el campo

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

Migraron un servidor de archivos Windows de ESXi a Proxmox durante una renovación rutinaria de hipervisores. El ingeniero que hacía el trabajo había hecho media docena de mudanzas Linux con éxito y supuso que Windows se comportaría igual: “Adjunta el disco como VirtIO, es más rápido, instalaremos drivers después.” Esa suposición tiene un código BSOD muy específico.

La VM arrancó, recibió INACCESSIBLE_BOOT_DEVICE y luego quedó atrapada en bucles de reparación automática. El equipo probó la clásica caja de trucos: cambiar tipo de CPU, alternar tipo de máquina, incluso “quizás es secure boot”. Cada reinicio hizo la situación más ruidosa, no mejor. Mientras tanto, un departamento mandaba capturas de pantalla de unidades compartidas perdidas como si fuera una nueva forma de arte.

La solución fue dolorosamente simple. Movieron la conexión del disco a SATA, arrancaron con éxito, instalaron controladores de almacenamiento y red VirtIO desde la ISO y solo entonces cambiaron a VirtIO SCSI. Windows se recuperó inmediatamente porque nada estaba corrupto; simplemente faltaba el controlador al arrancar.

La lección del postmortem no fue “VirtIO es malo”. La lección fue: no cambies hardware crítico de arranque antes de que el invitado pueda manejarlo. Una migración ya es un gran cambio; no necesitas apilar tuning de rendimiento encima durante el primer arranque.

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

Un equipo diferente decidió ser listos sobre almacenamiento: importar todo en qcow2 porque “los snapshots son más fáciles”, y luego almacenar esos qcow2 en un backend copy-on-write. Eso no es inherentemente incorrecto—hasta que lo haces a escala con cargas de trabajo pesadas en escritura y nadie modela la amplificación.

En días, el síntoma fue “Proxmox está lento”. La latencia de disco de VM subió. Los backups tardaban más y empezaron a solaparse con horas laborales. La gente empezó a culpar a la red porque siempre es de moda culpar a la red.

El problema real fue el comportamiento en capas de copy-on-write en un entorno que ya tenía snapshots y churn. Las escrituras aleatorias se convirtieron en un pequeño festival de impuestos. La sobrecarga de metadata subió. Los hosts no estaban rotos; la arquitectura lo estaba.

Lo arreglaron convirtiendo volúmenes de alto churn a raw sobre un backend más apropiado y manteniendo qcow2 solo donde tenía un beneficio operativo claro. El rendimiento volvió y con él la capacidad de dejar de adivinar.

La optimización es genial. Solo no optimices dos capas a la vez y luego te sorprendas cuando la física lo nota.

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

Una organización tenía un runbook de migración que parecía dolorosamente conservador. Cada VM importada arrancaba primero en SATA y una NIC de compatibilidad si el OS era desconocido. Hacían un backup inmediatamente después del primer arranque exitoso y luego procedían a instalar controladores y convertir a VirtIO como segunda fase.

Era lento. No era glamouroso. Y evitó un corte desagradable cuando una appliance Linux legacy arrancó bien en SATA pero falló en VirtIO porque su initramfs no tenía módulos y la imagen del vendor estaba bloqueada. Si hubieran empezado con VirtIO, habrían tenido una VM muerta y una lotería de tickets de soporte.

Porque tenían un backup en el punto “conocido bueno”, pudieron revertir cambios rápidamente mientras experimentaban con tipos de controlador. Finalmente mantuvieron esa appliance en SATA permanentemente, aceptando la pérdida de rendimiento porque la carga no justificaba el riesgo.

Ese es el verdadero movimiento de adulto: elegir fiabilidad aburrida sobre rendimiento teórico cuando el impacto al negocio no paga por el riesgo.

FAQ

1) ¿Debo convertir VMDK a raw o qcow2 para Proxmox?

Para ZFS o LVM-thin, normalmente elijo raw. Es más simple y a menudo más rápido. Elige qcow2 cuando necesites específicamente snapshots/compression basados en ficheros en un almacenamiento de directorio.

2) ¿Puede Proxmox importar un OVA directamente?

Proxmox puede trabajar con los discos dentro de un OVA, pero a menudo terminas extrayendo el OVA (es un tar archive) y convirtiendo los VMDK(s) tú mismo. Eso te da más control y menos sorpresas.

3) Mi VM usaba VMware PVSCSI. ¿Qué elijo en Proxmox?

Usa SATA para el primer arranque si eres cauteloso, luego pasa a VirtIO SCSI después de que los controladores estén en su lugar. PVSCSI es específico de VMware; no hay un “equivalente PVSCSI” que puedas activar directamente.

4) Windows arranca en SATA pero falla en VirtIO SCSI. ¿Por qué?

El controlador de VirtIO no está instalado/habilitado lo suficientemente temprano para el arranque. Arranca en SATA, instala los controladores VirtIO, luego cambia el controlador y reinicia.

5) Linux arranca pero cambió el nombre de la NIC y la red está caída. ¿Cuál es la solución limpia?

Actualiza tu configuración de red para el nuevo nombre de interfaz, o usa reglas de emparejamiento por MAC. Evita codificar a mano suposiciones eth0; ese barco zarpó hace años.

6) ¿Cuál es el error UEFI/BIOS más común?

Importar un invitado instalado en UEFI y arrancarlo con SeaBIOS (o al revés). Confirma con el VMX de ESXi y/o la presencia de una EFI System Partition.

7) ¿Necesito el QEMU guest agent?

¿Necesitas? No. ¿Lo quieres? Sí. Mejora el comportamiento de apagado, el reporte de IP y la automatización, y reduce la cantidad de discusiones “por qué Proxmox miente”.

8) Mi VM Windows importada perdió su IP estática. ¿Dónde se fue?

Windows trata la nueva NIC como un adaptador diferente. El adaptador antiguo puede seguir “poseyendo” la configuración IP pero estar oculto/desconectado. Reasigna la IP al adaptador activo y limpia NICs obsoletas si hace falta.

9) ¿Puedo dejar la VM en SATA para siempre?

Sí. Para cargas ligeras, la sobrecarga de SATA puede ser irrelevante. Para I/O pesado, VirtIO SCSI vale la pena una vez que la estabilidad esté probada.

10) ¿Cómo sé si el cuello de botella es el almacenamiento del host Proxmox o el invitado?

Empieza con métricas del host y salud del almacenamiento. Si el host está intercambiando, la CPU saturada o la latencia de almacenamiento alta, cambiar tipos de controlador en el invitado no te salvará.

Conclusión: próximos pasos que puedes hacer hoy

Si quieres que la migración se sienta aburrida (el mayor elogio en ops), hazla en dos fases: primero arranque, segundo rendimiento. Igualar firmware. Adjuntar el disco en un controlador conservador. Haz que arranque. Luego instala drivers VirtIO, cambia buses y solo entonces celebra.

Pasos concretos:

1. Elige una VM y ejecuta el flujo de trabajo “estabilidad-primero”: importa disco, arranca en SATA, valida servicios.
2. Instala QEMU guest agent y toma un backup de Proxmox en el primer punto conocido bueno.
3. Para Windows: monta la ISO VirtIO, instala storage + network drivers, luego migra a VirtIO SCSI + VirtIO NIC.
4. Para Linux: verifica que initramfs contenga módulos VirtIO, convierte fstab a UUIDs si hace falta, luego cambia controladores.
5. Solo después del éxito: estandariza plantillas y documenta tu mapeo NIC/VLAN para que la próxima migración no sea arqueología.