Migración de almacenamiento de ESXi a Proxmox: mover datastores VMFS a ZFS, NFS o iSCSI con tiempo de inactividad mínimo

Hechos y contexto que cambian las decisiones

Aquí hay algunos hechos concretos e historia que importan cuando planeás migraciones de VMFS a Proxmox. No es trivia. Es combustible para tomar decisiones.

1. VMFS fue diseñado para acceso concurrente por múltiples hosts ESXi, con primitivas de bloqueo en disco que asumen la pila de VMware. Linux puede leer VMFS, pero no es ciudadano de primera clase en el mundo Proxmox.
2. VMDK no es “un único formato”. Existen variantes monolíticas sparse, thick, divididas y optimizadas para stream. La ruta de exportación (OVF/OVA) puede cambiar silenciosamente el formato de disco que terminás copiando.
3. ZFS nació en Sun Microsystems con una filosofía de “checksumming end-to-end”. Eso importa para imágenes de VM porque la corrupción silenciosa es un modo de falla real, no una historia de miedo.
4. NFS existe desde los años 80 y ha tenido décadas para volverse aburrido. En sistemas de producción, aburrido es una característica por la que te llaman menos de noche.
5. iSCSI es almacenamiento a nivel de bloque sobre IP — lo que significa que el host de VM toma la responsabilidad del sistema de archivos (como ext4, xfs o ZFS). Eso hace que el tuning de rendimiento y los dominios de falla sean muy diferentes a NFS.
6. El change block tracking (CBT) de VMware puede hacer copias incrementales rápidas en el mundo VMware, pero no es un concepto nativo en Proxmox. Si dependías de eso indirectamente (productos de backup), planificá un cambio de comportamiento.
7. Thin provisioning es una política, no una ley de la física. Sobreaprovisionar es fácil; recuperar espacio después es donde empieza el drama, especialmente en conversiones de formato.
8. El alineamiento de sectores 4K solía ser opcional. Ya no lo es. El desalineamiento puede costarte escrituras dobles y momentos de “¿por qué este SSD es más lento que uno mecánico?” durante migraciones.

Broma #1: Las migraciones de almacenamiento son como mudarse: las cajas se multiplican cuando no mirás, y de algún modo terminás cargando una impresora que no usás desde 2017.

Elegí tu zona de aterrizaje: ZFS vs NFS vs iSCSI

ZFS en Proxmox (local o compartido vía replicación)

Cuándo elegirlo: Querés integridad fuerte de datos, snapshots, control operativo simple, y podés mantener discos de VM locales en un nodo Proxmox (o te conformás con HA basada en replicación en lugar de almacenamiento compartido).

Realidad operativa: ZFS no es “instalalo y olvidalo”. Es “instalalo y monitoréalo”. ZFS se comporta de forma excelente cuando respetás sus necesidades: suficiente RAM, decisiones sensatas de recordsize/volblocksize y no fingir que un RAIDZ1 de SSDs de consumo es almacenamiento empresarial.

Ángulo de downtime mínimo: Los snapshots de ZFS y zfs send/zfs receive son tus aliados para transferencias grandes y cortes repetibles. Si podés preparar un dataset y hacer un envío incremental final durante una ventana corta, obtenés un downtime predecible.

Evitarlo si: Necesitás semántica de almacenamiento compartido para migración en vivo entre nodos y no querés gestionar un cronograma de replicación con lógica de failover. Proxmox puede replicar, pero no es idéntico a un “datastore compartido”.

NFS (almacenamiento compartido sin la personalidad de iSCSI)

Cuándo elegirlo: Querés almacenamiento compartido fácil de entender, tenés un NAS sólido o un servidor Linux NFS, y valorás simplicidad operativa y portabilidad.

Realidad operativa: El rendimiento de NFS depende mucho del servidor, la red y las opciones de montaje. La ventaja: cuando algo se rompe, las herramientas y modelos mentales son comunes. La desventaja: si tu red tiene microburst, lo vas a notar.

Ángulo de downtime mínimo: NFS compartido te permite colocar discos de VM centralmente para mover cómputo por separado. Para el corte, igual tenés que copiar los datos, pero una vez en NFS, evacuar hosts es mucho más simple.

Evitarlo si: Tu única red es una LAN congestionada con buffering desconocido y no podés aislar el tráfico de almacenamiento. NFS sobre una red inestable se siente como una base de datos sobre una cama elástica.

iSCSI (almacenamiento por bloques con bordes afilados)

Cuándo elegirlo: Ya tenés un SAN, necesitás semántica a nivel de bloque, querés multipath y tenés disciplina para gestionarlo. iSCSI está bien—si lo tratás como un sistema, no como una casilla para marcar.

Realidad operativa: iSCSI te da modos de falla que parecen “el almacenamiento está lento” pero en realidad son “un path está flapping y multipath está haciendo una danza interpretativa”. Tu monitorización debe incluir salud de paths y distribución de latencias, no solo throughput.

