Migrar VM de ESXi a Proxmox sin vCenter: exportar OVF/OVA, importar y corregir controladores

Datos interesantes y contexto (lo que explica las rarezas)

• OVF es una especificación de empaquetado, no magia. OVF describe la VM (CPU, RAM, dispositivos). Los discos suelen ser archivos VMDK separados o empaquetados en una OVA (un archivo tar).
• OVA es solo tar. Si no puedes importar una OVA, casi siempre puedes extraerla con herramientas estándar y trabajar con el VMDK directamente.
• VMDK tiene variantes. ESXi usa comúnmente “monolithicSparse” o “streamOptimized” en las exportaciones. Algunos conversores e importadores odian algunas subclases. “Stream optimized” aparece con frecuencia en exportaciones OVF/OVA.
• VMXNET3 y PVSCSI son dispositivos de rendimiento específicos de VMware. Funcionan bien en ESXi, pero Proxmox/QEMU no los emulan de forma nativa. Cambiarás a VirtIO o Intel E1000, y eso tiene consecuencias de controladores.
• VirtIO es rápido porque está paravirtualizado. El sistema invitado necesita controladores. Linux generalmente ya los tiene; Windows a menudo no (a menos que sea moderno y ya tenga VirtIO instalado).
• UEFI vs BIOS es el asesino silencioso. Las VMs de ESXi pueden usar BIOS o EFI; Proxmox puede hacer ambos, pero debes coincidir. Arrancar un sistema instalado en BIOS con firmware UEFI es una forma rápida de obtener “no hay dispositivo de arranque”.
• Las snapshots complican las exportaciones. Si la VM tiene snapshots, el “disco actual” es una cadena de archivos delta. Las herramientas de exportación a veces consolidan; a veces no. Verifica siempre lo que exportaste.
• Thin vs thick afecta tiempo y almacenamiento. Un VMDK “thin” puede convertirse a una imagen “thick” raw si no tienes cuidado, inflando almacenamiento y tiempo de migración.
• Proxmox usa modelos de dispositivo de QEMU. La “misma” VM en un nuevo hipervisor sigue siendo hardware distinto. Los sistemas operativos son quisquillosos con las identidades de sus controladores de disco.

Decisiones que importan antes de tocar nada

1) Decide si toleras tiempo de inactividad

Si no tienes replicación de almacenamiento compartido o una herramienta de migración a nivel de bloque, una exportación OVF/OVA es una migración en frío por defecto. Puedes hacer un enfoque semi-tibio (ventana de corte, exportar, importar, probar y cortar), pero no finjas que es migración en vivo. Tus stakeholders interpretarán “migración” como “sin tiempo de inactividad”, porque el optimismo cuesta menos que la ingeniería.

2) Decide el formato de disco objetivo: raw vs qcow2

En Proxmox, normalmente colocarás discos en:

• ZFS: zvol raw es común; qcow2 es posible pero a menudo innecesario. Raw es más simple y rápido para la mayoría de cargas.
• LVM-thin: raw es típico (aprovisionamiento fino en la capa de almacenamiento).
• Almacenamiento en directorio (ext4/xfs): qcow2 es conveniente (snapshots), raw está bien (simplicidad).

Mi opinión: si tu almacenamiento en Proxmox es ZFS o LVM-thin, prefiere raw. Si es un directorio y necesitas snapshots, usa qcow2. No elijas qcow2 porque “suena virtual”. Elígelo porque coincide con tus necesidades de snapshots y rendimiento.

3) Decide los modelos de dispositivo objetivo: VirtIO cuando sea posible

Para invitados Linux: VirtIO para disco y NIC casi siempre funciona. Para Windows: VirtIO sigue siendo la respuesta correcta, pero debes planificar la instalación de controladores. Si es una VM Windows crítica y quieres que la migración sea aburrida, puedes arrancar inicialmente con SATA + E1000, y luego cambiar a VirtIO después de instalar los controladores.

4) Decide BIOS vs UEFI ahora

Coincide con el modo de arranque instalado en el invitado. Si la VM de ESXi arranca vía EFI, configura el firmware de Proxmox como OVMF (UEFI). Si es BIOS, usa SeaBIOS. Puedes convertir después, pero eso es un proyecto aparte con modos de fallo reales.

Idea parafraseada de Gene Kranz: “Ser duro y competente” es una elección que haces antes de la falla, no durante ella.

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

Esto es lo que haces cuando la VM importada no arranca, no ve su disco o no tiene red. No te precipites. Recorre la pila.

Primero: Confirma que la VM realmente tiene un disco arrancable adjunto

