Quante Raspberry Pi servono in una stazione radioamatoriale moderna?

Una per HBLink.

Una per il reflector.

Una per Grafana.

Una per ADS-B.

Una per WireGuard.

Una per il server web.

Una per Home Assistant.

Una per APRS.

Una per sperimentare.

Dopo qualche anno il rack può diventare:

Pi 1
Pi 2
Pi 3
Pi 4
Pi 5
5 alimentatori
5 SD card
5 indirizzi IP
5 sistemi operativi
5 sistemi da aggiornare

Esiste però un altro approccio:

virtualizzare.

Una singola macchina sufficientemente potente può ospitare numerosi server indipendenti utilizzando piattaforme come Proxmox Virtual Environment.

Proxmox VE è una piattaforma open source di virtualizzazione basata su Linux che integra macchine virtuali QEMU/KVM e container LXC, amministrabili attraverso un’interfaccia web. Nell’agosto 2026 la release corrente pubblicata da Proxmox è la serie 9.2, il cui installer 9.2-1 è stato pubblicato il 21 maggio 2026.

Per una stazione radioamatoriale può diventare una soluzione estremamente potente.

Che cos’è la virtualizzazione?

Supponiamo di avere un mini-PC con:

CPU 8 core
RAM 32 GB
SSD 1 TB
2 porte Ethernet

Normalmente installeremmo:

Debian

e sopra:

HBLink
Grafana
WireGuard
Web server
Reflector
Database

Tutto nello stesso sistema operativo.

Funziona.

Ma se rompiamo una libreria durante un aggiornamento potremmo danneggiare più servizi contemporaneamente.

Con la virtualizzazione facciamo invece:

HARDWARE
   │
   ▼
PROXMOX
   │
   ├── SERVER 1
   ├── SERVER 2
   ├── SERVER 3
   ├── SERVER 4
   └── SERVER 5

Ogni server virtuale vive in un ambiente separato.

VM e container: due filosofie differenti

Proxmox supporta entrambe.

VM — Virtual Machine

Una VM possiede un vero sistema operativo guest virtualizzato.

Esempio:

PROXMOX
   ↓
QEMU/KVM
   ↓
DEBIAN VM

Dal punto di vista del guest sembra quasi di avere un computer indipendente.

Proxmox utilizza QEMU/KVM per le macchine virtuali.

Container LXC

Un container è molto più leggero.

Non virtualizza un intero kernel indipendente nello stesso modo di una VM.

Proxmox utilizza Linux Containers — LXC come tecnologia container e fornisce il toolkit pct per gestirli.

Possiamo quindi avere:

PROXMOX HOST
 │
 ├── LXC HBLink
 ├── LXC Grafana
 ├── LXC WireGuard
 └── LXC Web

con un overhead generalmente molto ridotto.

Cosa sceglierei per i servizi radioamatoriali?

In linea generale:

LXC

Ottimo per:

server web;
dashboard;
Prometheus;
Grafana;
database;
HBLink;
reflector software;
DNS;
reverse proxy;
piccoli servizi Linux.

VM

Preferibile quando:

vogliamo isolamento più completo;
serve un kernel/sistema particolare;
dobbiamo usare hardware USB specifico;
vogliamo un ambiente Windows;
il software è complesso o poco adatto al container;
vogliamo poter sperimentare senza interferire con l’host.

Un esempio di stazione virtualizzata

Immaginiamo di acquistare un mini-PC Intel N100/N150 o una macchina x86 più potente.

Installiamo Proxmox.

Potremmo costruire:

PROXMOX HOST
192.168.10.2
│
├── CT 101
│   HBLink
│   192.168.20.11
│
├── CT 102
│   Grafana + Prometheus
│   192.168.30.11
│
├── CT 103
│   Web server
│   192.168.40.11
│
├── CT 104
│   WireGuard
│   192.168.50.11
│
├── VM 201
│   DVSwitch
│   192.168.20.20
│
└── VM 202
    Laboratorio
    192.168.60.10

La singola macchina fisica ospita sei sistemi logici indipendenti.

Il primo enorme vantaggio: ordine

Invece di avere:

RaspberryA
RaspberryB
Pi-old
Pi-new
server2
server-final
server-final2

possiamo assegnare nomi chiari:

CT101-HBLINK
CT102-MONITOR
CT103-WEB
CT104-VPN
VM201-DVSWITCH
VM202-LAB

