De VMware a Proxmox VE: instalación, configuración y operación empresarial

Publicado: 2 de noviembre de 2026. El laboratorio quedó instalado, actualizado y listo para crear máquinas virtuales. Todavía no debe alojar datos irremplazables: falta implementar backup externo y no existe redundancia de nodo ni de almacenamiento.

Quería dedicar un servidor físico a virtualización y comprobar, con una instalación real, cuánto hay de verdad en la idea de que una empresa queda atrapada en VMware porque las alternativas no están preparadas. Proxmox VE ofrecía el entorno ideal para poner esa afirmación a prueba: una plataforma basada en KVM, con administración centralizada, almacenamiento flexible, clustering, alta disponibilidad, automatización y respaldo.

La conclusión es incómoda para algunas organizaciones: la principal barrera para pasar de VMware a Proxmox no suele ser el hipervisor. Es la falta de ingenieros capaces de comprender y operar la infraestructura más allá de una interfaz conocida. Proxmox permite construir desde un laboratorio pequeño hasta una plataforma empresarial; cuanto mayor sea la criticidad, mayor debe ser la calidad del diseño, la disciplina operativa y el conocimiento del equipo.

1. El hardware real del laboratorio

Antes de instalar conviene inventariar el equipo y definir qué función tendrá cada dispositivo. La interfaz de Proxmox permitió confirmar las capacidades reales; algunas eran diferentes de las estimaciones iniciales.

Componente	Hardware detectado	Función
Placa base	ASRock B450M Pro4-F	Base del nodo de laboratorio
Procesador	AMD Ryzen 7 5700X, 8 núcleos / 16 hilos	Cómputo para hipervisor y VM
Memoria	128 GB instalados; 125,72 GiB utilizables	Memoria para host y guests
Disco del sistema	ADATA LEGEND 710 NVMe, 256,06 GB (/dev/nvme0n1)	Proxmox, local y local-lvm
Disco de VM	Micron 5300 SSD, 3,84 TB (/dev/sda)	Pool LVM-Thin vmdata
Red	Dos interfaces detectadas	Una en vmbr0; la segunda queda disponible
Gráfica	Tarjeta básica	Instalación local; GPU para IA queda como proyecto futuro

Distribución final

NVMe ADATA 256 GB
├── Proxmox VE 9.2.2
├── local       → ISO, plantillas y respaldos pequeños
└── local-lvm   → 151,64 GB para discos de VM/CT

SSD Micron 3,84 TB
└── vmdata      → LVM-Thin, 3,81 TB para VM y contenedores

nic0
└── vmbr0       → puente de administración y tráfico inicial de VM

nic1
└── disponible  → futuro almacenamiento, migración o redundancia

2. Preparación del USB de instalación

1. Descargué la ISO de Proxmox VE desde el sitio oficial y verifiqué que el archivo correspondiera a la versión esperada.
2. Conecté una memoria USB externa de 8,05 GB al Mac y la identifiqué como disk5. Este paso es crítico: confundir el identificador puede destruir otro disco.
3. Ejecuté el script local crear-usb-proxmox.sh, revisé el disco objetivo y confirmé expresamente el borrado de la USB.
4. macOS solicitó permisos administrativos. La escritura transfirió 1.706.178.560 bytes.
5. Al finalizar, el script expulsó la memoria y confirmó que el instalador estaba listo.

La preparación modificó exclusivamente la memoria externa. Para repetir el procedimiento, no conviene copiar comandos de Internet y cambiar el destino “a ojo”: primero se debe identificar el dispositivo, desmontarlo, escribir la imagen y expulsarlo. La guía oficial de administración mantiene las instrucciones por sistema operativo.

3. Instalación bare metal de Proxmox VE

1. Habilité la virtualización AMD-V en el firmware y seleccioné la USB como dispositivo de arranque.
2. Elegí la instalación gráfica de Proxmox VE y seleccioné únicamente el NVMe ADATA como disco del sistema.
3. Configuré país, zona horaria America/Bogota, teclado, correo administrativo y una contraseña robusta.
4. Asigné una dirección estable en la red privada, puerta de enlace y DNS.
5. Revisé el resumen antes de instalar y reinicié sin la USB conectada.
6. Accedí a la consola web por HTTPS en el puerto 8006.

El nodo quedó identificado como proxmox. La dirección que se observa en las capturas pertenece al rango privado RFC 1918 del laboratorio: no es enrutable desde Internet. En una empresa usaría DNS interno, certificados confiables, segmentación de administración y acceso mediante VPN o una red de gestión; nunca publicaría directamente la consola en Internet.

El instalador creó local y local-lvm sobre el NVMe. local es útil para ISO y plantillas; local-lvm quedó con aproximadamente 151,64 GB para discos virtuales. La documentación oficial recomienda la ISO bare metal para instalaciones nuevas y hardware de servidor de calidad para producción.

4. Validación de discos antes de borrar

