oVirt è una delle soluzioni open-source più affidabili per la virtualizzazione su larga scala, fornendo una piattaforma robusta per la gestione centralizzata delle macchine virtuali. Con la versione 4.5.5, oVirt introduce miglioramenti in termini di stabilità, sicurezza e funzionalità, rendendo ancora più efficiente la configurazione e l’amministrazione di ambienti virtualizzati.

In questo articolo, esploreremo i passaggi fondamentali per configurare un datacenter e un cluster in oVirt 4.5.5, nonché il processo per aggiungere nuovi nodi al sistema. Dalla creazione dell’infrastruttura di base fino all’integrazione dei nodi di calcolo, questa guida fornirà istruzioni dettagliate per ottimizzare l’implementazione di un ambiente virtuale scalabile e performante.

Se vuoi avere un’infrastruttura virtualizzata solida e ben configurata, segui i passaggi descritti e scopri come sfruttare al meglio le potenzialità di oVirt 4.5.5.

PREREQUISITI

Installazione e Configurazione di oVirt Node 4.5.5

Installazione e Configurazione di oVirt Engine 4.5.6 (Open Virtualization Manager) su CentOS Stream 9

CONFIGURAZIONE DEL DATACENTER

Accedere ad oVirt Engine via browser

Cliccare su Administration Portal

Inserire le credenziali di accesso quindi cliccare Log In

Cliccare su Compute

Cliccare Data Centers

Cliccare New

Inserire i seguenti parametri:

Name: Nome del Data Center.

Description: Descrizione opzionale per identificare il Data Center.

Storage Type: Shared o Local

• Shared Data Center

📌 Descrizione:
Gli host nel Data Center condividono uno o più storage domains.
Le VM possono essere migrate tra host perché tutti accedono allo stesso storage.
Richiede una configurazione di rete o di storage centralizzato (NFS, iSCSI, Fibre Channel, GlusterFS, ecc.).

✅ Vantaggi:
Migrazione live delle VM tra gli host.
Alta disponibilità (HA): se un host fallisce, le VM possono essere avviate su un altro host.
Scalabilità e flessibilità.

❌ Svantaggi:
Richiede una configurazione di storage condiviso (SAN/NAS).
Può essere più complesso da configurare rispetto a un Data Center locale.

🔹 Quando usarlo?
Ambienti di produzione o test con più host.
Quando è necessario failover e migrazione live delle VM.
Se si ha accesso a uno storage condiviso (NAS/SAN).

• Local Data Center

📌 Descrizione:
Ogni host usa lo storage solo localmente (disco interno o storage collegato direttamente).
Le VM create su un host non possono essere migrate ad altri host.
L’architettura è più semplice, senza necessità di storage condiviso.

✅ Vantaggi:
Facile da configurare, ideale per test o piccoli ambienti.
Non richiede uno storage condiviso esterno.
Minore complessità di rete e storage.

❌ Svantaggi:
Nessuna migrazione live delle VM.
Alta disponibilità assente: se l’host si spegne, tutte le VM si fermano.
Scalabilità limitata.

🔹 Quando usarlo?
Test Lab o ambienti di sviluppo con un singolo host.
Se non si dispone di storage condiviso e si vuole usare solo dischi locali.

Compatibility Version: (Versione Cluster): Specifica la compatibilità della versione del cluster (ad esempio, 4.4, 4.5, ecc.).

Quota Mode: Determina se il Data Center utilizza il sistema di quote per la gestione delle risorse:

• Disabled: Nessuna quota attiva, risorse illimitate.
• Audit: Il sistema monitora l’uso delle risorse ma non impone limiti.
• Enforced: Impone limiti sulle risorse utilizzabili da utenti e gruppi.

Comment

: Campo opzionale per aggiungere note o informazioni extra sul Data Center.

Al termine dell’inserimento dei dati cliccare OK

Procedere con la configurazione del Cluster selezionando Configure Cluster

CONFIGURAZIONE DEL CLUSTER

Procedere con la configurazione del cluster cliccando General

Di seguito la lista delle opzioni configurabili con le relative descrizioni del tab GENERAL

Data Center
Seleziona il Data Center in cui verrà creato il cluster.
Il cluster eredita la compatibilità dal Data Center scelto.

Name
Nome univoco per il cluster.
Deve essere significativo per identificare facilmente il cluster.

Description
Campo opzionale per fornire informazioni aggiuntive sul cluster.

Comment
Campo opzionale per inserire commenti relativi al cluster.

Management Network
Seleziona la rete di gestione che verrà utilizzata dagli host del cluster.
Di default, oVirt utilizza ovirtmgmt come rete di gestione principale.
Questa rete deve essere configurata correttamente per garantire la comunicazione tra gli host.

CPU Architecture
Definisce l’architettura della CPU del cluster.
Opzioni: x86_64, ppc64, s390x, Undefined

CPU Type
Specifica il modello di CPU supportato dagli host del cluster.
Deve essere compatibile con gli host fisici.

Chipset/Firmware Type
Definisce il tipo di firmware utilizzato dalle macchine virtuali (VM) create nel cluster.
Questo influenza aspetti critici come il supporto per UEFI, il Secure Boot e la compatibilità hardware delle VM.

• i440FX (BIOS)
  Descrizione: Simula un chipset più vecchio, compatibile con sistemi operativi meno recenti. Utilizza il firmware BIOS tradizionale (Legacy/MBR boot).
  Caratteristiche: Supporta solo boot MBR (no UEFI). Meno compatibile con moderni sistemi operativi. Non supporta il Secure Boot.
  Quando usarlo: Se si eseguono vecchie VM o sistemi operativi che non supportano UEFI.