Nell’interfaccia Proxmox vediamo immediatamente:

CPU;
RAM;
storage;
stato;
network;
console.

Proxmox integra proprio in un’unica interfaccia la gestione di VM, container, storage e networking.

Il secondo vantaggio: backup

Supponiamo di dover aggiornare HBLink.

Prima facciamo un backup.

Se qualcosa va storto:

RESTORE

e torniamo allo stato precedente.

Proxmox integra vzdump per il backup di VM e container; i backup comprendono configurazione e dati del guest e possono essere avviati dall’interfaccia oppure dalla riga di comando.

Per un Sysop è un cambiamento enorme.

La filosofia diventa: sperimenta, ma prima salva

Prima:

apt upgrade

e speriamo.

Con virtualizzazione:

BACKUP
 ↓
UPGRADE
 ↓
TEST

Se funziona:

KEEP

Se non funziona:

RESTORE

Il tempo necessario a recuperare da un errore può diminuire drasticamente.

Attenzione: snapshot e backup non sono sinonimi

Uno snapshot è estremamente comodo.

Ma non deve sostituire un vero backup conservato altrove.

Se il disco fisico muore:

HOST
VM
SNAPSHOT

possono sparire tutti insieme.

Il vero backup dovrebbe stare su un supporto o sistema indipendente.

Proxmox supporta storage locali e condivisi, inclusi storage di rete come NFS e iSCSI, e integra anche Proxmox Backup Server per strategie di backup dedicate.

Un NAS cambia tutto

Una configurazione molto interessante può essere:

MINI PC PROXMOX
      │
      │ LAN
      ▼
NAS

Sul NAS salviamo:

BACKUP VM
BACKUP CT
CONFIG
LOG

In caso di guasto dell’SSD del mini-PC reinstalliamo Proxmox e ripristiniamo i guest.

La rete virtuale

Uno degli aspetti più potenti di Proxmox è il networking.

La piattaforma utilizza un modello di rete bridged basato sullo stack Linux e supporta configurazioni VLAN.

Possiamo immaginare:

ETHERNET FISICA
      │
      ▼
   vmbr0
      │
 ┌────┼─────┐
 │    │     │
VM1  VM2   CT1

vmbr0 funziona concettualmente come uno switch virtuale.

VLAN: il vero salto di qualità

Invece di mettere tutto su:

192.168.1.0/24

possiamo creare reti separate:

VLAN 10  MANAGEMENT
VLAN 20  RADIO
VLAN 30  MONITORING
VLAN 40  WEB/DMZ
VLAN 50  VPN
VLAN 60  LAB

Proxmox può collegare i guest a bridge VLAN-aware oppure utilizzare le funzionalità SDN/VLAN previste dalla piattaforma.

Perché separare le reti?

Supponiamo che il web server venga compromesso.

Se tutto è nella stessa LAN:

WEB SERVER
   │
   ├── vede router
   ├── vede repeater
   ├── vede telecamera
   └── vede server management

Con VLAN:

WEB VLAN
   │
 FIREWALL
   │
   X → MANAGEMENT

Possiamo consentire soltanto il traffico necessario.

Un’architettura radioamatoriale ordinata

Per esempio:

                    INTERNET
                       │
                 ROUTER/FIREWALL
                       │
                   TRUNK VLAN
                       │
                 PROXMOX SERVER
                       │
      ┌────────────────┼────────────────┐
      │                │                │
    VLAN20           VLAN30           VLAN40
     RADIO          MONITORING          WEB
      │                │                │
   HBLink          Prometheus         Nginx
   DVSwitch         Grafana          Dashboard

Aggiungiamo:

VLAN50
  │
WireGuard

ed ecco una piccola infrastruttura professionale.

Una macchina può ospitare molti servizi, ma non esageriamo

Virtualizzare non significa:

“metto tutto su una scatola e ho eliminato ogni problema.”

Abbiamo creato un nuovo problema:

single point of failure.

Prima:

Pi HBLink muore
→ muore HBLink

Ora:

Proxmox host muore
→ HBLink
→ Grafana
→ VPN
→ Web
→ reflector

possono spegnersi tutti insieme.

Quindi la virtualizzazione aumenta enormemente ordine e flessibilità, ma deve essere accompagnata da una corretta progettazione.

UPS obbligatorio? Quasi

Se una macchina ospita cinque servizi importanti, proteggerla con un UPS diventa molto sensato.

230 V
 ↓
UPS
 ↓
PROXMOX
 ↓
VM/CT

Idealmente il sistema dovrebbe poter rilevare batteria scarica e spegnere ordinatamente i guest prima dell’arresto completo.

SSD: non risparmierei troppo

Una Raspberry con SD card svolge spesso poche scritture.

Un server Proxmox può avere contemporaneamente:

log;
database;
metriche;
VM;
cache;
backup temporanei.

Preferirei quindi SSD di buona qualità e, nei sistemi più importanti, storage ridondato.

RAM: più importante della CPU?

Per molti servizi radioamatoriali la CPU moderna rimane quasi inattiva.

Reflector, WireGuard, dashboard e piccoli server web non richiedono normalmente decine di core.

La RAM, invece, viene distribuita tra tutti i guest.

Supponiamo:

Proxmox      2 GB
HBLink       1 GB
Grafana      2 GB
Web          1 GB
DVSwitch     2 GB
Lab          4 GB

abbiamo già allocato diversi gigabyte.

Per una macchina destinata a crescere, 16 GB rappresentano un punto di partenza molto più interessante di 4 GB; 32 GB consentono grande libertà per un homelab radioamatoriale.

Queste cifre sono scelte progettuali, non requisiti Proxmox.

Non allocare tutta la RAM

Se il server possiede:

16 GB

non assegnerei:

16 GB alle VM

Il sistema host ha bisogno della propria memoria.

Bisogna inoltre lasciare margine per:

cache;
filesystem;
picchi;
nuovi guest.

Container per HBLink

HBLink è un ottimo candidato concettuale per un container Linux.

Potremmo avere:

CT 101
Debian
1 CPU
512 MB / 1 GB RAM
8 GB disk

installare HBLink e lasciare quel container dedicato esclusivamente a quello.

Vantaggio:

se dobbiamo modificare Python, dipendenze o configurazione:

HBLink CT

rimane isolato dal resto.

Container per Prometheus

Secondo container:

CT 102
Prometheus

riceve metriche da:

router;
server;
repeater;
UPS;
temperature;
VPN.

Container Grafana separato?

Possiamo tenerlo insieme a Prometheus.

Oppure separarlo.

CT 102 Prometheus
CT 103 Grafana

Separare permette aggiornamenti indipendenti.

Unire riduce il numero di guest.

Non esiste una soluzione universalmente corretta.

Reverse proxy

Un piccolo container può eseguire:

Nginx

oppure altra soluzione reverse proxy.

Da Internet esponiamo:

e il proxy indirizza:

grafana.dominio
dashboard.dominio
monitor.dominio

verso i vari servizi interni.

In questo modo nessun container deve necessariamente possedere direttamente una porta WAN.

WireGuard in VM o container?

Entrambe le soluzioni sono possibili in una corretta configurazione Linux.

Per una VPN particolarmente importante potremmo però preferire:

router fisico

oppure:

VM dedicata

per evitare che un problema del container influenzi la connettività di amministrazione.

Personalmente eviterei inoltre che l’unico accesso remoto al server dipenda da una VM che gira sullo stesso server che dobbiamo raggiungere.

Altrimenti:

Proxmox problema
 ↓
VPN problema
 ↓
non posso raggiungere Proxmox

È meglio avere almeno un percorso di management indipendente.

MMDVM USB: qui la VM diventa interessante

Supponiamo di voler collegare fisicamente:

MMDVM modem USB

al server.

Proxmox supporta il USB passthrough verso le VM: il dispositivo USB fisico dell’host può essere assegnato direttamente a una macchina virtuale, tramite identificativo dispositivo oppure porta USB fisica.

Possiamo quindi fare:

USB MMDVM
    │
    ▼
PROXMOX HOST
    │
 USB PASSTHROUGH
    │
    ▼
VM DVSWITCH

La VM vede il modem come se fosse collegato direttamente a lei.

Perché mappare la porta fisica?

Immaginiamo due dispositivi USB identici.

Potrebbero avere lo stesso:

Vendor ID
Product ID

Proxmox documenta anche la mappatura tramite porta USB fisica proprio per distinguere dispositivi identici collegati a porte differenti.

Questo può essere molto utile se abbiamo:

USB1 → MMDVM A
USB2 → MMDVM B
USB3 → AMBE dongle

AMBE USB e virtualizzazione

Lo stesso vale per un:

ThumbDV
DV3000
AMBE USB

Possiamo assegnarlo alla VM che esegue il transcoder.

AMBE USB
 ↓
PROXMOX
 ↓
VM TRANSCODER

Questo permette di mantenere tutto il software di transcoding isolato dagli altri servizi.

Attenzione alla dipendenza dall’hardware fisico

Una VM senza hardware dedicato può essere spostata relativamente facilmente tra host.

Una VM che dipende da:

USB MMDVM

non può magicamente utilizzare quel dispositivo su un altro server.

È quindi meno portabile.

Questo deve essere considerato se in futuro vogliamo creare un cluster.

Proxmox cluster: serve davvero?

Proxmox integra funzioni di clustering e gestione centralizzata di più nodi.

Possiamo avere:

NODE 1
NODE 2
NODE 3

gestiti insieme.

Per una normale stazione radioamatoriale domestica probabilmente è eccessivo.

Ma per una rete composta da diversi server può diventare interessante.

Alta disponibilità non significa soltanto avere due server

Per fare HA seria servono anche considerazioni su:

quorum;
storage;
networking;
disponibilità dei dati;
dispositivi fisici.

Se HBLink vive in una VM replicabile è relativamente semplice.

Se la VM usa:

USB modem fisicamente inserito nel Node 1

il Node 2 non possiede automaticamente quel modem.

Quindi non tutto può essere reso ridondante soltanto con la virtualizzazione.

Un laboratorio separato dalla produzione

Questa è una delle applicazioni che preferisco.

Creiamo:

VM PRODUCTION

VM LAB

Nella produzione:

HBLink stabile

Nel laboratorio:

nuova versione
nuovi script
bridge sperimentali

Possiamo rompere tutto nel LAB senza toccare la rete attiva.

Clonare una macchina

Immaginiamo di voler provare una modifica complessa.

Invece di modificare direttamente il server possiamo creare una copia o un nuovo guest dalla stessa base.

HBLink-PROD
        │
        └→ HBLink-TEST

Cambiamo:

porte
IP
callsign

e testiamo.

Questo riduce moltissimo il rischio.

Template

Possiamo preparare un container Debian standard:

DEBIAN-RADIO-TEMPLATE

con:

SSH;
timezone;
NTP;
utenti;
monitoring agent;
firewall base.

Ogni nuovo servizio nasce da quella base.

TEMPLATE
 ├→ HBLink
 ├→ Reflector
 ├→ Monitoring
 └→ Web

In pochi minuti otteniamo un server coerente con gli altri.

Backup automatico notturno

Una possibile politica:

02:00 HBLink
02:15 Web
02:30 Monitoring
03:00 DVSwitch

con retention:

7 daily
4 weekly
3 monthly

Il numero esatto dipende dallo spazio disponibile.

Proxmox permette di pianificare job di backup e gestire backup di VM/CT tramite la propria infrastruttura vzdump.

Ma non facciamo il backup dei dati inutili

Un database di metriche potrebbe occupare decine di GB.

Non necessariamente serve conservarlo interamente in ogni backup.

Potremmo separare:

SISTEMA

DATI

su storage differenti o impostare retention appropriate.

La virtualizzazione non sostituisce una buona strategia dei dati.

Monitoring del Proxmox stesso

Il server che monitora la rete deve a sua volta essere monitorato.

Dovremmo osservare almeno:

CPU
RAM
SSD health
temperature
storage usage
network
uptime
VM state
backup status

Perché altrimenti potremmo accorgerci che:

disco 99%

soltanto quando tutti i servizi smettono di funzionare.

Non installerei servizi direttamente sull’host Proxmox

Questo è un principio importante.

L’host dovrebbe rimanere il più possibile dedicato alla virtualizzazione.

Non installerei direttamente:

HBLink
Apache
Grafana
DVSwitch
database

sul sistema Proxmox.

Meglio:

HOST = HYPERVISOR

SERVIZI = VM / CT

Così riduciamo conflitti e semplifichiamo aggiornamenti e troubleshooting.

Separare produzione e management

Anche la GUI Proxmox dovrebbe preferibilmente vivere sulla rete:

MANAGEMENT

e non essere semplicemente esposta su Internet.

Una configurazione sensata:

INTERNET
   │
 FIREWALL
   │
 VPN
   │
MANAGEMENT VLAN
   │
PROXMOX

L’accesso amministrativo passa quindi attraverso una rete privata.