El SSD Micron contenía una partición NTFS. Antes del borrado confirmé tres datos: modelo, capacidad e identificador Linux. También confirmé que no existían archivos que debieran conservarse. Esa verificación evita el error más caro de este tipo de instalación: limpiar el disco correcto por una suposición incorrecta.

5. Creación del almacenamiento LVM-Thin vmdata

1. En Nodo → Disks seleccioné el Micron /dev/sda y ejecuté Wipe Disk.
2. Esperé el estado OK y regresé a Disks → LVM-Thin.
3. Seleccioné /dev/sda, asigné el nombre vmdata y mantuve Add Storage activado.
4. Proxmox creó el volume group y el thin pool y los registró como almacenamiento del datacenter.
5. Validé que apareciera habilitado, activo y con contenidos Disk image y Container.

Qué aporta LVM-Thin

El thin provisioning permite presentar discos virtuales de mayor tamaño lógico y consumir espacio físico a medida que se escriben datos. También facilita snapshots. No significa capacidad infinita: si el thin pool o sus metadatos llegan al límite, las VM pueden detenerse o sufrir corrupción. Por eso deben monitorearse uso de datos, metadatos y crecimiento real.

En este nodo separé sistema y cargas: una saturación de vmdata no llena directamente el filesystem raíz. Aun así, el SSD único sigue siendo un dominio de falla único. LVM-Thin mejora flexibilidad, no crea redundancia.

6. Repositorios y actualización del nodo

El primer refresh falló porque estaban activos los repositorios Enterprise de Proxmox y Ceph, para los cuales este laboratorio no tiene suscripción. La corrección fue explícita:

1. Deshabilité pve-enterprise.
2. Deshabilité el repositorio Enterprise de Ceph, que tampoco se utilizará en este nodo.
3. Habilité el repositorio oficial pve-no-subscription.
4. Actualicé nuevamente el catálogo y comprobé el estado OK.
5. Apliqué 194 actualizaciones y 2 paquetes nuevos; no se eliminó ningún paquete.
6. Reinicié para cargar el kernel nuevo y repetí la comprobación.

El resultado observado fue kernel 7.0.14-26-pve y pve-manager 9.2.25. Para una plataforma empresarial usaría una suscripción y el repositorio Enterprise: Proxmox documenta que contiene el conjunto más estable y validado, mientras pve-no-subscription está destinado a pruebas y uso no productivo.

7. Red: cómo funciona vmbr0

Un Linux bridge funciona conceptualmente como un switch virtual: las interfaces virtuales de las VM se conectan al puente y este las enlaza con la NIC física. En el laboratorio, vmbr0 transporta inicialmente administración y tráfico de guests. Es simple, pero comparte un único enlace y un único dominio de falla.

Diseño empresarial sugerido

• Separar administración, migración, almacenamiento, backup y redes de VM mediante enlaces o VLAN documentados.
• Usar bonding y switches redundantes cuando el SLA lo exija.
• No exponer el puerto 8006 a Internet; administrar desde VPN, bastión o red segura.
• Definir MTU extremo a extremo; no activar jumbo frames solo en una parte de la ruta.
• Documentar direccionamiento, VLAN, bridge, bond, gateway, DNS y rutas de recuperación.
• Probar pérdida de cada enlace antes de declarar redundancia.

8. ¿Proxmox realmente sirve para empresa?

Sí, técnicamente sirve. Proxmox VE integra KVM para máquinas virtuales, LXC para contenedores, administración web, API REST, clúster multi-master, migración en vivo, HA, firewall, SDN y varios backends de almacenamiento. Proxmox Backup Server añade copias incrementales, deduplicación, cifrado y live restore. El producto no está limitado a un laboratorio.

La pregunta correcta no es “¿Proxmox tiene el botón?”. Es: ¿puede mi organización diseñar, operar, actualizar y recuperar la plataforma durante un incidente? VMware convirtió durante años muchas tareas complejas en flujos conocidos. Al salir de ese ecosistema, algunas empresas descubren que habían comprado no solo software, sino también una zona de comodidad: procedimientos repetidos, integraciones conocidas y especialistas externos que asumían las decisiones difíciles.

El principal riesgo de una migración no es que Proxmox sea open source. Es adoptar una plataforma sin desarrollar las habilidades y la responsabilidad interna necesarias para operarla.

Los ingenieros que necesita la plataforma

• Virtualización: CPU, NUMA, overcommit, ballooning, drivers VirtIO, snapshots, live migration y compatibilidad de guests.
• Linux y KVM/QEMU: procesos, systemd, kernel, logs, paquetes, permisos y diagnóstico fuera de la GUI.
• Almacenamiento: LVM-Thin, ZFS, NFS/iSCSI o Ceph, latencia, IOPS, caché, consistencia y recuperación.
• Red: bridges, bonds, VLAN, MTU, routing, firewall, redundancia y análisis de paquetes.
• Protección: RPO/RTO, backup 3-2-1, inmutabilidad, restauraciones y pruebas de desastre.
• Operación: capacidad, monitoreo, parches, automatización, cambios, runbooks y respuesta a incidentes.
• Seguridad: RBAC, MFA, identidad, certificados, segmentación, hardening, auditoría y gestión de secretos.

Existe una carencia real de formación, práctica y cultura de ingeniería. Hay profesionales que saben administrar VMware mientras todo funciona, pero no dominan virtualización, Linux, almacenamiento o redes lo suficiente para cambiar de plataforma y diagnosticar una falla sin depender de un tercero. Eso no convierte a Proxmox en una opción inmadura; expone una incapacidad técnica que muchas organizaciones prefieren ocultar detrás de una marca y un contrato.

Instalar Proxmox toma poco tiempo; mantener una plataforma con SLA exige experiencia. Esperar que una empresa externa resuelva cada cambio y cada incidente crea dependencia y aumenta el tiempo de recuperación. Un proveedor especializado es valioso para arquitectura, validación y escalamiento, pero el equipo interno debe conservar conocimiento, acceso, procedimientos y capacidad de decisión.

9. De este nodo a una plataforma enterprise

Área	Laboratorio actual	Objetivo empresarial
Cómputo	Un nodo Ryzen	Clúster de al menos tres nodos, capacidad N+1 y hardware validado
Almacenamiento	Un SSD LVM-Thin	Redundancia local o compartida/distribuida, monitoreo y pruebas de fallo
Red	Una NIC en vmbr0	Enlaces y switches redundantes, separación por función
Backup	Pendiente	PBS/NAS separado, copia fuera del sitio, inmutabilidad y restauración probada
Actualizaciones	pve-no-subscription	Suscripción, repositorio Enterprise, anillo de pruebas y ventana de cambio
Identidad	Administrador local	LDAP/AD/OIDC, MFA, RBAC, cuentas nominativas y auditoría
Operación	Revisión manual	Monitoreo, alertas, CMDB, automatización, runbooks y guardia
Soporte	Comunidad	Contrato, matriz de escalamiento y responsables internos

Tres nodos no son una cifra mágica para todos los componentes, pero son el punto de partida habitual para mantener quorum y construir HA sin convertir cada mantenimiento en una interrupción. Si se incorpora Ceph, la cantidad y el tipo de nodos, discos y redes deben dimensionarse por rendimiento, capacidad y dominios de falla; instalar Ceph desde la interfaz no sustituye ese diseño.

10. Checklist antes de crear cargas importantes

• Crear un destino de backup separado de vmdata.
• Programar copias y realizar una restauración completa de prueba.
• Configurar alertas de capacidad, salud S.M.A.R.T., temperatura y errores de disco.
• Instalar UPS y comprobar apagado controlado ante pérdida de energía.
• Crear usuarios nominativos, MFA y permisos mínimos; evitar el uso cotidiano de root@pam.
• Configurar DNS y certificado confiable para la consola.
• Documentar firmware, BIOS, dispositivos, IP, bridge, almacenamiento y procedimientos de recuperación.
• Definir plantillas con QEMU Guest Agent y drivers VirtIO actualizados.
• Reservar recursos para el host; no asignar el 100 % de RAM y CPU a las VM.
• Medir rendimiento base antes de incorporar cargas y repetir después de cambios importantes.

11. Próximos pasos del laboratorio

1. Instalar Proxmox Backup Server o integrar un NAS separado y ejecutar la primera restauración.
2. Crear una plantilla Linux con cloud-init y una plantilla Windows con VirtIO.
3. Dedicar la segunda NIC a backup, almacenamiento o un bond, según el diseño que se pruebe.
4. Configurar VLAN y firewall para separar administración y redes de laboratorio.
5. Evaluar passthrough de GPU únicamente cuando exista una carga y una matriz IOMMU verificadas.
6. Automatizar inventario y creación de VM mediante la API, Terraform u otra herramienta declarativa.
7. Construir dos nodos adicionales si el objetivo evoluciona hacia clúster, quorum, migración y HA.

Conclusión

El resultado de esta instalación es un nodo de laboratorio potente y ordenado: Proxmox VE 9.2.2 actualizado, 16 hilos de CPU, casi 126 GiB de RAM, sistema separado de los datos, 3,81 TB en LVM-Thin y red funcional. Ya puede alojar VM de aprendizaje, pruebas, automatización y servicios no críticos.

También tiene límites claros: un solo nodo, un solo SSD de datos, una sola ruta activa y ningún backup externo. Reconocerlos es parte de hacer ingeniería. Proxmox no necesita disculpas para entrar en una evaluación empresarial; necesita un diseño verificable y personas capaces de operarlo.

Fuentes para ampliar

• Proxmox VE: instalación bare metal
• Requisitos de hardware de Proxmox VE
• Funciones: KVM, LXC, clúster, HA, red, almacenamiento y backup
• Proxmox VE Administration Guide
• Suscripciones y soporte de Proxmox VE
• Comparación y capacidades de Proxmox VE