Guida all'Amministrazione di Proxmox VE

Un'infrastruttura iperconvergente (HCI) è particolarmente utile per implementazioni in cui un'elevata esigenza infrastrutturale si combina con un budget di amministrazione limitato, per configurazioni distribuite come ambienti di uffici remoti e filiali oppure per cloud privati e pubblici virtuali.

HCI offre i seguenti vantaggi:

Proxmox VE offre un supporto strettamente integrato per la distribuzione di un'infrastruttura di storage iperconvergente. È possibile, ad esempio, distribuire e gestire le seguenti due tecnologie di storage utilizzando esclusivamente l'interfaccia web:

Oltre a quanto sopra, Proxmox VE supporta l'integrazione di un'ampia gamma di tecnologie di storage aggiuntive. È possibile trovare informazioni al riguardo nel capitolo Storage Manager.

La fonte principale di informazioni è il Proxmox VE Wiki. Esso combina la documentazione di riferimento con i contenuti forniti dagli utenti.

Proxmox VE è a sua volta completamente open source, quindi incoraggiamo sempre i nostri utenti a discutere e condividere le proprie conoscenze utilizzando il Proxmox VE Community Forum. Il forum è moderato dal team di supporto Proxmox e conta una vasta base di utenti provenienti da tutto il mondo. Inutile dire che un forum così ampio è un ottimo posto per reperire informazioni.

Questo è un modo rapido per comunicare con la community di Proxmox VE tramite email.

Proxmox VE è completamente open source e i contributi sono benvenuti! Il canale di comunicazione principale per gli sviluppatori è:

Proxmox Server Solutions GmbH offre anche supporto enterprise disponibile come Proxmox VE Subscription Service Plans. Tutti gli utenti con un abbonamento hanno accesso al Repository Enterprise di Proxmox VE e—con un abbonamento Basic, Standard o Premium—anche al Proxmox Customer Portal. Il customer portal fornisce assistenza e supporto con tempi di risposta garantiti da parte degli sviluppatori Proxmox VE.

Per sconti sui volumi, o per maggiori informazioni in generale, contattare sales@proxmox.com.

Proxmox gestisce un bug tracker pubblico all'indirizzo https://bugzilla.proxmox.com. Se si riscontra un problema, segnalarlo lì. Un problema può essere sia un bug sia una richiesta per una nuova funzionalità o un miglioramento. Il bug tracker aiuta a tenere traccia del problema e invierà una notifica una volta risolto.

I file delle lingue sono disponibili come repository git. Chi ha familiarità con git è invitato a contribuire secondo la documentazione per sviluppatori.