Ángulo de downtime mínimo: Si tu LUN iSCSI ya es el backing store compartido, podés migrar cómputo con más libertad. La migración de datos (VMFS a lo que uses en el LUN) sigue existiendo, pero después ganás flexibilidad.

Evitarlo si: No tenés redes redundantes, no podés hacer multipath correctamente, o necesitás que el equipo duerma. iSCSI sin estándares es generador de tickets.

Arquitecturas objetivo que realmente funcionan

Arquitectura A: Proxmox de nodo único con ZFS local

Ideal para entornos pequeños a medianos, labs, sucursales o equipos que migran por fases. Poné VMs en un pool ZFS local. Usá snapshots para rollback. Usá replicación ZFS a un segundo nodo para recuperación ante desastres o “HA del pobre”.

Decisiones clave: mirror vs RAIDZ, SLOG o no, compresión, ashift y cómo manejarás backups (Proxmox Backup Server u otro). La disposición del pool es una puerta de una sola vía.

Arquitectura B: Cluster Proxmox con NFS compartido

Esta es la opción “hazlo aburrido”. Almacenamiento NFS compartido para discos de VM + red separada de Proxmox para corosync + ruta de backup dedicada. La migración en vivo se convierte en mover cómputo, no almacenamiento.

Decisiones clave: diseño del servidor NFS (NAS respaldado en ZFS es común), aislamiento de red (VLANs o NICs físicas separadas) y opciones de montaje que coincidan con tu carga.

Arquitectura C: Cluster Proxmox con iSCSI + multipath + LVM-thin o ZFS

Puedes usar LUNs iSCSI con LVM-thin, o LUNs iSCSI consumidos por ZFS como vdev (no es mi favorito a menos que sepas exactamente por qué). La mayoría usa LVM-thin sobre iSCSI para semántica de bloque.

Decisiones clave: política de multipath, profundidades de cola, parámetros ALUA y cómo monitorizar la latencia por path. También: quién administra la configuración del SAN y cómo se controlan los cambios.

Broma #2: iSCSI es como una relación con gran química y pésima comunicación—cuando anda, es brillante; cuando falla, es Wireshark a las 3 a.m.

Preflight: inventario, restricciones y cálculo de downtime

Inventariá las VMs como si importara

El plan de migración solo es tan bueno como tu inventario. “Unas 40 VMs” no es inventario. Incluí: tamaños de disco (provisionado y usado), tipos de OS, modos de arranque (BIOS vs UEFI), servicios críticos, expectativas de RPO/RTO y si el guest soporta apagado limpio.

Mide la tasa de cambio, no solo el tamaño

Si una VM tiene 2 TB de disco pero cambia 2 GB/día, podés preparar la mayor parte de los datos y mantener el corte corto. Si cambia 400 GB/día, estás haciendo un corte frío o armando una estrategia de replicación a nivel de aplicación.

Decidí qué significa “downtime mínimo”

Downtime mínimo no es cero downtime. Es la ventana de caída más pequeña que sea honesta: tiempo para quiesce la aplicación, copia delta final, arranque en Proxmox, validación y rollback si hace falta.

Elegí una historia de reversión antes de empezar

Si no podés revertir, no estás migrando; estás apostando. El rollback suele significar: mantener la VM ESXi intacta, no borrar datos VMFS y planificar reversiones de DNS/load balancer. Si tenés que reutilizar IPs, prepará un plan para refrescar cachés ARP y resetear estados de firewall.

Tareas prácticas con comandos (y qué decidir según la salida)

Estos son los chequeos reales que ejecuto antes, durante y después de una migración de almacenamiento. Cada tarea incluye un comando, un fragmento plausible de salida, qué significa y la decisión que tomás a partir de eso.

Task 1: Confirmar salud del nodo Proxmox y conceptos básicos del kernel

cr0x@server:~$ pveversion -v
pve-manager/8.2.2/1a2b3c4d (running kernel: 6.8.12-4-pve)

Qué significa: Estás en una versión moderna de Proxmox con un kernel pve actual. Los controladores de almacenamiento y el comportamiento de ZFS dependen del kernel.

Decisión: Si tenés un kernel viejo, arreglalo antes de migrar. No combines “almacenamiento nuevo + kernel viejo + corte a medianoche”.

Task 2: Verificar virtualización CPU e IOMMU (para futuro)

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Model name'
Model name:                           Intel(R) Xeon(R) Silver 4214R CPU @ 2.40GHz
Virtualization:                       VT-x

Qué significa: Hay virtualización de hardware. No es almacenamiento directo, pero afecta la migración cuando necesitás ejecutar las mismas configuraciones de guest.

Decisión: Si falta o está deshabilitada la virtualización, frená y corregí la BIOS. La migración de almacenamiento no importa si nada arranca.

Task 3: Verificar enlace NIC, velocidad y errores (la red de almacenamiento depende de esto)

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  1234567      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    8765432109  1122334      0       0       0       0