• Revisa hardware de la VM en Proxmox: disco presente, bus correcto (SATA/SCSI/VirtIO), orden de arranque correcto.
• Revisa el almacenamiento: ¿existe la imagen de disco donde Proxmox cree que está?

Segundo: Confirma que el firmware coincide con la instalación (UEFI vs BIOS)

• Instalación en BIOS + firmware UEFI = teatro de “no hay dispositivo de arranque”.
• Instalación UEFI + firmware BIOS = lo mismo, pero con confusión extra.
• UEFI suele requerir un disco EFI en Proxmox (pequeño dispositivo separado para NVRAM).

Tercero: Confirma disponibilidad de drivers para el controlador de disco y la NIC elegidos

• Si Windows hace blue-screen temprano (INACCESSIBLE_BOOT_DEVICE): falta el driver del controlador de disco. Arranca con SATA, instala VirtIO, cambia después.
• Si Linux cae a initramfs: mapeo de dispositivo root incorrecto o initramfs sin drivers para el nuevo controlador; reconstruye initramfs y/o ajusta fstab/GRUB.

Cuarto: Confirma que la red está mapeada correctamente

• ¿Bridge adjunto? ¿Etiqueta VLAN correcta? ¿Firewall en Proxmox bloqueando?
• Sistema invitado: nombre de NIC cambiado (Linux), métrica de interfaz extraña (Windows), o IP estática ligada al adaptador antiguo.

Quinto: Problemas de rendimiento después de arrancar

• Revisa si usaste emulación IDE o E1000 para cargas de alto rendimiento por error.
• Revisa modo de caché y iothreads. Revisa latencia de almacenamiento en el nodo Proxmox. Rara vez es “Proxmox lento” y suele ser “ahora tu ruta de almacenamiento es distinta”.

Tareas prácticas con comandos, significado de salidas y decisiones

Estos son comandos ejecutables y qué hacer con los resultados. El objetivo es reemplazar conjeturas por evidencia.

Task 1: Identificar el modo de arranque y tipos de controladores en ESXi

En el host ESXi (SSH habilitado), encuentra el archivo VMX y revísalo.

cr0x@server:~$ vim-cmd vmsvc/getallvms
Vmid   Name                 File                                      Guest OS       Version   Annotation
12     app-prod-01          [datastore1] app-prod-01/app-prod-01.vmx   ubuntu64Guest  vmx-14

Significado: Tienes la ruta del datastore al VMX. Ahora puedes revisar firmware y tipos de dispositivo.

Decisión: Si esta VM es crítica, la estrategia de snapshot/consolidación importa antes de exportar.

cr0x@server:~$ grep -E 'firmware|scsi|sata|nvme|ethernet|virtualDev' /vmfs/volumes/datastore1/app-prod-01/app-prod-01.vmx
firmware = "efi"
scsi0.virtualDev = "pvscsi"
ethernet0.virtualDev = "vmxnet3"

Significado: Arranque EFI, controlador PVSCSI, NIC VMXNET3. Ninguno de esos mapea 1:1 a los valores por defecto de Proxmox.

Decisión: Configura la VM en Proxmox con OVMF (UEFI). Planea cambiar controladores a VirtIO (o temporalmente a SATA/E1000 para Windows).

Task 2: Buscar snapshots (y no ignorarlos)

cr0x@server:~$ vim-cmd vmsvc/snapshot.get 12
Get Snapshot:
|-ROOT
|--Snapshot Name        : pre-patch
|--Snapshot Id          : 1
|--Snapshot Created On  : 2025-11-02
|--Snapshot State       : poweredOff

Significado: Existen snapshots. El comportamiento de exportación depende de la herramienta; puede exportar la cadena o una imagen consolidada.

Decisión: Prefiere consolidar snapshots antes de exportar a menos que tengas una razón específica para no hacerlo. Las exportaciones no son el lugar para cadenas ingeniosas de snapshots.

Task 3: Exportar sin vCenter (opciones prácticas)

Sin vCenter, normalmente exportas copiando archivos del datastore o usando una herramienta OVF desde una estación de trabajo que pueda alcanzar la IP de gestión de ESXi.

Si ya tienes una exportación OVA/OVF, salta adelante. Si no, copiar los VMDK(s) directamente a menudo es lo más sencillo.

cr0x@server:~$ ls -lh /vmfs/volumes/datastore1/app-prod-01/
total 22G
-rw-------    1 root     root        8.5K Nov  2 09:10 app-prod-01.vmx
-rw-------    1 root     root        2.0K Nov  2 09:10 app-prod-01.nvram
-rw-------    1 root     root        512B Nov  2 09:10 app-prod-01.vmsd
-rw-------    1 root     root        30G  Nov  2 09:11 app-prod-01-flat.vmdk
-rw-------    1 root     root        1.2K Nov  2 09:11 app-prod-01.vmdk