• Q35 (UEFI)
  Descrizione: Emula un chipset più moderno, con supporto avanzato per hardware più recente. Permette di scegliere tra BIOS (Legacy Boot) e UEFI Boot.
  Caratteristiche: Supporta sia BIOS (MBR boot) che UEFI boot. Abilita il supporto per Secure Boot (se usato con UEFI). Maggiore compatibilità con OS moderni (Windows 10/11, RHEL 8/9, Ubuntu 22.04, ecc.).
  Quando usarlo: Se si vogliono creare VM più moderne con supporto per UEFI/Secure Boot. Se si installano OS recenti con GPT.

• Q35 con Secure Boot (UEFI + Secure Boot)
  Descrizione: Simile all’opzione Q35 (UEFI), ma con Secure Boot attivato. Secure Boot impedisce l’avvio di software non firmato, migliorando la sicurezza.
  Caratteristiche: Richiede UEFI Boot. Funziona solo con OS compatibili con Secure Boot (Windows 10/11, alcune distro Linux firmate). Blocca l’esecuzione di bootloader non firmati.
  Quando usarlo: Se si vuole migliorare la sicurezza delle VM. Se si devono eseguire OS che richiedono Secure Boot (es. Windows 11).

ATTENZIONE:

consiglio vivamente di configurare l’opzione Auto Detect

Change existing VMs/Templates from I440fx to Q35 Chipset with BIOS
Questa opzione permette di modificare il chipset di macchine virtuali (VMs) e template esistenti, passando da i440FX (BIOS legacy) a Q35 (BIOS o UEFI).
Il chipset è un componente virtuale che determina le funzionalità hardware disponibili per la VM.

• Quando usare questa opzione?
  ✅ Se vuoi aggiornare il chipset di VM esistenti a un hardware virtuale più recente.
  ✅ Se devi abilitare funzioni come PCIe, TPM o periferiche moderne.
  ✅ Se vuoi migliorare compatibilità e prestazioni con sistemi operativi più recenti.

• Cosa non fa questa opzione?
  ❌ Non converte automaticamente il boot da BIOS (MBR) a UEFI (GPT).
  ❌ Non attiva Secure Boot (per farlo, devi passare manualmente a UEFI).
  ❌ Non garantisce che il sistema operativo della VM supporti il cambio chipset (potrebbe essere necessario reinstallare i driver).

• Possibili problemi dopo la conversione
  La VM potrebbe non avviarsi se il sistema operativo non riconosce il nuovo chipset.
  Necessario riconfigurare alcuni driver per l’hardware virtuale.
  Windows potrebbe richiedere una riattivazione della licenza a causa del cambio hardware.

🔹 Conclusione
Questa opzione modernizza il chipset delle VM esistenti, mantenendo il boot con BIOS legacy (senza UEFI). Se vuoi anche abilitare Secure Boot e UEFI, devi modificarlo manualmente dopo il cambio del chipset. 🚀

FIPS Mode: L’opzione FIPS Mode in oVirt abilita il supporto per la conformità FIPS 140-2 (Federal Information Processing Standards), un insieme di standard critici per la sicurezza delle informazioni, richiesto per ambienti governativi e ad alta sicurezza.

Compatibility Version: La Compatibility Version (Versione di Compatibilità) di un Cluster in oVirt definisce quali funzionalità avanzate e impostazioni sono disponibili per gli host e le VM all’interno di quel cluster.

Switch Type: L’opzione Switch Type in un Cluster di oVirt determina il tipo di switch virtuale utilizzato per gestire il traffico di rete tra le macchine virtuali e gli host. Quando si configura un cluster in oVirt, si possono scegliere due tipi di switch virtuale:

• Linux Bridge
  Descrizione: Usa il tradizionale Linux Bridge per la gestione del traffico di rete.
  Caratteristiche:
  ✅ Compatibile con tutte le versioni di Linux.
  ✅ Supporta VLAN e bonding.
  ✅ Facile da configurare e mantenere.
  ❌ Non supporta funzionalità avanzate come VXLAN o OpenFlow.
  Quando usarlo?
  Se si vuole una configurazione di rete semplice e affidabile.
  Se non si necessitano funzionalità avanzate di SDN (Software Defined Networking).

• Open vSwitch (OVS)
  Descrizione: Usa Open vSwitch, uno switch virtuale avanzato con supporto per SDN (Software Defined Networking).
  Caratteristiche:
  ✅ Supporta VXLAN, GRE e altre tecnologie di overlay.
  ✅ Compatibile con OpenStack Neutron e altre piattaforme SDN.
  ✅ Offre migliori prestazioni e supporto per OpenFlow.
  ❌ Richiede maggiore configurazione rispetto a Linux Bridge.
  ❌ Non supportato su tutte le distribuzioni di Linux senza pacchetti aggiuntivi.
  Quando usarlo?
  Se hai bisogno di rete SDN avanzata.
  Se vuoi usare VXLAN per reti virtualizzate su larga scala.
  Se stai integrando oVirt con OpenStack o altre piattaforme cloud.

Firewall Type:

L’opzione Firewall Type in un Cluster di oVirt definisce quale sistema firewall viene utilizzato per la gestione della sicurezza e del traffico di rete sugli host del cluster.

• iptables
  Descrizione: Il firewall tradizionale basato su iptables, usato in versioni più vecchie di Linux.
  Caratteristiche:
  ✅ Stabile e ampiamente supportato.
  ✅ Compatibile con versioni più datate di oVirt e RHEL/CentOS.
  ❌ Meno flessibile rispetto a firewalld.
  ❌ Regole più complesse da gestire manualmente.
  Quando usarlo?
  Se gli host del cluster eseguono distribuzioni Linux più vecchie.
  Se preferisci gestire manualmente le regole del firewall.