Qué significa: Errores en cero; algunas caídas pueden ser normales bajo ráfagas, pero “12 dropped” es un olor que deberías entender.

Decisión: Si los errores aumentan durante las pruebas, arreglá cableado/conmutación antes de culpar a NFS/iSCSI/ZFS.

Task 4: Validar jumbo frames end-to-end (solo si insistís en usarlos)

cr0x@server:~$ ping -M do -s 8972 -c 3 10.10.20.10
PING 10.10.20.10 (10.10.20.10) 8972(9000) bytes of data.
8980 bytes from 10.10.20.10: icmp_seq=1 ttl=64 time=0.612 ms
8980 bytes from 10.10.20.10: icmp_seq=2 ttl=64 time=0.590 ms
8980 bytes from 10.10.20.10: icmp_seq=3 ttl=64 time=0.605 ms

--- 10.10.20.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms

Qué significa: MTU 9000 funciona en todo el path. Si esto falla, no tenés jumbo frames; tenés fragmentación y tristeza.

Decisión: Si falla, o arreglá MTU consistentemente en todos lados o volvé a 1500. MTU mixto es peor que no tener jumbo.

Task 5: Crear un pool ZFS con ashift correcto (ejemplo: SSDs en mirror)

cr0x@server:~$ sudo zpool create -o ashift=12 -o autotrim=on rpool mirror /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N123456 /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N789012
cr0x@server:~$ sudo zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME                                                                STATE     READ WRITE CKSUM
        rpool                                                               ONLINE       0     0     0
          mirror-0                                                          ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N123456                  ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N789012                  ONLINE       0     0     0

errors: No known data errors

Qué significa: El pool está sano; ashift=12 es un default sensato para dispositivos con sector 4K (incluyendo muchos SSD que mienten sobre sectores).

Decisión: Si ya creaste un pool con ashift incorrecto, reconstruyelo. No hay “arreglo mágico después”.

Task 6: Afinar datasets ZFS para imágenes de VM (volblocksize + compression)

cr0x@server:~$ sudo zfs create -o compression=zstd -o atime=off rpool/vmdata
cr0x@server:~$ sudo zfs get -o name,property,value compression,atime rpool/vmdata
NAME         PROPERTY     VALUE
rpool/vmdata compression  zstd
rpool/vmdata atime        off

Qué significa: La compresión está activada (normalmente mejora imágenes de VM), atime está desactivado (menos churn de metadatos).

Decisión: Si tu carga ya está limitada por CPU, la compresión puede empeorarla. Si no, suele mejorar espacio y rendimiento.

Task 7: Benchmark de latencia de almacenamiento de la forma aburrida (fio, escrituras sync)

cr0x@server:~$ sudo fio --name=sync4k --directory=/rpool/vmdata --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --size=2G --direct=1 --fsync=1
sync4k: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.33
sync4k: (groupid=0, jobs=1): err= 0: pid=22110: Mon Dec 23 14:03:41 2025
  write: IOPS=4200, BW=16.4MiB/s (17.2MB/s)(2048MiB/124800msec)
    clat (usec): min=120, max=24000, avg=230.50, stdev=410.20

Qué significa: Latencia sync 4K promedio ~230 µs es decente para NVMe en mirror. El tail máximo (24 ms) es lo que va a perjudicar bases de datos y servicios con mucho log.

Decisión: Si la latencia tail es fea, frená. Arreglá firmware del dispositivo, revisá settings de cache de escritura o reconsiderá el layout del pool antes de importar VMs de producción.

Task 8: Exportar discos de VM desde el datastore ESXi a un servidor de staging (vía SSH + vmkfstools copy)

cr0x@server:~$ ssh root@esxi-01 "vim-cmd vmsvc/getallvms | head"
Vmid   Name                 File                                 Guest OS           Version   Annotation
12     app01                [vmfs01] app01/app01.vmx              ubuntu64Guest      vmx-19
13     db01                 [vmfs01] db01/db01.vmx                centos7_64Guest    vmx-19

Qué significa: Podés enumerar VMs y ubicar sus rutas VMX. Desde ahí podés localizar VMDKs dentro del directorio de la VM.

Decisión: Si no podés SSH a ESXi por políticas, tendrás que usar un método de exportación (OVF/OVA) o restaurar desde producto de backup. Planificá cambios de formato y tiempo.

Task 9: Confirmar tipo y tamaño de VMDK en ESXi antes de copiar

cr0x@server:~$ ssh root@esxi-01 "ls -lh /vmfs/volumes/vmfs01/app01 | egrep 'vmdk|vmx'"
-rw-------    1 root     root         8.0K Dec 20 10:12 app01.vmx
-rw-------    1 root     root         1.2K Dec 20 10:12 app01.vmdk
-rw-------    1 root     root        150G Dec 23 03:20 app01-flat.vmdk