Significado: Tienes un VMDK descriptor y su extensión flat. Ese es un layout común en ESXi.

Decisión: Copia tanto el .vmdk como el -flat.vmdk si haces una copia en crudo. Si solo copias el descriptor, copias una etiqueta, no el disco.

Task 4: Verificar qué tipo de VMDK tienes

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

Significado: Este es un descriptor estilo VMFS apuntando al flat extent. Bien.

Decisión: La conversión con qemu-img debería funcionar. Si createType es streamOptimized, espera un comportamiento distinto y posiblemente un paso intermedio de conversión.

Task 5: En Proxmox, confirma destinos de almacenamiento y espacio libre

cr0x@server:~$ pvesm status
Name       Type     Status           Total            Used       Available        %
local      dir      active        19619632         2231040        16252232   11.37%
local-lvm  lvmthin  active       468582400        89366528       379215872   19.07%
zfspool    zfspool  active       950000000       410000000       540000000   43.16%

Significado: Tienes múltiples backends de almacenamiento. El espacio está disponible, pero no infinito.

Decisión: Elige el almacenamiento objetivo según rendimiento y necesidad de snapshots. No pongas una VM de base de datos en un almacenamiento lento por ser “fácil”.

Task 6: Extraer una OVA (si eso es lo que tienes)

cr0x@server:~$ mkdir -p /var/tmp/ova/app-prod-01 && tar -xvf app-prod-01.ova -C /var/tmp/ova/app-prod-01
app-prod-01.ovf
app-prod-01.mf
app-prod-01-disk1.vmdk

Significado: Ahora tienes el descriptor OVF y los VMDK(s).

Decisión: Ignora el archivo manifest si debes, pero si estás en un entorno regulado, la validación de checksums no es teatro opcional—es la traza de auditoría.

Task 7: Inspeccionar el OVF para expectativas de dispositivo

cr0x@server:~$ grep -nE 'OperatingSystemSection|VirtualSystemType|ResourceType|rasd:ResourceSubType' /var/tmp/ova/app-prod-01/app-prod-01.ovf | head
25:  <OperatingSystemSection ovf:id="94">
44:  <vssd:VirtualSystemType>vmx-14</vssd:VirtualSystemType>
120: <rasd:ResourceType>17</rasd:ResourceType>
121: <rasd:ResourceSubType>vmxnet3</rasd:ResourceSubType>

Significado: Describe hardware VMware (vmxnet3). Proxmox no respetará ese modelo de dispositivo.

Decisión: Trata OVF como metadata, no como promesa. Definirás el hardware objetivo explícitamente en Proxmox.

Task 8: Convertir VMDK a raw o qcow2 en Proxmox

Elige raw para objetivos ZFS/LVM-thin; qcow2 para directorios con snapshots.

cr0x@server:~$ qemu-img info /var/tmp/ova/app-prod-01/app-prod-01-disk1.vmdk
image: /var/tmp/ova/app-prod-01/app-prod-01-disk1.vmdk
file format: vmdk
virtual size: 30 GiB (32212254720 bytes)
disk size: 8.2 GiB
cluster_size: 65536
Format specific information:
    cid: 12345678
    create type: streamOptimized

Significado: Disco streamOptimized. La conversión funciona, pero presta atención al comportamiento sparse.

Decisión: Convierte con qemu-img convert. Si ves corrupción o fallos, convierte primero a raw y luego importa.

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw /var/tmp/ova/app-prod-01/app-prod-01-disk1.vmdk /var/tmp/app-prod-01-disk1.raw
    (100.00/100%)

Significado: Tienes una imagen raw lista para importar. Que el progreso llegue al 100% es necesario, no suficiente—aún valida el arranque luego.

Decisión: Si tu backend soporta aprovisionamiento fino en la capa de bloque (ZFS zvol, LVM-thin), importa raw en ese backend.

Task 9: Crear la VM en Proxmox (sin adjuntar discos todavía)

cr0x@server:~$ qm create 120 --name app-prod-01 --memory 8192 --cores 4 --cpu host --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci --ostype l26 --machine q35
create VM 120: success

Significado: La VM existe con NIC VirtIO y controlador SCSI VirtIO. El tipo de máquina q35 es moderno y funciona bien con UEFI.

Decisión: Si el origen es UEFI, configura OVMF ahora. Si es BIOS, deja SeaBIOS.

Task 10: Configurar UEFI (OVMF) y añadir un disco EFI cuando haga falta

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