• firewalld (Consigliato)
  Descrizione: Il firewall dinamico di Red Hat, basato su zones per una gestione più flessibile.
  Caratteristiche:
  ✅ Supporta regole dinamiche, senza bisogno di riavviare il firewall.
  ✅ Più semplice da configurare con interfacce grafica e CLI.
  ✅ Gestione più avanzata rispetto a iptables.
  ✅ Raccomandato per oVirt 4.4+ e sistemi basati su RHEL 8+.
  ❌ Non supportato su distribuzioni Linux più vecchie.
  Quando usarlo?
  Se stai usando RHEL 8, CentOS Stream, AlmaLinux o Rocky Linux.
  Se vuoi una gestione più semplice e flessibile del firewall.
  Se segui le best practices di sicurezza più recenti.

Default Network Provider

: L’opzione Default Network Provider in un Cluster di oVirt specifica quale provider di rete verrà utilizzato per gestire le configurazioni di rete all’interno del cluster.

• oVirt Provider OVN (Open Virtual Network)
  Descrizione: Basato su OVN (Open Virtual Network), un sistema SDN (Software Defined Networking) integrato in oVirt.
  Caratteristiche:
  ✅ Supporta VXLAN, GRE, OpenFlow e altre tecnologie SDN.
  ✅ Permette la creazione di reti overlay indipendenti dalla rete fisica.
  ✅ Migliore scalabilità per ambienti cloud o datacenter complessi.
  ✅ Possibilità di gestione avanzata con OpenStack Neutron.
  ❌ Richiede configurazione aggiuntiva rispetto alla rete standard.
  Quando usarlo?
  Se vuoi un’infrastruttura SDN avanzata per gestire reti overlay.
  Se stai integrando oVirt con OpenStack o ambienti cloud.

• oVirt (Default – Standard Network)
  Descrizione: Il provider di rete tradizionale gestito direttamente da oVirt Engine senza SDN.
  Caratteristiche:
  ✅ Usa Linux Bridge o Open vSwitch per la gestione delle reti.
  ✅ Più semplice da configurare rispetto a OVN.
  ✅ Compatibile con tutte le versioni di oVirt senza requisiti aggiuntivi.
  ❌ Non supporta reti overlay avanzate come VXLAN senza configurazioni manuali.
  Quando usarlo?
  Se vuoi una configurazione semplice e compatibile con tutti gli host.
  Se non hai bisogno di reti virtualizzate complesse.

Maximum Log Memory Threshold:

L’opzione Maximum Log Memory Threshold in un Cluster di oVirt definisce la quantità massima di memoria (RAM) che può essere utilizzata per la registrazione dei log di debug sugli host del cluster.

Enable Virt Service: L’opzione Enable Virt Service in un Cluster di oVirt abilita o disabilita il supporto per la virtualizzazione sugli host del cluster.

Enable Gluster Service:L’opzione Enable Gluster Service in un Cluster di oVirt abilita il supporto per GlusterFS, un sistema di storage distribuito.

/dev/hwrng source: L’opzione /dev/hwrng Source in un Cluster di oVirt definisce l’uso di un Generatore di Numeri Casuali Hardware (Hardware RNG) per le macchine virtuali (VM) all’interno del cluster.

• Quando abilitarlo?
  ✅ Se le VM eseguono applicazioni che necessitano di elevata entropia, come:
  Sistemi di crittografia (TLS, SSH, OpenVPN).
  Generazione di chiavi private (PKI, SSL/TLS).
  Sistemi operativi con alta richiesta di numeri casuali (Linux server, firewall, ecc.).
  ✅ Se gli host del cluster dispongono di un generatore hardware RNG.

• Quando disabilitarlo?
  ❌ Se gli host del cluster non dispongono di un dispositivo /dev/hwrng fisico.
  ❌ Se le VM non eseguono applicazioni che richiedono numeri casuali critici.
  ❌ Se si preferisce utilizzare solo fonti di entropia software (/dev/random o /dev/urandom).

Configurare le Impostazioni di OPTIMIZATION

Memory Optimization: L’opzione Memory Optimization in un Cluster di oVirt regola il comportamento della gestione della memoria tra le macchine virtuali (VMs) e gli host del cluster. Questa impostazione è cruciale per ottimizzare l’uso della RAM, migliorare le prestazioni delle VM e bilanciare il carico sugli host.

Symmetric Multithreading: L’opzione Symmetric Multithreading (SMT) in un Cluster di oVirt controlla se gli host nel cluster possono utilizzare l’Hyper-Threading della CPU, che permette a ogni core fisico di eseguire più thread simultaneamente.

CPU Threads: L’opzione CPU Threads in un Cluster di oVirt determina quanti thread virtuali possono essere mappati su ciascun core fisico degli host nel cluster. Questa impostazione è particolarmente importante in ambienti con processori che supportano Hyper-Threading (Intel) o Simultaneous Multithreading (SMT) (AMD), in quanto permette di ottimizzare l’uso della CPU e migliorare la densità delle VM.

Memory Balloon: L’opzione Memory Balloon in un Cluster di oVirt permette alle macchine virtuali (VMs) di rilasciare o allocare memoria dinamicamente sugli host, ottimizzando l’uso della RAM.

KSM control: L’opzione KSM Control (Kernel Samepage Merging) in un Cluster di oVirt permette di ottimizzare l’uso della memoria condividendo pagine di RAM identiche tra più macchine virtuali (VM).

Configurare le Impostazioni di MIGRATION POLICY

La Migration Policy del cluster determina il comportamento della migrazione live delle macchine virtuali (VM) tra gli host. Questa impostazione è cruciale per garantire l’efficienza e la continuità operativa delle VM durante le migrazioni.

Ecco le principali opzioni di Migration Policy disponibili:

Minimal downtime: Questa politica ottimizza il processo di migrazione per ridurre al minimo il tempo di inattività della VM. È ideale per ambienti di produzione dove è fondamentale mantenere la continuità del servizio.