Qué significa: Esta VM usa descriptor + extent flat (común en formatos thick-ish). Copiá ambos. El descriptor es pequeño pero requerido.

Decisión: Si solo copiás el grande -flat.vmdk y olvidás el descriptor, vas a perder tiempo reconstruyendo metadata. No te hagas eso.

Task 10: Copiar VMDKs eficientemente (rsync sobre SSH, con resume)

cr0x@server:~$ rsync -avP --inplace -e ssh root@esxi-01:/vmfs/volumes/vmfs01/app01/ /srv/stage/app01/
sending incremental file list
app01.vmdk
          1,248 100%    1.19KB/s    0:00:01 (xfr#1, to-chk=1/3)
app01-flat.vmdk
  12,884,901,888  8%   112.34MB/s    0:19:42

Qué significa: Estás moviendo el extent a ~112 MB/s. La opción --inplace ayuda a reanudar archivos grandes.

Decisión: Si el throughput está muy por debajo de lo que la red/almacenamiento debería dar, frená y diagnosticá (ver playbook rápido). No “esperes” y pierdas tu ventana.

Task 11: Convertir VMDK a raw o qcow2 del lado Proxmox

cr0x@server:~$ qemu-img info /srv/stage/app01/app01.vmdk
image: /srv/stage/app01/app01.vmdk
file format: vmdk
virtual size: 150 GiB (161061273600 bytes)
disk size: 150 GiB

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw /srv/stage/app01/app01.vmdk /rpool/vmdata/app01-disk-0.raw
    (100.00/100%)

Qué significa: Validaste el formato origen y convertiste a raw, que es simple y performante sobre ZFS (ZVOL también es común; archivo raw en dataset funciona si está afinado).

Decisión: Si necesitás snapshots a nivel de almacenamiento y comportamiento thin, qcow2 puede ayudar—pero añade overhead. Para VMs sensibles al rendimiento en ZFS, raw o ZVOL suelen ser la opción.

Task 12: Importar disco en una VM Proxmox y verificar configuración de arranque (BIOS/UEFI)

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

cr0x@server:~$ qm importdisk 120 /rpool/vmdata/app01-disk-0.raw rpool
importing disk 'app01-disk-0.raw' to VM 120 ...
transferred 0.0 B of 150.0 GiB (0.00%)
transferred 150.0 GiB of 150.0 GiB (100.00%)
Successfully imported disk as 'unused0: rpool:vm-120-disk-0'

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

Qué significa: El disco está adjuntado y configurado como dispositivo de arranque. Si el guest era UEFI en ESXi, también necesitás OVMF y un disco EFI.

Decisión: Si la VM no arranca, revisá firmware (SeaBIOS vs OVMF), tipo de controlador de disco (LSI vs virtio) y si el SO tiene drivers virtio.

Task 13: Configurar almacenamiento NFS en Proxmox y validar el comportamiento de montaje

cr0x@server:~$ sudo pvesm add nfs nfs-vmstore --server 10.10.20.10 --export /export/vmstore --content images,iso,backup --options vers=4.1
create storage 'nfs-vmstore'

cr0x@server:~$ pvesm status
Name         Type     Status     Total      Used      Available   %
local        dir      active     98.00GB    12.44GB    85.56GB   12.69%
nfs-vmstore  nfs      active     10.00TB     4.20TB     5.80TB   42.00%

Qué significa: El almacenamiento está montado y visible. Si aparece inactive, tenés problemas de red/export/options.

Decisión: Si NFS está activo pero el rendimiento es malo, revisá threads del servidor NFS, settings de sync y QoS de red antes de culpar a Proxmox.

Task 14: Configurar target iSCSI y verificar sesión/login

cr0x@server:~$ sudo apt-get update -qq
cr0x@server:~$ sudo apt-get install -y -qq open-iscsi multipath-tools

cr0x@server:~$ sudo iscsiadm -m discovery -t sendtargets -p 10.10.30.20
10.10.30.20:3260,1 iqn.2001-04.com.example:san.lun01

cr0x@server:~$ sudo iscsiadm -m node -T iqn.2001-04.com.example:san.lun01 -p 10.10.30.20 --login
Logging in to [iface: default, target: iqn.2001-04.com.example:san.lun01, portal: 10.10.30.20,3260]
Login to [iface: default, target: iqn.2001-04.com.example:san.lun01, portal: 10.10.30.20,3260] successful.

Qué significa: La discovery funciona y estás logueado. El siguiente paso es sanity de multipath y creación de filesystem/LVM.

Decisión: Si la discovery está vacía, tenés ACLs del target, routing VLAN o mismatch de CHAP. Arreglalos antes de tocar la configuración de almacenamiento en Proxmox.

Task 15: Validar multipath y salud de paths (iSCSI)

cr0x@server:~$ sudo multipath -ll
mpatha (36001405abcde1234567890fedcba9876) dm-2 DGC,VRAID
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:10 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:10 sdc 8:32 active ready running

Qué significa: Existen dos paths; uno es active/optimized (prio 50). Esto es lo que querés con arrays ALUA-capables.

Decisión: Si solo ves un path, no procedas. Arreglá la red redundante ahora; después lo vas a hacer bajo carga.

Task 16: Revisar salud de ZFS y detectar problemas silenciosos temprano

cr0x@server:~$ sudo zpool iostat -v rpool 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                        320G   612G    120    450  12.3M  55.1M
  mirror-0                   320G   612G    120    450  12.3M  55.1M
    nvme-SAMSUNG...123456      -      -     60    225  6.1M   27.5M
    nvme-SAMSUNG...789012      -      -     60    225  6.2M   27.6M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: I/O balanceado en el mirror y throughput sensato. Si un dispositivo muestra picos de latencia extraños, lo verás en los patrones de zpool iostat.

Decisión: Si un vdev individual está retrasado, reemplazalo antes de la migración. No “monitorées hasta convertirlo en falla” durante la semana de corte.

Métodos de migración: frío, semi-caliente y “no hagan eso”

Método 1: Migración fría (apagar VM, copiar discos, arrancar en Proxmox)

Esto es el default porque es predecible. Apagás la VM en ESXi, copiás el estado final del disco, convertís/importás, arrancás en Proxmox, validás servicios y actualizás redes/DNS.

Perfil de downtime: Potencialmente alto, pero acotado y comprensible. Podés probar el proceso de importación antes con un clon o exportación por snapshot.

Donde gana: Bases de datos con consistencia estricta, OS legacy o cuando no confiás en replicación a nivel de guest.

Método 2: Copia escalonada + corte corto (copiar la mayor parte primero, luego sync final)

Si podés mantener la VM activa mientras preparás una copia bulk (o podés partir de un snapshot), podés reducir el downtime a “delta final + arranque”. Enfoque común:

• Prepará una copia completa de VMDK(s) en un host de transferencia.
• Programá una ventana de corte.
• Apagá la VM, ejecutá el rsync/copia final (delta pequeño si la tasa de cambio es baja), convertí/importá, arrancá.

Perfil de downtime: A menudo excelente para VMs de baja tasa de cambio. La clave es no mentirte sobre la tasa de cambio.

Método 3: Replicación a nivel de aplicación (downtime mínimo, más partes móviles)

Para bases de datos grandes o sistemas con muchas escrituras, copiar imágenes de disco suele ser la abstracción equivocada. Replicá a nivel de aplicación: replicación de base de datos, replicación de archivos o sync específico del servicio, y luego cortá clientes.

Perfil de downtime: Puede ser muy pequeño, pero operacionalmente más pesado. Además exige que la aplicación tenga un plan de failover limpio.

Método 4: “Montar VMFS y copiar desde Linux” (funciona, pero no lo romantices)

Puedes montar volúmenes VMFS desde Linux con herramientas como vmfs-fuse y luego copiar VMDKs. Es útil en apuros, sobre todo si ESXi está muerto pero los LUNs están vivos. Pero no es el plan principal más limpio. Puede ser read-only, el rendimiento varía y estás añadiendo otra capa de abstracción en un momento estresante.

Métodos a evitar salvo que sepas por qué

• “Convertiremos directamente desde el datastore ESXi en vivo.” Si el datastore está ocupado, competís con I/O de producción mientras intentás copiarlo. Así se inventa un incidente.
• “Usaremos qcow2 en todos lados porque es flexible.” Flexibilidad no es gratis. qcow2 puede estar bien, pero añade CPU y overhead de metadata. Usalo cuando tenga un propósito (snapshots, thin), no por religión.
• “Haremos RAIDZ con VMs de escritura aleatoria y esperamos lo mejor.” RAIDZ puede ser excelente para cargas secuenciales y capacidad. Los patrones aleatorios de VM te muestran por qué existen los mirrors.

Listas de verificación / plan paso a paso

Checklist A: Decidir el almacenamiento objetivo (decisión de 10 minutos)

1. Si necesitás almacenamiento compartido para live migration hoy, preferí NFS (aburrido) o iSCSI (afilado) según tu entorno.
2. Si priorizás integridad de datos + operaciones predecibles y podés aceptar discos locales + replicación, elegí ZFS local.
3. Si ya tenés un SAN y competencia en multipath, iSCSI está bien. Si no, no lo aprendas en la semana de migración.

Checklist B: Staging pre-migración (hacelo antes de tocar una VM de producción)

1. Construí almacenamiento Proxmox (ZFS/NFS/iSCSI) y ejecutá fio con escrituras sync.
2. Validá consistencia de MTU en la red y contadores de error.
3. Creá al menos una VM de prueba en Proxmox; asegurá que los backups funcionen.
4. Elegí una VM ESXi no crítica; hacé un ensayo completo de migración y documentá pasos y tiempos exactos.
5. Definí rollback: la VM ESXi queda apagada pero intacta hasta que la validación pase; cambios DNS rastreados; reglas de firewall/NAT preconfiguradas.

Checklist C: Plan de cutover (por VM)

1. Confirmá último backup válido y prueba de restauración (sí, hacelo realmente).
2. Notificá stakeholders con una ventana de outage que incluya tiempo de validación.
3. Apagá el guest limpiamente (pará la aplicación primero para bases de datos).
4. Ejecutá la copia final de disco / delta final.
5. Convertí/importá el disco al formato de almacenamiento Proxmox.
6. Configurá firmware/controlador de VM para coincidir con requerimientos del guest.
7. Arrancá en una VLAN aislada o con la red desconectada primero si necesitás evitar conflictos de IP.
8. Validá salud del servicio (systemd, logs, chequeos de aplicación).
9. Redirigí tráfico (DNS/LB) y monitorizá.
10. Mantené opción de rollback por un período definido; luego retirás artefactos antiguos.

Checklist D: Endurecimiento post-migración (porque quien venga después opera esto)

1. Habilitá backups en Proxmox con retención y pruebas periódicas de restauración.
2. Configurá schedule de scrub de ZFS y alertas, o checks de salud NFS/iSCSI con alertas de latencia.
3. Documentá topología de almacenamiento: pools, datasets, exports, IDs de LUN, WWIDs de multipath.
4. Baselineá latencia de disco desde dentro del guest (para tener números “normales”).

Playbook de diagnóstico rápido: encontrar el cuello de botella

Cuando las copias de migración están lentas o las VMs en Proxmox se sienten lentas tras el corte, no adivinés. Triageá como SRE: aislá si estás limitado por cómputo, red o almacenamiento. Este es el camino más corto a la verdad.

Primero: ¿es la red?

• Revisá errores/caídas de interfaces en el host Proxmox y en el servidor de almacenamiento/puertos de switch.
• Hacé un ping MTU (solo si usás jumbo frames).
• Medí throughput bruto con iperf3 entre Proxmox y endpoints NFS/iSCSI.

Interpretación: Si iperf3 está débil o inestable, el tuning de almacenamiento no te salvará. Arreglá la red primero.

Segundo: ¿es la latencia del dispositivo de almacenamiento (tail latency)?

• Corré fio con --fsync=1 y bloques pequeños (4k/8k) para imitar escrituras peores de VM.
• En ZFS, usá zpool iostat para ver si un dispositivo se comporta mal.
• En iSCSI, chequéa estado de multipath y latencia por path si el array lo provee.

Interpretación: Los IOPS promedio pueden verse bien mientras la latencia tail destruye bases de datos. Confiá en las colas altas.

Tercero: ¿es contención o mala configuración en el host?

• Buscá CPU steal / saturación de CPU del host durante conversiones.
• Verificá que tu disco de VM use virtio-scsi y no un controlador emulado salvo que sea necesario.
• Confirmá que no estés accidentalmente en un backend lento (como un directorio local en disco giratorio).

Interpretación: Si el host está ocupado convirtiendo múltiples discos en paralelo, podés hacer que el almacenamiento parezca malo. Limitá tu propia ambición.

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

1) Síntoma: Velocidad de copia estancada en 20–40 MB/s en una red de 10Gb

Causa raíz: Cuello de botella de stream TCP único, configuración pobre de offloads NIC, o estás leyendo desde un datastore VMFS ocupado bajo carga.

Solución: Validá con iperf3. Si la red está bien, prepará copia desde un snapshot o fuera de horario cuando el datastore esté quieto. Considerá paralelizar con cuidado (dos streams ayudan; veinte pueden quemar el array origen).

2) Síntoma: La VM arranca en Proxmox pero el disco es “sistema de archivos de solo lectura”

Causa raíz: Inconsistencia del sistema de archivos por apagado sucio o copia incompleta; a veces también mismatch de driver/controlador que causa timeouts.

Solución: Hacé un apagado limpio en ESXi. Re-copiá después del apagado. Ejecutá fsck (Linux) o chkdsk (Windows) durante la validación en una red aislada.

3) Síntoma: La VM no arranca; cae al EFI shell o “no bootable device”

Causa raíz: Mismatch de firmware (UEFI vs BIOS), falta de disco EFI, orden de arranque errónea o bootloader ligado al tipo de controlador.

Solución: Igualá firmware: SeaBIOS para instalaciones BIOS, OVMF para UEFI. Agregá disco EFI para OVMF. Asegurá el disco como scsi0/virtio donde el SO lo espera.

4) Síntoma: Almacenamiento NFS está activo pero I/O de VM es espasmódico y la latencia salta

Causa raíz: Settings de sync del servidor NFS, CPU del NAS sobrecargado o microbursts/caídas de red. A veces es una NIC/puerto defectuoso.

Solución: Revisá contadores de error NIC y stats del puerto del switch. Validá la versión NFS (4.1 suele comportarse mejor) y la cantidad de hilos en el servidor. Aislá el tráfico de almacenamiento si podés.

5) Síntoma: Rendimiento de LUN iSCSI está bien hasta que falla un path, luego todo se queda bloqueado

Causa raíz: Multipath mal configurado (queue_if_no_path sin timeouts sensatos), ALUA no respetado o paths asimétricos no manejados.

Solución: Arreglá política y timeouts de multipath. Validá prioridades ALUA. Probá una falla controlada de path antes del corte en producción.

6) Síntoma: El pool ZFS parece sano pero escrituras de VM son lentas

Causa raíz: RAIDZ bajo carga de escrituras aleatorias, RAM insuficiente (ARC misses) o concepto erróneo sobre SLOG (agregar un SLOG lento puede perjudicar).

Solución: Mirrors para pools con VMs pesadas en I/O. No compres un SSD barato para SLOG; si no necesitás semántica síncrona, dejalo fuera. Medí con fio.

7) Síntoma: El espacio de almacenamiento “desaparece” después de la migración

Causa raíz: Discos thick creados desde orígenes thin, opciones de preallocación de qcow2 o snapshots obsoletos en el nuevo backend.

Solución: Decidí thin vs thick intencionalmente. Rastreá snapshots y podá. En ZFS, observá referenced vs used; en LVM-thin, monitoreá uso de datos+metadata.

Tres mini-historias del mundo corporativo (con dolor incluido)

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

Tenían un plan bonito: exportar VMs desde ESXi, importar a Proxmox, apuntar todo al nuevo store NFS. El equipo hizo un piloto con dos VMs Linux pequeñas, todo parecía bien y la presentación casi se escribió sola.

La suposición equivocada fue simple: “Si se monta NFS, el rendimiento será bueno.” Nadie midió latencia tail. Nadie revisó buffers del switch. La VLAN de almacenamiento compartía uplinks con tráfico de backups, y los backups corrían cuando el equipo de backups sentía ganas de clickear “run now”.

La noche del cutover, un servidor Windows pesado cayó en Proxmox. El lunes a la mañana los usuarios dijeron que Explorer “se congelaba”. La VM no estaba caída; era peor: estaba viva y sufriendo. En el host, I/O de NFS tenía stalls periódicos; dentro del guest, los timeouts SMB se acumulaban como malas decisiones.

El equipo persiguió fantasmas: drivers virtio, updates de Windows, antivirus, hasta DNS. Finalmente alguien graficó latencia NFS y notó que los picos se alineaban con tráfico de backups en los mismos uplinks.

La solución fue aburrida: dedicar ancho de banda para almacenamiento, imponer QoS y programar backups con la disciplina que usualmente se reserva para nóminas. La lección fue más afilada: “Se montó” no es prueba de rendimiento. Es apenas un saludo.

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

Otro equipo quería velocidad. Eligieron ZFS para almacenamiento local y leyeron posts confiados sobre SLOG. Así que agregaron un NVMe “rápido” de consumo como SLOG, porque lo tenían y “separar intent log” suena como un truco.

El entorno tenía cargas mixtas. Algunas VMs eran bases de datos con writes síncronos. Otras eran servidores de apps generales. Una semana todo parecía bien. Luego el NVMe de consumo empezó a lanzar picos de latencia intermitentes bajo carga sync sostenida. No era una falla total. Peor: media falla.

ZFS hizo lo que ZFS hace: preservó la corrección. El rendimiento, sin embargo, cayó en picada durante esos picos. Las VMs tuvieron pausas periódicas de I/O. El equipo interpretó “ZFS es lento” y empezó a girar perillas: cambiar recordsize, desactivar compresión, tweaks de arc. Lo convirtieron en una semana de tuning.

El problema real fue la “optimización”: el dispositivo SLOG no tenía protección contra pérdida de energía y mostró latencias inconsistentes bajo cargas sync. Quitar el SLOG y volver a SSDs empresariales en mirror restauró comportamiento estable. Más tarde, agregaron un SLOG adecuado con protección contra pérdida de energía solo después de medir que las cargas sync realmente lo beneficiaban.

Optimizar no es agregar partes. Es reducir incertidumbre. Cuando agregás un componente con latencia impredecible, estás optimizando para asignación de culpas.

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

Una compañía del área financiera tuvo que mover un conjunto de VMs antiguas pero críticas: un servidor de licencias, una app interna y una base de datos que todos fingían que no era importante hasta que rompió. Tenían una ventana de cambio estricta y ejecutivos que oían “virtual” y asumían que significaba “instantáneo”.

La práctica del equipo era dolorosamente poco glamorosa: cada migración de VM tenía un runbook ensayado, una hoja de tiempos y un drill de rollback. También mantenían las VMs ESXi intactas por un “período de confianza” luego del cutover. Nadie podía reclamar espacio temprano, por tentador que fuera.

Durante el cutover real, la base de datos importó bien pero no arrancó por un mismatch de firmware: ESXi la tenía en modo UEFI; la VM inicial en Proxmox se creó con SeaBIOS. Es un arreglo simple, pero no es divertido cuando el reloj de outage corre.

Como ensayaron, reconocieron el modo de falla rápido. Cambiaron la VM a OVMF, agregaron un disco EFI, corrigieron el orden de arranque y arrancaron limpio. Retraso total: minutos, no horas.

El verdadero salvavidas vino después: una app downstream tenía una IP codificada y la regla NAT de la red no aplicaba en el nuevo segmento. El rollback no fue teórico. Revirtieron el tráfico, corrigieron la regla NAT y recortaron otra vez. Práctica aburrida—runbooks y disciplina de rollback—superó a la inteligencia. Cada vez.

Una cita sobre confiabilidad (aprobada por operaciones)

Idea parafraseada (atrib. a Gene Kim): “Mejorar la confiabilidad suele significar mejorar el flujo de trabajo y la retroalimentación, no solo añadir más controles.”

Preguntas frecuentes

1) ¿Puede Proxmox leer VMFS directamente?

No de forma soportada y de primera clase para escrituras en producción. A veces podés leer volúmenes VMFS desde Linux con herramientas auxiliares y copiar datos. Tratálo como técnica de recuperación, no como pipeline principal de migración.

2) ¿Conviene convertir VMDK a qcow2 o raw?

Para VMs sensibles al rendimiento, raw (o discos respaldados por ZVOL) suele ser la opción más segura. qcow2 es útil cuando necesitás snapshots fáciles en almacenamiento basado en archivos o comportamiento thin, pero añade overhead.

3) ¿Cuál es la mejor opción para live migration en Proxmox?

El almacenamiento compartido (comúnmente NFS, o iSCSI con backend de bloque compartido) facilita la live migration. ZFS local puede funcionar con enfoques basados en replicación, pero no es el mismo modelo de “datastore compartido”.

4) ¿Cómo mantengo el downtime mínimo para VMs grandes?

O bien preparás la mayor parte de los datos con antelación y hacés un sync final corto durante el cutover, o replicás a nivel de aplicación (replicación de base de datos, replicación de archivos). Copiar imágenes de disco por sí solo no vence a la física para cargas con alta tasa de cambio.

5) ¿Necesito drivers virtio?

Linux generalmente maneja virtio bien. Windows a menudo necesita drivers virtio dependiendo de la instalación y el tipo de controlador. Si cambiás controladores (por ejemplo, de LSI a virtio-scsi), planificá la disponibilidad de drivers antes del cutover.

6) ¿Mirrors o RAIDZ para almacenamiento ZFS de VMs?

Mirrors para I/O aleatorio intensivo por VM. RAIDZ es genial para capacidad y patrones secuenciales, pero puede castigar escrituras aleatorias y latencia tail—exactamente lo que generan las VMs.

7) ¿Es obligatorio un dispositivo SLOG para ZFS?

No. SLOG solo importa para escrituras síncronas cuando usás sync=standard y las cargas realmente emiten sync. Un SLOG malo puede empeorar el rendimiento. Usalo solo después de medir y elegí hardware con protección contra pérdida de energía.

8) ¿NFS o iSCSI para almacenamiento compartido?

NFS suele ser más fácil operativamente y más sencillo de depurar. iSCSI puede ser excelente con multipath y disciplina SAN adecuada, pero viene con más configuración y modos de falla más interesantes.

9) ¿Cómo valido el rendimiento después de la migración?

Medí desde ambos lados: a nivel host (fio, zpool iostat, estado de multipath) y a nivel guest (latencia de la aplicación, latencia del filesystem, tiempos de commit de la base de datos). Los usuarios sienten latencia, no throughput.

10) ¿Cuál es la estrategia de rollback más segura?

Mantené la VM ESXi original apagada pero intacta hasta validar funcionalidad y rendimiento en Proxmox, y hasta pasar una ventana de observación definida. El rollback debe ser un procedimiento, no una sensación.

Conclusión: próximos pasos que podés ejecutar

Acá está el camino práctico que te mantiene afuera del club de “incidentes por migración de almacenamiento”:

1. Elegí la zona de aterrizaje: ZFS local (integridad + simplicidad), NFS (compartido + aburrido) o iSCSI (compartido + afilado).
2. Benchmarkeá lo que importa: latencia sync 4K y comportamiento tail, no solo throughput secuencial grande.
3. Ensayá una VM de punta a punta: copiar, convertir, importar, arrancar, validar, revertir. Cronometrá.
4. Prepará datos con anticipación para VMs de baja tasa de cambio; usá replicación a nivel de aplicación para sistemas con alta tasa de cambio.
5. Hacé el cutover con rollback intacto, y no borres datos VMFS hasta haber sobrevivido a la realidad.

Si no hacés otra cosa: medí, ensayá y mantené el rollback aburrido y disponible. Así es como se ve “downtime mínimo” en producción—menos drama, más pruebas.