Qué es Proxmox VE y cómo instalar tu primer nodo

Tienes un servidor y necesitas convertirlo en varias máquinas. La respuesta obvia durante quince años fue ESXi con un vCenter al lado, y hoy esa respuesta cuesta lo que cuesta: Broadcom eliminó las licencias perpetuas, pasó el precio de socket a core y, desde abril de 2025, el pedido mínimo por suscripción subió de 16 a 72 cores. Un servidor de dos sockets que antes se licenciaba con dos números ahora se factura como si tuviera 72 cores aunque tenga 32.

Proxmox VE resuelve el mismo problema con otro modelo: todo el software es AGPLv3, todas las funciones están disponibles sin pagar, y la suscripción compra soporte y un repositorio de paquetes más probado, no funcionalidad. Ese matiz —que no hay edición recortada— es el que hace que un homelab y un cluster de producción corran exactamente el mismo binario.

Este capítulo es el punto de partida del curso. Al terminarlo tendrás un nodo Proxmox VE 9.2 instalado, con el filesystem correcto para tu hardware, los repositorios APT apuntando donde deben y el sistema actualizado con la orden que no rompe el estado de paquetes. Y sabrás por qué cada una de esas decisiones importa antes de que haya una sola máquina virtual encima.

Los datos de este capítulo están verificados contra la documentación oficial 9.2.4, compilada el 4 de agosto de 2026. Cuando algo depende de tu hardware o de tu versión, te digo cómo comprobarlo en el propio sistema en lugar de inventármelo.

Qué es Proxmox VE: virtualización y HCI en una sola herramienta

Proxmox Virtual Environment es una plataforma de virtualización de servidores y de infraestructura hiperconvergente, de código abierto, construida sobre Debian GNU/Linux. Lo que la distingue de “un Debian con KVM instalado” es que integra en un solo producto piezas que normalmente compras por separado:

• Virtualización completa con KVM/QEMU: cualquier sistema operativo x86-64 o arm64, con el hardware virtual configurable pieza a pieza. Es el tema del capítulo 3.
• Virtualización a nivel de sistema operativo con LXC: contenedores de sistema Linux que comparten el kernel del host. Desde 9.1 también se pueden crear contenedores desde imágenes OCI, en technology preview.
• Almacenamiento definido por software: ZFS local, Ceph hiperconvergido (RBD y CephFS), LVM, LVM-thin, iSCSI, NFS, CIFS, GlusterFS y Proxmox Backup Server.
• Red definida por software: bridges Linux, Open vSwitch, VLAN, VXLAN, EVPN y fabrics —OpenFabric y OSPF, y desde 9.2 también WireGuard y BGP—.
• Clustering multi-maestro con corosync y pmxcfs, alta disponibilidad y live migration.
• Firewall distribuido cluster-wide, IPv4 e IPv6.
• Backup y restore integrados con vzdump, con integración nativa con Proxmox Backup Server.
• Interfaz web única, API REST y CLI, los tres hablando contra el mismo backend.

Los máximos declarados por Proxmox en su página de comparación son 128 TiB de RAM, 8192 CPUs lógicas y 8 sockets por host. No son límites que vayas a rozar: sirven para descartar la idea de que esto es “el hipervisor de los aficionados”.

Advertencia sobre las cifras de marketing: la nota de prensa de 9.2 habla de “más de 2 millones de hosts” y “más de 225.000 miembros de la comunidad”. Son números publicados por la propia empresa, sin auditoría de terceros. Úsalos como orden de magnitud, no como dato duro.

El diferencial: no hay vCenter, cualquier nodo gestiona el cluster

Si vienes de VMware, esta es la frase que cambia tu arquitectura mental. La documentación oficial lo dice sin rodeos en el capítulo 1 del Admin Guide:

“Every node in a Proxmox VE cluster can perform all management tasks. There is no single-point-of-failure central management server — any node can manage the entire cluster.”

En vSphere, vCenter es una appliance adicional que hay que desplegar, licenciar, respaldar y proteger, y sin la cual pierdes DRS, vMotion orquestado y buena parte de la gestión. En Proxmox VE ese componente no existe: cada nodo tiene el mismo demonio pveproxy escuchando en el puerto 8006 y la misma copia replicada de la configuración del cluster. Te conectas a cualquiera de ellos y ves y administras todo.

El mecanismo que lo hace posible es pmxcfs, un filesystem respaldado por una base de datos que se replica en tiempo real entre todos los nodos usando corosync, y que se monta en /etc/pve. Cuando escribes la configuración de una VM en un nodo, aparece en el resto en el acto. Esa pieza tiene un capítulo entero: la desmontamos en el capítulo 2, y el modelo de quorum que la gobierna en el capítulo 11.

La contrapartida honesta: al no haber un punto central, la configuración del cluster es el estado replicado, y perder quorum deja /etc/pve en solo lectura en los nodos que se quedan en minoría. No es un fallo, es el diseño.

Historia del proyecto y los cuatro productos del ecosistema

Proxmox Server Solutions GmbH es una empresa austriaca con sede en Viena, fundada por Dietmar Maurer y Martin Maurer. El pie de página del sitio corporativo arranca la cuenta en 2004; el desarrollo del producto empezó en 2005, cuando los fundadores detectaron que OpenVZ no tenía ni herramienta de backup ni interfaz de gestión.

Año	Hito
15 abr 2008	Primera release pública: Proxmox VE 1.0, con contenedores OpenVZ, KVM y GUI web, sobre Debian 5 Lenny
2012	PVE 2.0: llega corosync, se introduce pmxcfs, se pasa a AGPLv3 y aparece la API REST con esquema declarativo en JSON Schema
2014	Primera distribución en incluir ZFS on Linux por defecto
2015 (PVE 4.0)	OpenVZ es reemplazado por LXC; se introduce el HA manager
PVE 5.x	Replicación asíncrona de storage sobre ZFS y gestión automática de certificados ACME
2020	Lanzamiento de Proxmox Backup Server, escrito en Rust
2022	Lanzamiento de Proxmox Offline Mirror
8.1 (23 nov 2023)	El stack SDN pasa a soportado e instalado por defecto
8.2 (24 abr 2024)	Instalación desatendida desde la ISO y asistente de importación desde ESXi y OVF/OVA
05 ago 2025	PVE 9.0 sobre Debian 13 Trixie
21 may 2026	PVE 9.2, la versión estable actual
05 ago 2026	PVE 9.2 para arm64, la primera arquitectura distinta de x86-64 en la historia del proyecto

El backend histórico está en Perl (pve-manager, qemu-server, pve-container) y los componentes nuevos en Rust (PBS, proxmox-firewall, la UI móvil, PDM). La web UI clásica usa ExtJS 7.x. El roadmap declara dos direcciones de largo plazo: migrar gradualmente el backend Perl a Rust apoyándose en la capa de interoperabilidad perlmod, y migrar la interfaz principal de ExtJS al toolkit Rust/Yew.

Alrededor de PVE hay tres productos más. Conviene tener el mapa claro desde el principio, porque los ISOs conviven en el mismo servidor de descargas y es fácil bajarse el equivocado.

flowchart LR
    PVE["Proxmox VE 9.2<br/>virtualizacion y HCI"]
    PBS["Proxmox Backup Server 4.2<br/>backup incremental dedup y cifrado"]
    PMG["Proxmox Mail Gateway 9.1<br/>anti-spam y anti-virus"]
    PDM["Proxmox Datacenter Manager 1.1<br/>gestion multi-cluster"]

    PVE -->|storage de backup| PBS
    PDM -->|gestiona| PVE
    PMG -.->|producto independiente| PVE

Los ISOs vigentes en http://download.proxmox.com/iso/ a 9 de agosto de 2026:

Producto	ISO	Fecha	Tamaño
Proxmox VE	proxmox-ve_9.2-1.iso	2026-05-21	1.6 GB
Proxmox VE arm64	proxmox-ve_9.2-1-arm64.iso	2026-08-05	—
Proxmox VE	proxmox-ve_9.1-1.iso	2025-11-19	1.7 GB
Proxmox VE	proxmox-ve_8.4-1.iso	2025-04-09	1.5 GB
PBS	proxmox-backup-server_4.2-1.iso	2026-04-28	1.4 GB
PMG	proxmox-mail-gateway_9.1-1.iso	2026-06-10	1.6 GB

El SHA256 oficial de la ISO de PVE 9.2 es 4e88fe416df9b527624a175f24c9aa07c714d3332afb1ee3dbf3879573ef2c6c. Cada ISO trae además su .asc con la firma GPG, un fichero CHECKSUM y un .torrent.

# verificar el checksum
sha256sum proxmox-ve_9.2-1.iso

# verificar la firma GPG con el keyring de release de Proxmox
gpg --verify proxmox-ve_9.2-1.iso.asc proxmox-ve_9.2-1.iso

# alternativa con sequoia
sqv --signature-file proxmox-ve_9.2-1.iso.asc proxmox-ve_9.2-1.iso

Licencia AGPLv3, planes de suscripción y el diálogo “No valid subscription”

Proxmox VE 1.x se publicó bajo GPLv2. Desde PVE 2.x la licencia es GNU Affero General Public License v3 (AGPLv3), y el código completo está en https://git.proxmox.com/, con un repositorio git por componente.

La consecuencia práctica que más confunde a quien viene del mundo comercial está respondida literalmente en la FAQ oficial de precios:

“Are Proxmox VE features limited by subscription level? No. High availability, live migration, clustering, backup, software-defined storage, networking, and all other Proxmox VE features are available at every level.”

No hay edición Community recortada. Lo que compras con una suscripción es: acceso al repositorio enterprise (paquetes más probados), soporte técnico con SLA y activación de claves offline.

Plan	Precio anual por socket	Tickets/año	Tiempo de respuesta	Repo enterprise	Soporte SSH remoto
COMMUNITY	€120	0, solo foro	—	Sí	No
BASIC	€370	3	1 día hábil	Sí	No
STANDARD	€550	10	4 horas	Sí	Sí
PREMIUM	€1.100	Ilimitados	2 horas	Sí	Sí

Precios verificados el 9 de agosto de 2026, netos y sin IVA, con término de un año. El horario del soporte enterprise es de lunes a viernes, 07:00 a 17:00 CET/CEST, en días hábiles austriacos.

Las reglas de licenciamiento, textuales:

“A subscription is required for every occupied physical CPU socket. The number of CPU cores does not affect the price. Every server in a cluster needs coverage for its occupied sockets, and all nodes in a cluster must use the same subscription level.”

Gotcha: los cores no cuentan, los sockets ocupados sí, y todos los nodos del cluster deben tener el mismo nivel. No puedes cubrir dos nodos con PREMIUM y dejar el tercero en COMMUNITY. Además, desde la llegada de arm64, las claves están ligadas a la arquitectura del host: una clave x86 no vale en un host arm64 ni al revés.

El nag de “No valid subscription”

Cuando el nodo no tiene suscripción activa, la interfaz web muestra un diálogo modal al entrar. La lógica está en Proxmox.Utils.checked_command(), que hace un GET /nodes/localhost/subscription y muestra el aviso si el estado no es active. En el sistema instalado, ese código vive en /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js.

Circulan parches comunitarios que editan ese fichero. No están soportados, se revierten en cada actualización del paquete proxmox-widget-toolkit, y no eliminan el error de apt contra el repositorio enterprise. La vía soportada para trabajar sin pagar es desactivar el repo enterprise y habilitar pve-no-subscription, que verás más abajo. El diálogo seguirá apareciendo: es el comportamiento diseñado, no un bug.

Comparativa honesta: vSphere, XCP-ng, Hyper-V y Nutanix AHV

Dimensión	Proxmox VE 9.2	VMware ESXi / vSphere	XCP-ng 8.3 LTS	Microsoft Hyper-V	Nutanix AHV
Hipervisor	KVM tipo 1 sobre kernel Linux, más LXC	ESXi propietario, VMkernel	Xen con dom0 separado	Hyper-V con partición raíz Windows	AHV, KVM endurecido
Licencia	AGPLv3, 100% libre	Propietaria, suscripción	Open source GPL	Propietaria, con Windows Server	Propietaria
Modelo comercial	Suscripción por socket, opcional	Suscripción por core, obligatoria	Soporte por Vates, opcional	Licencia Windows Server por core	Por nodo, en bundle
Consola central	Ninguna necesaria	vCenter, appliance adicional	Xen Orchestra, appliance aparte	Windows Admin Center / SCVMM	Prism Element / Central
Contenedores nativos	Sí, LXC más OCI en preview	No	No	No	No
Storage SDS integrado	Ceph hiperconvergido y ZFS	vSAN, licencia aparte en VVF	Sin SDS nativo	Storage Spaces Direct	Nutanix AOS DSF
SDN	Integrado: VLAN, VXLAN, EVPN, fabrics, BGP, WireGuard	NSX, licencia aparte	Limitado, vía XO	Network Controller	Flow
Backup nativo	vzdump más PBS incremental	Solo API VADP	XO Backup	Windows Server Backup	Nutanix Mine o tercero
API	REST con JSON Schema	REST, SOAP, PowerCLI	XAPI y XO API	PowerShell y WMI	REST v3/v4
Punto débil honesto	Ecosistema de partners y certificaciones ISV menor; documentación densa; curva Linux	Coste post-Broadcom; mínimos de licencia	Comunidad e ISV menores; sin SDS nativo; releases lentas	Atado al ecosistema Windows	Coste enterprise; modelo de appliance

El efecto Broadcom, con las cifras en su sitio

Advertencia metodológica: Broadcom no publica una lista de precios pública. Todas las cifras que siguen provienen de analistas y consultoras, no de fuente primaria del fabricante. Preséntalas como órdenes de magnitud reportados.

Los hechos que sostienen la ola de migraciones: se eliminaron las licencias perpetuas, se pasó de precio por socket a precio por core con un mínimo de 16 cores por CPU física, y desde el 10 de abril de 2025 el pedido mínimo subió de 16 a 72 cores por suscripción. El portfolio se simplificó a VCF, VVF y vSphere Standard, con precios de lista ampliamente reportados en torno a 400, 155 y 55 USD por core y año.

Ejemplo ilustrativo con un servidor de 2 sockets por 32 cores, es decir 64 cores:

• VVF a ~155 USD por core y año sería ≈ 9.920 USD/año, pero con el mínimo de 72 cores se factura como 72 → ≈ 11.160 USD/año.
• Proxmox VE STANDARD: 2 sockets × €550 = €1.100/año, con todas las funciones.
• Proxmox VE sin suscripción: €0, con el repositorio pve-no-subscription.

Los matices que hay que decir en voz alta: el coste de licencia no es el coste total. Migrar implica reingeniería de storage (VMFS y vSAN hacia ZFS, Ceph o LVM), reescritura de la automatización (PowerCLI hacia API REST, Ansible o Terraform), formación del equipo, revalidación del backup y del plan de recuperación, y pérdida de certificaciones ISV concretas. Proxmox reduce parte de esa fricción con el asistente de importación desde ESXi que trae desde 8.2 y con el soporte de OVF/OVA; ese camino completo es el capítulo 16.

Y un dato de contexto: lo que se mueve hoy es sobre todo SMB, mid-market, edge y cargas nuevas. En gran empresa las encuestas de intención siguen poniendo a Hyper-V primero como alternativa considerada. Las métricas de “mindshare” de agregadores de reviews son ruidosas y conviene usarlas con pinzas.

Versiones, ciclo de vida y el EOL de Proxmox VE 8

El stack base de Proxmox VE 9.2, publicada el 21 de mayo de 2026:

Componente	Versión
Debian	13.5 “Trixie” (13.6 en la build arm64)
Kernel Linux	7.0
QEMU	11.0
LXC	7.0
ZFS	2.4
Ceph	Squid 19.2.3 y Tentacle 20.2.1, este último default en despliegues nuevos

Lo más relevante que trajo 9.2 y que verás a lo largo del curso: balanceo dinámico de carga con el Cluster Resource Scheduler en modo dynamic, que migra automáticamente guests gestionados por HA usando métricas en tiempo real y respetando las reglas de HA; los nuevos protocolos de fabric WireGuard y BGP en SDN con route maps y prefix lists; modelos de CPU personalizados desde la web UI; y los comandos disarm-ha y arm-ha para hacer mantenimiento cluster-wide sin disparar fencing.

Proxmox usa un modelo de rolling release sobre Debian. La FAQ oficial fija el soporte así:

“Proxmox VE versions are supported at least as long as the corresponding Debian version is supported by the Debian Security Team, i.e. approximately 3 years after its initial release.”

PVE	Debian	Primera release	EOL de Proxmox
9	13 Trixie	2025-08	por anunciar
8	12 Bookworm	2023-06	2026-08
7	11 Bullseye	2021-07	2024-07
6	10 Buster	2019-07	2022-09

Advertencia: Proxmox VE 8 llega a EOL en agosto de 2026, es decir, ahora mismo. Si administras nodos en 8.4, el upgrade a 9 no es una mejora opcional sino una tarea con fecha vencida. La guía oficial es https://pve.proxmox.com/wiki/Upgrade_from_8_to_9. Un upgrade menor dentro de la rama 9, en cambio, es una actualización normal:

apt update
apt full-upgrade

Una nota sobre versionado que ahorra confusiones: cada componente lleva su propia numeración. En un nodo 9.2 puedes encontrar pve-manager en 9.2.10, pve-cluster en 9.1.6, qemu-server en 9.2.5, pve-container en 6.1.13 y pve-docs en 9.2.4. Que pve-cluster diga 9.1 no significa que tu sistema sea 9.1. La foto real la da pveversion -v.

Requisitos de hardware, virtualización por CPU e IOMMU

Los mínimos absolutos, útiles solo para evaluación, son ridículos a propósito: una CPU x86-64 de 64 bits con Intel VT o AMD-V —o una CPU ARM de 64 bits ARMv8-A o superior—, 1 GB de RAM más la de los guests, un disco y una tarjeta de red.

Los requisitos de producción son los que importan:

Recurso	Recomendación oficial
CPU	Intel 64 o AMD64 con flag VT o AMD-V; o host ARM de 64 bits con ARMv9-A o superior
Memoria	Mínimo 2 GB para el SO y los servicios de Proxmox VE, más la memoria asignada a los guests
Memoria con ZFS o Ceph	Sumar aproximadamente 1 GB de RAM por cada TB de almacenamiento usado
Disco del SO	RAID hardware con caché de escritura protegida por batería, o sin RAID hardware usando ZFS
Disco de VMs	RAID hardware con BBWC, o sin RAID para ZFS y Ceph
SSD	Con Power-Loss-Protection. Los SSD de consumo están desaconsejados
Red	NICs multi-Gbit redundantes, más NICs adicionales según el diseño de storage y cluster
Passthrough PCI(e)	CPU y placa con IOMMU: Intel VT-d o AMD-Vi en x86, SMMU en arm64. Normalmente hay que habilitarlo en la BIOS/UEFI

Advertencia, la más cara de todo el capítulo. Cita literal de la documentación:

“ZFS on top of any hardware RAID is not supported and can result in data loss.”

Ni ZFS ni Ceph son compatibles con una controladora RAID hardware. Si tu servidor trae una, hay que ponerla en modo HBA/IT o cambiarla, no “configurarla en RAID0 por disco”. Este punto se desarrolla entero en el capítulo 8.

La regla de dimensionado de RAM para ZFS que da el propio Admin Guide es directa: “4GB plus 1GB RAM for each TB RAW disk space”. Un nodo con 24 TB crudos en ZFS quiere unos 28 GB solo para ZFS, antes de arrancar la primera VM.

Comprobar que tu CPU sirve

El comando textual de la FAQ:

egrep '(vmx|svm)' /proc/cpuinfo

vmx es Intel VT-x y svm es AMD-V. Si no aparece nada, o la CPU no lo soporta o está desactivado en la BIOS/UEFI. Comprobaciones adicionales estándar, útiles con el sistema ya instalado:

lscpu | grep -i virtual
ls -l /dev/kvm                      # debe existir si KVM esta cargado
lsmod | grep kvm                    # kvm_intel o kvm_amd
dmesg | grep -i -e DMAR -e IOMMU    # evidencia de IOMMU activo

Sobre IOMMU, dos datos que ahorran horas de foros desactualizados: con CPUs AMD el IOMMU está habilitado por defecto, y con kernels 6.8 o superiores también lo está en CPUs Intel. El famoso intel_iommu=on solo hace falta en kernels antiguos. Dónde se edita esa línea depende del bootloader: en sistemas gestionados por proxmox-boot-tool —lo habitual cuando la raíz está en ZFS o BTRFS— se edita /etc/kernel/cmdline y se ejecuta proxmox-boot-tool refresh; en sistemas con GRUB se edita GRUB_CMDLINE_LINUX_DEFAULT en /etc/default/grub y se ejecuta update-grub. El passthrough completo, con módulos VFIO y grupos IOMMU, está en el capítulo 3.

En cuanto a navegadores para la interfaz web: Firefox en la release del año en curso o el último ESR, Chrome del año en curso, Edge en una versión soportada por Microsoft y Safari del año en curso. Desde móvil, Proxmox redirige a una interfaz ligera táctil.

Soporte arm64: qué funciona y qué no

Agosto de 2026 trajo la primera arquitectura no x86 del proyecto. Los límites están declarados con precisión y conviene leerlos antes de comprar hardware:

• Soporte nativo solo en las plataformas NVIDIA Grace Hopper y NVIDIA Vera. En otro hardware ARMv9-A o superior basado en UEFI, el soporte es best-effort.
• Los SBC que solo tienen device-tree, como Raspberry Pi, NO están soportados. El host debe arrancar por UEFI y describir su hardware por ACPI.
• Las VMs no pueden usar SeaBIOS: en arm64 siempre arrancan por UEFI con la build ARM de OVMF, llamada AAVMF. El machine type es virt.
• AMD SEV e Intel GVT-g son solo x86, y no existe paquete de microcódigo de CPU a nivel de sistema operativo.
• memtest86+ no existe en medios arm64.

Un cluster puede mezclar nodos x86 y arm64, con dos reglas duras: la live migration solo funciona entre nodos de la misma arquitectura, y un guest solo corre donde la arquitectura coincide. La migración offline, el backup/restore o el storage compartido pueden mover los datos, pero el guest hay que reinstalarlo o reconfigurarlo para la otra arquitectura. Y como ya vimos, la clave de suscripción también está ligada a la arquitectura; hoy no hay compra online self-service de claves arm64.

Preparar el medio y el menú de arranque del instalador

La ISO es híbrida: sirve como imagen de CD/DVD y como imagen raw para USB. Proxmox recomienda USB por velocidad.

# GNU/Linux: identificar el dispositivo antes y despues de enchufar el USB
lsblk

# escribir la imagen (sustituye /dev/XYZ por el dispositivo real del USB)
dd bs=1M conv=fdatasync if=./proxmox-ve_9.2-1.iso of=/dev/XYZ

# macOS
hdiutil convert proxmox-ve_9.2-1.iso -format UDRW -o proxmox-ve_9.2-1.dmg
diskutil list
diskutil unmountDisk /dev/diskX
sudo dd if=proxmox-ve_9.2-1.dmg bs=1M of=/dev/rdiskX

El rdiskX en vez de diskX es intencional: el dispositivo raw acelera mucho la escritura.

En Windows, Etcher funciona directo. Con Rufus hay que usar modo DD: al pulsar Start responde No al diálogo que ofrece descargar otro GRUB y elige DD mode.

Advertencia literal de la documentación: NO uses UNetbootin. “It does not work with the Proxmox VE installation image.”

El menú de arranque del instalador tiene más entradas de las que parece, y varias son salvavidas:

Entrada	Qué hace
Install Proxmox VE (Graphical)	Instalación normal. Se puede manejar solo con teclado usando ALT + la letra subrayada de cada botón
Install Proxmox VE (Terminal UI)	Mismo asistente en modo texto, misma base de código. Mejor compatibilidad con hardware muy viejo o muy nuevo
Install Proxmox VE (Terminal UI, Serial Console)	Igual, pero configurando el kernel para usar el primer puerto serie como entrada/salida
Advanced Options → Graphical, Debug Mode	Abre una consola en varios puntos de la instalación. CTRL-D sale de cada consola de debug. Sirve también como sistema live para reparar un rpool degradado o un bootloader roto
Advanced Options → Terminal UI, Debug Mode	Lo mismo preparando el instalador de texto
Advanced Options → Serial Console Debug Mode	Debug en modo texto sobre consola serie
Advanced Options → Automated	Arranca el instalador en modo desatendido aunque la ISO no esté preparada para ello. Útil para depurar un setup automatizado
Advanced Options → Rescue Boot	Busca instalaciones existentes en todos los discos y arranca la primera usando el kernel de la ISO. Salva la papeleta con GRUB o systemd-boot rotos
Advanced Options → Test Memory (memtest86+)	Test de memoria. Requiere Secure Boot desactivado. Solo en medios x86

Dos trucos que resuelven la mayoría de los arranques fallidos:

Uno. Pantalla negra o cuelgue al arrancar el instalador. Casi siempre es el driver gráfico. Sitúate sobre Install Proxmox VE (Terminal UI), pulsa e, ve con las flechas al final de la línea que empieza por linux, añade un espacio y nomodeset, y arranca con Ctrl-X o F10.

Dos. La instalación falla sin mensaje claro. Los errores reales están en la segunda TTY: CTRL + ALT + F2.

Sobre Secure Boot: la documentación dice que hay que desactivarlo “when booting an installer prior to Proxmox VE version 8.1”. Desde 8.1 el instalador arranca con Secure Boot activo. El memtest86+ sigue exigiendo desactivarlo.

El asistente paso a paso y la elección de filesystem

flowchart TD
    A["EULA"] --> B["Seleccion de discos destino"]
    B --> B1["Boton Options<br/>filesystem y parametros avanzados"]
    B1 --> C["Location and Time Zone<br/>pais zona horaria y teclado"]
    C --> D["Administration Password<br/>password de root y email"]
    D --> E["Management Network<br/>interfaz hostname FQDN IP/CIDR gateway y DNS"]
    E --> F["Summary<br/>revision completa"]
    F --> G["Install<br/>formatea y copia paquetes"]
    G --> H["Reboot automatico tras unos segundos"]

Pantalla por pantalla, con lo que no es obvio:

Uno. Target disks. “By default, the whole server is used and all existing data is removed.” El instalador no añade entradas de arranque para otros sistemas operativos: olvídate del dual boot. El botón Options abre el selector de filesystem y, para ZFS, la selección de los discos que forman el pool; los ajustes finos están en Advanced Options dentro de ese diálogo.

Dos. Location & Time Zone. La localización se usa para elegir un mirror de descarga cercano. Suele autodetectarse bien.

Tres. Password y email. El mínimo que acepta el instalador son 8 caracteres; la guía oficial recomienda al menos 12, mezclando minúsculas, mayúsculas, números y símbolos, y evitando repeticiones, patrones de teclado, palabras de diccionario, secuencias, nombres de usuario, de mascotas o de familiares y datos biográficos. El email recibe avisos de actualizaciones de paquetes disponibles y errores de cron: pon uno que leas.

Cuatro. Management Network. Las interfaces que están UP se muestran con un círculo relleno en el desplegable. Durante la instalación puedes poner IPv4 o IPv6, pero no ambas. Para dual-stack, añade la segunda dirección después de instalar, editando /etc/network/interfaces o desde la GUI; la red del host es el capítulo 9.

Cinco. Summary e Install. Revisa y usa Previous si algo está mal. La copia de paquetes tarda varios minutos según el medio y el disco destino, y el sistema reinicia solo pasados unos segundos.

Qué filesystem elegir

El instalador ofrece cuatro: ext4 sobre LVM (el default), xfs sobre LVM, ZFS con RAID software integrado y BTRFS, marcado como technology preview.

flowchart TD
    Q1{"Hay controladora RAID hardware<br/>que no puedes pasar a modo HBA o IT"}
    Q1 -->|Si| LVM["ext4 o xfs sobre LVM<br/>la redundancia la da la controladora"]
    Q1 -->|No| Q2{"Necesitas checksums de datos<br/>snapshots baratos y replicacion"}
    Q2 -->|Si| ZFS["ZFS con su nivel RAID<br/>RAID0 RAID1 RAID10 RAIDZ-1 RAIDZ-2 RAIDZ-3"]
    Q2 -->|No| LVM
    Q2 -->|Solo para probar| BTRFS["BTRFS technology preview<br/>no apto para produccion"]
    ZFS --> WARN["Regla dura<br/>ZFS sobre RAID hardware no esta soportado<br/>y puede causar perdida de datos"]

La decisión real es esta: si tu servidor tiene una controladora RAID hardware con caché protegida por batería y no puedes ponerla en modo HBA, vas a ext4 o xfs sobre LVM y dejas que la controladora haga la redundancia. Si tienes los discos directos o una HBA en modo IT, ZFS te da checksums de extremo a extremo, snapshots baratos y replicación asíncrona entre nodos —la base del capítulo 8—. BTRFS es preview: no lo pongas debajo de producción.

Opciones avanzadas de LVM y de ZFS

Estas son las opciones detrás del botón Options que casi nadie toca y que luego se lamenta de no haber tocado.

Con ext4 o xfs: el volume group pve

El instalador crea un Volume Group llamado pve con los Logical Volumes root, data y swap.

Opción	Qué define	Valor por defecto exacto
hdsize	Tamaño total del disco a usar. Permite reservar espacio libre para otra partición, PV o VG	Todo el disco
swapsize	Tamaño del volumen swap. Si pones 0, no se crea swap	El tamaño de la RAM instalada, con mínimo 4 GB y máximo 8 GB, y el resultado nunca puede superar hdsize / 8
maxroot	Tamaño máximo del volumen root, el del sistema operativo	Con disco mayor de 48 GiB: hdsize / 4 con máximo 96 GiB. Con disco menor de 48 GiB: el root es al menos hdsize / 2
maxvz	Tamaño máximo del volumen data. El real es datasize = hdsize - rootsize - swapsize - minfree. Si pones 0, no se crea el volumen data y la configuración de storage se adapta. Con LVM-thin el pool solo se crea si datasize > 4 GB	El resto calculado
minfree	Espacio libre que debe quedar en el VG pve. LVM necesita espacio libre en el VG para crear snapshots clásicos —no hace falta para los de lvmthin—	16 GB si el disco supera 128 GB; si no, hdsize / 8

El caso de uso más frecuente de hdsize: dejar libre una parte del NVMe de arranque para añadir después otro pool o un PV separado. Si no reduces hdsize durante la instalación, tendrás que reparticionar en caliente más tarde. El instalador coloca además dos bootloaders: una primera partición con GRUB estándar y una segunda EFI System Partition que permite arrancar en sistemas EFI y aplicar actualizaciones de firmware persistentes desde espacio de usuario.

Con ZFS: el pool rpool

El instalador crea el pool rpool y no crea swap. Si quieres swap, puedes reservar espacio sin particionar en los discos de instalación, o crear un zvol de swap después, con las advertencias conocidas del swap sobre ZFS.

Opción	Qué define
ashift	El ashift del pool. Debe ser al menos el tamaño de sector de los discos subyacentes —2^ashift es el tamaño de sector— o el de cualquier disco que pueda entrar después, por ejemplo el reemplazo de uno averiado
compress	Si la compresión está activa en rpool
checksum	Algoritmo de checksum de rpool
copies	El parámetro copies de rpool. La documentación avisa: no sustituye a la redundancia a nivel de disco
ARC max size	Tamaño máximo al que puede crecer el ARC. Es la palanca para limitar cuánta RAM se come ZFS
hdsize	Tamaño total de disco a usar. Solo se respeta en los discos arrancables: el primer disco o mirror en RAID0, RAID1 y RAID10, y todos los discos en RAID-Z[123]

Gotcha: ashift no se puede cambiar después de crear el pool. Si eliges un ashift menor que el sector físico real de un disco que vayas a meter más adelante, o el pool rinde mal o directamente no admite el reemplazo. Elígelo pensando en el disco más grande de sector que vas a usar en la vida del pool, no en el que tienes hoy.

Un ZIL en SSD dedicado sí se puede añadir después de instalar:

zpool add rpool log /dev/disk/by-id/<id-del-ssd-rapido>

Sustituye <id-del-ssd-rapido> por el identificador estable que veas con ls -l /dev/disk/by-id/. Usar rutas by-id en lugar de /dev/sdX evita que un reordenamiento de discos rompa el pool.

Con BTRFS, las únicas opciones son compress —con valores on, que equivale a zlib, más zlib, lzo y zstd, y por defecto off— y hdsize. Tampoco crea swap; ahí se usa btrfs filesystem mkswapfile.

Instalación desatendida

Para desplegar muchos nodos, el instalador soporta un answer file con reglas de filtro para decidir qué discos y qué tarjetas de red usar. El flujo es: eliges la fuente del answer file, preparas una ISO con esa elección, y el menú de arranque de esa ISO muestra una entrada nueva llamada Automated Installation que se selecciona sola tras un timeout de 10 segundos. Tras el primer arranque, la propia documentación recomienda continuar con Ansible u otra herramienta de gestión de configuración, terreno del capítulo 14. El procedimiento detallado está en https://pve.proxmox.com/wiki/Automated_Installation.

Instalación sobre un Debian 13 existente

Hay un camino alternativo: partir de un Debian 13 Trixie ya instalado —típico cuando el proveedor del servidor dedicado solo ofrece imágenes de distribución estándar— y convertirlo en un nodo Proxmox VE. La documentación es explícita sobre a quién va dirigido:

“This option is only recommended for advanced users because detailed knowledge about Proxmox VE is required.” y “In general, this is not trivial, especially when LVM or ZFS is used.”

La red hay que configurarla a mano y no obtienes el particionado que hace el instalador. Dicho eso, el procedimiento verificado es corto.

Paso 1. /etc/hosts con una IP no-loopback. Esto no es opcional: es la causa número uno de instalaciones rotas por esta vía.

127.0.0.1       localhost
192.168.15.77   prox4m1.proxmox.com prox4m1

::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

hostname --ip-address     # debe devolver la IP real, NUNCA 127.0.0.1

Paso 2. Añadir el repositorio de instalación en formato deb822.

cat > /etc/apt/sources.list.d/pve-install-repo.sources << 'EOL'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOL

Paso 3. Descargar y verificar el keyring.

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg

sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg
# 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45

md5sum /usr/share/keyrings/proxmox-archive-keyring.gpg
# 77c8b1166d15ce8350102ab1bca2fcbf

Paso 4 a 8. El resto de la secuencia.

# 4. actualizar el sistema base
apt update && apt full-upgrade

# 5. instalar el kernel de Proxmox y reiniciar
apt install proxmox-default-kernel
systemctl reboot

# 6. instalar Proxmox VE y utilidades
apt install proxmox-ve postfix open-iscsi chrony

# 7. quitar el kernel de Debian
apt remove linux-image-amd64 'linux-image-6.12*'
update-grub

# 8. quitar os-prober
apt remove os-prober

Durante la instalación de postfix te pedirá el tipo de configuración; si el host no envía correo hacia fuera, “Local only” basta.

Por qué el paso 8: os-prober escanea todas las particiones, incluidas las de dentro de tus VMs, y añadiría entradas de arranque erróneas a GRUB. No es teórico: es un clásico.

Las advertencias de la wiki para esta ruta:

• Secure Boot debe estar deshabilitado para que el kernel de Proxmox arranque.
• El hostname tiene que resolver a una dirección no-loopback.
• Evita paquetes como resolvconf y rdnssd, que sobrescriben /etc/resolv.conf.
• Los fallos de DNS raros casi siempre son un /etc/hosts mal configurado.

Repositorios APT en formato deb822 y verificación del keyring

Cambio importante en PVE 9: los repositorios usan el formato deb822 con extensión .sources, no el legacy .list. Y el componente de test cambió de nombre: pvetest en PVE 8 y anteriores pasó a ser pve-test en PVE 9. Si copias un tutorial viejo, ese es el primer error que vas a cometer.

Los repositorios base de Debian viven en /etc/apt/sources.list.d/debian.sources, con main non-free-firmware habilitado por defecto en instalaciones nuevas de PVE 9 para poder recibir microcódigo temprano de CPU.

flowchart TD
    START{"Tienes una suscripcion activa<br/>en este nodo"}
    START -->|Si| ENT["Deja pve-enterprise.sources habilitado<br/>y usa el repo enterprise de Ceph"]
    START -->|No| DIS["Anade la linea Enabled: no<br/>en pve-enterprise.sources"]
    DIS --> NOSUB["Crea proxmox.sources<br/>con Components: pve-no-subscription"]
    NOSUB --> CEPH["Haz lo mismo en ceph.sources<br/>cambia enterprise por no-subscription"]
    CEPH --> UPD["apt update y apt full-upgrade"]
    ENT --> UPD
    UPD --> VER["pveversion -v para confirmar el stack"]

pve-enterprise — recomendado, requiere suscripción. Fichero /etc/apt/sources.list.d/pve-enterprise.sources, habilitado por defecto tras instalar desde la ISO:

Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Texto oficial: “This is the recommended repository and available for all Proxmox VE subscription users. It contains the most stable packages and is suitable for production use.”

pve-no-subscription — gratuito, no recomendado en producción. Fichero /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Texto oficial: “It can be used for testing and non-production use. It’s not recommended to use this on production servers, as these packages are not always as heavily tested and validated.”

pve-test — solo desarrollo. Mismo fichero, cambiando el componente a pve-test.

pve-dbgsym — símbolos de depuración, en /etc/apt/sources.list.d/pve-dbgsym.sources apuntando a https://dbgsym.proxmox.com/debian/pve. Sirve para que gdb, systemd-coredump o crash produzcan backtraces útiles.

Ceph tiene su propio fichero, /etc/apt/sources.list.d/ceph.sources, que antes de PVE 9 era ceph.list. En PVE 9 conviven dos releases:

Release	EOL estimado	enterprise	no-subscription	test
ceph-tentacle v20.2	2027-11	recomendado	disponible	disponible
ceph-squid v19.2	2026-09	disponible	disponible	disponible

Ceph tiene capítulo propio, el capítulo 12; aquí solo importa que si desactivas el enterprise de PVE y te olvidas del de Ceph, apt update seguirá dando 401.

Desactivar sin borrar

La forma limpia de desactivar un repositorio en deb822 no es borrar el fichero, sino añadirle una línea:

Enabled: no

Así el paquete que gestiona ese fichero puede seguir actualizándolo y tú conservas la configuración original para cuando compres la suscripción.

# desactivar el repo enterprise anadiendo la linea justo despues del componente
sed -i '/^Components: pve-enterprise/a Enabled: no' \
  /etc/apt/sources.list.d/pve-enterprise.sources

Migrar sources legacy

Si vienes de un sistema con ficheros .list, Debian Trixie trae la herramienta de conversión, y el Admin Guide la recomienda explícitamente porque “otherwise, apt on Debian Trixie will complain”:

apt modernize-sources

El keyring

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg

Los hashes oficiales a agosto de 2026 son los mismos que ya viste en la sección de instalación sobre Debian: sha256 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 y md5 77c8b1166d15ce8350102ab1bca2fcbf.

Gotcha: una vez instalado el paquete proxmox-archive-keyring, es el paquete quien gestiona ese fichero, y los hashes cambiarán cuando se añadan o quiten claves. A partir de ahí, modificarlo a mano está desaconsejado. Y el Signed-By: de cada stanza debe coincidir exactamente con la ruta real del keyring, o tendrás NO_PUBKEY.

Todo esto también se gestiona desde la GUI en Nodo → Updates → Repositories, que lista los repositorios detectados, permite activarlos y desactivarlos con un clic y avisa cuando la combinación es incoherente, con el mensaje literal Enterprise repository needs valid subscription.

Post-instalación, apt full-upgrade y primeras comprobaciones

Tras el reinicio, la lista oficial de tareas del Admin Guide es corta:

1. Apunta el navegador a https://<IP-del-nodo>:8006. Es HTTPS y el puerto no es negociable.
2. Entra con usuario root y realm PAM, con el password que pusiste en la instalación.
3. Sube la clave de suscripción para acceder al repositorio enterprise. Si no tienes, configura uno de los repositorios públicos para poder recibir parches de seguridad.
4. Comprueba la configuración de IP y el hostname.
5. Comprueba la zona horaria.
6. Revisa la configuración del firewall, que es el capítulo 10.

La secuencia CLI equivalente para un nodo sin suscripción:

# 1. desactivar el repo enterprise
sed -i '/^Components: pve-enterprise/a Enabled: no' \
  /etc/apt/sources.list.d/pve-enterprise.sources

# 2. habilitar no-subscription
cat > /etc/apt/sources.list.d/proxmox.sources << 'EOL'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOL

# 3. desactivar tambien el enterprise de Ceph editando /etc/apt/sources.list.d/ceph.sources

# 4. actualizar
apt update
apt full-upgrade

# 5. verificar el stack completo
pveversion -v

La regla de oro: full-upgrade, nunca upgrade

Texto literal del Admin Guide 3.2:

“As Proxmox VE uses a rolling release model on top of Debian, performing an apt upgrade may result in a partially upgraded or broken package state. This is because apt full-upgrade can also remove existing packages to satisfy dependencies if needed, while apt upgrade cannot.”

En Proxmox VE siempre apt full-upgrade, nunca apt upgrade. No es una preferencia de estilo: apt upgrade no puede eliminar paquetes para satisfacer dependencias, y en un modelo rolling eso deja el sistema a medio actualizar. La operación de actualizaciones en producción, con ventanas y orden de nodos, está en el capítulo 15.

Para ver qué tienes instalado:

pveversion       # una linea: pve-manager/<version>/<hash> con el kernel en ejecucion
pveversion -v    # listado completo de todos los paquetes del stack

Lo que ya tienes montado sin haber hecho nada

Tras instalar desde la ISO, /etc/pve/storage.cfg ya trae storages configurados, y esto explica por qué la primera VM que crees te ofrece local-lvm o local-zfs:

dir: local
        path /var/lib/vz
        content iso,vztmpl,backup

# default image store on LVM based installation
lvmthin: local-lvm
        thinpool data
        vgname pve
        content rootdir,images

# default image store on ZFS based installation
zfspool: local-zfs
        pool rpool/data
        sparse
        content images,rootdir

El storage local es un directorio en /var/lib/vz que guarda ISOs, plantillas de contenedor y backups. local-lvm o local-zfs —según el filesystem que elegiste— guarda las imágenes de disco de VMs y los rootfs de contenedores. El modelo completo de plugins de storage es el capítulo 7.

Las rutas que conviene memorizar desde el primer día:

/etc/pve/
  storage.cfg
  qemu-server/
  lxc/
/var/lib/pve-cluster/config.db
/var/lib/vz/
  template/iso/
  template/cache/
  dump/
/etc/network/interfaces
/etc/default/pveproxy

Por último, un servicio que corre solo desde el primer arranque: pve-daily-update.service con su timer asociado refresca a diario el índice de paquetes y la base de datos de plantillas de contenedor —la que consulta pveam available—, y también intenta la renovación de certificados ACME. El timer aplica un retardo aleatorio.