Post-copy migration: Con questa politica, la migrazione inizia trasferendo un numero minimo di pagine di memoria, attivando la VM sull’host di destinazione e continuando a trasferire le restanti pagine mentre la VM è in esecuzione sul nuovo host. Questo approccio riduce significativamente il downtime della VM e garantisce che la migrazione si completi anche in presenza di carichi di lavoro intensivi che potrebbero impedire la convergenza con metodi standard. Tuttavia, durante la fase post-copy, la VM potrebbe rallentare se parti mancanti della memoria devono essere trasferite tra gli host.

Suspend workload if needed : Questa politica consente la migrazione della VM anche in presenza di carichi di lavoro pesanti. Se la migrazione non riesce a concludersi a causa dell’elevato utilizzo delle risorse, la VM può essere sospesa temporaneamente per completare la migrazione, comportando un downtime più significativo rispetto ad altre politiche. È utile per garantire la migrazione di VM con carichi di lavoro intensivi che altrimenti potrebbero non riuscire a migrare.

Very large VMs: Questa politica è progettata per facilitare la migrazione di VM con una quantità significativa di memoria. Utilizza la tecnica di migrazione “zero-copy”, che consente di trasferire la VM all’host di destinazione senza copiare preventivamente tutte le pagine di memoria. Questo approccio è particolarmente utile per VM di grandi dimensioni che potrebbero non migrare correttamente con le politiche standard.

La scelta della Migration Policy più appropriata dipende dalle esigenze specifiche del tuo ambiente e dalle caratteristiche delle VM:

Minimal downtime: per VM che richiedono alta disponibilità e dove il downtime deve essere minimizzato.

Post-copy migration: per VM con grandi quantità di RAM o carichi di lavoro che cambiano rapidamente, dove la migrazione standard potrebbe non convergere.

Suspend workload if needed: per VM con carichi di lavoro molto pesanti che potrebbero impedire la migrazione live; accetta un downtime maggiore per garantire il completamento della migrazione.

Very large VMs: per VM di dimensioni notevoli che richiedono tecniche avanzate come la migrazione “zero-copy” per essere trasferite con successo.

Configurare le Impostazioni di SCHEDULING POLICY

Le Scheduling Policies determinano come le macchine virtuali (VM) vengono distribuite tra gli host all’interno di un cluster. Queste politiche utilizzano una combinazione di filtri, pesi e logiche di bilanciamento del carico per ottimizzare l’allocazione delle risorse e garantire prestazioni efficienti.

Di seguito sono descritte le principali opzioni di Scheduling Policy disponibili in oVirt:

Evenly Distributed:
Descrizione: Questa politica distribuisce in modo uniforme il carico di memoria e CPU su tutti gli host del cluster. L’obiettivo è evitare che alcuni host siano sovraccarichi mentre altri rimangono sotto-utilizzati.
Uso consigliato: Ideale per ambienti in cui si desidera un bilanciamento equilibrato del carico tra gli host.

Power Saving:
Descrizione: Questa politica concentra il carico di lavoro su un sottoinsieme di host, consentendo agli altri di essere spenti o messi in standby per risparmiare energia. Gli host con un carico CPU inferiore a una soglia definita migrano le loro VM su altri host, permettendo lo spegnimento dell’host sotto-utilizzato.
Uso consigliato: Adatto per ambienti dove il risparmio energetico è prioritario e una leggera diminuzione delle prestazioni è accettabile.

VM Evenly Distributed:
Descrizione: Questa politica distribuisce le VM in modo che il numero di VM su ciascun host sia il più uniforme possibile, indipendentemente dal loro consumo di risorse.
Uso consigliato: Utile in scenari dove si desidera evitare che troppe VM siano concentrate su un singolo host, indipendentemente dal loro carico.

Cluster Maintenance:
Descrizione: Questa politica limita l’avvio di nuove VM durante le operazioni di manutenzione del cluster. Le VM altamente disponibili possono comunque essere avviate, e le migrazioni non sono bloccate, permettendo la continuità operativa durante la manutenzione.
Uso consigliato: Ideale durante le finestre di manutenzione in cui si desidera prevenire l’avvio di nuove VM ma mantenere operative quelle esistenti.

None:
Descrizione: Non applica alcuna politica specifica di bilanciamento o risparmio energetico. Le VM vengono avviate sugli host disponibili senza considerare il bilanciamento del carico.
Uso consigliato: Quando si desidera un comportamento di schedulazione predefinito senza ottimizzazioni specifiche.

Oltre alle politiche predefinite, oVirt consente la creazione di politiche di schedulazione personalizzate. Queste possono essere configurate combinando vari moduli di filtro e moduli di peso per soddisfare esigenze specifiche. Ad esempio, è possibile creare una politica che favorisca l’allocazione delle VM su host con determinate caratteristiche hardware o che rispetti regole di affinità tra VM e host.

Moduli di Filtro:

CpuPinning: Filtra gli host che non soddisfano la configurazione di pinning della CPU della VM.
Memory: Esclude gli host che non dispongono di memoria sufficiente per eseguire la VM.
Network: Esclude gli host su cui non sono installate le reti richieste dalla VM.
VmAffinityGroups: Considera le regole di affinità tra VM definite nei gruppi di affinità.

Moduli di Peso:

OptimalForEvenGuestDistribution: Assegna un peso agli host in base al numero di VM in esecuzione, favorendo una distribuzione uniforme.
OptimalForHaReservation: Assegna un peso agli host in base al punteggio di alta disponibilità, favorendo quelli più adatti a ospitare VM altamente disponibili.
VmToHostsAffinityGroups: Considera le regole di affinità tra VM e host definite nei gruppi di affinità.
La combinazione di questi moduli consente di creare politiche di schedulazione che rispondono a requisiti specifici, ottimizzando l’allocazione delle risorse e garantendo che le VM vengano eseguite sugli host più appropriati in base alle esigenze operative.

Configurare le Impostazioni di CONSOLE

Overridden SPICE Proxy Address: Questa opzione permette di specificare un indirizzo proxy SPICE che sovrascrive il proxy SPICE globale definito per l’ambiente oVirt. È particolarmente utile quando gli utenti si connettono alle macchine virtuali da reti esterne rispetto a quella in cui risiedono gli host.
Questa configurazione garantisce che le connessioni SPICE delle macchine virtuali nel cluster utilizzino il proxy specificato, facilitando l’accesso per gli utenti esterni.

Enable VNC Encryption: L’opzione Enable VNC Encryption abilita la crittografia per le connessioni VNC alle macchine virtuali. Questo è essenziale in ambienti che richiedono un elevato livello di sicurezza, come quelli con FIPS (Federal Information Processing Standards) abilitato.
Dopo aver abilitato questa opzione, è necessario eseguire ulteriori configurazioni sugli host per supportare la crittografia VNC, come descritto nella Guida all’Amministrazione di oVirt. Abilitando la crittografia VNC, le comunicazioni tra il client e la macchina virtuale sono protette, garantendo la riservatezza dei dati trasmessi.

Configurare le Impostazioni di FENCING POLICY

Il fencing è il processo di isolamento di un host non responsivo per assicurarsi che le VM in esecuzione su di esso possano essere riavviate su altri host senza rischio di conflitti o corruzione dei dati. Questo isolamento può avvenire tramite il riavvio forzato dell’host problematico o attraverso altri metodi di isolamento.

Opzioni della Fencing Policy nel Cluster di oVirt
Quando si configura la Fencing Policy in un cluster oVirt, sono disponibili diverse opzioni:

Enable Fencing:
Descrizione: Abilita o disabilita il fencing nel cluster. Il fencing è abilitato per impostazione predefinita, ma può essere disabilitato temporaneamente, ad esempio durante attività di manutenzione o diagnosi di rete.
Nota: Se il fencing è disabilitato, le VM altamente disponibili in esecuzione su host non responsivi non verranno riavviate su altri host.

Skip Fencing if Host has Live Lease on Storage:
Descrizione: Se selezionato, il fencing verrà ignorato per gli host non responsivi che risultano ancora connessi allo storage.
Utilizzo: Utile per evitare il fencing di host che potrebbero avere problemi di rete transitori ma mantengono l’accesso allo storage condiviso.

Skip Fencing on Cluster Connectivity Issues:
Descrizione: Se selezionato, il fencing sarà temporaneamente disabilitato se una percentuale definita di host nel cluster presenta problemi di connettività.
Configurazione: È possibile impostare una soglia (Threshold) con valori del 25%, 50%, 75% o 100%. Se la percentuale di host con problemi supera la soglia, il fencing viene sospeso.
Utilizzo: Utile per prevenire il fencing massivo in caso di problemi di rete che coinvolgono una parte significativa del cluster.

Configurare le Impostazioni di MAC ADDRESS POOL

L’opzione MAC Address Pool in un cluster definisce l’insieme di indirizzi MAC che possono essere assegnati alle interfacce di rete delle macchine virtuali (VM) all’interno di quel cluster. Questa funzionalità è cruciale per garantire l’unicità degli indirizzi MAC e prevenire conflitti di rete.

Funzionamento del MAC Address Pool:

Assegnazione Automatica: Quando si crea una nuova interfaccia di rete per una VM, oVirt assegna automaticamente un indirizzo MAC disponibile dal pool associato al cluster. Questo processo automatizzato riduce il rischio di duplicazione degli indirizzi MAC.

Condivisione tra Cluster: È possibile configurare un singolo MAC Address Pool per essere condiviso tra più cluster. Tuttavia, ogni cluster può avere assegnato un solo MAC Address Pool alla volta.

Pool Predefinito: oVirt crea un MAC Address Pool predefinito utilizzato se non ne viene assegnato uno specifico al cluster.

Considerazioni Importanti:

Evitare Conflitti: Se più cluster condividono la stessa rete fisica, è fondamentale assegnare a ciascun cluster un range di indirizzi MAC univoco. L’uso del pool predefinito in questo scenario potrebbe portare a conflitti, poiché le VM di diversi cluster potrebbero tentare di utilizzare lo stesso intervallo di indirizzi MAC.

Gestione dei Range: È possibile definire uno o più intervalli di indirizzi MAC all’interno di un pool. Quando un intervallo esaurisce gli indirizzi disponibili, oVirt inizia ad assegnare indirizzi dal successivo intervallo definito nel pool.

Permettere Duplicati: Durante la creazione o la modifica di un MAC Address Pool, è possibile scegliere se consentire l’uso di indirizzi MAC duplicati. Se abilitato, oVirt non assegnerà automaticamente indirizzi duplicati, ma gli utenti potranno manualmente assegnare lo stesso indirizzo MAC a più interfacce, se necessario.

Cliccare OK per terminare la configurazione del Cluster

CONFIGURAZIONE DEGLI HOSTS

Procedere con la configurazione degli Host all’interno del Cluster

Cliccare Configure Host

Di seguito la lista delle opzioni configurabili con le relative descrizioni del tab GENERAL

Name
Descrizione: Nome descrittivo per l’host, utilizzato all’interno dell’interfaccia di gestione di oVirt.
Nota: Non è necessario che coincida con il nome DNS o l’hostname dell’host.
Esempio: node1, hypervisor01, host-prod-1

Comment
Descrizione: Campo opzionale per fornire una descrizione aggiuntiva dell’host.
Utilizzo: Può essere utile per annotare il ruolo dell’host (es. “Host per applicazioni critiche”).

Hostname/IP
Descrizione: Indirizzo IP o hostname dell’host da aggiungere al cluster.
Requisiti:
✅ Deve essere risolvibile via DNS o accessibile direttamente via IP.
✅ Deve essere già configurato con un sistema operativo compatibile con oVirt (es. oVirt Node, CentOS Stream, RHEL, AlmaLinux).
Esempio: Hostname: node1.domain.local oppure IP: 192.168.1.10

SSH Port
Descrizione: La porta utilizzata per connettersi all’host tramite SSH.
Valore predefinito: 22
Quando modificarlo? Se l’host utilizza una porta personalizzata per SSH per motivi di sicurezza.

Activate host after install
Descrizione: Se abilitata, l’host verrà automaticamente attivato al termine dell’installazione.
Opzioni:
✅ Sì (predefinito) – L’host sarà pronto per eseguire VM immediatamente.
❌ No – L’host verrà aggiunto ma rimarrà in stato Maintenance fino all’attivazione manuale.
Quando disabilitarlo? Se vuoi configurare ulteriormente l’host prima di renderlo operativo.

Reboot host after install
Descrizione: Se abilitata, l’host verrà riavviato automaticamente una volta completata l’installazione.
Opzioni:
✅ Sì – Richiesto se sono stati aggiornati pacchetti critici durante l’installazione.
❌ No – Se vuoi riavviare l’host manualmente in un secondo momento.
Quando abilitarlo? Se è necessario un riavvio per applicare aggiornamenti o modifiche di sistema.

User Name
Descrizione: Nome utente utilizzato per connettersi all’host tramite SSH.
Valore predefinito: root (raccomandato per l’installazione iniziale).
Nota: Se l’host non consente l’accesso SSH come root, è necessario usare un utente con privilegi sudo.

Password
Descrizione: Password dell’utente specificato per la connessione SSH.
Alternativa: Se si utilizza autenticazione a chiave pubblica SSH, lasciare vuoto questo campo.

SSH Public Key
Descrizione: Chiave pubblica SSH utilizzata per autenticare l’host senza richiedere una password.
Utilizzo: Alternativa più sicura rispetto all’uso della password.
Quando usarlo? Se hai già configurato le chiavi SSH per la gestione sicura degli host.

Di seguito la lista delle opzioni configurabili con le relative descrizioni del tab POWER MANAGEMENT

Durante la configurazione della Gestione dell’Alimentazione di un host, sono disponibili due opzioni chiave: Kdump Integration e Disable Policy Control of Power Management.

Kdump Integration: Questa opzione, se abilitata, impedisce che l’host venga isolato (fenced) durante l’esecuzione di un dump della memoria del kernel tramite Kdump. Kdump è un meccanismo che cattura il contenuto della memoria in caso di crash del sistema, utile per diagnosticare problemi. Senza questa integrazione, un host potrebbe essere erroneamente considerato non responsivo durante il processo di dump e quindi soggetto a fencing.

NOTA BENE: Se si abilita o disabilita l’integrazione Kdump su un host esistente, è necessario reinstallare l’host affinché la configurazione abbia effetto.

Disable Policy Control of Power Management: Questa opzione, se selezionata, esclude l’host dal controllo automatico della gestione dell’alimentazione definito dalla Scheduling Policy del cluster. In oVirt, le politiche di scheduling possono prevedere lo spegnimento automatico degli host in caso di bassa utilizzazione o la loro accensione quando aumenta la domanda di risorse. Abilitando Disable Policy Control of Power Management, l’host non sarà soggetto a queste azioni automatiche, permettendo un controllo manuale completo delle operazioni di alimentazione. Questa opzione è utile in scenari in cui si desidera che specifici host rimangano sempre attivi o siano gestiti manualmente, indipendentemente dalle politiche automatiche del cluster.

Di seguito la lista delle opzioni configurabili con le relative descrizioni del tab SPM

L’opzione SPM (Storage Pool Manager) in oVirt determina quale host nel cluster sarà responsabile della gestione delle operazioni di storage all’interno di un Storage Pool.

Quando si configura un host in oVirt, è possibile assegnargli uno dei seguenti ruoli SPM:

SPM Priority (Priorità SPM): Definisce la priorità di un host per diventare SPM nel caso in cui l’host attualmente assegnato a questo ruolo diventi non disponibile.

Valori disponibili:

Low (Bassa) → L’host verrà scelto come SPM solo se non ci sono alternative migliori.
Normal (Normale, Default) → L’host è un candidato standard per diventare SPM.
High (Alta) → L’host avrà una priorità elevata per diventare SPM se il ruolo deve essere riassegnato.
Never (Mai) → L’host non potrà mai essere selezionato come SPM.

Cambio automatico del SPM: Se l’host attuale con il ruolo SPM diventa non disponibile, oVirt assegnerà automaticamente il ruolo a un altro host disponibile con priorità più alta.

Di seguito la lista delle opzioni configurabili con le relative descrizioni del tab CONSOLE AND GPU

Override display address

Questa opzione permette di forzare l’indirizzo IP o il nome host utilizzato per connettersi alla console di una macchina virtuale.

• Utile in ambienti con NAT, dove l’indirizzo IP interno della VM non è direttamente raggiungibile dal client esterno.
• Permette di definire un endpoint pubblico fisso per l’accesso remoto alla console della VM.
• Può essere configurato a livello di VM, cluster o datacenter, offrendo flessibilità nella gestione dell’infrastruttura virtuale.

vGPU Placement

La funzione vGPU Placement è utilizzata per assegnare risorse GPU virtualizzate alle macchine virtuali in oVirt. Questo è essenziale per workload che richiedono accelerazione hardware, come l’elaborazione grafica avanzata o il machine learning.

Modalità di assegnazione delle vGPU:
Dedicated (Pass-through): la GPU è assegnata in modo esclusivo a una singola VM, fornendo prestazioni simili a quelle di una GPU fisica.
Shared (Mediated Devices – mdev): una singola GPU fisica è suddivisa in più vGPU, permettendo la condivisione tra più VM.

Automatic Placement: oVirt può gestire in modo dinamico l’assegnazione delle vGPU alle VM in base alle risorse disponibili.
Configurazione della vGPU:
Definizione dei profili vGPU supportati dall’hardware (es. NVIDIA GRID, AMD MxGPU).
Associazione delle VM ai profili vGPU tramite l’interfaccia di gestione di oVirt.
Controllo delle policy di allocazione per garantire prestazioni ottimali.
Questa funzionalità è particolarmente utile per ambienti VDI (Virtual Desktop Infrastructure) e scenari di AI/ML, dove la potenza della GPU è un fattore critico.

Di seguito la lista delle opzioni configurabili con le relative descrizioni del tab KERNEL

Hostdev Passthrough e SR-IOV: questa opzione permette il passthrough di dispositivi hardware fisici (come schede di rete, GPU, controller USB) direttamente alle macchine virtuali.
Hostdev Passthrough consente a una VM di utilizzare un dispositivo fisico dell’host come se fosse collegato direttamente a essa, migliorando le prestazioni e riducendo l’overhead della virtualizzazione.
SR-IOV (Single Root I/O Virtualization) consente di suddividere una singola scheda di rete (o GPU) in più funzioni virtuali (VFs, Virtual Functions) che possono essere assegnate a diverse VM.
Vantaggi: Minore latenza e maggiore throughput rispetto ai dispositivi virtualizzati standard. Essenziale per ambienti ad alte prestazioni, come data center, NFV (Network Function Virtualization) e workload GPU-intensive.

Nested Virtualization: La Nested Virtualization consente di eseguire macchine virtuali all’interno di altre macchine virtuali, utile per ambienti di test e sviluppo.
Usi principali: Test di infrastrutture cloud (es. OpenStack, Kubernetes con KubeVirt). Simulazione di ambienti di produzione con più livelli di virtualizzazione.

Interrupt Unsafe: Opzione avanzata legata alla gestione delle interruzioni hardware.

• Quando abilitarlo: In ambienti dove le VM necessitano di un controllo diretto sulle interruzioni hardware. Se il sistema ha problemi di latenza o dispositivi PCIe con esigenze specifiche.
• Quando evitarlo: Se il sistema è esposto a rischi di instabilità legati a interruzioni mal gestite. In ambienti di produzione dove la stabilità è prioritaria.

Riallocazione PCI: 

Permette di modificare la disposizione delle risorse PCIe assegnate a un host o una VM.

Utilità: Necessario per il passthrough di dispositivi che richiedono un particolare layout di memoria PCI. Utile in presenza di conflitti di risorse PCI tra VM diverse.

Blacklist Nouveau: Nouveau è il driver open-source per le schede grafiche NVIDIA. Poiché NVIDIA non supporta Nouveau per il passthrough delle GPU, è spesso necessario disabilitarlo e usare i driver proprietari.

• Quando è necessario: Per usare il passthrough delle GPU NVIDIA con vGPU o SR-IOV. Per migliorare la stabilità del sistema in ambienti con GPU NVIDIA.

FIPS mode:

FIPS è uno standard di sicurezza per la crittografia usato da governi e organizzazioni con requisiti di conformità elevati.

• Effetti: Usa solo algoritmi di crittografia conformi a FIPS. Potrebbe impedire l’uso di alcune librerie non compatibili.
• Quando abilitarlo: In ambienti con regolamentazioni di sicurezza (es. enti governativi, sanità, finanza).

SMT Disabled:

SMT (Hyper-Threading su CPU Intel) permette a un singolo core fisico di eseguire più thread simultaneamente. Disabilitarlo può migliorare la sicurezza riducendo attacchi basati su side-channel (es. Spectre, Meltdown).

• Quando disabilitarlo:
  In ambienti altamente sicuri, per mitigare vulnerabilità speculative della CPU.
  In workload sensibili, dove l’isolamento delle CPU è critico.
• Quando mantenerlo attivo:
  Per massimizzare le prestazioni nei workload multi-threaded (es. database, rendering 3D).

Di seguito la lista delle opzioni configurabili con le relative descrizioni del tab HOSTED ENGINE

Choose hosted engine deployment action: Quando si avvia il deployment dell’Hosted Engine in oVirt, il sistema chiede di scegliere un’azione specifica per il deployment. Questo è un passaggio critico, poiché l’Hosted Engine è il componente chiave che gestisce l’intero ambiente di virtualizzazione oVirt.

Di seguito la lista delle opzioni configurabili con le relative descrizioni del tab AFFINITY

Select an Affinity Group: I Gruppi di Affinità (Affinity Groups) vengono usati per definire regole che stabiliscono dove e come le VM devono essere posizionate sugli host.
Tipologie di Affinity Group:
Positive Affinity → Le VM devono essere eseguite insieme sullo stesso host.
Negative Affinity → Le VM devono essere separate su host diversi per garantire alta disponibilità.
Affinity tra VM e Host:
“Preferisci eseguire su questo host” → La VM tenta di avviarsi sempre su uno specifico host.
“Deve eseguire su questo host” → La VM può avviarsi solo su uno specifico host.
Esempi d’uso:
✅ Server in cluster HA → Separa due macchine critiche su host diversi per evitare downtime simultanei.
✅ Applicazioni che devono stare insieme → Mantieni una VM database e una VM applicativa sullo stesso host per ridurre latenza.

Select an Affinity Label: Le Affinity Labels sono tag che vengono assegnati a VM e Host per controllarne l’esecuzione senza regole rigide come gli Affinity Groups.
Le VM con la stessa etichetta preferiscono essere eseguite su host con la stessa etichetta.
Non impone una restrizione assoluta, ma migliora la gestione delle risorse in cluster grandi.
Esempi d’uso:
✅ Assegna etichette a host con GPU dedicate → Le VM con requisiti grafici si avvieranno preferibilmente su questi host.
✅ Cluster multi-tenancy → Raggruppa le VM dei clienti in base alle etichette per separare i workload.

Selected Affinity Labels: Mostra le etichette già assegnate alla VM o all’host corrente.
Permette di modificare le etichette esistenti o aggiungerne di nuove.
Le VM possono avere più etichette per una gestione più flessibile.

Cliccare OK Per confermare tutte le impostazioni di aggiunta dell’Host

Se non si è configurato il Power Management potremmo visualizzare il seguente Alert, ingnorarlo cliccando su OK

Cliccare su Add Another Host per aggiungere un altro Host

Per verificare il processo di installazione dell’Host cliccare su Tasks

Cliccare sull’icona indicata dalla freccia e controllare che l’installazione dell’Host proceda senza problemi

Se è andato tutto a buon fine dovremmo visualizzare una schermata come mostrato nell’immagine sovrastante

Andando sul menù Compute -> Hosts dovremmo visualizzare l’Host appena aggiunto

Al termine dell’aggiunta degli Hosts dovremmo visualizzare una schermata come quella sovrastante

CONFIGURAZIONE DELLO STORAGE CONDIVISO

I domini di storage possono essere ulteriormente classificati in base al loro utilizzo all’interno di oVirt:

Data Domain: Contiene immagini disco, snapshot e dischi di macchine virtuali.
ISO Domain: Archivia file ISO di installazione dei sistemi operativi (solo su NFS).
Export Domain: Utilizzato per il backup e la migrazione delle macchine virtuali tra diversi data center (non più supportato nelle versioni più recenti di oVirt).

Per aggiungere lo storage condiviso al cluster

Cliccare su Storage quindi Domains

Cliccare New Domain

Di seguito la lista delle opzioni configurabili con le relative allo Storage

NF
Descrizione: Un protocollo di file storage che consente a più host di accedere ai file come se fossero locali.
Tipo: File-Based Storage
Vantaggi: Semplice da configurare e gestire. Accesso centralizzato da più host. Supporta la scalabilità orizzontale.
Svantaggi: Prestazioni inferiori rispetto allo storage a blocchi (iSCSI, Fibre Channel). Dipendenza dalla rete (latenza e larghezza di banda possono influenzare le prestazioni).

POSIX Compliant FS
Descrizione: Qualsiasi filesystem che rispetti gli standard POSIX per la gestione di file e directory può essere utilizzato.
Tipo: File-Based Storage
Esempi: EXT4, XFS, Btrfs
Vantaggi: Flessibilità nell’uso di diversi filesystem. Compatibile con molte configurazioni di storage. Supporta operazioni avanzate come snapshot (a seconda del filesystem).
Svantaggi: Generalmente usato solo in configurazioni locali o distribuite. Può richiedere configurazioni aggiuntive per garantire alta disponibilità.

GlusterFS
Descrizione: Un file system distribuito che consente di aggregare più storage in un’unica entità, garantendo ridondanza e scalabilità.
Tipo: File-Based Storage (Distribuito)
Vantaggi: Supporta la replica dei dati per alta disponibilità. Scalabilità orizzontale semplice (aggiunta di nuovi nodi). Può essere usato con hyperconverged infrastructures.
Svantaggi: Richiede più configurazione rispetto a NFS. Le prestazioni possono variare a seconda del tipo di volume (distribuito, replicato, stripe). Potenziale overhead di gestione rispetto a storage a blocchi.

iSCSI
Descrizione: Un protocollo di storage a blocchi basato su TCP/IP, che consente l’accesso remoto ai dispositivi di archiviazione.
Tipo: Block-Based Storage
Vantaggi: Prestazioni migliori rispetto allo storage basato su file. Supporta funzionalità avanzate come multipath e thin provisioning. Può essere utilizzato con SAN (Storage Area Network).
Svantaggi: Richiede una rete dedicata o ottimizzata per le migliori prestazioni. Più complesso da configurare rispetto a NFS o GlusterFS.

Fibre Channel
Descrizione: Una tecnologia di storage a blocchi ad alte prestazioni, che utilizza una rete dedicata per la connessione tra server e storage.
Tipo: Block-Based Storage
Vantaggi: Prestazioni molto elevate, con bassa latenza. Affidabile per ambienti enterprise con elevati carichi di lavoro. Supporta multipath per ridondanza e failover.
Svantaggi: Costoso da implementare (richiede switch e HBA Fibre Channel). Richiede hardware specializzato. Complesso da configurare rispetto ad altre soluzioni.

In questo tutorial farò una configurazione iSCSI

Inserire l’IP o l’FDQN del server storage quindi cliccare Discover

Dovrebbe comparire il Target iSCSI come mostrato nell’immagine sovrastante

Cliccare sul pulsante Loading come mostrato nell’immagine sovrastante

Cliccare su Add per aggiungere lo storage

Se il volume è montato dovremmo vederlo in neretto come mostrato nell’immagine sovrastante

Cliccare OK per confermare

Selezionare Approve the operation quindi cliccare OK

Monitorare nel tab Tasks l’aggiunta dello storage

Se è tutto OK dovremmo visualizzare una schermata come quella sovrastante

Al termine dell’aggiunta del Domain dovremmo visualizzare una schermata come quella sovrastante dove in corrispondenza dello Status dovremmo visualizzare una freccia verde verso l’alto

Anche nell’area relativa al Datacenter dovremmo vedere un triangolo verde verso l’alta che indica che il Datacenter è attivo

Dalla Dashboard generale dovremmo vedere il riepilogo di tutto quello che è stato fatto.

Quindi dovremmo vedere un Datacenter, un Cluster, 3 Hosts e 1 Data Storage Domain

Adesso è possibile procedere con la creazione di Virtual Machine…