Sustituir vCenter por Proxmox: qué ganas, qué pierdes y soluciones que realmente funcionan

El marco de decisión: qué estás reemplazando realmente

Reemplazar vCenter por Proxmox no es «cambiar de hipervisor». Es reemplazar todo un modelo operativo:

• Plano de control: vCenter (y a menudo SSO, historial PSC, plugins, modelo de roles) frente a la gestión de clúster de Proxmox VE (pve-cluster/corosync) con una interfaz web y API.
• Capa de cómputo: ESXi frente a KVM + QEMU (y opcionalmente LXC).
• Historia de almacenamiento: VMFS+SAN/NVMe-oF/vSAN frente a ZFS/Ceph/NFS/iSCSI/FC (sí, FC todavía existe).
• Redes: vDS/NSX frente a bridges de Linux, bonds, VLANs, OVS (opcional) y lo que realmente sea tu red física.
• Operaciones: «Todo es una casilla por marcar» frente a «la mayoría de las cosas son un archivo, un comando y un log».

Ese último punto es el importante. vSphere es una suite de productos diseñada para hacer que la mayoría de las cosas sean seguras para personas que no quieren SSH. Proxmox está diseñado para hacer las cosas posibles para quienes sí.

Ningún enfoque es moralmente superior. Pero solo uno coincidirá con los instintos de tu equipo. Si la herramienta de troubleshooting por defecto de tu equipo es «abrir un ticket», necesitarás invertir en formación y guardarraíles. Si la herramienta por defecto es «tail -f», Proxmox se sentirá como llegar a casa a un apartamento un poco desordenado donde por fin puedes mover los muebles.

Hechos interesantes y contexto histórico (que importan operacionalmente)

1. KVM entró en el kernel de Linux en 2007, convirtiendo la virtualización de «salsa especial» en una característica del kernel. Por eso la capa de cómputo de Proxmox parece aburrida—en el buen sentido.
2. QEMU precede a KVM; KVM lo aceleró. En la práctica, la mayoría de la «magia» de las VM en Proxmox es configuración de QEMU más la plomería de Linux.
3. Proxmox VE existe desde 2008. No es un proyecto de fin de semana; es una distribución duradera con opiniones firmes.
4. El objetivo temprano de Ceph fue hardware commodity a escala. Esa historia aparece en su personalidad operativa: resistente, potente y alérgico a suposiciones vagas sobre almacenamiento.
5. ZFS nació en Sun con checksums de extremo a extremo y copy-on-write. ZFS es el sistema de almacenamiento que asume que te estás mintiendo sobre tus discos.
6. La migración en estilo vMotion no es una sola característica; es compatibilidad de CPU, almacenamiento compartido o flujos de migración, estabilidad de red y lógica de scheduling trabajando juntos.
7. Las reglas de quórum de Corosync vienen del mundo de evitar split-brain. No es negociable; es física y sistemas distribuidos siendo estrictos.
8. El dominio de vSphere fue en parte UX operativo: una GUI consistente, conceptos consistentes y un gran ecosistema de partners. Cuando te vas, te vas de un ecosistema, no solo de un hipervisor.
9. Las snapshots de VMware se volvieron una anti-patrón cultural porque eran demasiado fáciles. Proxmox también facilita las snapshots, así que necesitarás la misma supervisión adulta.

Qué ganas con Proxmox (las victorias reales)

1) Un plano de gestión más simple de lo que parece

El modelo de clúster de Proxmox es directo: membresía corosync, un sistema de archivos de configuración distribuido (pmxcfs) y nodos que deberían coincidir en la realidad. No tendrás un árbol de inventario de mil objetos con plugins pegados.

En producción, eso se traduce a menudo en recuperación más rápida cuando las cosas se tuercen. Menos piezas móviles significa menos momentos de «la cosa de gestión que gestiona la otra cosa de gestión está rota».

2) KVM es ampliamente conocido (y ampliamente depurado)

Si contratas gente de Linux, puedes dotar de personal esto. Si tienes que contratar «gente de vCenter», estás buscando en un mercado más pequeño con un sticker salarial mayor.

Además: cuando golpeas un problema de kernel/controlador, estás en el mainstream de Linux. Eso importa para NICs, HBAs, NVMe y plataformas de servidor extrañas que los proveedores llaman «certificadas» hasta que preguntas por la versión de firmware exacta.

3) Opciones de almacenamiento que coinciden con la realidad

Proxmox no impone una sola visión del almacenamiento. Puedes correr:

• ZFS local para rendimiento predecible y simplicidad operativa.
• Ceph para almacenamiento compartido y distribuido con tolerancia a fallos—a costa de complejidad y sensibilidad a la latencia.
• NFS/iSCSI/FC cuando la empresa ya tiene un array y no estás para empezar una religión.