Proxmox + WireGuard

E qui si collegano gli articoli precedenti.

Possiamo avere:

SYSOP
  │
WIREGUARD
  │
ROUTER
  │
MANAGEMENT VLAN
  │
PROXMOX

Dentro Proxmox:

HBLink
Reflector
Grafana
DVSwitch

Abbiamo quindi un’infrastruttura molto ordinata.

Firewall per ogni livello

Possiamo applicare regole:

WAN
 ↓
ROUTER FIREWALL
 ↓
VLAN
 ↓
PROXMOX NETWORK
 ↓
GUEST FIREWALL
 ↓
SERVICE

Non è necessario complicare inutilmente la rete.

Ma separare le responsabilità rende più difficile che un singolo errore esponga tutto.

Un esempio completo per D2ALP

Immaginiamo un mini-PC installato in una sede centrale.

Specifiche indicative:

CPU x86 moderna
32 GB RAM
1 TB NVMe
2× Ethernet
UPS

Installiamo:

PROXMOX VE

e creiamo:

CT100
Reverse Proxy

CT101
HBLink / servizi DMR

CT102
Prometheus

CT103
Grafana

CT104
Server Web

VM200
DVSwitch / Crossmode

VM201
Transcoder + USB AMBE

VM202
Laboratorio Linux

Networking:

VLAN10 MANAGEMENT
VLAN20 DIGITAL VOICE
VLAN30 MONITORING
VLAN40 WEB
VLAN50 LAB

Backup:

NAS esterno

Alimentazione:

UPS

Accesso remoto:

WireGuard

A quel punto abbiamo trasformato un semplice mini-PC in un piccolo datacenter radioamatoriale.

E se il mini-PC muore?

Qui entra in gioco la strategia di recovery.

Dobbiamo poter dire:

HARDWARE GUASTO
 ↓
nuovo hardware
 ↓
installazione Proxmox
 ↓
collegamento storage backup
 ↓
restore guest

Più questo processo è documentato, più la rete è realmente robusta.

Documentare tutto

Preparerei un semplice documento:

HOSTNAME
IP
VLAN
VMID
SERVIZIO
CPU
RAM
STORAGE
PORTA
BACKUP
NOTE

Esempio:

101 | HBLink | VLAN20 | 1 CPU | 1 GB
102 | Prometheus | VLAN30 | 2 CPU | 2 GB
103 | Grafana | VLAN30 | 1 CPU | 1 GB
200 | DVSwitch | VLAN20 | 2 CPU | 2 GB

Quando la rete crescerà, questa tabella diventerà preziosissima.

Quando NON userei Proxmox

Non serve virtualizzare per forza.

Se abbiamo soltanto:

1 hotspot
1 Raspberry

Proxmox probabilmente aggiungerebbe complessità inutile.

Lo prenderei seriamente in considerazione quando iniziamo ad avere:

molti Raspberry;
più server Linux;
reflector;
bridge;
monitoring;
VPN;
web services;
laboratori;
necessità di backup strutturati.

È soprattutto allora che la virtualizzazione inizia a ripagare lo sforzo iniziale.

Raspberry Pi o Proxmox?

Non è una guerra.

Il Raspberry rimane eccellente quando:

serve GPIO
serve HAT
serve bassissimo consumo
serve dispositivo fisicamente vicino alla radio

Proxmox è eccellente quando:

servono molti servizi software
serve isolamento
servono backup
serve networking complesso
serve sperimentazione

In una rete ben progettata possono convivere.

Un’architettura ibrida

Questa è probabilmente la soluzione migliore.

Sul monte:

Raspberry
+
MMDVM
+
ripetitore

Nel datacenter:

Proxmox
+
HBLink
+
reflector
+
Grafana
+
VPN
+
database

La postazione RF rimane leggera.

La parte server viene centralizzata e virtualizzata.

Il Raspberry diventa un edge node

Possiamo quindi vedere:

Raspberry remoto

non più come:

server principale.

Ma come:

edge device.

La logica centrale vive:

PROXMOX DATACENTER

mentre il Raspberry sul sito gestisce:

modem;
GPIO;
telemetria locale;
collegamento RF.

Questo è esattamente il modello utilizzato in moltissime moderne infrastrutture distribuite.

Conclusioni

Proxmox può cambiare radicalmente il modo in cui un radioamatore costruisce la propria infrastruttura digitale.