Errores comunes y diagnóstico

Durante la instalación

Síntoma	Causa probable	Diagnóstico o solución
El instalador se cuelga, pantalla negra	Driver gráfico incompatible	Arrancar Terminal UI, pulsar e, añadir nomodeset al final de la línea linux, Ctrl-X
Falla sin mensaje claro	Varias	CTRL + ALT + F2 para ver la segunda TTY con los errores reales
El USB no arranca	Se usó UNetbootin, o Rufus sin modo DD	Rehacer con dd, Etcher o Rufus en DD mode
No arranca el medio	Secure Boot activo con una ISO anterior a 8.1	Desactivar Secure Boot en la UEFI
Test Memory no arranca	Secure Boot activo	Desactivar Secure Boot
Pérdida de datos con ZFS	ZFS sobre RAID hardware	Nunca ZFS sobre RAID hardware. Poner la controladora en modo HBA/IT
No se puede poner IPv4 e IPv6 a la vez	Limitación del instalador	Configurar una y añadir la otra después en /etc/network/interfaces

Instalación sobre Debian

Síntoma	Causa	Solución
El kernel de Proxmox no arranca	Secure Boot activo	Desactivarlo en la UEFI
Fallos de DNS raros, servicios que no levantan	/etc/hosts con el hostname resolviendo a 127.0.0.1	hostname --ip-address debe devolver la IP real
/etc/resolv.conf se sobrescribe solo	resolvconf o rdnssd instalados	Eliminar esos paquetes
GRUB muestra entradas de arranque de VMs	os-prober instalado	apt remove os-prober && update-grub
Arranca el kernel de Debian y no el de Proxmox	No se eliminó el kernel de Debian	apt remove linux-image-amd64 'linux-image-6.12*' && update-grub

Repositorios y actualizaciones

Síntoma	Causa	Solución
401 Unauthorized en apt update contra enterprise.proxmox.com	Repo enterprise activo sin suscripción	Añadir Enabled: no a pve-enterprise.sources y activar pve-no-subscription
NO_PUBKEY o firma inválida	Falta el keyring, o Signed-By: apunta a otra ruta	Descargar proxmox-archive-keyring-trixie.gpg, verificar el sha256 y ajustar Signed-By:
Estado de paquetes roto tras actualizar	Se usó apt upgrade	Reparar con apt full-upgrade y apt --fix-broken install
apt se queja del formato de los sources en Trixie	Sources en formato legacy .list	apt modernize-sources
El repositorio pvetest no existe	El componente se renombró en PVE 9	Usar pve-test
Diálogo “No valid subscription” en cada login	Comportamiento por diseño sin suscripción activa	Comprar suscripción desde €120/año o convivir con el aviso

Arranque, kernel y virtualización

Síntoma	Causa	Solución
No se pueden crear VMs KVM, o el rendimiento es pésimo	VT-x o AMD-V desactivado en la BIOS	egrep '(vmx|svm)' /proc/cpuinfo y ls -l /dev/kvm
El passthrough PCI falla	IOMMU desactivado	dmesg | grep -e DMAR -e IOMMU; en Intel con kernel anterior a 6.8, añadir intel_iommu=on
Servidor OVH que arranca en memtest86+ tras subir a 9.2	La entrada memtest86+ nueva de 9.2 más el iPXE de OVH	Fijar efiBootloaderPath vía la API de OVH; determinarlo con efibootmgr -v, será \efi\proxmox\shimx64.efi con Secure Boot activo o \efi\systemd\systemd-bootx64.efi sin él
Dell PowerEdge que no arranca con kernel 6.17	Incompatibilidad de firmware y kernel	Habilitar SR-IOV Global e I/OAT DMA en firmware; si no, proxmox-boot-tool kernel pin 6.14.11-4-pve
Fallos tras actualizar con NVIDIA vGPU	Driver vGPU incompatible con el kernel	Actualizar el driver antes de subir; proxmox-boot-tool kernel unpin y apt install proxmox-default-headers
VM Windows con VBS que se congela en hosts Intel	Bug conocido de 9.2, Bugzilla #7825	Actualizar qemu-server a 9.2.0 o superior y poner machine version 11.0+pve2 o superior

Comandos de cabecera para el primer diagnóstico

# versiones del stack completo
pveversion -v

# estado de los servicios centrales
systemctl status pve-cluster pveproxy pvedaemon pvestatd pvescheduler
systemctl --failed

# logs
journalctl -b -p err
journalctl -u pveproxy -n 200 --no-pager

# storage y disco
pvesm status
df -h
zpool status     # solo si instalaste sobre ZFS
lvs; vgs; pvs    # solo si instalaste sobre LVM

# red
ip -br a
ip -br link

# benchmark muy rapido del nodo recien instalado
pveperf

pveperf es, en palabras de su propia man page, “just a very quick and general benchmark”: no sirve como prueba de aceptación de I/O, pero da una foto instantánea. Sus umbrales de referencia son REGEX/SECOND por encima de 300000, BUFFERED READS de al menos 40 MB/s en discos modernos, AVERAGE SEEK TIME por debajo de 8 ms en SCSI rápidos y FSYNCS/SECOND por encima de 200.

Qué tienes ahora y qué viene después

Al final de este capítulo tienes un nodo Proxmox VE 9.2 sobre Debian 13 Trixie: instalado con el filesystem que corresponde a tu hardware, con hdsize y ashift elegidos a conciencia en vez de aceptados por inercia, con los repositorios APT en formato deb822 apuntando al canal correcto, con el sistema actualizado usando apt full-upgrade y con la interfaz web respondiendo en el puerto 8006 con el realm PAM.

También sabes lo que aún no has tocado: por qué /etc/pve no es un directorio normal, qué demonio hace qué, dónde vive la configuración de cada VM y qué comando corresponde a cada objeto del sistema.

Eso es exactamente el capítulo 2: la anatomía del nodo servicio por servicio, pmxcfs y su modo de rescate, el inventario completo de /etc/pve, los puertos que expone el nodo, la interfaz web región por región y el catálogo de comandos —qm, pct, pvesm, pvecm, pveum, pvesh, pvenode— con el patrón que los une a todos: son clientes de la misma API REST que usa la GUI.