La ventaja no es «más opciones». La ventaja es poder elegir un modelo de almacenamiento alineado con tu carga de trabajo, dominios de fallo y habilidades del equipo.

4) Configuración transparente y ganchos para automatización

Proxmox es amigable con infraestructura como código sin forzarte a un ecosistema de un proveedor. La API es utilizable, existe la CLI y muchas partes críticas son texto en disco.

Eso no es «más fácil». Es recuperable. Cuando la UI cae, todavía puedes trabajar. Esa es una característica subvalorada hasta que son las 02:17 y miras una pestaña del navegador en blanco.

5) Control de costes que no es solo licencias

Sí, la licencia es un motor. Pero la historia de costes no es solo el precio de suscripción. Es también:

• Menos dependencia de conocimiento propietario.
• Más flexibilidad en el ciclo de vida del hardware.
• Capacidad para estandarizar en herramientas Linux para monitorización, logging y respuesta a incidentes.

Broma #1: vCenter puede sentirse como un crucero de lujo. Proxmox es más como un buque de carga: menos buffets, más juegos de llaves.

Qué pierdes (y qué duele en producción)

1) Integración del ecosistema y «un único responsable»

El ecosistema de vSphere sigue siendo imbatible para integraciones empresariales: plugins de almacenamiento, proveedores de backup, herramientas de seguridad, informes de cumplimiento y equipos que ya saben operarlo.

Con Proxmox, las integraciones existen, pero debes asumir que integrarás mediante protocolos y APIs estándar en lugar de magia de proveedor. Eso está bien—hasta que una auditoría corporativa espera capturas de pantalla de un dashboard específico.

2) Scheduling al nivel de DRS y motores de políticas maduros

vSphere DRS no es solo «mover VMs». Es un scheduler con opinión refinado durante años, más una UI que lo hace sentir inevitable.

Proxmox tiene HA, migración en vivo y herramientas, pero su scheduling es más simple. Si dependes de DRS para enmascarar problemas crónicos de planificación de capacidad, Proxmox expondrá esos problemas como luz de estadio.

3) Algunas «comodidades empresariales»

Cosas que podrías echar de menos según tu entorno:

• Modelos RBAC profundos a través de muchos objetos y plugins.
• «Todo está soportado si está en la HCL» como comodidad de compras.
• Experiencias de lifecycle manager pulidas (Proxmox tiene herramientas, pero son menos amigables para corporaciones).

4) Guardarraíles operativos (los que previenen que la gente inteligente haga locuras)

Proxmox te da poder. El poder es genial hasta que un ingeniero bienintencionado «optimiza» algo y tumba un clúster. En vSphere, la UI y los valores por defecto a menudo previenen la creatividad peligrosa. En Proxmox, Linux te permite cometer errores a velocidad de línea.

5) La realidad de las expectativas de soporte

El soporte de Proxmox es real, pero no es la misma experiencia cultural que un equipo de cuenta de un megavendedor. Si tu organización necesita que un proveedor asista a cada postmortem y bendiga cada actualización de firmware, planifica en consecuencia.

Broma #2: Algunos dicen «nadie es despedido por comprar VMware». Es cierto—hasta que llega la factura y finanzas se convierte en tu comandante de incidentes.

Soluciones que realmente funcionan (y cuáles no)

Reemplazar DRS: acepta «suficientemente bueno», luego añade guardarraíles

Qué funciona:

• Grupos HA y prioridades en Proxmox para definir «estas VMs deben volver primero».
• Afinidad/anti-afinidad de VMs mediante etiquetas + automatización (chequeos de colocación scriptados) para las pocas cargas que realmente lo requieren.
• Headroom de capacidad como política: operar a una utilización steady-state más baja para no necesitar un scheduler omnisciente.

Qué no funciona: intentar recrear DRS a la perfección. Construirás un clon frágil del scheduler que fallará en casos límite y hará que on-call te odie.

Reemplazar vSAN: elige entre Ceph o «mantener el SAN», y comprométete

Ceph funciona cuando: tienes al menos 4–6 nodos, red rápida y redundante, discos consistentes y la voluntad de tratar el almacenamiento como un servicio de primera clase.

ZFS local funciona cuando: aceptas que «las VMs viven donde están los datos», y estás conforme con replicación/backups en lugar de semánticas de almacenamiento compartido.

Mantener NFS/iSCSI/FC funciona cuando: ya tienes un equipo de arrays y quieres rendimiento predecible con menos complejidad operativa en el clúster de hipervisores.

Qué no funciona: «Ceph en 3 nodos con 1GbE porque en el laboratorio funcionó». El laboratorio siempre funciona. En producción es donde la latencia muestra su carácter.