Significado: La VM arrancará con firmware UEFI y tiene un disco para variables EFI.

Decisión: Si no se usó Secure Boot en ESXi, mantén pre-enrolled-keys=0 para evitar problemas de firma.

Task 11: Importar el disco al almacenamiento gestionado por Proxmox

cr0x@server:~$ qm importdisk 120 /var/tmp/app-prod-01-disk1.raw zfspool --format raw
importing disk '/var/tmp/app-prod-01-disk1.raw' to VM 120 ...
transferred 32212254720 bytes in 94 seconds (342.7 MiB/s)
Successfully imported disk as 'zfspool:vm-120-disk-0'

Significado: El disco ahora es un volumen gestionado por el almacenamiento. Esto es lo que quieres para backups, replicación y cordura.

Decisión: Adjunta el disco importado en el bus correcto. Para Linux, VirtIO SCSI suele ser adecuado. Para Windows sin controladores VirtIO, arranca con SATA.

Task 12: Adjuntar disco y establecer orden de arranque

cr0x@server:~$ qm set 120 --scsi0 zfspool:vm-120-disk-0,discard=on,ssd=1 --boot order=scsi0
update VM 120: -scsi0 zfspool:vm-120-disk-0,discard=on,ssd=1 -boot order=scsi0

Significado: Disco adjuntado como SCSI (controlador VirtIO SCSI) y puesto como primer dispositivo de arranque.

Decisión: Si el arranque falla y es un invitado Windows, cambia temporalmente a SATA e instala drivers VirtIO.

Task 13: Inicia la VM y observa la consola como si te importara

cr0x@server:~$ qm start 120

cr0x@server:~$ qm terminal 120
starting serial terminal on interface serial0 (press Ctrl+O to exit)
[    0.000000] Linux version 5.15.0-...
[    3.214567] virtio_scsi 0000:00:05.0: 1/0/0 default/read/poll queues
...

Significado: Si ves inicialización de drivers virtio, vas por buen camino. Si cae a initramfs, necesitas arreglar root device e initramfs.

Decisión: No “esperes a ver” por 20 minutos. Los fallos de arranque no se curan con tiempo.

Task 14: Validar visibilidad del disco dentro de Linux

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME   SIZE TYPE FSTYPE MOUNTPOINT
sda     30G disk
├─sda1  512M part vfat   /boot/efi
├─sda2    1G part ext4   /boot
└─sda3 28.5G part ext4   /

Significado: Particiones presentes y montadas. El SO ve el disco.

Decisión: Si los nombres de dispositivo cambiaron (por ejemplo, de /dev/sda a /dev/vda), confirma que /etc/fstab usa UUIDs, no nombres de dispositivos.

Task 15: Validar dispositivo de red y estado de enlace

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens18            UP             52:54:00:12:34:56

Significado: Interfaz arriba. El nombre probablemente cambió respecto a ESXi. Eso es normal.

Decisión: Si el nombre de la interfaz cambió y tu configuración de red referencia el antiguo, actualiza netplan/systemd-networkd/ifcfg según corresponda.

Task 16: En Proxmox, revisa bridge y tagging VLAN

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.10/24
        gateway 192.0.2.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Significado: Bridge Linux estándar. Las etiquetas VLAN pueden establecerse por VM NIC o mediante configuración de bridge con conciencia VLAN.

Decisión: Si necesitas trunking VLAN, ajusta bridge-vlan-aware yes y configura etiquetas de forma intencional. No adivines; tu switch no te perdonará.

Task 17: Confirma que Proxmox ve la configuración de VM que pretendías

cr0x@server:~$ qm config 120
bios: ovmf
boot: order=scsi0
cores: 4
cpu: host
efidisk0: zfspool:vm-120-disk-1,size=4M,pre-enrolled-keys=0
memory: 8192
name: app-prod-01
net0: virtio=52:54:00:12:34:56,bridge=vmbr0
ostype: l26
scsi0: zfspool:vm-120-disk-0,discard=on,ssd=1
scsihw: virtio-scsi-pci
machine: q35

Significado: Esta es la verdad canónica. Si la GUI difiere, la configuración aún gana.

Decisión: Conserva esta salida en tu registro de cambios. Es cómo probarás qué cambió más tarde.

Broma #1: OVF es como un manifiesto de envío: te dice qué debería estar en la caja, no si la caja sobrevivió al montacargas.

Listas de verificación / plan paso a paso (aburridamente correcto)

Checklist previa a la migración (origen ESXi)