È possibile creare una nuova traduzione procedendo come segue (sostituire <LANG> con l'ID della lingua):

Oppure è possibile modificare una traduzione esistente, utilizzando l'editor preferito:

Anche senza familiarità con git, è possibile contribuire alla traduzione di Proxmox VE. Per iniziare, è possibile scaricare i file delle lingue qui. Individuare la lingua da migliorare, quindi fare clic con il tasto destro sul link "raw" di tale file di lingua e selezionare Salva link come…. Apportare le modifiche al file e inviare la traduzione finale direttamente a office(at)proxmox.com, insieme a un contributor license agreement firmato.

Perché la traduzione possa essere utilizzata in Proxmox VE, è necessario prima tradurre il file .po in un file .js. È possibile farlo eseguendo il seguente script, presente nello stesso repository:

Il file risultante pve-lang-xx.js può quindi essere copiato nella directory /usr/share/pve-i18n, sul server proxmox, per effettuare la verifica.

In alternativa, è possibile creare un pacchetto deb eseguendo il seguente comando dalla radice del repository:

È possibile inviare la traduzione completata (file .po) al team Proxmox all'indirizzo office(at)proxmox.com, insieme a un contributor license agreement firmato. In alternativa, con una certa esperienza di sviluppo, è possibile inviarla come patch alla mailing list di sviluppo di Proxmox VE. Vedere la documentazione per sviluppatori.

Questi requisiti minimi sono solo per scopi di valutazione e non dovrebbero essere utilizzati in produzione.

Proxmox VE supporta in modo nativo ARM a 64 bit (arm64, aarch64) sulle piattaforme NVIDIA Grace Hopper e NVIDIA Vera. Su altro hardware ARMv9-A o più recente basato su UEFI, il supporto è best-effort. I single-board computer basati solo su device-tree, come il Raspberry Pi, non sono supportati.

Un host arm64 deve avviarsi tramite UEFI e descrivere il proprio hardware tramite ACPI (Advanced Configuration and Power Interface). Proxmox VE non supporta l'avvio basato solo su device-tree o il BIOS legacy su arm64.

Diverse funzionalità specifiche di x86 non sono disponibili su arm64:

Un cluster può contenere sia nodi x86 che arm64, ma i guest non possono spostarsi tra nodi di architetture diverse mentre sono in esecuzione:

Per ottenere una panoramica delle prestazioni della CPU e del disco rigido su un sistema Proxmox VE installato, eseguire lo strumento incluso pveperf.

Per accedere all'interfaccia utente basata sul web, si consiglia di utilizzare uno dei browser seguenti:

Quando si accede da un dispositivo mobile, Proxmox VE mostrerà un'interfaccia leggera e touch.

La chiavetta deve avere una capacità maggiore rispetto all'immagine ISO.

Sui sistemi operativi Unix-like utilizzare il comando dd per copiare l'immagine ISO sulla chiavetta USB. Individuare prima il nome del dispositivo corretto della chiavetta USB (vedere sotto). Eseguire poi il comando dd.

Aprire il terminale (cercare Terminal in Spotlight).

Convertire il file .iso in formato .dmg utilizzando l'opzione convert di hdiutil, ad esempio:

Per ottenere l'elenco attuale dei dispositivi eseguire il comando:

Inserire quindi la chiavetta USB ed eseguire nuovamente questo comando per determinare quale nodo di dispositivo le è stato assegnato (ad es. /dev/diskX).

Dopo un'installazione riuscita e il riavvio del sistema, è possibile utilizzare l'interfaccia web di Proxmox VE per ulteriori configurazioni.

L'installer crea un Volume Group (VG) denominato pve, e Logical Volume (LV) aggiuntivi denominati root, data e swap, se viene utilizzato ext4 o xfs. Per controllare la dimensione di questi volumi, utilizzare:

Il programma di installazione crea il pool ZFS rpool, se viene utilizzato ZFS. Non viene creato alcuno spazio di swap, ma è possibile riservare dello spazio non partizionato sui dischi di installazione per lo swap. È anche possibile creare uno zvol di swap dopo l'installazione, anche se questo può portare a problemi (vedere le note sullo swap ZFS).

Quando si utilizza BTRFS non viene creato alcuno spazio di swap, ma è possibile riservare dello spazio non partizionato sui dischi di installazione per lo swap. È possibile creare una partizione separata, un subvolume BTRFS o un file di swap utilizzando il comando btrfs filesystem mkswapfile.

ZFS funziona meglio con molta memoria. Se si intende utilizzare ZFS, assicurarsi di disporre di RAM sufficiente. Un buon calcolo è 4GB più 1GB di RAM per ogni TB di spazio disco RAW.

ZFS può utilizzare un drive dedicato come cache di scrittura, chiamato ZFS Intent Log (ZIL). Utilizzare un drive veloce (SSD) per questo scopo. Può essere aggiunto dopo l'installazione con il comando seguente:

Su hardware molto vecchio o molto recente possono verificarsi problemi a causa dei driver grafici. Se l'installazione si blocca durante l'avvio, è possibile provare ad aggiungere il parametro nomodeset. Questo impedisce al kernel Linux di caricare qualsiasi driver grafico e lo costringe a continuare a utilizzare il framebuffer fornito dal BIOS/UEFI.

Nel menu del bootloader di Proxmox VE, navigare su Install Proxmox VE (Terminal UI) e premere e per modificare la voce. Utilizzando i tasti freccia, posizionarsi sulla riga che inizia con linux, spostare il cursore alla fine di tale riga e aggiungere il parametro nomodeset, separato da uno spazio dall'ultimo parametro preesistente.

Premere quindi Ctrl-X o F10 per avviare la configurazione.

I repository sono un insieme di package software; possono essere utilizzati per installare nuovo software, ma sono anche importanti per ottenere nuovi aggiornamenti.

I repository APT sono definiti nel file /etc/apt/sources.list nel formato legacy a riga singola e nei file .sources posti in /etc/apt/sources.list.d/ per il moderno formato deb822 multi-riga; vedere Formati dei repository per i dettagli.

Questo è il repository consigliato e disponibile per tutti gli utenti con abbonamento Proxmox VE. Contiene i package più stabili ed è adatto all'uso in produzione. Il repository pve-enterprise è abilitato per impostazione predefinita:

Si noti che è necessaria una chiave di abbonamento valida per accedere al repository pve-enterprise. Sono disponibili diversi livelli di supporto, di cui si possono trovare ulteriori dettagli su https://proxmox.com/en/proxmox-virtual-environment/pricing.

Come suggerisce il nome, non è necessaria una chiave di abbonamento per accedere a questo repository. Può essere utilizzato per test e per uso non in produzione. Non è consigliato utilizzarlo su server di produzione, poiché questi package non sono sempre testati e validati in modo altrettanto rigoroso.

Si consiglia di configurare questo repository in /etc/apt/sources.list.d/proxmox.sources.

Questo repository contiene i package più recenti ed è utilizzato principalmente dagli sviluppatori per testare nuove funzionalità. Per configurarlo, aggiungere la seguente sezione al file /etc/apt/sources.list.d/proxmox.sources:

I package dei simboli di debug, denominati <package>-dbgsym, contengono le informazioni di debug separate corrispondenti al package binario. Non sono necessari per il normale funzionamento, ma consentono a strumenti come gdb, systemd-coredump o crash di produrre backtrace utili durante l'analisi di un crash o di un blocco. Sono forniti in un repository dedicato, separato da quelli normali, per le release di Proxmox VE basate su Debian Bookworm e Trixie (e successive).

Dopo aver abilitato il repository, installare il package -dbgsym corrispondente al binario da sottoporre a debug.

I package relativi a Ceph vengono mantenuti aggiornati tramite un repository enterprise Ceph preconfigurato. I package preinstallati consentono di connettersi a un cluster Ceph esterno e di aggiungere i suoi pool RBD o CephFS come storage. È inoltre possibile realizzare un'infrastruttura hyper-converged (HCI) eseguendo Ceph sopra il cluster Proxmox VE.

Le informazioni di questo capitolo sono utili nei seguenti casi:

Per leggere la versione più recente della guida per amministratori relativa alla propria release di Proxmox VE, verificare che tutti gli aggiornamenti di sistema siano installati e che questa pagina sia stata ricaricata.

Il contenuto del file ceph.sources riportato di seguito è da intendersi come riferimento (prima di Proxmox VE 9 veniva utilizzato il file ceph.list). Per apportare modifiche, seguire il caso applicabile alla propria situazione come descritto all'inizio di questo sottocapitolo. Se è stato disabilitato un repository nell'interfaccia web e si desidera anche rimuoverlo dall'elenco, è possibile eliminare manualmente la voce corrispondente dal file.

A partire da Debian Bookworm (Proxmox VE 8) il firmware non libero (come definito dalle DFSG) è stato spostato nel componente del repository Debian di nuova creazione non-free-firmware.

A partire da Proxmox VE 9 questo repository è abilitato per impostazione predefinita per le nuove installazioni, al fine di garantire la possibilità di ricevere gli aggiornamenti anticipati del microcodice del sistema operativo.

È inoltre possibile acquisire ulteriori file firmware di runtime non già inclusi nel package preinstallato pve-firmware.

Per poter installare i package da questo componente, eseguire editor /etc/apt/sources.list, aggiungere non-free-firmware alla fine di ogni riga di repository .debian.org ed eseguire apt update.

Se l'installazione di Proxmox VE 9 è stata aggiornata da una versione precedente di Proxmox VE e i repository dei package sono stati modernizzati al nuovo stile deb822, sarà necessario adattare invece /etc/apt/sources.list.d/debian.sources. Eseguire editor /etc/apt/sources.list.d/debian.sources e aggiungere non-free-firmware alle righe che iniziano con Components: di ciascuna sezione.

I file Release nei repository sono firmati con GnuPG. APT utilizza queste firme per verificare che tutti i package provengano da una fonte attendibile.

Se Proxmox VE viene installato da un'immagine ISO ufficiale, la chiave per la verifica è già installata.

Se Proxmox VE viene installato sopra Debian, scaricare e installare la chiave con i seguenti comandi:

Verificare quindi il checksum con lo strumento CLI sha512sum:

oppure con lo strumento CLI md5sum:

Questa sezione è adatta a tutti i dispositivi. Il microcodice aggiornato, solitamente incluso in un aggiornamento BIOS/UEFI, viene memorizzato sulla scheda madre, mentre il resto del firmware viene memorizzato sul rispettivo dispositivo. Questo metodo persistente è particolarmente importante per la CPU, poiché consente il caricamento regolare più precoce possibile del microcodice aggiornato al momento del boot.

Si consiglia di verificare con il proprio fornitore quali metodi di aggiornamento sono disponibili.

Proxmox VE distribuisce una propria versione del package fwupd per abilitare il supporto Secure Boot con la chiave di firma Proxmox. In questo package è stata deliberatamente eliminata la dipendenza consigliata dal package udisks2, a causa di problemi riscontrati nel suo utilizzo sugli hypervisor.

Questo metodo memorizza il firmware nel sistema operativo Proxmox VE e lo trasferisce a un dispositivo se il relativo firmware persistente è meno recente. È supportato da dispositivi come le schede di rete e grafiche, ma non da quelli che si basano sul firmware persistente, come la scheda madre e i dischi fissi.

In Proxmox VE il package pve-firmware è già installato di default. Pertanto, con i normali aggiornamenti di sistema (APT), il firmware incluso dell'hardware comune viene automaticamente mantenuto aggiornato.

Esiste un ulteriore repository firmware di Debian, ma non è configurato per impostazione predefinita.

Se si tenta di installare un package firmware aggiuntivo ma questo è in conflitto, APT interromperà l'installazione. È possibile che il firmware specifico possa essere ottenuto in un altro modo.

Gli aggiornamenti del microcodice sono destinati a correggere vulnerabilità di sicurezza riscontrate e altri bug CPU gravi. Sebbene le prestazioni della CPU possano essere influenzate, un microcodice con patch è generalmente comunque più performante di un microcodice senza patch in cui il kernel stesso deve applicare le mitigazioni. In base al tipo di CPU, è possibile che i risultati prestazionali dello stato di fabbrica difettoso non possano più essere raggiunti senza eseguire consapevolmente la CPU in uno stato non sicuro.

Per ottenere una panoramica delle vulnerabilità CPU presenti e delle relative mitigazioni, eseguire lscpu. Le vulnerabilità reali attualmente note possono comparire solo se l'host Proxmox VE è aggiornato, la sua versione non è a fine vita ed è stato riavviato almeno una volta dall'ultimo aggiornamento del kernel.

Oltre all'aggiornamento del microcodice consigliato tramite aggiornamenti BIOS/UEFI persistenti, esiste anche un metodo indipendente tramite gli Early OS Microcode Updates. È comodo da utilizzare e anche molto utile quando il produttore della scheda madre non fornisce più aggiornamenti BIOS/UEFI. Indipendentemente dal metodo utilizzato, è sempre necessario un riavvio per applicare un aggiornamento del microcodice.

Proxmox VE non scrive le modifiche direttamente in /etc/network/interfaces. Invece, vengono scritte in un file temporaneo chiamato /etc/network/interfaces.new, in modo da poter effettuare molte modifiche correlate in una sola volta. Questo permette anche di verificare che le modifiche siano corrette prima di applicarle, poiché una configurazione di rete errata potrebbe rendere un nodo inaccessibile.

Attualmente vengono utilizzate le seguenti convenzioni di denominazione per i nomi dei dispositivi:

Questo semplifica il debug dei problemi di rete, perché il nome del dispositivo indica il tipo di dispositivo.

In base all'attuale organizzazione di rete e alle risorse disponibili è possibile scegliere una configurazione di rete con bridge, instradata (routed) o con mascheramento (masquerading).

I bridge sono come switch di rete fisici implementati in software. Tutti i guest virtuali possono condividere un singolo bridge, oppure è possibile creare più bridge per separare i domini di rete. Ciascun host può avere fino a 4094 bridge.

Il programma di installazione crea un singolo bridge denominato vmbr0, che è collegato alla prima scheda Ethernet. La configurazione corrispondente in /etc/network/interfaces potrebbe essere simile alla seguente:

Le macchine virtuali si comportano come se fossero collegate direttamente alla rete fisica. La rete, a sua volta, vede ogni macchina virtuale come se avesse un proprio MAC, anche se vi è un solo cavo di rete che collega tutte queste VM alla rete.

La maggior parte dei provider di hosting non supporta la configurazione sopra descritta. Per motivi di sicurezza, disabilitano la rete non appena rilevano più indirizzi MAC su una singola interfaccia.

È possibile evitare il problema instradando («routing») tutto il traffico tramite una singola interfaccia. Ciò garantisce che tutti i pacchetti di rete utilizzino lo stesso indirizzo MAC.

Uno scenario comune è quello in cui si dispone di un IP pubblico (si supponga 198.51.100.5 per questo esempio) e di un blocco di IP aggiuntivo per le VM (203.0.113.16/28). Per queste situazioni si consiglia la seguente configurazione:

L’indirizzo di vmbr0, 203.0.113.17, è il primo indirizzo host utilizzabile del blocco 203.0.113.16/28; l’indirizzo di rete del blocco 203.0.113.16 non può essere assegnato a un’interfaccia.

Il masquerading consente ai guest che dispongono solo di un indirizzo IP privato di accedere alla rete utilizzando l’indirizzo IP dell’host per il traffico in uscita. Ogni pacchetto in uscita viene riscritto da iptables in modo da apparire proveniente dall’host, e le risposte vengono riscritte di conseguenza per essere instradate al mittente originale.

L’aggiunta di queste righe in /etc/network/interfaces può risolvere questo problema:

Per maggiori informazioni in merito, fare riferimento ai seguenti link:

Flusso dei pacchetti di Netfilter

Patch sulla netdev-list che introduce le zone conntrack

Articolo del blog con una buona spiegazione tramite l’uso di TRACE nella tabella raw

Il bonding (chiamato anche NIC teaming o Link Aggregation) è una tecnica per associare più NIC a un singolo dispositivo di rete. È possibile raggiungere obiettivi diversi, come rendere la rete tollerante ai guasti, aumentare le prestazioni o entrambe le cose insieme.

L’hardware ad alta velocità come Fibre Channel e il relativo hardware di switching possono risultare piuttosto costosi. Mediante la link aggregation, due NIC possono presentarsi come un’unica interfaccia logica, ottenendo una velocità doppia. Si tratta di una funzionalità nativa del kernel Linux supportata dalla maggior parte degli switch. Se i nodi dispongono di più porte Ethernet, è possibile distribuire i punti di guasto collegando i cavi di rete a switch diversi; la connessione in bond effettuerà il failover su un cavo o sull’altro in caso di problemi di rete.

I link aggregati possono migliorare i tempi di live-migration e la velocità di replica dei dati tra i nodi del cluster Proxmox VE.

Sono disponibili 7 modalità di bonding:

Se lo switch supporta il protocollo LACP (IEEE 802.3ad), si consiglia di utilizzare la modalità di bonding corrispondente (802.3ad). In caso contrario, si dovrebbe generalmente utilizzare la modalità active-backup.

Per la rete del cluster (Corosync) si consiglia una configurazione con più reti. Corosync non necessita di un bond per la ridondanza di rete, poiché può passare da una rete all'altra autonomamente qualora una diventi inutilizzabile. Alcune modalità di bonding sono note per essere problematiche per Corosync, vedere Corosync su bond.

La seguente configurazione di bonding può essere utilizzata come rete di storage distribuito/condiviso. Il vantaggio è quello di ottenere maggiore velocità e una rete tollerante ai guasti.

Un'altra possibilità è utilizzare il bond direttamente come porta del bridge. Questo può essere utilizzato per rendere la rete guest tollerante ai guasti.

Una LAN virtuale (VLAN) è un dominio di broadcast partizionato e isolato nella rete a livello due. È quindi possibile avere più reti (4096) in una rete fisica, ciascuna indipendente dalle altre.

Ogni rete VLAN è identificata da un numero spesso chiamato tag. I pacchetti di rete vengono quindi contrassegnati per identificare a quale rete virtuale appartengono.

Proxmox VE funziona correttamente in tutti gli ambienti, indipendentemente dal fatto che IPv6 sia distribuito o meno. Si consiglia di lasciare tutte le impostazioni ai valori predefiniti forniti.

Qualora fosse comunque necessario disabilitare il supporto per IPv6 sul nodo, è possibile farlo creando un apposito file snippet sysctl.conf (5) e impostando i relativi sysctl, ad esempio aggiungendo /etc/sysctl.d/disable-ipv6.conf con il seguente contenuto:

Questo metodo è preferibile rispetto alla disabilitazione del caricamento del modulo IPv6 tramite la riga di comando del kernel.

Per impostazione predefinita, l'apprendimento MAC è abilitato su un bridge per garantire un'esperienza fluida con i guest virtuali e le relative reti.

Tuttavia, in alcuni ambienti questo comportamento può non essere desiderato. A partire da Proxmox VE 7.3 è possibile disabilitare l'apprendimento MAC sul bridge impostando la configurazione ‘bridge-disable-mac-learning 1` su un bridge in `/etc/network/interfaces’, ad esempio:

Una volta abilitata questa opzione, Proxmox VE aggiungerà manualmente l'indirizzo MAC configurato delle VM e dei container al forwarding database del bridge, per garantire che il guest possa continuare a utilizzare la rete, ma solo quando utilizza il proprio indirizzo MAC effettivo.

In alcuni casi, può essere desiderabile utilizzare server NTP diversi da quelli predefiniti. Ad esempio, se i nodi Proxmox VE non hanno accesso a internet pubblico a causa di regole firewall restrittive, è necessario configurare server NTP locali e indicare al demone NTP di utilizzarli.

La porta predefinita è impostata su 2003 e il percorso graphite predefinito è proxmox.

Per impostazione predefinita, Proxmox VE invia i dati tramite UDP, quindi il server graphite deve essere configurato per accettarli. In questo caso è possibile configurare la maximum transmission unit (MTU) per gli ambienti che non utilizzano l'MTU standard di 1500.

È anche possibile configurare il plugin per utilizzare TCP. Per non bloccare l'importante demone di raccolta statistiche pvestatd, è richiesto un timeout per gestire eventuali problemi di rete.

Proxmox VE invia i dati tramite UDP, quindi il server influxdb deve essere configurato di conseguenza. Se necessario, è possibile configurare anche l'MTU.

Di seguito un esempio di configurazione per influxdb (sul server influxdb):

Con questa configurazione, il server resta in ascolto su tutti gli indirizzi IP sulla porta 8089 e scrive i dati nel database proxmox

In alternativa, il plugin può essere configurato per utilizzare l'API http(s) di InfluxDB 2.x. InfluxDB 1.8.x contiene un endpoint API compatibile con questa API v2 di versione successiva.

Per utilizzarla, impostare influxdbproto su http oppure https (in base alla configurazione). Per impostazione predefinita, Proxmox VE utilizza l'organizzazione proxmox e il bucket/db proxmox (possono essere impostati rispettivamente tramite le configurazioni organization e bucket).

Poiché l'API v2 di InfluxDB è disponibile solo con autenticazione, è necessario generare un token in grado di scrivere nel bucket corretto e impostarlo.

Nell'API compatibile v2 della versione 1.8.x, è possibile utilizzare user:password come token (se richiesto) e si può omettere organization, poiché non ha alcun significato in InfluxDB 1.x.

È anche possibile impostare il timeout HTTP (il valore predefinito è 1s) tramite l'impostazione timeout, così come la dimensione massima del batch (predefinita 25000000 byte) tramite l'impostazione max-body-size (corrispondente all'impostazione di InfluxDB con lo stesso nome).

Si consiglia vivamente di utilizzare un controller RAID hardware (con BBU) per tali configurazioni. Ciò aumenta le prestazioni, fornisce ridondanza e rende più semplice la sostituzione dei dischi (sostituibili a caldo).

LVM di per sé non richiede alcun hardware particolare, e i requisiti di memoria sono molto bassi.

Per impostazione predefinita vengono installati due boot loader. La prima partizione contiene il boot loader GRUB standard. La seconda partizione è una EFI System Partition (ESP), che consente di avviare sistemi EFI e di applicare aggiornamenti firmware persistenti dallo spazio utente.

Si supponga di avere un disco vuoto /dev/sdb, sul quale si desidera creare un gruppo di volumi denominato “vmdata”.

Innanzitutto, creare una partizione.

Creare un Physical Volume (PV) senza conferma e con una dimensione dei metadati di 250K.

Creare un gruppo di volumi denominato “vmdata” su /dev/sdb1

Questo può essere fatto facilmente creando un nuovo LV thin.

Un esempio concreto:

Ora è necessario creare un filesystem sul LV.

Infine deve essere montato.

Per renderla sempre accessibile, aggiungere la seguente riga in /etc/fstab.

Ridimensionare il LV e il pool di metadati con il seguente comando:

Un thin pool deve essere creato su un gruppo di volumi. Per sapere come creare un gruppo di volumi, vedere la sezione LVM.

ZFS dipende fortemente dalla memoria, quindi sono necessari almeno 8 GB per iniziare. In pratica, utilizzare quanta più memoria possibile in base all'hardware/budget disponibile. Per prevenire la corruzione dei dati, si consiglia l'uso di RAM ECC di alta qualità.

Se si utilizza un disco dedicato per cache e/o log, è consigliabile utilizzare un SSD di classe enterprise. Questo può aumentare significativamente le prestazioni complessive.

Se si sta sperimentando un'installazione di Proxmox VE all'interno di una VM (virtualizzazione annidata), non utilizzare virtio per i dischi di quella VM, poiché non sono supportati da ZFS. Utilizzare invece IDE o SCSI (funziona anche con il tipo di controller SCSI virtio).

Quando si installa utilizzando il programma di installazione di Proxmox VE, è possibile scegliere ZFS come file system root. È necessario selezionare il tipo di RAID al momento dell'installazione:

Il programma di installazione partiziona automaticamente i dischi, crea un pool ZFS denominato rpool e installa il file system root sul subvolume ZFS rpool/ROOT/pve-1.

Viene creato un altro subvolume denominato rpool/data per archiviare le immagini delle VM. Per poterlo utilizzare con gli strumenti di Proxmox VE, il programma di installazione crea la seguente voce di configurazione in /etc/pve/storage.cfg:

Dopo l'installazione, è possibile visualizzare lo stato del pool ZFS utilizzando il comando zpool:

Il comando zfs viene utilizzato per configurare e gestire i file system ZFS. Il seguente comando elenca tutti i file system dopo l'installazione:

Ci sono alcuni fattori da tenere in considerazione quando si sceglie il layout di un pool ZFS. L'elemento costitutivo di base di un pool ZFS è il dispositivo virtuale, o vdev. Tutti i vdev in un pool vengono utilizzati in egual modo e i dati vengono distribuiti tra di essi mediante striping (RAID0). Per maggiori dettagli sui vdev, consultare la pagina di manuale zpoolconcepts(7).

In un ZFS dRAID (RAID declusterizzato) le unità hot spare partecipano al RAID. La loro capacità di riserva viene riservata e utilizzata per la ricostruzione in caso di guasto di un'unità. Ciò consente, in base alla configurazione, una ricostruzione più rapida rispetto a un RAIDZ in caso di guasto di un'unità. Ulteriori informazioni sono disponibili nella documentazione ufficiale di OpenZFS.
[OpenZFS dRAID https://openzfs.github.io/openzfs-docs/Basic%20Concepts/dRAID%20Howto.html]

Ulteriori informazioni sono disponibili nella pagina del manuale:

Proxmox VE utilizza proxmox-boot-tool per gestire la configurazione del bootloader. Per i dettagli, consultare il capitolo sui bootloader host di Proxmox VE.

Questa sezione fornisce alcuni esempi di utilizzo per le attività più comuni. ZFS di per sé è estremamente potente e offre numerose opzioni. I comandi principali per gestire ZFS sono zfs e zpool. Entrambi i comandi dispongono di ottime pagine di manuale, consultabili con:

ZFS viene fornito con un daemon di eventi ZED, che monitora gli eventi generati dal modulo kernel ZFS. Il daemon può anche inviare e-mail su eventi ZFS come errori del pool. I package ZFS più recenti distribuiscono il daemon in un package separato zfs-zed, che dovrebbe già essere installato per impostazione predefinita in Proxmox VE.

È possibile configurare il daemon tramite il file /etc/zfs/zed.d/zed.rc con l'editor preferito. L'impostazione richiesta per la notifica e-mail è ZED_EMAIL_ADDR, che per impostazione predefinita è impostata su root.

Si noti che Proxmox VE inoltra le e-mail destinate a root all'indirizzo e-mail configurato per l'utente root.

ZFS utilizza per impostazione predefinita il 10% della memoria dell'host, limitato a un massimo di 16 GiB, per la Adaptive Replacement Cache (ARC). Questo valore viene scritto in /etc/modprobe.d/zfs.conf durante l'installazione. Consultare il manuale man 4 zfs per ulteriori informazioni sui parametri del modulo kernel ZFS.

Prima di Proxmox VE 8.1, il limite di utilizzo dell'ARC non veniva impostato durante l'installazione e corrispondeva al valore predefinito di ZFS, che era pari al 62,5% a partire da ZFS 2.3.0 o al 50% per le versioni precedenti. Per le installazioni esistenti precedenti a Proxmox VE 8.1, è necessario eseguire manualmente i passaggi descritti di seguito per abbassare il limite di utilizzo.

Allocare memoria sufficiente per l'ARC è fondamentale per le prestazioni di IO, quindi ridurla con cautela. Come regola generale, allocare almeno 2 GiB di base + 1 GiB/TiB di storage. Ad esempio, se si dispone di un pool con 8 TiB di spazio di storage disponibile, si consiglia di utilizzare 10 GiB di memoria per l'ARC.

ZFS impone inoltre un valore minimo di 64 MiB.

È possibile modificare il limite di utilizzo dell'ARC per l'avvio corrente (un riavvio annulla questa modifica) scrivendo direttamente nel parametro del modulo zfs_arc_max:

Per modificare permanentemente i limiti dell'ARC, aggiungere (o modificare se già presente) la riga seguente in /etc/modprobe.d/zfs.conf:

Questo esempio di impostazione limita l'utilizzo a 8 GiB (8 * 2³⁰).

Questo esempio di impostazione limita (temporaneamente) l'utilizzo a 8 GiB (8 * 2³⁰) su sistemi con più di 256 GiB di memoria totale, dove semplicemente impostare zfs_arc_max da solo non funzionerebbe.

Lo spazio di swap creato su uno zvol può generare alcuni problemi, come il blocco del server o la generazione di un elevato carico IO, spesso riscontrato quando si avvia un backup verso uno storage esterno.

Si consiglia vivamente di utilizzare memoria sufficiente, in modo da non trovarsi normalmente in situazioni di memoria insufficiente. Qualora sia necessario o si desideri aggiungere swap, è preferibile creare una partizione su un disco fisico e utilizzarla come dispositivo di swap. È possibile lasciare dello spazio libero per questo scopo nelle opzioni avanzate del programma di installazione. Inoltre, è possibile abbassare il valore di “swappiness”. Un buon valore per i server è 10:

Per rendere persistente il valore di swappiness, creare un nuovo file /etc/sysctl.d/99-swappiness.conf con un editor a scelta e aggiungere la riga seguente:

ZFS on Linux versione 0.8.0 ha introdotto il supporto per la cifratura nativa dei dataset. Dopo un aggiornamento da versioni precedenti di ZFS on Linux, la funzionalità di cifratura può essere abilitata per pool:

La cifratura deve essere configurata al momento della creazione di dataset/zvol, ed è ereditata per impostazione predefinita dai dataset figli. Ad esempio, per creare un dataset cifrato tank/encrypted_data e configurarlo come storage in Proxmox VE, eseguire i seguenti comandi:

Tutti i volumi/dischi dei guest creati su questo storage saranno cifrati con il materiale crittografico condiviso del dataset padre.

Per utilizzare effettivamente lo storage, è necessario caricare il materiale della chiave associato e montare il dataset. Ciò può essere fatto in un unico passaggio con:

È anche possibile utilizzare un file di chiave (casuale) invece di richiedere una passphrase impostando le proprietà keylocation e keyformat, sia al momento della creazione sia con zfs change-key sui dataset esistenti:

Un volume guest creato all'interno di un dataset cifrato avrà la propria proprietà encryptionroot impostata di conseguenza. Il materiale della chiave deve essere caricato solo una volta per ciascun encryptionroot per essere disponibile per tutti i dataset cifrati sottostanti.

Per maggiori dettagli e un utilizzo avanzato, consultare le proprietà encryptionroot, encryption, keylocation, keyformat e keystatus, i comandi zfs load-key, zfs unload-key e zfs change-key e la sezione Encryption di man zfs.

Quando la compressione è abilitata su un dataset, ZFS tenta di comprimere tutti i blocchi nuovi prima di scriverli e li decomprime durante la lettura. I dati già esistenti non verranno compressi retroattivamente.

È possibile abilitare la compressione con:

Si consiglia di utilizzare l'algoritmo lz4, poiché aggiunge un overhead di CPU molto basso. Sono disponibili anche altri algoritmi come lzjb e gzip-N, dove N è un numero intero da 1 (il più veloce) a 9 (il miglior rapporto di compressione). A seconda dell'algoritmo e di quanto siano comprimibili i dati, avere la compressione abilitata può persino aumentare le prestazioni di I/O.

È possibile disabilitare la compressione in qualsiasi momento con:

Anche in questo caso, solo i nuovi blocchi saranno interessati da questa modifica.

A partire dalla versione 0.8.0, ZFS supporta i dispositivi special. Un dispositivo special in un pool viene utilizzato per memorizzare metadati, tabelle di deduplicazione e, opzionalmente, piccoli blocchi di file.

Un dispositivo special può migliorare la velocità di un pool costituito da hard disk lenti a rotazione con numerose modifiche ai metadati. Ad esempio, i carichi di lavoro che comportano la creazione, l'aggiornamento o l'eliminazione di un gran numero di file beneficeranno della presenza di un dispositivo special. I dataset ZFS possono anche essere configurati per memorizzare interi file piccoli sul dispositivo special, il che può migliorare ulteriormente le prestazioni. Utilizzare SSD veloci per il dispositivo special.

I dataset ZFS espongono la proprietà special_small_blocks=<size>. size può essere 0 per disabilitare la memorizzazione dei blocchi di piccole dimensioni dei file sul dispositivo special, oppure una potenza di due nell'intervallo compreso tra 512B e 1M. Dopo l'impostazione della proprietà, i nuovi blocchi di file più piccoli di size verranno allocati sul dispositivo special.

L'impostazione della proprietà special_small_blocks su un pool modifica il valore predefinito di tale proprietà per tutti i dataset ZFS figli (ad esempio tutti i container nel pool opteranno per i blocchi di file piccoli).

Le modifiche al formato su disco in ZFS vengono apportate solo tra cambi di versione principale e sono specificate tramite le feature. Tutte le feature, così come il meccanismo generale, sono ben documentate nella pagina di manuale zpool-features(5).

Poiché l'abilitazione di nuove feature può rendere un pool non importabile da una versione precedente di ZFS, questa operazione deve essere eseguita attivamente dall'amministratore, eseguendo zpool upgrade sul pool (vedere la pagina di manuale zpool-upgrade(8)).

A meno che non sia necessario utilizzare una delle nuove feature, non vi è alcun vantaggio nell'abilitarle.

Infatti, vi sono alcuni svantaggi nell'abilitare nuove feature:

Quando si effettua l'installazione tramite il programma di installazione di Proxmox VE, è possibile scegliere BTRFS per il file system root. È necessario selezionare il tipo di RAID al momento dell'installazione:

Il programma di installazione partiziona automaticamente i dischi e crea un sottovolume aggiuntivo in /var/lib/pve/local-btrfs. Per poter utilizzare tale sottovolume con gli strumenti Proxmox VE, il programma di installazione crea la seguente voce di configurazione in /etc/pve/storage.cfg:

Questo disabilita esplicitamente lo storage local predefinito a favore di una voce di storage specifica per BTRFS sul sottovolume aggiuntivo.

Il comando btrfs viene utilizzato per configurare e gestire il file system BTRFS. Dopo l'installazione, il seguente comando elenca tutti i sottovolumi aggiuntivi:

Questa sezione fornisce alcuni esempi di utilizzo per le attività comuni.

Wake-on-LAN (WoL) consente di accendere un computer in modalità sospensione sulla rete, inviando un magic packet. Almeno una NIC deve supportare questa funzionalità e la relativa opzione deve essere abilitata nella configurazione del firmware del computer (BIOS/UEFI). Il nome dell’opzione può variare da Enable Wake-on-Lan a Power On By PCIE Device; in caso di dubbio, consultare il manuale del produttore della scheda madre. ethtool può essere utilizzato per verificare la configurazione WoL di <interface> eseguendo:

pvenode consente di risvegliare i membri sospesi di un cluster tramite WoL, utilizzando il comando:

Questo invia in broadcast il magic packet WoL sulla porta UDP 9, contenente l’indirizzo MAC di <node> ottenuto dalla proprietà wakeonlan. La proprietà wakeonlan specifica del nodo può essere impostata utilizzando il seguente comando:

L’interfaccia tramite cui viene inviato il pacchetto WoL è determinata in base alla route predefinita. Può essere sovrascritta impostando bind-interface tramite il seguente comando:

L’indirizzo di broadcast (predefinito 255.255.255.255) utilizzato durante l’invio del pacchetto WoL può inoltre essere modificato impostando esplicitamente broadcast-address utilizzando il seguente comando:

Durante la risoluzione dei problemi del server, ad esempio i job di backup non riusciti, può spesso essere utile avere un log delle attività eseguite in precedenza. Con Proxmox VE, è possibile accedere alla cronologia delle attività del nodo tramite il comando pvenode task.

È possibile ottenere un elenco filtrato delle attività completate di un nodo con il sottocomando list. Ad esempio, per ottenere un elenco delle attività relative alla VM 100 terminate con un errore, il comando sarebbe:

Il log di un’attività può quindi essere stampato utilizzando il suo UPID:

Nel caso in cui siano presenti numerose VM/container, l’avvio e l’arresto dei guest possono essere eseguiti tramite operazioni in blocco con i sottocomandi startall e stopall di pvenode. Per impostazione predefinita, pvenode startall avvierà solo le VM/container che sono state impostate per l’avvio automatico al boot (vedere Avvio e arresto automatico delle macchine virtuali); tuttavia, è possibile sovrascrivere questo comportamento con il flag --force. Entrambi i comandi dispongono anche di un’opzione --vms, che limita i guest arrestati/avviati ai VMID specificati.

Ad esempio, per avviare le VM 100, 101 e 102, indipendentemente dal fatto che abbiano onboot impostato, è possibile utilizzare:

Per arrestare questi guest (e qualsiasi altro guest eventualmente in esecuzione), utilizzare il comando:

Nel caso in cui le VM/container dipendano da risorse esterne lente da avviare, ad esempio un server NFS, è anche possibile impostare un ritardo per singolo nodo tra il momento in cui Proxmox VE si avvia e il momento in cui la prima VM/container configurata per l’avvio automatico si avvia (vedere Avvio e arresto automatico delle macchine virtuali).

Ciò può essere ottenuto impostando quanto segue (dove 10 rappresenta il ritardo in secondi):

Nel caso in cui una situazione di aggiornamento richieda la migrazione di tutti i guest da un nodo a un altro, pvenode offre anche il sottocomando migrateall per la migrazione in blocco. Per impostazione predefinita, questo comando migrerà ogni guest del sistema verso il nodo di destinazione. È tuttavia possibile configurarlo per migrare solo un insieme di guest.

Ad esempio, per migrare le VM 100, 101 e 102 verso il nodo pve2, con la migrazione live per i dischi locali abilitata, è possibile eseguire:

La percentuale obiettivo per l’allocazione automatica della memoria è impostata per impostazione predefinita sull’80%. È possibile personalizzare questo obiettivo per nodo impostando la proprietà ballooning-target. Ad esempio, per impostare come obiettivo il 90% di utilizzo della memoria dell’host:

Per impostazione predefinita, ogni cluster Proxmox VE crea una propria Certificate Authority (CA) autofirmata e genera un certificato per ciascun nodo, firmato dalla suddetta CA. Questi certificati sono utilizzati per la comunicazione cifrata con il servizio pveproxy del cluster e con la funzionalità Shell/Console se viene utilizzato SPICE.

Il certificato della CA e la chiave sono memorizzati nel Proxmox Cluster File System (pmxcfs).

Per distribuire la CA del cluster alle workstation degli amministratori ed evitare avvisi del browser, copiare /etc/pve/pve-root-ca.pem da un nodo qualsiasi del cluster fuori banda (ad esempio tramite scp o leggendolo attraverso una sessione SSH esistente) e importarlo nell'archivio dei certificati attendibili del sistema operativo o del browser. Non esiste un endpoint API o dell'interfaccia web per scaricare il file.

L'API REST e la GUI web sono fornite dal servizio pveproxy, che viene eseguito su ciascun nodo.

Sono disponibili le seguenti opzioni per il certificato utilizzato da pveproxy:

Per le opzioni 2 e 3 viene utilizzato il file /etc/pve/local/pveproxy-ssl.pem (e /etc/pve/local/pveproxy-ssl.key, che deve essere privo di password).

I certificati vengono gestiti con il comando di gestione dei nodi di Proxmox VE (vedere la pagina man pvenode(1)).

Se è già disponibile un certificato da utilizzare per un nodo Proxmox VE, è possibile caricare tale certificato semplicemente tramite l'interfaccia web.

Da notare che il file della chiave del certificato, se fornito, non deve essere protetto da password.

Proxmox VE include un'implementazione del protocollo Automatic Certificate Management Environment (ACME), che consente agli amministratori di Proxmox VE di utilizzare un provider ACME come Let's Encrypt per configurare facilmente certificati TLS accettati e considerati attendibili nativamente dai moderni sistemi operativi e browser web.

Attualmente, i due endpoint ACME implementati sono l'ambiente di produzione Let's Encrypt (LE) e il relativo ambiente di staging. Il client ACME supporta la validazione delle verifiche http-01 tramite un web server integrato e la validazione delle verifiche dns-01 tramite un plugin DNS che supporta tutti gli endpoint API DNS supportati da acme.sh.

È sempre configurato implicitamente un plugin standalone per la validazione delle verifiche http-01 tramite il webserver integrato avviato sulla porta 80.

Ci sono alcuni prerequisiti per utilizzarlo per la gestione dei certificati con l'ACME di Let's Encrypt.

Nei sistemi in cui l'accesso esterno per la validazione tramite il metodo http-01 non è possibile o desiderato, è possibile utilizzare il metodo di validazione dns-01. Questo metodo di validazione richiede un server DNS che consenta il provisioning di record TXT tramite un'API.

Se un nodo è stato configurato correttamente con un certificato fornito da ACME (sia tramite pvenode che tramite la GUI), il certificato verrà rinnovato automaticamente dal pve-daily-update.service. Attualmente, il rinnovo viene tentato se il certificato è già scaduto o scadrà nei prossimi 30 giorni.

L'installer di Proxmox VE crea 3 partizioni su tutti i dischi selezionati per l'installazione.

Le partizioni create sono:

I sistemi che utilizzano ZFS come filesystem di root vengono avviati con un kernel e un'immagine initrd memorizzati sulla EFI System Partition di 512 MB. Per i sistemi BIOS legacy e i sistemi EFI con Secure Boot abilitato, viene utilizzato GRUB, mentre per i sistemi EFI senza Secure Boot viene utilizzato systemd-boot. Entrambi vengono installati e configurati per puntare alle ESP.

GRUB in modalità BIOS (--target i386-pc) viene installato sulla BIOS Boot Partition di tutti i dischi selezionati su tutti i sistemi avviati con GRUB
[Si tratta di tutte le installazioni con root su ext4 o xfs e delle installazioni con root su ZFS su sistemi non EFI]
.

proxmox-boot-tool è un'utility usata per mantenere il contenuto delle EFI System Partition correttamente configurato e sincronizzato. Copia determinate versioni del kernel su tutte le ESP e configura il relativo bootloader per l'avvio dalle ESP formattate in vfat. Nel contesto di ZFS come filesystem di root, questo significa che è possibile utilizzare tutte le funzionalità opzionali sul pool di root invece del sottoinsieme presente anche nell'implementazione ZFS in GRUB, evitando di dover creare un boot-pool separato di piccole dimensioni
[Avvio di ZFS su root con GRUB https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Bookworm%20Root%20on%20ZFS.html]
.

Nelle configurazioni con ridondanza, tutti i dischi vengono partizionati con una ESP dal programma di installazione. Questo garantisce che il sistema si avvii anche se il primo dispositivo di avvio si guasta o se il BIOS può eseguire l'avvio solo da un disco specifico.

Le ESP non vengono mantenute montate durante il normale funzionamento. Questo contribuisce a prevenire la corruzione del filesystem sulle ESP formattate in vfat in caso di crash del sistema, ed elimina la necessità di adattare manualmente /etc/fstab nel caso in cui il dispositivo di boot primario presenti un guasto.

proxmox-boot-tool gestisce le seguenti attività:

È possibile visualizzare le ESP attualmente configurate e il relativo stato eseguendo:

Per formattare e inizializzare una partizione come ESP sincronizzata, ad esempio dopo aver sostituito un vdev guasto in un rpool, oppure quando si converte un sistema esistente che precede il meccanismo di sincronizzazione, è possibile utilizzare proxmox-boot-tool da proxmox-kernel-helper.

Ad esempio, per formattare una partizione vuota /dev/sda2 come ESP, eseguire quanto segue:

Per configurare una ESP esistente e non montata situata su /dev/sda2 per l'inclusione nel meccanismo di sincronizzazione degli aggiornamenti del kernel di Proxmox VE, utilizzare quanto segue:

oppure

per forzare l'inizializzazione con GRUB invece di systemd-boot, ad esempio per il supporto Secure Boot.

Successivamente /etc/kernel/proxmox-boot-uuids dovrebbe contenere una nuova riga con l'UUID della partizione appena aggiunta. Il comando init attiverà anche automaticamente un aggiornamento di tutte le ESP configurate.

Per copiare e configurare tutti i kernel avviabili e mantenere sincronizzate tutte le ESP elencate in /etc/kernel/proxmox-boot-uuids, è sufficiente eseguire:

(L'equivalente dell'esecuzione di update-grub su sistemi con ext4 o xfs su root).

Ciò è necessario nel caso in cui si apportino modifiche alla riga di comando del kernel, o si desideri sincronizzare tutti i kernel e gli initrd.

Per impostazione predefinita sono configurate le seguenti versioni del kernel:

Per aggiungere un determinato kernel e la relativa immagine initrd all'elenco dei kernel avviabili, utilizzare proxmox-boot-tool kernel add.

Ad esempio, eseguire quanto segue per aggiungere il kernel con versione ABI 5.0.15-1-pve all'elenco dei kernel da mantenere installati e sincronizzati su tutte le ESP:

proxmox-boot-tool kernel list elencherà tutte le versioni del kernel attualmente selezionate per l'avvio:

Eseguire proxmox-boot-tool kernel remove per rimuovere un kernel dall'elenco dei kernel selezionati manualmente, ad esempio:

Il modo più semplice e affidabile per determinare quale bootloader viene utilizzato è osservare il processo di avvio del nodo Proxmox VE.

Verrà visualizzato il riquadro blu di GRUB oppure il semplice schermo nero su bianco di systemd-boot.

Determinare il bootloader da un sistema in esecuzione potrebbe non essere accurato al 100%. Il modo più sicuro è eseguire il seguente comando:

Se restituisce un messaggio che indica che le variabili EFI non sono supportate, GRUB viene utilizzato in modalità BIOS/Legacy.

Se l'output contiene una riga simile alla seguente, GRUB viene utilizzato in modalità UEFI.

Se la voce di avvio attiva punta a \EFI\proxmox\shimx64.efi come nel seguente esempio, GRUB viene utilizzato in modalità UEFI con Secure Boot abilitato.

Se l'output contiene una riga simile alla seguente, viene utilizzato systemd-boot.

Eseguendo:

è possibile verificare se proxmox-boot-tool è configurato, il che è una buona indicazione di come viene avviato il sistema.

GRUB è lo standard de facto per l'avvio dei sistemi Linux da molti anni ed è documentato in modo piuttosto approfondito
[GRUB Manual https://www.gnu.org/software/grub/manual/grub/grub.html]
.

systemd-boot è un bootloader EFI leggero. Legge le immagini del kernel e dell'initrd direttamente dalla EFI Service Partition (ESP) in cui è installato. Il principale vantaggio del caricamento diretto del kernel dalla ESP è che non è necessario reimplementare i driver per l'accesso allo storage. In Proxmox VE proxmox-boot-tool viene utilizzato per mantenere la configurazione sincronizzata tra le ESP.

È possibile modificare la riga di comando del kernel nei punti seguenti, in base al bootloader utilizzato:

La riga di comando del kernel deve essere inserita nella variabile GRUB_CMDLINE_LINUX_DEFAULT nel file /etc/default/grub. L'esecuzione di update-grub ne aggiunge il contenuto a tutte le voci linux in /boot/grub/grub.cfg.

La riga di comando del kernel deve essere inserita su un'unica riga in /etc/kernel/cmdline. Per applicare le modifiche, eseguire proxmox-boot-tool refresh, che la imposta come riga option per tutti i file di configurazione in loader/entries/proxmox-*.conf.

Un elenco completo dei parametri del kernel è disponibile all'indirizzo https://www.kernel.org/doc/html/v<YOUR-KERNEL-VERSION>/admin-guide/kernel-parameters.html. Sostituire <YOUR-KERNEL-VERSION> con la versione major.minor; ad esempio, per i kernel basati sulla versione 6.5, l'URL sarebbe: https://www.kernel.org/doc/html/v6.5/admin-guide/kernel-parameters.html

È possibile individuare la versione del kernel controllando l'interfaccia web (Nodo → Riepilogo), oppure eseguendo

Utilizzare i primi due numeri all'inizio dell'output.

Per selezionare un kernel diverso da quello attualmente predefinito, è possibile:

Questo dovrebbe aiutare ad aggirare le incompatibilità tra una versione più recente del kernel e l'hardware.

Ad esempio: per selezionare in modo permanente la versione 5.15.30-1-pve per l'avvio, si dovrebbe eseguire:

È inoltre possibile impostare una versione del kernel da avviare solo al successivo avvio del sistema. Ciò è utile, ad esempio, per verificare se un kernel aggiornato ha risolto un problema che aveva inizialmente indotto a fissare una versione tramite pin:

Per rimuovere qualsiasi configurazione di versione bloccata, utilizzare il sottocomando unpin:

Sebbene anche unpin disponga di un'opzione --next-boot, questa viene utilizzata per annullare il blocco di una versione impostato con --next-boot. Poiché ciò avviene già automaticamente all'avvio, invocarla manualmente è di scarsa utilità.

Dopo aver impostato o rimosso le versioni bloccate, è necessario sincronizzare il contenuto e la configurazione sulle ESP eseguendo il sottocomando refresh.

A partire da Proxmox VE 8.1, Secure Boot è supportato nativamente tramite package firmati e integrazione in proxmox-boot-tool.

I seguenti package sono necessari per il funzionamento di secure boot. È possibile installarli tutti in una sola volta utilizzando il meta-package 'proxmox-secure-boot-support'.

Solo GRUB è supportato nativamente come bootloader, poiché gli altri bootloader attualmente non sono idonei alla firma del codice per Secure Boot.

Qualsiasi nuova installazione di Proxmox VE includerà automaticamente tutti i package indicati sopra.

Maggiori dettagli su come funziona Secure Boot e su come personalizzare la configurazione sono disponibili nel nostro wiki.

KSM può ottimizzare l'utilizzo della memoria negli ambienti di virtualizzazione, poiché più VM che eseguono sistemi operativi o workload simili potrebbero potenzialmente condividere molte pagine di memoria comuni.

Tuttavia, sebbene KSM possa ridurre l'utilizzo della memoria, comporta anche alcuni rischi per la sicurezza, poiché può esporre le VM ad attacchi side-channel. Alcune ricerche hanno dimostrato che è possibile dedurre informazioni su una VM in esecuzione tramite una seconda VM sullo stesso host, sfruttando determinate caratteristiche di KSM.

Pertanto, se Proxmox VE viene utilizzato per fornire servizi di hosting, si consiglia di valutare la possibilità di disabilitare KSM, al fine di offrire agli utenti una maggiore sicurezza. Inoltre, è opportuno verificare le normative del proprio paese, poiché la disabilitazione di KSM potrebbe essere un requisito legale.

KSM può essere disabilitato a livello di nodo o per singola VM.

Per verificare se KSM è attivo su un nodo, è possibile controllare l'output di:

In tal caso, può essere disabilitato immediatamente con:

Infine, per separare tutte le pagine attualmente unite, eseguire:

L'opzione di configurazione della VM allow-ksm controlla se l'unione delle pagine di memoria è consentita per una determinata VM. L'opzione è impostata su true per impostazione predefinita e può essere disabilitata con:

Nella parte superiore sinistra, la prima cosa visibile è il logo Proxmox. Accanto si trova la versione attualmente in esecuzione di Proxmox VE. Nella barra di ricerca vicina è possibile cercare oggetti specifici (VM, container, nodi, …). Questo è talvolta più rapido rispetto alla selezione di un oggetto nell'albero delle risorse.

La parte destra dell'intestazione contiene quattro pulsanti:

La finestra Le mie impostazioni consente di configurare impostazioni memorizzate localmente. Queste includono gli Storage della dashboard, che permettono di abilitare o disabilitare storage specifici affinché vengano conteggiati nel totale visibile nel riepilogo del datacenter. Se non viene selezionato alcuno storage, il totale è la somma di tutti gli storage, come se fossero stati abilitati singolarmente tutti.

Sotto le impostazioni della dashboard si trova il nome utente memorizzato e un pulsante per cancellarlo, così come un pulsante per ripristinare ogni layout dell'interfaccia ai valori predefiniti.

Sul lato destro sono presenti le impostazioni xterm.js. Queste contengono le seguenti opzioni:

Questo è l'albero di navigazione principale. Nella parte superiore dell'albero è possibile selezionare alcune visualizzazioni predefinite, che modificano la struttura dell'albero sottostante. La visualizzazione predefinita è la Vista server, e mostra i seguenti tipi di oggetto:

Sono disponibili i seguenti tipi di visualizzazione:

Lo scopo principale del pannello di log è mostrare cosa sta attualmente accadendo nel cluster. Azioni come la creazione di una nuova VM vengono eseguite in background, e tale job in background viene chiamato task.

Qualsiasi output di un tale task viene salvato in un file di log separato. È possibile visualizzare quel log facendo semplicemente doppio clic su una voce di log del task. È inoltre possibile interrompere un task in esecuzione da lì.

Si noti che qui vengono mostrati i task più recenti di tutti i nodi del cluster. In questo modo è possibile vedere in tempo reale quando qualcun altro sta lavorando su un altro nodo del cluster.

Alcune azioni di breve durata inviano semplicemente log a tutti i membri del cluster. È possibile visualizzare questi messaggi nel pannello Log del cluster.

A livello di datacenter, è possibile accedere a impostazioni e informazioni a livello di cluster.

A questo livello è possibile gestire singolarmente i nodi del cluster.

L'intestazione superiore contiene pulsanti utili come Reboot, Shutdown, Shell, Bulk Actions e Help. Shell presenta le opzioni noVNC, SPICE e xterm.js. Bulk Actions presenta le opzioni Bulk Start, Bulk Shutdown e Bulk Migrate.

Esistono due diversi tipi di guest ed entrambi possono essere convertiti in template. Uno di essi è una macchina virtuale basata su kernel (KVM) e l'altro è un container Linux (LXC). La navigazione per entrambi è perlopiù identica; solo alcune opzioni sono diverse.

Per accedere alle varie interfacce di gestione dei guest, selezionare una VM o un container dal menu a sinistra.

L'intestazione contiene comandi per elementi come la gestione dell'alimentazione, la migrazione, l'accesso e il tipo di console, la clonazione, l'HA e la guida. Alcuni di questi pulsanti contengono menu a discesa; ad esempio, Shutdown contiene anche altre opzioni di alimentazione, e Console contiene i diversi tipi di console: SPICE, noVNC e xterm.js.

Il pannello a destra contiene un'interfaccia relativa all'elemento selezionato dal menu a sinistra.

Le interfacce disponibili sono le seguenti.

Come per l'interfaccia dei guest, l'interfaccia per lo storage è costituita da un menu a sinistra per determinati elementi di storage e da un'interfaccia a destra per gestire tali elementi.

In questa vista è presente una visualizzazione divisa in due parti. Sul lato sinistro sono presenti le opzioni di storage e sul lato destro viene mostrato il contenuto dell'opzione selezionata.

Anche in questo caso, la vista dei pool è composta da due partizioni: un menu a sinistra e le relative interfacce per ciascuna voce di menu a destra.

Per impostazione predefinita, i colori dei tag derivano dal relativo testo in modo deterministico. È possibile personalizzare il colore, la forma nell'albero delle risorse e la distinzione tra maiuscole e minuscole, così come l'ordinamento dei tag. Ciò può essere effettuato tramite l'interfaccia web in Datacenter → Options → Tag Style Override. In alternativa, è possibile farlo tramite la CLI. Ad esempio:

imposta il colore di sfondo del tag example su nero (#000000) e il colore del testo su bianco (#FFFFFF).

Per impostazione predefinita, gli utenti con il privilegio VM.Config.Options su un guest (/vms/ID) possono impostare qualsiasi tag desiderino (vedere Gestione dei permessi). Per limitare questo comportamento, è possibile impostare permessi appropriati in Datacenter → Options → User Tag Access:

Lo stesso può essere effettuato anche tramite la CLI.

Si noti che un utente con i privilegi Sys.Modify su / può sempre impostare o eliminare qualsiasi tag, indipendentemente dalle impostazioni qui descritte. Inoltre, esiste un elenco configurabile di tag registrati che possono essere aggiunti e rimossi solo da utenti con il privilegio Sys.Modify su /. L'elenco dei tag registrati può essere modificato in Datacenter → Options → Registered Tags o tramite la CLI.

Per maggiori dettagli sulle opzioni esatte e su come richiamarle nella CLI, vedere Configurazione del datacenter.

In Datacenter → Cluster, fare clic su Crea cluster. Inserire il nome del cluster e selezionare una connessione di rete dall'elenco a discesa da utilizzare come rete principale del cluster (Link 0). Il valore predefinito è l'IP risolto tramite il nome host del nodo.

A partire da Proxmox VE 6.2, è possibile aggiungere fino a 8 link di fallback a un cluster. Per aggiungere un link ridondante, fare clic sul pulsante Aggiungi e selezionare un numero di link e un indirizzo IP nei rispettivi campi. Prima di Proxmox VE 6.2, per aggiungere un secondo link come fallback, è possibile selezionare la casella di controllo Avanzate e scegliere un'ulteriore interfaccia di rete (Link 1, vedere anche Ridondanza Corosync).

Accedere tramite ssh al primo nodo Proxmox VE ed eseguire il comando seguente:

Per verificare lo stato del nuovo cluster utilizzare:

È possibile creare più cluster nella stessa rete fisica o logica. In questo caso, ogni cluster deve avere un nome univoco per evitare possibili conflitti nello stack di comunicazione del cluster. Inoltre, questo aiuta a evitare confusione, rendendo i cluster chiaramente distinguibili.

Sebbene il requisito di banda di un cluster corosync sia relativamente basso, la latenza dei pacchetti e il tasso di pacchetti al secondo (PPS) rappresentano il fattore limitante. Cluster diversi nella stessa rete possono competere tra loro per queste risorse, quindi può comunque essere opportuno utilizzare un'infrastruttura di rete fisica separata per i cluster più grandi.

Accedere all'interfaccia web su un nodo cluster esistente. In Datacenter → Cluster, fare clic sul pulsante Join Information in alto. Quindi, fare clic sul pulsante Copy Information. In alternativa, copiare manualmente la stringa dal campo Information.

Successivamente, accedere all'interfaccia web sul nodo che si desidera aggiungere. In Datacenter → Cluster, fare clic su Join Cluster. Compilare il campo Information con il testo Join Information copiato precedentemente. La maggior parte delle impostazioni necessarie per aggiungersi al cluster verrà compilata automaticamente. Per motivi di sicurezza, la password del cluster deve essere inserita manualmente.

Dopo aver fatto clic sul pulsante Join, il processo di adesione al cluster inizierà immediatamente. Dopo che il nodo si è unito al cluster, il suo certificato di nodo attuale verrà sostituito con uno firmato dall'autorità di certificazione (CA) del cluster. Ciò significa che la sessione corrente smetterà di funzionare dopo pochi secondi. Potrebbe quindi essere necessario forzare il ricaricamento dell'interfaccia web ed effettuare nuovamente l'accesso con le credenziali del cluster.

Ora il nodo dovrebbe essere visibile in Datacenter → Cluster.

Accedere tramite ssh al nodo che si desidera aggiungere a un cluster esistente.

Per IP-ADDRESS-CLUSTER, utilizzare l'IP o il nome host di un nodo cluster esistente. Si consiglia un indirizzo IP (vedere Tipi di indirizzo del collegamento).

Per impostazione predefinita, pvecm add si autentica tramite l'API del nodo esistente del cluster, richiedendo la password di root@pam di quel nodo e verificando l'impronta digitale SHA-256 del suo certificato. L'autenticazione SSH tramite password non è richiesta per questo flusso predefinito, pertanto gli amministratori possono mantenere PasswordAuthentication no impostato in sshd_config.

Passare --use_ssh per tornare all'adesione legacy basata su SSH, che utilizza ssh-copy-id per unire la chiave root del cluster esistente al nuovo nodo. Questo flusso richiede effettivamente l'accesso SSH come root (con password o chiave) sul nodo esistente.

Per verificare lo stato del cluster utilizzare:

Se si desidera solo un elenco di tutti i nodi, utilizzare:

Quando si aggiunge un nodo a un cluster con una rete del cluster separata, è necessario utilizzare il parametro link0 per impostare l'indirizzo del nodo su quella rete:

Se si desidera utilizzare la ridondanza integrata del livello di trasporto Kronosnet, utilizzare anche il parametro link1.

Utilizzando la GUI, è possibile selezionare l'interfaccia corretta dai corrispondenti campi Link X nella finestra di dialogo Cluster Join.

Prima che un nodo possa essere rimosso da un cluster, è necessario assicurarsi che non faccia più parte di un cluster Ceph e che nessuna risorsa o servizio Ceph risieda su di esso.

Nell'esempio seguente, il nodo del cluster node4 verrà rimosso sia da Ceph che dal cluster corosync di Proxmox VE.

Se si desidera che lo stesso server si unisca nuovamente allo stesso cluster, è necessario:

Lo stack del cluster Proxmox VE richiede una rete affidabile con latenze inferiori a 5 millisecondi (prestazioni LAN) tra tutti i nodi per operare in modo stabile. Sebbene su configurazioni con un numero limitato di nodi una rete con latenze più elevate possa funzionare, ciò non è garantito e diventa piuttosto improbabile con più di tre nodi e latenze superiori a circa 10 ms.

La rete non dovrebbe essere utilizzata intensamente da altri membri, poiché, sebbene corosync non utilizzi molta banda, è sensibile alle variazioni di latenza (jitter); idealmente corosync dovrebbe funzionare su una propria rete fisicamente separata. In particolare, non utilizzare una rete condivisa per corosync e storage (eccetto come potenziale fallback a bassa priorità in una configurazione ridondante).

Prima di configurare un cluster, è buona norma verificare se la rete è adatta a tale scopo. Per assicurarsi che i nodi possano connettersi tra loro sulla rete del cluster, è possibile testare la connettività tra essi con lo strumento ping.

Se il firewall di Proxmox VE è abilitato, le regole ACCEPT per corosync verranno generate automaticamente - non è richiesta alcuna azione manuale.

Quando si crea un cluster senza alcun parametro, la rete cluster corosync è generalmente condivisa con l'interfaccia web e la rete delle VM. In base alla configurazione, anche il traffico storage potrebbe essere inviato sulla stessa rete. Si raccomanda di modificare questo comportamento, poiché corosync è un'applicazione in tempo reale e critica dal punto di vista temporale.

Un indirizzo link di corosync (indicato per compatibilità con le versioni precedenti da ringX_addr in corosync.conf) può essere specificato in due modi:

Se si preferisce utilizzare i nomi host, si consiglia un nome host separato e statico specifico per corosync. Assicurarsi inoltre che ogni nodo del cluster possa risolvere correttamente tutti i nomi host.

A partire da Proxmox VE 5.1, sebbene siano supportati, i nomi host verranno risolti al momento dell'inserimento. Solo l'IP risolto viene salvato nella configurazione.

I nodi che si sono uniti al cluster in versioni precedenti probabilmente utilizzano ancora il loro nome host non risolto in corosync.conf. Potrebbe essere opportuno sostituire tali nomi host con indirizzi IP o un nome host separato, come indicato sopra.

Per aggiungere un nuovo link a una configurazione in esecuzione, è necessario prima verificare come modificare il file corosync.conf.

Successivamente, aggiungere un nuovo ringX_addr a ogni nodo nella sezione nodelist. Assicurarsi che la X sia la stessa per ogni nodo a cui viene aggiunta, e che sia univoca per ciascun nodo.

Infine, aggiungere una nuova interface, come mostrato di seguito, alla sezione totem, sostituendo X con il numero di link scelto sopra.

Supponendo di aver aggiunto un link con numero 1, il nuovo file di configurazione potrebbe avere questo aspetto:

Il nuovo link verrà abilitato non appena si seguono gli ultimi passaggi per modificare il file corosync.conf. Non dovrebbe essere necessario un riavvio. È possibile verificare che corosync abbia caricato il nuovo link usando:

Potrebbe essere una buona idea testare il nuovo link disconnettendo temporaneamente il vecchio link su un nodo e verificando che il suo stato rimanga online mentre è disconnesso:

Se si osserva uno stato del cluster integro, significa che il nuovo link è in uso.

Sui sistemi Proxmox VE, vengono apportate le seguenti modifiche alla configurazione/impostazione SSH:

Nel caso sia presente un .bashrc personalizzato, o file simili che vengono eseguiti al login dalla shell configurata, ssh lo eseguirà automaticamente una volta che la sessione è stata stabilita con successo. Ciò può causare comportamenti inattesi, poiché tali comandi potrebbero essere eseguiti con permessi di root in una qualsiasi delle operazioni descritte sopra. Questo può causare possibili effetti collaterali problematici!

Per evitare tali complicazioni, si consiglia di aggiungere un controllo in /root/.bashrc per verificare che la sessione sia interattiva, ed eseguire i comandi di .bashrc solo in tal caso.

È possibile aggiungere questo snippet all'inizio del proprio file .bashrc:

Il Corosync Quorum Device (QDevice) è un demone che viene eseguito su ogni nodo del cluster. Fornisce un numero configurato di voti al sottosistema di quorum del cluster, basandosi sulla decisione di un arbitro di terze parti in esecuzione esternamente. Il suo scopo principale è consentire a un cluster di sostenere un numero di guasti dei nodi superiore a quello consentito dalle regole standard di quorum. Ciò può essere fatto in sicurezza poiché il dispositivo esterno può vedere tutti i nodi e scegliere quindi un solo insieme di nodi a cui assegnare il proprio voto. Questo viene fatto solo se l’insieme di nodi in questione può ottenere (nuovamente) il quorum dopo aver ricevuto il voto della terza parte.

Attualmente, solo QDevice Net è supportato come arbitro di terze parti. Si tratta di un demone che fornisce un voto a una partizione del cluster, se può raggiungere i membri della partizione tramite la rete. Assegnerà i voti a una sola partizione del cluster in un determinato momento. È progettato per supportare più cluster ed è quasi completamente privo di configurazione e stato. I nuovi cluster vengono gestiti dinamicamente e non è necessario alcun file di configurazione sull’host su cui viene eseguito un QDevice.

Gli unici requisiti per l’host esterno sono l’accesso di rete al cluster e la disponibilità di un pacchetto corosync-qnetd. Viene fornito un pacchetto per gli host basati su Debian e anche altre distribuzioni Linux dovrebbero avere un pacchetto disponibile tramite il rispettivo gestore di pacchetti.

Il supporto per i QDevice è previsto per i cluster con un numero pari di nodi e ne è consigliato l’uso per i cluster a 2 nodi, qualora si voglia garantire una maggiore disponibilità. Per i cluster con un numero dispari di nodi, l’uso dei QDevice è attualmente sconsigliato. Il motivo è la differenza nel numero di voti che il QDevice fornisce per ciascun tipo di cluster. I cluster con numero pari di nodi ottengono un singolo voto aggiuntivo, che aumenta soltanto la disponibilità, poiché se il QDevice stesso si guasta, si torna nella stessa condizione di assenza del QDevice.

D’altra parte, con un numero dispari di nodi nel cluster, il QDevice fornisce (N-1) voti — dove N corrisponde al numero di nodi del cluster. Questo comportamento alternativo è sensato; se fornisse solo un voto aggiuntivo, il cluster potrebbe trovarsi in una situazione di split-brain. Questo algoritmo consente il guasto di tutti i nodi tranne uno, purché anche il QDevice stesso rimanga operativo. Tuttavia, ciò comporta due inconvenienti:

Se gli inconvenienti e le implicazioni sono chiari, è possibile decidere autonomamente se utilizzare questa tecnologia in una configurazione di cluster con numero dispari di nodi.

Si consiglia di eseguire qualsiasi demone che fornisce voti a corosync-qdevice come utente non privilegiato. Proxmox VE e Debian forniscono un package già configurato in tal senso. Il traffico tra il demone e il cluster deve essere crittografato per garantire un’integrazione sicura e protetta del QDevice in Proxmox VE.

Per prima cosa, installare il package corosync-qnetd sul server esterno

e il package corosync-qdevice su tutti i nodi del cluster

Dopo aver fatto ciò, assicurarsi che tutti i nodi del cluster siano online.

È ora possibile configurare il QDevice eseguendo il seguente comando su uno dei nodi Proxmox VE:

La chiave SSH del cluster verrà copiata automaticamente sul QDevice.

Una volta completati correttamente tutti i passaggi, verrà mostrato "Done". È possibile verificare che il QDevice sia stato configurato con:

Modificare il file corosync.conf non è sempre molto semplice. Ne sono presenti due su ciascun nodo del cluster, uno in /etc/pve/corosync.conf e l'altro in /etc/corosync/corosync.conf. Modificando quello nel file system del cluster, le modifiche verranno propagate a quello locale, ma non viceversa.

La configurazione verrà aggiornata automaticamente, non appena il file viene modificato. Ciò significa che le modifiche che possono essere integrate in un corosync in esecuzione avranno effetto immediatamente. Pertanto, si consiglia di creare sempre una copia e modificare quella, per evitare di attivare modifiche indesiderate durante il salvataggio del file in fase di modifica.

Quindi, aprire il file di configurazione con l'editor preferito, come nano o vim.tiny, che sono preinstallati su ogni nodo Proxmox VE.

Dopo aver effettuato le modifiche necessarie, creare un'altra copia del file di configurazione attualmente funzionante. Questa serve come backup nel caso in cui la nuova configurazione non venga applicata correttamente o causi altri problemi.

Quindi sostituire il vecchio file di configurazione con quello nuovo:

È possibile verificare se le modifiche sono state applicate automaticamente, utilizzando i seguenti comandi:

Se le modifiche non sono state applicate automaticamente, potrebbe essere necessario riavviare il servizio corosync tramite:

In caso di errori, consultare la sezione sulla risoluzione dei problemi di seguito.

Il coefficiente del token può essere configurato nella sezione totem in /etc/pve/corosync.conf. Se il coefficiente del token non è impostato esplicitamente, il valore predefinito è 650 millisecondi. A partire da Proxmox VE 9.2, i nuovi cluster vengono creati con un coefficiente del token più basso, impostato esplicitamente a 125 millisecondi in /etc/pve/corosync.conf. Questo riduce il tempo necessario per ristabilire una nuova appartenenza al cluster dopo un guasto a un nodo.

corosync utilizza il coefficiente di token per calcolare diversi timeout in relazione alla dimensione del cluster
[token_coefficient nella pagina di manuale di corosync https://manpages.debian.org/stable/corosync/corosync.conf.5.en.html#token_coefficient]
, soprattutto il timeout del token e il timeout di consenso. corosync implementa un protocollo di passaggio di token. Il timeout del token specifica per quanto tempo un nodo attende il token prima di dichiararlo perso
[token nella pagina di manuale di corosync https://manpages.debian.org/stable/corosync/corosync.conf.5.en.html#token]
. Il timeout di consenso
[consensus nella pagina di manuale di corosync https://manpages.debian.org/stable/corosync/corosync.conf.5.en.html#consensus]
specifica il tempo che i nodi attendono per raggiungere un consenso su una nuova appartenenza al cluster. La somma dei timeout di token e di consenso definisce il tempo minimo necessario per ristabilire una nuova appartenenza al cluster dopo che un nodo va offline.

Mantenere la somma dei timeout di token e di consenso sotto i 30 secondi riduce il tempo necessario per ristabilire una nuova appartenenza al cluster dopo un guasto a un nodo. Quando l'HA è abilitata, è particolarmente importante che questo tempo resti sotto i 45 secondi per garantire che una nuova appartenenza al cluster venga formata prima che il timeout del watchdog di 60 secondi scada, il che innescherebbe il fencing del nodo. È consigliabile un margine di sicurezza sotto questo limite di 45 secondi affinché variazioni temporanee di tempistica non spingano il cluster oltre la soglia del watchdog. Il meccanismo consigliato per abbassare i timeout di token e consenso è abbassare il coefficiente di token come spiegato di seguito.

È possibile controllare i timeout attuali di token e consenso (in millisecondi) con il seguente comando:

Ad esempio:

La somma di questi due valori (10,89 secondi nell'esempio) definisce il tempo minimo necessario per ristabilire una nuova appartenenza al cluster dopo che un nodo va offline. Abbassare il coefficiente di token è

Per abbassare il coefficiente di token, assicurarsi prima che la configurazione soddisfi i requisiti di rete, in particolare per quanto riguarda la latenza. Quindi:

Dopo aver modificato token_coefficient in corosync.conf, le versioni recenti di corosync adotteranno automaticamente il nuovo valore per il cluster. Per versioni di corosync precedenti a 3.1.10-pve1, è necessario riavviare corosync su tutti i nodi perché la modifica abbia effetto.

Il tipo di migrazione definisce se i dati della migrazione devono essere inviati tramite un canale crittografato (secure) o non crittografato (insecure). Impostare il tipo di migrazione su insecure significa che anche il contenuto della RAM di un guest virtuale viene trasferito senza crittografia, il che può comportare la divulgazione di dati critici provenienti dall'interno del guest (ad esempio, password o chiavi di crittografia).

Si raccomanda pertanto vivamente di utilizzare il canale sicuro se non si ha il pieno controllo della rete e non si può garantire che nessuno la stia intercettando.

La crittografia richiede molta potenza di calcolo, pertanto questa impostazione viene spesso modificata in insecure per ottenere prestazioni migliori. L'impatto sui sistemi moderni è minore poiché implementano la crittografia AES in hardware. L'impatto sulle prestazioni è particolarmente evidente nelle reti veloci, dove è possibile trasferire 10 Gbps o più.

Per impostazione predefinita, Proxmox VE utilizza la rete in cui avviene la comunicazione del cluster per inviare il traffico di migrazione. Questo non è ottimale, sia perché il traffico sensibile del cluster può essere disturbato, sia perché questa rete potrebbe non disporre della migliore larghezza di banda disponibile sul nodo.

Impostare il parametro della rete di migrazione consente di utilizzare una rete dedicata per tutto il traffico di migrazione. Oltre alla memoria, questo influisce anche sul traffico di storage per le migrazioni offline.

La rete di migrazione viene impostata come rete utilizzando la notazione CIDR. Questo ha il vantaggio di non dover impostare indirizzi IP individuali per ogni nodo. Proxmox VE può determinare l'indirizzo reale sul nodo di destinazione a partire dalla rete specificata in forma CIDR. Per abilitare questa funzionalità, la rete deve essere specificata in modo che ogni nodo abbia esattamente un IP nella rispettiva rete.

Alcune directory all'interno del file system del cluster utilizzano link simbolici, per puntare ai file di configurazione propri di un nodo. Pertanto, i file indicati nella tabella seguente si riferiscono a file diversi su ciascun nodo del cluster.

È possibile abilitare i messaggi syslog estesi con:

Ed è possibile disabilitare i messaggi syslog estesi con:

Il metodo consigliato è reinstallare il nodo dopo averlo rimosso dal cluster. Questo garantisce che tutte le chiavi segrete di cluster/ssh e qualsiasi dato di configurazione condiviso vengano distrutti.

In alcuni casi, può essere preferibile riportare un nodo in modalità locale senza reinstallarlo, come descritto in Separare un nodo senza reinstallare

Per i file di configurazione dei guest in nodes/<NAME>/qemu-server/ (VM) e nodes/<NAME>/lxc/ (container), Proxmox VE considera il nodo <NAME> che li contiene come il proprietario del rispettivo guest. Questo concetto consente l'utilizzo di lock locali invece di costosi lock a livello di cluster per prevenire modifiche concorrenti alla configurazione del guest.

Di conseguenza, se il nodo proprietario di un guest subisce un guasto (ad esempio, a causa di un'interruzione di corrente, un evento di fencing, ecc.), una migrazione normale non è possibile (anche se tutti i dischi si trovano su storage condiviso), poiché tale lock locale sul nodo proprietario (offline) non è ottenibile. Questo non è un problema per i guest gestiti da HA, poiché lo stack di alta disponibilità di Proxmox VE include le necessarie funzionalità di locking (a livello di cluster) e di watchdog per garantire un ripristino corretto e automatico dei guest dai nodi sottoposti a fencing.

Se un guest non gestito da HA dispone solo di dischi condivisi (e di nessun'altra risorsa locale disponibile unicamente sul nodo non funzionante), è possibile un ripristino manuale semplicemente spostando il file di configurazione del guest dalla directory del nodo non funzionante in /etc/pve/ alla directory di un nodo online (il che modifica il proprietario logico o la posizione del guest).

Ad esempio, per ripristinare la VM con ID 100 da un node1 offline a un altro nodo node2, è necessario eseguire il seguente comando come root su qualsiasi nodo membro del cluster:

Numerosi storage, e il formato immagine QEMU qcow2, supportano il thin provisioning. Con il thin provisioning attivato, solo i blocchi effettivamente utilizzati dal sistema guest verranno scritti sullo storage.

Si supponga ad esempio di creare una VM con un disco rigido da 32 GB e che, dopo aver installato il sistema operativo guest, il file system radice della VM contenga 3 GB di dati. In questo caso solo 3 GB vengono scritti sullo storage, anche se la VM guest vede un disco rigido da 32 GB. In questo modo il thin provisioning consente di creare immagini disco più grandi dei blocchi di storage attualmente disponibili. È possibile creare immagini disco di grandi dimensioni per le proprie VM e, quando necessario, aggiungere altri dischi allo storage senza ridimensionare i file system delle VM.

Tutti i tipi di storage che dispongono della funzionalità "Snapshot" supportano anche il thin provisioning.

Ogni pool di storage ha un <type> ed è identificato in modo univoco dal proprio <STORAGE_ID>. Una configurazione di pool si presenta così:

La riga <type>: <STORAGE_ID> avvia la definizione del pool, seguita poi da un elenco di proprietà. La maggior parte delle proprietà richiede un valore. Alcune hanno valori predefiniti ragionevoli, nel qual caso il valore può essere omesso.

Per maggiore chiarezza, si osservi la configurazione di storage predefinita dopo l'installazione. Contiene un pool di storage locale speciale denominato local, che fa riferimento alla directory /var/lib/vz ed è sempre disponibile. Il programma di installazione di Proxmox VE crea voci di storage aggiuntive in base al tipo di storage scelto al momento dell'installazione.

Alcune proprietà di storage sono comuni tra i diversi tipi di storage.

Esiste una relazione di proprietà per i volumi di tipo image. Ogni volume di questo tipo è di proprietà di una VM o di un container. Ad esempio il volume local:230/example-image.raw è di proprietà della VM 230. La maggior parte dei backend di storage codifica questa informazione di proprietà nel nome del volume.

Quando si rimuove una VM o un container, il sistema rimuove anche tutti i volumi associati di proprietà di quella VM o container.

Aggiungere pool di storage

Disabilitare pool di storage

Abilitare pool di storage

Modificare/impostare le opzioni di storage

Rimuove i pool di storage. Questo non elimina alcun dato e non disconnette né smonta nulla. Rimuove semplicemente la configurazione dello storage.

Allocare volumi

Allocare un volume da 4G nello storage locale. Il nome viene generato automaticamente se viene passata una stringa vuota come <name>

Volumi liberi

Elencare lo stato dello storage

Elencare il contenuto dello storage

Elencare i volumi allocati per VMID

Elencare le immagini ISO

Elencare i template dei container

Mostrare il percorso del file system per un volume

Esportazione del volume local:103/vm-103-disk-0.qcow2 nel file target. Questa operazione viene utilizzata principalmente internamente con pvesm import. Il formato stream qcow2+size è diverso dal formato qcow2. Di conseguenza, il file esportato non può essere semplicemente collegato a una VM. Questo vale anche per gli altri formati.

Questo backend supporta tutte le proprietà comuni dello storage e ne aggiunge due ulteriori. La proprietà path viene utilizzata per specificare la directory. Deve essere un percorso assoluto del file system.

La proprietà opzionale content-dirs consente di modificare il layout predefinito. È costituita da un elenco separato da virgole di identificatori nel seguente formato:

Dove vtype è uno dei tipi di contenuto consentiti per lo storage, e path è un percorso relativo al punto di mount dello storage.

La configurazione precedente definisce un pool di storage denominato backup. Tale pool può essere utilizzato per memorizzare fino a 7 backup regolari (keep-last=7) e 3 backup protetti per VM. Il percorso reale per i file di backup è /mnt/backup/custom/backup/dir/....

Questo backend utilizza uno schema di denominazione ben definito per le immagini delle VM:

Quando si crea un template di VM, tutte le immagini delle VM vengono rinominate per indicare che sono ora di sola lettura e possono essere utilizzate come immagine di base per i cloni:

Come indicato in precedenza, la maggior parte dei file system non supporta gli snapshot di per sé. Per risolvere questo problema, questo backend è in grado di utilizzare le funzionalità di snapshot interno di qcow2.

Lo stesso vale per i cloni. Il backend utilizza la funzionalità di immagine di base qcow2 per creare i cloni.

Utilizzare il seguente comando per allocare un'immagine da 4 GB sullo storage local:

Il percorso reale nel file system viene mostrato con:

Ed è possibile rimuovere l'immagine con: