Llevaba semanas dándole vueltas. Mi BMAX B2Plus, el mini PC que hacía de nodo Proxmox de todo el homelab, tenía 7.6GB de RAM y 21 contenedores encima. El resultado era el que cabía esperar: overcommit de memoria constante, con el swap rondando los 6.2GB de los 7.6GB disponibles casi todo el tiempo. Funcionaba, pero funcionaba mal, y cada servicio nuevo que añadía lo empeoraba un poco más.
La decisión llegó cuando encontré una oferta flash de un GMKtec G11 (AMD Ryzen Embedded R2514, 16GB DDR4 en dos SO-DIMM ampliables, 256GB SSD de fábrica, doble NIC 2.5G). Con dos slots M.2 2280 independientes (uno para el disco de serie, otro libre) y RAM en módulos normales en vez de soldada, era justo lo que necesitaba: sitio para crecer, no solo un salto puntual de potencia.
Agradecimientos a BMAX
En 2022 compré el BMAX para retirar las Raspberry Pi que llevaban años dándome tantas satisfacciones. En aquel momento no tenía ni idea de que, unos meses después, descubriría Proxmox — y que ese mismo BMAX, un equipo modesto donde los haya, aguantaría como un jabato gestionando esa carga hasta septiembre de 2026.
Cuatro años virtualizando sobre un hardware que nunca fue pensado para eso: dos VMs y un par de decenas de contenedores corriendo sin pausa, sin quejarse, sin darme ningún susto serio hasta el final. Así que, gracias, BMAX.
Ahora le toca jubilarse. Antes tendré que limpiarlo bien y ponerlo a la venta, y sospecho que costará explicarle a un comprador que una máquina tan modesta ha estado sosteniendo tanta virtualización — cuesta creérselo incluso a mí, que lo he visto con mis propios ojos. Veremos por cuánto se vende, si es que finalmente se vende.
Lo que decidí antes de tocar nada
Antes de empezar, fijé varias cosas que luego resultaron clave para no complicarme la vida:
No iba a montar cluster Proxmox. Con solo dos nodos, el quorum da más problemas de los que resuelve, y como el plan era apagar el BMAX definitivamente al final, no aportaba nada real. El GMKtec quedaría como nodo independiente, compartiendo el mismo storage PBS pero sin compartir usuarios ni configuración de cluster con el BMAX — una decisión que más adelante me obligó a recrear a mano varios tokens de API, pero que a cambio me ahorró bastante complejidad de mantener un quorum de dos.
El plan de migración era convivencia, no corte limpio. Durante toda la migración, BMAX y GMKtec estarían encendidos y en red a la vez, cada uno con su propia IP. Restauraría los CT/VM uno a uno desde los backups de PBS, y solo apagaría cada equivalente en el BMAX cuando el nuevo ya estuviera confirmado funcionando en el GMKtec — nunca antes, para no arriesgarme a tener IP duplicada en la red.
Aproveché el segundo NIC 2.5G para algo más que redundancia. En vez de comprar el router dedicado y el punto de acceso Ubiquiti que tenía en mente desde hacía tiempo (eso quedó aparcado para más adelante), ddecidí usar esa segunda tarjeta de red para montar vmbr1, una red interna dedicada (10.50.99.0/24) solo para los servicios que se acceden desde fuera por WireGuard — Pi-hole, AdGuard, gestión de Proxmox, Home Assistant. La idea era simple: en vez de ir acumulando rutas /32 sueltas en el AllowedIPs de WireGuard cada vez que quisiera acceder a un servicio nuevo, tener un /24 limpio que las cubriera todas de golpe.
Home Assistant, mqtt, zigbee2mqtt, el RFXtrx y el SAI se dejaron para el final. Todos dependen de hardware USB físico (el coordinador Zigbee, el propio RFXtrx, el cable del SAI), así que no tenía sentido migrarlos hasta el momento del traslado físico definitivo del equipo, cuando pudiera mover los cables sin tener que hacerlo dos veces.
El almacenamiento se planteó en dos fases. El GMKtec arrancaría con un Samsung 970 EVO Plus de 500GB (reciclado, comprobado y sano) como disco único. Más adelante, al decomisar el BMAX, reutilizaría su Crucial P3 500GB NVMe como segundo miembro para completar un mirror ZFS en el segundo slot M.2 — sin comprar hardware extra, solo reaprovechando lo que ya teníamos.
Proxmox VE 9.2, no la misma versión que el BMAX
El BMAX corría Proxmox VE 8.4.11. Al ir a instalar el GMKtec, la web de Proxmox ya solo ofrecía la 8.4-1 (más antigua que la que corría en producción) o la 9.2, la actual. Decidí ir directo a la 9.2, y no por capricho de tener lo último: como los nodos no iban a estar en cluster, no había ningún requisito técnico de que coincidieran en versión, y restaurar backups de PBS de un nodo 8.x a uno 9.x es la vía soportada y recomendada por Proxmox para este tipo de salto — más limpia que un apt dist-upgrade in-place. Además, la 9.2 trae un kernel bastante más moderno, con mejor soporte para el Ryzen Embedded del GMKtec, un chip que ni existía cuando se cortó la rama de kernel de la serie 8.x.
En el instalador, elegí ZFS (RAID0) como filesystem con el único disco disponible en ese momento, en vez del ext4/LVM por defecto — la pieza que me permitiría más adelante hacer zpool attach para convertirlo en mirror sin reinstalar nada.
El primer tropiezo: el password fácil no era tan fácil
Puse un password temporal durante la instalación, con la idea de cambiarlo en cuanto entrara por SSH. El problema llegó antes: al intentar conectar, SSH me rechazaba el password una y otra vez, pese a estar seguro de que era correcto. La sospecha recayó en un desajuste de layout de teclado entre el que usó el instalador y el que estaba usando yo para escribirlo — un clásico cuando hay caracteres especiales de por medio.
Probé un rescate desde el propio USB de instalación para resetear el password, pero el zpool import daba un error de "no such device rpool" que no llegué a depurar del todo con la paciencia que merecía en ese momento. Con la instalación todavía sin nada configurado, la decisión más pragmática fue simplemente reinstalar desde cero, esta vez con un password sencillo tecleado directamente (sin copiar y pegar), sin caracteres especiales, para eliminar cualquier ambigüedad de layout.
Al reinstalar, apareció otro pequeño susto sin importancia real: SSH avisó de "REMOTE HOST IDENTIFICATION HAS CHANGED" al conectar a la misma IP de antes. No es ningún ataque — es completamente esperable tras una reinstalación, porque el servidor SSH genera claves nuevas. Se soluciona limpiando la entrada antigua antes de reconectar:
ssh-keygen -R <IP-del-nodo>
ssh root@<IP-del-nodo>Configurar el doble NIC desde el primer arranque
Quise dejar la red de las dos tarjetas bien montada desde el principio, para no tener que mover contenedores de bridge más tarde. El primer paso fue identificar los nombres de las interfaces:
ip -br linkEn el GMKtec G11 aparecen como nic0 y nic1 — no el clásico enpXsX, sino nombres que dependen del firmware/BIOS del fabricante. El instalador configura automáticamente vmbr0 sobre la interfaz que tuviera el cable conectado durante la instalación; la otra queda DOWN hasta conectarle el segundo cable Ethernet.
Justo en este punto me topé con el problema más serio de toda la fase de instalación: una de las dos NIC (un Realtek RTL8125 rev 05) nunca levantaba enlace con el driver de fábrica r8169, sin importar cable ni puerto del switch — descarté ambos como causa cruzándolos entre las dos tarjetas, y el fallo se quedaba fijo en la misma NIC. Era un problema de compatibilidad conocido entre ese driver y esa revisión concreta del chip, y la solución (sustituir el driver por el r8125 del propio fabricante, vía DKMS) mereció su propio post aparte, con un matiz importante que se nos escapó en un primer intento y casi me obliga a reinstalar de nuevo. Lo dejamos documentado ahí: Arreglando el RTL8125 rev 05 en el GMKtec G11 con Proxmox VE 9.2.
Con las dos NIC ya funcionando, conecté el segundo cable 2.5G a la interfaz que había quedado DOWN y confirmé que subía:
ip -br linkAntes de tocar nada, revisé lo que el instalador ya había dejado configurado:
cat /etc/network/interfacesañadí el bloque de vmbr1 sin pisar lo que ya existía de vmbr0:
auto lo
iface lo inet loopback
auto nic1
iface nic1 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.1.15/24
gateway 192.168.1.1
bridge-ports nic1
bridge-stp off
bridge-fd 0
#LAN principal, misma red que el BMAX (IP provisional, se cambiaría a .10 al decomisar el BMAX)
auto nic0
iface nic0 inet manual
auto vmbr1
iface vmbr1 inet static
address 10.50.99.1/24
bridge-ports nic0
bridge-stp off
bridge-fd 0
#Red interna dedicada, sin gateway — segmento aislado a propósitoElegí 192.168.1.15 como IP de gestión provisional (tras dudar entre un par de opciones y cambiar de idea un par de veces durante el proceso), con intención de reasignarle la 192.168.1.10 — la que tenía el BMAX — una vez este quedara desconectado del todo.
El detalle importante de vmbr1 es que no lleva gateway: así el propio host Proxmox no tiene ruta por defecto hacia ese segmento y no acaba haciendo de router entre las dos redes por accidente. Confirmé también que el reenvío de paquetes estaba desactivado en el host:
sysctl net.ipv4.ip_forwardTenía que dar 0 — si Proxmox lo hubiera activado por defecto (a veces lo hace para NAT de VMs), habría que forzarlo a 0 en /etc/sysctl.d/. La única ruta entre 10.50.99.0/24 y el resto de la red sería la que definiéramos explícitamente más adelante en WireGuard, no el propio nodo.
Reinicié el networking y verifiqué:
ip a
ping 192.168.1.1Por último, añadí el storage PBS al nuevo nodo desde Datacenter → Storage → Add → Proxmox Backup Server, con los mismos datos (servidor, datastore, fingerprint, usuario/token) que ya usaba el BMAX — no hace falta estar en el mismo cluster para compartir un mismo storage PBS.
Con la red montada, el driver de red resuelto, y el storage de backups ya visible desde el nodo nuevo, estaba listo para empezar a restaurar servicios de verdad. De eso trata la segunda parte.