1. Documentar hardware de la VM: firmware (EFI/BIOS), controlador de disco, tipo de NIC, número de discos, configuración IP.
2. Limpiar snapshots: consolidar o al menos entender la cadena. Exportar una cadena de snapshots es donde los datos se pierden.
3. Quiescer el invitado: apagar a nivel de aplicación si es posible (bases de datos, colas). Si no puedes, al menos apagar la VM limpiamente.
4. Recolectar controladores: para Windows, prepara el ISO de controladores VirtIO. Para Linux, asegúrate de que la herramienta de initramfs exista dentro del invitado.
5. Decidir método de cutover: ¿nueva IP o misma IP? ¿Cambios DNS? ¿Reservas MAC? ¿Reglas de firewall?

Checklist de ejecución de migración (Proxmox)

1. Crear la VM con CPU/RAM similar al origen. No ajustes exactos aún.
2. Establecer firmware (OVMF vs SeaBIOS) para coincidir con el origen.
3. Importar disco al backend de almacenamiento elegido.
4. Adjuntar disco con un controlador sensato (VirtIO SCSI para Linux; SATA primero para Windows si faltan drivers).
5. Establecer orden de arranque explícitamente.
6. Arrancar con la consola abierta; capturar errores temprano.
7. Arreglar arranque/controladores (ver secciones abajo).
8. Arreglar mapeo de red, confirmar conectividad, confirmar hostname/DNS.
9. Eliminar VMware Tools si corresponde, instalar QEMU guest agent.
10. Ejecutar validación de carga: I/O de disco, comprobaciones de aplicación, logs, monitoring.

Checklist post-migración (estabilidad y operabilidad)

1. Backups: asegura que los jobs de backup de Proxmox incluyan la VM y que una restauración de prueba funcione.
2. Monitorización: confirma que la VM esté en las alertas correctas, con endpoints de agente adecuados.
3. Sincronización horaria: verifica NTP/chrony; no confíes en la magia de tiempo del hipervisor.
4. Sanidad de rendimiento: confirma que estás usando VirtIO y no IDE. Revisa scheduler de I/O y ajustes de discard/TRIM si aplican.
5. Registro de cambios: guarda la configuración de hardware “antes” y “después” y detalles de red.

Corrección de controladores y arranque: Windows y Linux

Windows: el camino seguro (arrancar primero, optimizar después)

Si Windows estaba en ESXi con PVSCSI y VMXNET3, no sabrá qué hacer con VirtIO automáticamente. El modo fallo suele ser un BSOD al arrancar: INACCESSIBLE_BOOT_DEVICE. Eso es Windows diciendo: “Buen controlador nuevo. No hablo ese dialecto.”

Secuencia recomendada para Windows

1. Importa el disco y adjúntalo como SATA (o incluso IDE si es necesario, pero SATA es menos horrible).
2. Modelo NIC: usa E1000 o VirtIO si ya tienes el driver instalado. Si necesitas conectividad inicial sin drivers, E1000 son ruedas de entrenamiento.
3. Arranca Windows con éxito.
4. Montar el ISO de drivers VirtIO e instalar drivers de almacenamiento y red.
5. Cambiar controlador de disco a VirtIO SCSI (o VirtIO block), reiniciar y verificar.
6. Cambiar la NIC a VirtIO, reiniciar y verificar.

En términos de Proxmox, a menudo eso se ve como: empezar con --sata0 y e1000, luego pasar a --scsi0 más NIC VirtIO.

cr0x@server:~$ qm set 130 --name win-app-01 --memory 16384 --cores 6 --cpu host --net0 e1000,bridge=vmbr0 --sata0 zfspool:vm-130-disk-0 --boot order=sata0
update VM 130: -name win-app-01 -memory 16384 -cores 6 -cpu host -net0 e1000,bridge=vmbr0 -sata0 zfspool:vm-130-disk-0 -boot order=sata0

Significado: Elegiste compatibilidad. Primero arranca, luego modernizas.

Decisión: Si la VM es controlador de dominio o tiene enlaces NIC estrictos, planifica la transición de adaptadores cuidadosamente para evitar perder identidad de red.

Linux: por lo general fácil, hasta que no lo es

Linux tiende a arrancar en VirtIO sin drama. Cuando no lo hace, las razones son consistentes:

• /etc/fstab referencia /dev/sdX en lugar de UUID/LABEL y el nombre del dispositivo cambió.
• initramfs sin módulos para el nuevo controlador (menos común en distribuciones modernas, aún ocurre en imágenes mínimas).
• mismatch de modo de arranque (UEFI vs BIOS).

Solución: confirma que fstab usa UUIDs

cr0x@server:~$ grep -vE '^\s*#|^\s*$' /etc/fstab
UUID=3d2f7a2f-aaaa-bbbb-cccc-111122223333 / ext4 defaults 0 1
UUID=9f8e7d6c-aaaa-bbbb-cccc-444455556666 /boot ext4 defaults 0 2
UUID=1A2B-3C4D /boot/efi vfat umask=0077 0 1

Significado: Montajes basados en UUID. Bien. El renombrado de dispositivos no romperá el arranque.

Decisión: Si ves montajes con /dev/sda1, arréglalos antes de reiniciar otra vez.

Solución: reconstruir initramfs (ejemplo Debian/Ubuntu)

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.15.0-92-generic

Significado: initramfs refrescado; incluirá los módulos necesarios actuales.

Decisión: Si la VM solo arranca con un tipo de controlador, reconstruye initramfs mientras está en un estado funcional, luego cambia controladores.

Solución: reinstalar GRUB tras un mismatch de firmware o cambio de mapeo de disco

Para instalaciones BIOS en un nuevo controlador virtual, reinstalar GRUB puede ser el martillo más simple.

cr0x@server:~$ grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-92-generic
done

Significado: El gestor de arranque se restablece para modo BIOS en ese disco.

Decisión: Si en realidad eres UEFI, no ejecutes grub-install en BIOS. Solo crearás una segunda capa de confusión de arranque.

Broma #2: UEFI es genial hasta que no lo es, momento en el que se convierte en una danza interpretativa realizada por el firmware.

Redes: bridges, VLANs y sorpresas de MAC

Selección de bridge: conecta la VM al mundo correcto

La red en Proxmox es la red de Linux. Eso es un cumplido y una advertencia.

• vmbr0 suele ser tu bridge de LAN.
• El etiquetado VLAN puede hacerse por NIC en Proxmox (tag=123) o usando bridges con conciencia VLAN.
• Bonding/LACP se configura en el host; la VM solo ve una NIC.

cr0x@server:~$ qm set 120 --net0 virtio=52:54:00:12:34:56,bridge=vmbr0,tag=120,firewall=1
update VM 120: -net0 virtio=52:54:00:12:34:56,bridge=vmbr0,tag=120,firewall=1

Significado: La NIC de la VM está en VLAN 120, firewall habilitado en la capa Proxmox.

Decisión: Si habilitas el firewall de Proxmox, define reglas intencionales. Si no, migrarás la VM a una brecha de aire auto-impuesta.

Dirección MAC y licenciamiento

Algún software vincula licencias a direcciones MAC. Algunas pilas de seguridad también confían en ellas. Proxmox generará una MAC nueva a menos que la establezcas.

cr0x@server:~$ qm config 120 | grep -E '^net0'
net0: virtio=52:54:00:12:34:56,bridge=vmbr0

Significado: Tienes una MAC estable configurada en la configuración de la VM.

Decisión: Si necesitas preservar la MAC de ESXi, establécela explícitamente aquí antes del primer arranque para evitar el comportamiento de “NIC nueva” en el invitado.

Cambios de nombre de NIC en Linux y reglas persistentes

En ESXi, tu NIC pudo haber sido ens160. En Proxmox, puede ser ens18 o enp0s18. Si tu distro usa netplan o systemd-networkd, la lógica de renombre puede darte problemas.

cr0x@server:~$ journalctl -b | grep -iE 'rename|ens|enp' | head
systemd-udevd[312]: renamed network interface eth0 to ens18
systemd-networkd[401]: ens18: Link UP

Significado: Ocurrió un renombrado; systemd ve la interfaz.

Decisión: Actualiza tu configuración de red para coincidir con el nuevo nombre, o fija el nombrado usando reglas de match por dirección MAC.

Tres micro-historias corporativas (cómo sale mal en la vida real)

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

La empresa tenía un host ESXi independiente ejecutando un puñado de VMs “temporales”. Ya sabes cómo termina esto: las VMs temporales habían estado generando ingresos durante años, como un cable de extensión olvidado detrás de un mueble.

Alguien finalmente compró un clúster Proxmox. El mandato fue simple: migrar la VM más crítica durante un fin de semana, sin vCenter, y sin gastar dinero. El ingeniero exportó una OVA desde ESXi, la importó y la VM arrancó. Ese fue el momento en que todos se relajaron, que históricamente es el momento más peligroso en operaciones.

El lunes por la mañana, los usuarios reportaron fallos intermitentes. La aplicación estaba “arriba”, pero la mitad de las solicitudes hacían timeout. La causa raíz no fue CPU ni memoria. Fue la red: la VM tenía dos NIC en ESXi—una para frontend y otra para backend—y la metadata del OVA no mapeó roles de dispositivo. En Proxmox, el orden de NICs cambió, el SO mantuvo sus asignaciones de IP estáticas y la app intentó hablar con servicios backend a través de la VLAN frontend.

Se puso peor: los cheques de monitorización estaban en verde porque el endpoint de health vivía en la interfaz frontend. Las fallas backend solo aparecieron en transacciones reales. La suposición fue “si arranca y hace ping, está bien”. Esa suposición costó una caída.

La solución fue aburrida: mapear NICs intencionalmente (bridge + tag VLAN), fijar MACs, verificar tablas de enrutamiento y validar el grafo real de dependencias de la aplicación—no solo ICMP. La lección quedó porque dolió y fue pública.

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

Otro equipo trató la migración como una oportunidad de rendimiento. Convirtieron todos los discos a qcow2 porque “los snapshots son útiles” y activaron cada ajuste de caché que sonara rápido. También pasaron VMs Windows directamente a VirtIO para disco y NIC en el primer arranque, porque lo habían hecho una vez en laboratorio.

Los resultados fueron impresionantes en el mismo sentido que una fábrica de fuegos artificiales puede ser “impresionante”. Algunas VMs no arrancaron (problema de drivers). Otras arrancaron pero tuvieron picos de latencia extraños bajo carga. El equipo persiguió fantasmas dentro del SO—antivirus, actualizaciones de Windows, “tal vez SQL hace algo”.

El problema real fue una pila de pequeñas decisiones: qcow2 sobre almacenamiento en directorio apoyado en un controlador RAID con caché volátil, caching agresivo en writeback en QEMU y sin garantías de UPS. Funcionó hasta que no funcionó. La latencia subió durante eventos de flush del host y el perfil de riesgo era inapropiado para cargas con estado.

Revirtieron a volúmenes raw en ZFS zvols para las bases de datos, usaron caching conservador y el rendimiento se estabilizó de inmediato. Los snapshots se movieron a snapshots nativos de ZFS donde debían estar. Optimizar no es malo; la optimización ilimitada sí lo es.

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

Una empresa regulada debía migrar una VM ESXi que ejecutaba un servicio con dependencias antiguas y un proveedor que hacía tiempo que había quedado atrás. El entorno no tenía vCenter. El host ESXi era una “mascota”, no ganado, con almacenamiento local y un equipo de instalaciones nervioso.

El SRE de guardia insistió en un proceso aburrido: capturar la configuración VMX, registrar checksums de disco tras la exportación, importar en Proxmox con el mismo modo de arranque y mantener la VM vieja apagada pero intacta durante una semana laboral completa. También exigieron un arranque de prueba en una VLAN aislada antes del corte a producción.

Durante la prueba aislada, la VM arrancó pero no pudo alcanzar su servidor de licencias. El problema no era la red; era la deriva del tiempo. La VM había confiado silenciosamente en la sincronización de tiempo de VMware Tools, y Proxmox no ofrece ese comportamiento exacto. El handshake de licencia falló cuando la deriva de reloj superó la tolerancia.

Porque el equipo probó en aislamiento y tenía un plan de reversión, configuraron NTP/chrony correctamente, documentaron el comportamiento y luego cortaron limpiamente. No pasó nada dramático en producción, que es la forma más alta de cumplido que puede recibir alguien de operaciones.

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

1) Síntoma: “No hay dispositivo de arranque” inmediatamente al iniciar

Causa raíz: Mismatch BIOS/UEFI, falta disco EFI o orden de arranque incorrecto.

Solución: Coincide firmware con el origen (OVMF para EFI, SeaBIOS para BIOS). Añade efidisk0 para OVMF. Establece orden de arranque explícito.

2) Síntoma: Windows BSOD INACCESSIBLE_BOOT_DEVICE

Causa raíz: Controlador de almacenamiento cambiado a VirtIO sin driver instalado.

Solución: Adjunta disco como SATA, arranca, instala drivers VirtIO de almacenamiento, luego cambia a VirtIO SCSI y reinicia.

3) Síntoma: Linux cae a initramfs o shell de emergencia

Causa raíz: Sistema de archivos root no encontrado por cambio de nombre de dispositivo, initramfs sin módulos o fstab apuntando a /dev/sdX.

Solución: Usa UUIDs en fstab, reconstruye initramfs, verifica que GRUB apunte al root correcto.

4) Síntoma: VM arranca, pero sin conectividad de red

Causa raíz: Bridge/VLAN mal, reglas de firewall de Proxmox, cambio de nombre de NIC en el invitado o IP estática de Windows ligada al adaptador antiguo.

Solución: Verifica bridge y tagging VLAN en el host; desactiva temporalmente firewall de Proxmox para aislar; corrige configuración de red del invitado; preserva MAC si es necesario.