Reemplazar flujos de trabajo vMotion: estandariza tus rutas de migración

Proxmox soporta migración en vivo, pero la experiencia depende del almacenamiento compartido y la calidad de la red. Para mantenimiento planificado, la migración en vivo está bien. Para «tenemos que evacuar un nodo ahora», necesitas restricciones previsibles:

• Misma familia de CPU y flags compatibles si quieres migraciones sin problemas.
• Almacenamiento compartido (Ceph/NFS/iSCSI) o aceptar que las migraciones copian discos y toman tiempo.
• Red de migración dedicada o QoS para que no compita con la replicación de almacenamiento.

Reemplazar suites de backup empresariales: decide si quieres consistencia de app o consistencia por crash

Proxmox Backup Server (PBS) es bueno en lo que está diseñado: backups rápidos, deduplicados e incrementales con test de restauración. Muchas herramientas de terceros también soportan Proxmox/KVM.

La decisión real: ¿necesitas snapshots con consistencia de aplicación (VSS, quiesce de bases de datos, etc.) o es aceptable la consistencia por crash con procesos de recuperación al nivel de la app? Si finges que la consistencia por crash es suficiente para todo, tu primera restauración seria de base de datos será una lección para la dirección.

Reemplazar «vCenter como fuente de la verdad»: elige una nueva

En muchas organizaciones, vCenter termina siendo la CMDB de facto. No es un cumplido, pero sucede.

Qué funciona: elige un sistema para poseer el inventario (CMDB, modelo estilo NetBox, incluso Git) y que Proxmox sea la capa de ejecución, no la capa de verdad.

Qué no funciona: dejar que la verdad se disperse entre hojas de cálculo, la UI de Proxmox y la memoria de alguien.

Una cita de fiabilidad para mantenerte honesto

«La esperanza no es una estrategia.» — General Gordon R. Sullivan

Tareas prácticas: comandos, salidas y decisiones

Estos son los chequeos del día a día que separan «migramos» de «operamos». Cada tarea incluye un comando, salida de ejemplo, qué significa y la decisión que tomas.

Tarea 1: Verificar membresía del clúster y quórum

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-pve
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 10:12:08 2025
Quorum provider:  corosync_votequorum
Nodes:            5
Node ID:          0x00000003
Ring ID:          1.54
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   5
Highest expected: 5
Total votes:      5
Quorum:           3
Flags:            Quorate

Significado: «Quorate: Yes» significa que el clúster está de acuerdo sobre la membresía; puedes hacer cambios a nivel de clúster de forma segura.

Decisión: Si no hay quórum, deja de hacer cualquier cosa «ingeniosa». Arregla enlaces corosync, la alcanzabilidad de nodos o el riesgo de split-brain primero.

Tarea 2: Comprobar salud del enlace corosync (pérdida de paquetes y latencia)

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 3
RING ID 0
    id    = 10.10.10.13
    status= ring 0 active with no faults
RING ID 1
    id    = 10.10.11.13
    status= ring 1 active with no faults

Significado: Varias anillas (rings) sanas reducen la probabilidad de que un único problema de red tumbe el quórum.

Decisión: Si una anilla muestra fallos, trátalo como un incidente de producción. El clúster que hace flapping provoca eventos HA «aleatorios» en VMs.

Tarea 3: Ver qué nodos están listos y qué versiones ejecutan

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 pve01
0x00000002          1 pve02
0x00000003          1 pve03
0x00000004          1 pve04
0x00000005          1 pve05

Significado: Si un nodo desaparece aquí pero todavía responde a ping, puede que tengas problemas de corosync, no fallo del host.

Decisión: No empieces mantenimiento hasta que la membresía sea estable durante varios minutos.

Tarea 4: Confirmar latencia de almacenamiento a nivel OS (ZFS o IO general)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.12-4-pve (pve03)  12/28/2025  _x86_64_ (64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.12    0.00    2.01    8.45    0.00   83.42

Device            r/s     w/s   rKB/s   wKB/s  await  svctm  %util
nvme0n1         220.0   410.0  8800.0 16400.0  3.20   0.15  9.60
sdg              10.0    80.0    90.0  1200.0 25.40   1.10  8.90

Significado: await es la latencia end-to-end. Un dispositivo lento puede cuellos de botella en mirrors/RAIDZ vdevs de ZFS o journals de OSD de Ceph.

Decisión: Si await sube durante incidentes, persigue almacenamiento antes de culpar «al hipervisor».

Tarea 5: Comprobar estado de pool ZFS y contadores de errores

cr0x@server:~$ zpool status -x
all pools are healthy

Significado: No hay fallos de dispositivo conocidos ni errores de checksum.

Decisión: Si ves errores de checksum, planifica reemplazo de discos y revisa cableado/backplane; no lo «monitores por un tiempo».

Tarea 6: Comprobar compresión ZFS y presión de espacio

cr0x@server:~$ zfs get -o name,property,value -r compression,compressratio,used,avail rpool
NAME   PROPERTY       VALUE
rpool  compression    zstd
rpool  compressratio  1.62x
rpool  used           3.41T
rpool  avail          820G

Significado: La compresión está activada y es efectiva; el espacio disponible se está reduciendo.

Decisión: Al ~80–85% de uso del pool, programa expansión. ZFS bajo presión de espacio se vuelve «¿por qué todo está lento?»

Tarea 7: Comprobar salud del clúster Ceph (si lo usas)

cr0x@server:~$ ceph -s
  cluster:
    id:     3a9b5d4a-6f3c-4ed7-a4a5-1f2cc1dcb8b2
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 31 sec

  services:
    mon: 3 daemons, quorum pve01,pve02,pve03 (age 2d)
    mgr: pve01(active, since 2d), standbys: pve02
    osd: 15 osds: 15 up (since 2d), 15 in (since 2d)

  data:
    pools:   3 pools, 256 pgs
    objects: 1.20M objects, 4.6 TiB
    usage:   14 TiB used, 28 TiB / 42 TiB avail
    pgs:     256 active+clean

Significado: «slow ops» suele ser latencia: discos, red o un OSD sobrecargado.

Decisión: Trata slow ops como un incidente de almacenamiento. Las «pausas aleatorias» de VMs a menudo se rastrean aquí.

Tarea 8: Identificar qué daemon de Ceph falla

cr0x@server:~$ ceph health detail
HEALTH_WARN 1 slow ops, oldest one blocked for 31 sec
[WRN] SLOW_OPS: 1 slow ops, oldest one blocked for 31 sec, daemons [osd.7] have slow ops.

Significado: Tienes un sospechoso: osd.7.

Decisión: Inspecciona la latencia de disco de ese host, steal de CPU, errores de NIC. No rebalancees a ciegas.

Tarea 9: Validar estado de bridge/VLAN/bond en un nodo

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:fd:fe:aa:bb:01
eno2             UP             3c:fd:fe:aa:bb:02
bond0            UP             3c:fd:fe:aa:bb:01
vmbr0            UP             3c:fd:fe:aa:bb:01
vmbr1            UP             3c:fd:fe:aa:bb:01

Significado: Enlaces y bridges están arriba. Esto no prueba que el etiquetado VLAN sea correcto, pero descarta «interfaz caída».

Decisión: Si el vmbr para almacenamiento/migración está abajo, detén migraciones y espera dolor en Ceph/replicación.

Tarea 10: Comprobar salud del bond y enlaces activos

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eno1
MII Status: up
Actor Churn State: none
Partner Mac Address: 24:5a:4c:11:22:33

Slave Interface: eno2
MII Status: up
Actor Churn State: none
Partner Mac Address: 24:5a:4c:11:22:33

Significado: LACP está arriba en ambos enlaces, churn es none. Bien.

Decisión: Si un esclavo hace flapping, espera timeouts intermitentes de almacenamiento y rarezas en corosync. Arregla la red física antes de sintonizar Linux.

Tarea 11: Ver si las VMs sufren ballooning o presión de memoria

cr0x@server:~$ qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       101 api-prod-01          running    8192              80.00 22011
       114 db-prod-02           running   32768             500.00 18433
       130 kafka-03             running   16384             200.00 27190

Significado: Inventario básico de VMs y estado actual.

Decisión: Si una VM «running» está lenta, confirma la holgura de memoria del host; no asumas que es problema del guest.

Tarea 12: Comprobar memoria del host y actividad de swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           251Gi       198Gi       8.2Gi       2.1Gi        45Gi        41Gi
Swap:           16Gi       3.5Gi        12Gi

Significado: Swap está en uso. Puede ser normal o una advertencia, según la tendencia y sensibilidad a la latencia.

Decisión: Si el swap crece en picos y aumenta la latencia IO, reduce overcommit, desactiva ballooning para cargas críticas o añade RAM.

Tarea 13: Detectar steal de CPU y contención de scheduling

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0  356812 856432  9012 328912    0    0   120   450 1200 4100 18  6 70  6  0
 9  0  356812 844120  9012 329500    0    0   140   520 1350 4700 22  7 64  7  0
 7  0  356812 838900  9012 329910    0    0   160   610 1420 4900 25  6 60  9  0
 5  0  356812 834220  9012 330020    0    0   130   480 1280 4300 19  6 68  7  0
 6  0  356812 830440  9012 330120    0    0   110   460 1250 4200 17  5 72  6  0

Significado: wa indica IO wait. Si sube, la CPU espera almacenamiento. Si st sube (en nested virt/cloud), la CPU está siendo robada.

Decisión: Alto IO wait apunta a latencia de almacenamiento; deja de tunear gobernadores de CPU y mira discos/red.

Tarea 14: Confirmar sincronización de tiempo (corosync y Ceph lo requieren)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:15:44 UTC
           Universal time: Sun 2025-12-28 10:15:44 UTC
                 RTC time: Sun 2025-12-28 10:15:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: El reloj está sincronizado.

Decisión: Si los relojes se desvían, arregla NTP antes de diagnosticar «errores de autenticación aleatorios» o inestabilidad de clúster.

Tarea 15: Inspeccionar estado del manager HA y fallos

cr0x@server:~$ ha-manager status
quorum OK
master pve02 (active, Wed Dec 24 11:02:14 2025)
lrm pve01 (active, Wed Dec 24 11:03:10 2025)
lrm pve02 (active, Wed Dec 24 11:02:14 2025)
lrm pve03 (active, Wed Dec 24 11:03:05 2025)
lrm pve04 (active, Wed Dec 24 11:03:02 2025)
lrm pve05 (active, Wed Dec 24 11:03:00 2025)
service vm:114 (started)

Significado: Quórum OK, master HA elegido, gestores de recursos locales activos.

Decisión: Si HA hace flapping, revisa corosync primero. HA está aguas abajo de la salud del clúster.

Tarea 16: Convertir un disco VMware a un formato amigable para Proxmox

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 disk-flat.vmdk vm-101-disk-0.qcow2
    (100.00/100%)

Significado: Disco convertido. qcow2 soporta snapshots; raw suele ser más rápido. Elige intencionalmente.

Decisión: Para bases de datos de alto IO, prefiere raw en ZFS zvol o Ceph RBD; para cargas generales, qcow2 puede ser suficiente.

Guion de diagnóstico rápido: encuentra el cuello de botella antes de adivinar

Este es el checklist de «primeros 10 minutos» cuando alguien dice: «Proxmox está lento» o «las VMs se están quedando pilladas». La velocidad importa. Y el ego es caro.

Primero: salud del clúster y quórum (no depures fantasmas)

• Comprobar quórum: pvecm status → si no hay quórum, para y arregla la membresía.
• Comprobar anillas corosync: corosync-cfgtool -s → busca fallos.
• Comprobar HA: ha-manager status → si HA no es estable, trátalo como un problema de clúster.

Segundo: latencia de almacenamiento (la mayoría de «problemas del hipervisor» son de almacenamiento)

• Local/ZFS: iostat -xz 1 3, zpool status, porcentaje de llenado del pool.
• Ceph: ceph -s, ceph health detail para slow ops y OSDs culpables.
• Mapeo de síntomas: pausas de VM, alto IO wait, backups atascados, timeouts de guests.

Tercero: red (porque el almacenamiento y el quórum dependen de ella)

• Estado de enlaces: ip -br link, estado del bond en /proc/net/bonding/*.
• Errores: ethtool -S (no mostrado arriba, pero úsalo) para CRC, drops, resets.
• Segmentación: corosync y tráfico de almacenamiento no deberían competir con tráfico VM a menos que disfrutes latencia impredecible.

Luego: contención de cómputo

• Memoria: free -h, ajustes de ballooning, tendencias de crecimiento de swap.
• CPU: vmstat, pinning de CPU por VM solo si puedes justificarlo.
• Logs del kernel: journalctl -k para resets de controladores y rarezas de IOMMU.

Regla general: si no puedes probar una hipótesis con un comando y un fragmento de log, todavía estás adivinando.

Tres micro-historias corporativas desde el campo

Incidente causado por una suposición errónea: «Es igual que vMotion»

Una compañía SaaS mediana migró un conjunto de VMs de aplicaciones de vSphere a Proxmox durante una pelea por licencias. Tenían almacenamiento compartido en NFS y una red dedicada 10GbE. En vSphere, habían hecho ventanas de mantenimiento en vivo durante años: evacuar host, parchear, reiniciar, seguir. La memoria muscular es poderosa.

En Proxmox habilitaron migración en vivo y ejecutaron una evacuación planificada de nodo. Funcionó para la capa de apps sin estado. Luego intentaron la VM de base de datos. La migración empezó, progresó y luego se ralentizó hasta casi detenerse. El equipo de apps informó timeouts. El on-call asumió que era «lentitud normal de migración» y dejó que siguiera.

No era normal. La VM de base de datos tenía una NIC virtual en un bridge que compartía ancho de banda con el tráfico de migración porque la «red de migración» no estaba realmente aislada; era una VLAN en el mismo bond sin QoS y con una política de switch que no la trataba especialmente. Bajo carga, el flujo de migración apretó el tráfico de réplica de la base, lo que disparó reintentos, que aumentaron IO, que incrementaron memoria sucia, lo que hizo la migración aún más lenta. Un bucle de realimentación, el tipo que hace que los gráficos parezcan un mal día en la bolsa.

La solución no fue heroica. Separaron el tráfico de migración en su propio par de NIC físicas (o al menos impusieron QoS), limitaron el ancho de banda de migración y dejaron de migrar VMs con estado durante periodos de escritura pico. También actualizaron su runbook: «La migración en vivo es una herramienta, no un ritual.»

La suposición errónea fue sutil: asumieron que «migración en vivo» es una característica binaria. En realidad es un contrato de rendimiento con tu red y almacenamiento. vSphere los cuidaba más. Proxmox les mostró la física desnuda.

Optimización que salió mal: «Vamos a aumentar réplica y compresión en todo»

Un gran equipo de TI interno movió una flota de VMs Windows y Linux a Proxmox con ZFS en cada nodo y replicación asíncrona entre nodos como «almacenamiento compartido para pobre». El diseño estaba bien. La ejecución se puso… ambiciosa.

Alguien decidió que, dado que la compresión ZFS es básicamente gratis (a menudo lo es), deberían usar la compresión más fuerte y además replicar todo cada cinco minutos. El clúster tenía CPU de sobra, ¿por qué no? Activaron zstd en un nivel alto en datasets que contenían discos de VM, activaron jobs de replicación frecuentes y se felicitaron por ser modernos.

Dos semanas después, helpdesk vio un patrón: lentitud aleatoria de VMs durante horas de trabajo. Nada «caído», solo lento. Los gráficos de almacenamiento mostraban picos periódicos. Los gráficos de red mostraban picos periódicos. Los backups a veces llegaban tarde.

La causa raíz no fue la compresión per se. Fue la combinación de intervalos de replicación agresivos con cargas que tenían escrituras con ráfagas. La replicación creó tormentas periódicas de IO. La compresión a alto nivel añadió CPU en esas tormentas. Y como la replicación estaba alineada por reloj, varios nodos hicieron picos simultáneos. Crearon un thundering herd distribuido.

La solución fue aburrida: bajar el nivel de compresión (o mantener zstd en un valor sensato), escalonar los horarios de replicación y crear tiers: VMs críticas replican con más frecuencia, el resto menos. Después de eso, el rendimiento se estabilizó y la tasa de incidentes bajó. La moraleja: las funciones «gratis» no son gratis cuando las programas para golpearte cada cinco minutos.

Práctica aburrida pero correcta que salvó el día: «Reglas de quórum, acceso fuera de banda y mantenimiento disciplinado»

Una compañía regulada ejecutaba un clúster Proxmox en dos racks dentro del mismo sala de datos. Nada glamoroso. Su equipo SRE insistió en tres cosas que nadie quería presupuestar: una red corosync dedicada con switches redundantes, acceso fuera de banda documentado para cada nodo y un proceso estricto de mantenimiento rolling con una puerta de «check de quórum».

Una tarde, un top-of-rack empezó a perder paquetes intermitentemente por un bug de firmware. El síntoma inicial fue raro: algunas VMs bien, otras con stuttering y el clúster Ceph avisando ocasionalmente de slow ops. Este es el tipo de fallo que te hace perder el día.

Porque su red corosync era separada y redundante, el clúster no hizo flapping. HA no migró VMs por pánico innecesario. Eso impidió una cascada. Luego el acceso fuera de banda permitió sacar logs y validar errores de enlace aun cuando partes de la red se comportaban mal. Aislaron el switch, failover de enlaces y reemplazaron firmware de forma controlada.

Nada de esto fue impresionante en una demo. Pero previno downtime. Su post-mortem fue casi aburrido—y ese es el mayor elogio que un equipo de operaciones puede darse.

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

1) Síntoma: pausas aleatorias de VM, comportamiento tipo «stun», timeouts

Causa raíz: latencia de almacenamiento (Ceph slow ops, pool ZFS casi lleno, disco lento único o caídas en VLAN de almacenamiento).

Solución: revisa ceph -s/ceph health detail o iostat y el llenado del pool; separa tráfico de almacenamiento; reemplaza discos fallando; mantiene ZFS por debajo de ~80–85%.

2) Síntoma: HA reinicia servicios o migra VMs inesperadamente

Causa raíz: inestabilidad de corosync, pérdida de paquetes o flapping de quórum.

Solución: valida pvecm status y corosync-cfgtool -s; pon corosync en una red dedicada; arregla LACP y problemas de switch.

3) Síntoma: migraciones en vivo lentas o que fallan intermitentemente

Causa raíz: tráfico de migración compitiendo con tráfico VM/almacenamiento; falta de almacenamiento compartido; tasa de memoria sucia demasiado alta; incompatibilidades de CPU.

Solución: dedica una red de migración o aplica QoS; programa migraciones; reduce carga de escritura durante migraciones; estandariza familias de CPU o usa tipos compatibles.

4) Síntoma: backups inconsistentes, restauraciones «sorprendentemente malas»

Causa raíz: confiar en snapshots crash-consistent para apps que necesitan quiesce; acumulación de snapshots; no probar restauraciones.

Solución: define requisitos de consistencia de app; usa agentes dentro de guests cuando aplique; aplica TTL a snapshots; prueba restauraciones mensualmente.

5) Síntoma: la red funciona para algunas VLANs pero no para otras

Causa raíz: desajuste en awareness de VLAN de bridges, mismatch de trunks en el switch o usar la interfaz equivocada para gestión vs tráfico VM.

Solución: verifica configuración de bridges de Linux, VLANs permitidas en trunks del switch y modo de bond; valida con ip link y captures cuando haga falta.

6) Síntoma: «La UI de Proxmox está lenta» pero las VMs parecen bien

Causa raíz: contención del plano de gestión, problemas de DNS, deriva de tiempo o problemas de conectividad navegador→nodo.

Solución: revisa carga y memoria de nodos; valida resolución DNS desde tu estación y desde nodos; confirma timedatectl sincronizado; mantén tráfico de gestión estable.

7) Síntoma: el rendimiento cae tras «tuneos»

Causa raíz: optimización prematura: ajustes ZFS demasiado agresivos, demasiados jobs de replicación, placement groups de Ceph mal dimensionados o CPU pinning sin mediciones.

Solución: revierte a defaults conocidos; cambia una variable a la vez; mide latencia y throughput; escalona jobs pesados.

8) Síntoma: la actualización del clúster causa sorpresas

Causa raíz: repos mezclados, versiones de paquetes inconsistentes o actualizar sin revisar estado de quórum/HA.

Solución: estandariza repos; haz upgrades rolling; actúa según pvecm status y ha-manager status; mantiene acceso por consola disponible.

Listas de verificación / plan paso a paso

Plan de migración paso a paso (vCenter a Proxmox con drama mínimo)

1. Inventario real: lista VMs, tipos de SO, modos de arranque (BIOS/UEFI), dispositivos especiales, patrones tipo RDM, necesidades de GPU y requisitos de consistencia de app.
2. Elige tu modelo de almacenamiento primero: Ceph vs array compartido vs ZFS local+replicación. Si decides tarde, lo rehaces todo.
3. Diseña redes intencionalmente: al menos separa gestión, almacenamiento (si Ceph) y migración. Si no puedes separar físicamente, aplica QoS y documenta.
4. Construye un clúster Proxmox pequeño: no un juguete de laboratorio—usa NICs, MTU, VLANs y almacenamiento similares a producción. Valida comportamiento ante fallos.
5. Define compatibilidad de CPU: elige un modelo base de CPU para VMs si esperas migraciones entre hosts mixtos.
6. Decide herramienta de backups: PBS o terceros; define RPO/RTO por carga; establece expectativas con propietarios de apps.
7. Montaa monitoreo antes de migrar: salud de nodos, latencia de almacenamiento, errores de NIC y alertas de clúster/quórum. Si esperas, el primer incidente te enseñará en público.
8. Migra en oleadas: comienza con servicios sin estado, luego stateful de bajo riesgo y al final las cargas críticas y stateful.
9. Ejecuta operaciones duales brevemente: mantén vSphere en modo solo lectura si es posible durante ventanas de corte; documenta caminos de rollback.
10. Estandariza plantillas: cloud-init para Linux cuando sea posible, drivers consistentes, QEMU guest agent y formatos de disco sensatos.
11. Aplica higiene de ciclo de vida: cadencia de parches, actualizaciones de kernel, alineamiento de firmware y ventanas de cambio.
12. Haz simulacros de restauración: prueba que puedes restaurar la VM «difícil» (base de datos) y no solo un servidor web desechable.

Checklist operacional para un clúster Proxmox sano

• Quórum estable, múltiples anillas corosync si puedes.
• Sincronización de tiempo verde en todos los nodos.
• Redes dedicadas o controladas para almacenamiento/migración.
• Pools ZFS no cerca del límite; calendario de scrub; errores de discos atendidos.
• Ceph: sin HEALTH_WARN persistente; slow ops tratados como incidentes.
• Backups monitorizados; restauraciones probadas; TTL de snapshots aplicado.
• Upgrades rolling con runbook escrito y puerta de «parar si no hay quórum».

Preguntas frecuentes

1) ¿Puede Proxmox reemplazar completamente vCenter para una empresa?

Para muchas empresas, sí—si defines «reemplazar» como «ejecutar y gestionar virtualización de forma fiable». Si te refieres a «igualar cada flujo de trabajo de plugin y motor de políticas de vCenter», no. Planea herramientas distintas para RBAC, CMDB e informes de cumplimiento.

2) ¿Cuál es el equivalente más cercano a vSphere HA?

Proxmox HA puede reiniciar VMs en otros nodos y gestionar prioridades. Es efectivo cuando corosync es estable y el almacenamiento es compartido (Ceph/NFS/iSCSI) o cuando aceptas que VMs con almacenamiento local pueden requerir patrones de recuperación distintos.

3) ¿Cuál es el equivalente más cercano a DRS?

No hay un equivalente uno a uno. Usa reglas de colocación más simples, políticas de headroom y automatización para las pocas cargas que «deben separarse». Si dependes de DRS para mantener todo en marcha, arregla la planificación de capacidad primero.

4) ¿Debo usar Ceph o ZFS?

Si necesitas almacenamiento compartido y comportamientos HA como «la VM puede reiniciar en cualquier nodo con su disco», Ceph es la vía nativa para Proxmox—pero exige red de baja latencia y hardware consistente. Si valoras simplicidad y rendimiento predecible por nodo, ZFS es excelente. Muchas infraestructuras productivas usan ambos: Ceph para propósito general, ZFS para cargas locales con requisitos de latencia.

5) ¿Necesito una red separada para corosync?

No es estrictamente obligatorio, pero deberías comportarte como si la tuvieras. Corosync odia pérdida de paquetes y jitter. Si corosync comparte una red congestionada, la inestabilidad de HA será tu nuevo pasatiempo.

6) ¿Cómo migro VMs de VMware a Proxmox de forma segura?

Ruta estándar: exportar/convertir discos (VMDK a qcow2/raw), recrear la configuración de la VM y validar modo de arranque y drivers. Para flotas grandes, automatiza la conversión y la generación de configuración. Siempre prueba las VMs «raras» primero: UEFI, drivers NIC especiales, bases de datos y cualquier cosa con licencias ligadas al HW virtual.

7) ¿Es Proxmox Backup Server suficiente para producción?

Sí, para muchos entornos. Es rápido, deduplicado y operativamente sensato. La pregunta clave no es «¿es PBS bueno?» sino «¿necesitas backups consistentes a nivel de aplicación y pruebas de restauración?» Las herramientas no sustituyen la disciplina.

8) ¿Qué hay del RBAC y multitenancy?

Proxmox tiene roles y permisos, pero si haces hosting multitenant estricto con separación profunda, necesitarás controles adicionales: segmentación de red, separación de almacenamiento y procesos operativos fuertes. Para uso interno empresarial típicamente es suficiente.

9) ¿Cuál es el mayor coste oculto al migrar fuera de vCenter?

Reentrenamiento operativo y reconstruir «memoria institucional»: monitorización, respuesta a incidentes, workflows de backup/restore y diseño de red/almacenamiento. Cambiar el hipervisor es lo fácil.

10) ¿Cuál es el mayor riesgo?

Subestimar cuánto los valores por defecto de vCenter te protegían de tu propia organización. En Proxmox puedes construir una plataforma rock-solid—pero tienes que elegir y hacer cumplir estándares.

Siguientes pasos que puedes ejecutar esta semana

1. Escribe tu «definición de hecho» para la migración: estabilidad de quórum, comportamiento HA, RPO/RTO de backups y cobertura de monitorización.
2. Elige almacenamiento intencionalmente (Ceph vs ZFS vs array) y documenta los dominios de fallo para los que estás diseñando.
3. Levanta un piloto de 3–5 nodos con redes similares a producción. Valida: pérdida de nodo, pérdida de switch, pérdida de disco y procedimientos de restauración.
4. Crea un runbook de migración que incluya: pasos de conversión, checks de validación, camino de rollback y «condiciones de parada» (no hay quórum, Ceph health WARN, etc.).
5. Instrumenta lo básico: alertas de quórum, slow ops de Ceph, salud de pools ZFS, errores de NIC, fallos de backup y recordatorios de pruebas de restauración.
6. Haz un simulacro: simula fallo de un nodo y mide tiempo de recuperación y tiempo para entender el incidente. Si no puedes explicar el incidente en 15 minutos, arregla la observabilidad.

Reemplaza vCenter por Proxmox cuando quieras una plataforma que puedas razonar bajo estrés. No lo hagas porque alguien prometió que sería «lo mismo pero más barato». No es lo mismo. Puede ser mejor—si lo construyes con intención.