5) Síntoma: Disco presente en Proxmox pero el invitado ve 0 bytes o sistema de ficheros corrupto

Causa raíz: Copia incompleta de extents VMDK, cadena de snapshots no consolidada o error de conversión desde streamOptimized.

Solución: Reexporta tras consolidar snapshots; verifica que se copiaran descriptor y flat; reconvierte usando un intermedio raw; valida con checksums.

6) Síntoma: VM lenta, especialmente I/O

Causa raíz: Uso de IDE/SATA para una carga que necesita VirtIO, modo de caché erróneo, mismatch de backend de almacenamiento o falta de iothread para discos muy ocupados.

Solución: Mueve discos a VirtIO SCSI con iothreads cuando corresponda, usa volúmenes nativos del almacenamiento (ZFS/LVM-thin), revisa ajustes de caché, mide latencia en el host.

7) Síntoma: La aplicación funciona pero la licencia falla

Causa raíz: Cambio de MAC, deriva de tiempo o cambio de huella de hardware.

Solución: Preserva la MAC cuando sea necesario, arregla NTP, documenta el nuevo perfil de hardware virtual y contacta al proveedor si es inevitable.

Preguntas frecuentes

1) ¿Necesito vCenter para exportar un OVF/OVA?

No. vCenter lo hace más sencillo, pero puedes exportar copiando archivos de datastore de ESXi o usando una herramienta OVF contra el host ESXi directamente.

2) ¿Es mejor exportar OVF/OVA o copiar VMDKs?

Si puedes apagar limpiamente, copiar archivos VMDK suele ser más simple y transparente. OVF/OVA es conveniente para empaquetar, pero puede ocultar peculiaridades de formato de disco (como streamOptimized).

3) ¿Proxmox puede importar OVF directamente?

No de una manera en la que debas apostar la producción. Trata OVF como descriptor; extrae discos e impórtalos con qm importdisk tras convertir si es necesario.

4) ¿Debo usar qcow2 o raw en Proxmox?

Raw en ZFS zvols o LVM-thin suele ser la decisión correcta por rendimiento y simplicidad. qcow2 está bien en almacenamiento en directorio cuando quieres snapshots basados en fichero.

5) Mi VM Linux arranca en ESXi pero falla en Proxmox con initramfs. ¿Por qué?

Porque el “hardware” cambió: modelo de controlador, nombres de disco o firmware. Arregla fstab para usar UUIDs, reconstruye initramfs y confirma modo BIOS/UEFI.

6) ¿Cómo manejo los drivers VirtIO en Windows de forma segura?

Arranca Windows en SATA primero, instala drivers VirtIO desde un ISO adjunto, luego cambia el controlador de disco a VirtIO SCSI y la NIC a VirtIO. Un cambio a la vez, con reinicios intermedios.

7) ¿Necesito desinstalar VMware Tools?

Generalmente sí, eventualmente. Puede interferir con la sincronización horaria y algunos comportamientos de dispositivo. No lo hagas como primera acción el día de la migración; estabiliza arranque y red primero.

8) ¿Qué hay sobre el soporte de guest agent en Proxmox?

Instala el QEMU guest agent en la VM después de que esté estable. Mejora comportamiento de apagado, reporte de IPs y algunos flujos de backup. Es higiene operativa.

9) ¿Puedo mantener la misma IP después de la migración?

Sí, pero solo después de asegurarte de que la VM esté en la VLAN/bridge correcto y tu plan de cutover evite IPs duplicadas. Si puedes, prueba con una IP temporal primero.

10) ¿Cuál es el mayor “unknown unknown” en estas migraciones?

Dependencias en comportamientos específicos de VMware: sincronización horaria, orden de NICs, drivers personalizados y suposiciones de snapshots. Audita eso por adelantado y la migración se vuelve rutinaria.

Conclusión: próximos pasos que realmente reducen el riesgo

Si solo tomas tres acciones de esta guía, haz estas:

1. Coincide el modo de arranque (UEFI vs BIOS) antes del primer arranque en Proxmox. Es la victoria más barata.
2. Arranca para compatibilidad primero (especialmente Windows), luego migra a VirtIO una vez instalados los controladores.
3. Prueba la corrección con comandos: presencia de almacenamiento, orden de arranque, estado de interfaces y logs. Tu memoria mentirá bajo presión.

Operacionalmente, trata la migración como dos entregables: capacidad de arranque y operabilidad. Obtener un prompt de login no es la meta final. Backups, monitorización, sincronía horaria y rendimiento son lo que evitará que vuelvas a esta VM a las 3 a.m. con una audiencia.