La configurazione del KVM linux network rappresenta un aspetto fondamentale per garantire connettività e prestazioni ottimali nelle infrastrutture virtualizzate Linux. Una corretta implementazione della rete virtuale non solo assicura una comunicazione efficiente tra macchine virtuali e mondo esterno, ma permette anche di sfruttare appieno le potenzialità di KVM in termini di flessibilità e scalabilità. La padronanza di questi concetti è essenziale per amministratori di sistema e professionisti IT che desiderano costruire ambienti virtualizzati robusti e performanti.
IN QUESTO ARTICOLO
Differenze tra Rete Fisica e Rete Virtuale
Nel contesto della virtualizzazione KVM linux network, l’architettura di rete replica efficacemente quella fisica attraverso componenti virtualizzati. In fatti il virtual switch, al quale si connettono le Virtual Machines, elemento chiave operante al layer 2 OSI, funge da ponte tra le macchine virtuali e la rete fisica, connettendosi a una porta fisica della scheda di rete che a sua volta comunica con uno switch fisico. Questo componente software è cruciale per gestire il traffico tra le VM e garantire l’isolamento di rete. Durante l’installazione di KVM Hypervisor, questi elementi virtuali vengono configurati automaticamente con impostazioni NAT e DHCP, fornendo una connettività immediata. Tale approccio architetturale offre vantaggi significativi in termini di costi ed efficienza: riduce la necessità di hardware fisico come schede di rete e porte switch, ottimizza l’utilizzo delle risorse di rete e semplifica la gestione dell’infrastruttura attraverso il consolidamento delle connessioni.
Virtual Networking
Le macchine virtuali si connettono al virtual switch attraverso interfacce di rete virtuali (vNIC), che emulano il comportamento delle schede fisiche. In KVM network Linux supporta diversi tipi di interfacce virtuali, vediamo quali sono:
Interfacce di rete principali:
- Bridge: crea un bridge di rete Layer 2
- Bond: aggrega più interfacce per ridondanza/bilanciamento
- Team: alternativa moderna al bonding
- MACVLAN: assegna indirizzi MAC multipli a una singola interfaccia
- IPVLAN: simile a MACVLAN ma opera a Layer 3
- MACVTAP/IPVTAP: combina MACVLAN con dispositivi TAP
- VXLAN: estende reti Layer 2 su Layer 3
- VETH: crea coppie di interfacce virtuali connesse
- IPOIB: supporta InfiniBand su IP
Interfacce di tunneling:
- GRETAP: tunnel GRE con supporto Ethernet
- GENEVE: protocollo di tunneling flessibile
- IPIP: incapsula IPv4 in IPv4
- SIT: tunnel IPv6 su IPv4
- ip6tnl: tunnel IPv4/IPv6 su IPv6
- IP6GRE: tunnel GRE su IPv6
- IP6GRETAP: tunnel GRE con supporto Ethernet su IPv6
La dipendenza di tutte le VM da un singolo virtual switch connesso a una sola NIC fisica rappresenta un punto singolo di fallimento: un guasto della scheda fisica interromperebbe la connettività di tutte le VM. Per migliorare la resilienza, è consigliabile implementare una configurazione ridondante utilizzando bridge connessi a multiple schede fisiche, replicando le best practice delle reti fisiche.
Comandi principali per la gestione dei bridge:
# Creazione
sudo ip link add name br0 type bridge
# Visualizza interfacce disponibili
ip link show
# Aggiungi NIC al bridge
sudo ip link set eth0 master br0
sudo ip link set eth1 master br0
# Attiva le interfacce
sudo ip link set eth0 up
sudo ip link set eth1 up
# Configurazione IP
sudo ip addr add 192.168.8.122/24 dev br0
# Visualizzazione dettagli
ip link show type bridge
ip link show master br0
# Rimozione interfaccia
sudo ip link set eth0 nomaster
# Eliminazione bridge
sudo ip link delete br0 type bridgeTipi di Network Basilari KVM Linux Network
Libvirt NAT Network
Le macchine virtuali (VM) connesse a un virtual switch configurato in modalità NAT (Network Address Translation) fanno parte di un segmento di rete separato, isolato dalla rete fisica dell’host. Questo significa che le VM create in KVM linux possono connettersi a qualsiasi sistema presente sulla rete fisica network (e quindi anche a Internet), ma le connessioni inverse, ovvero quelle che partono dalla rete fisica verso le VM, non sono possibili a meno che non si utilizzi il port forwarding. Il port forwarding consiste nel reindirizzare le connessioni in entrata su una specifica porta dell’host verso una specifica porta di una VM. Ad esempio, se si vuole accedere a un server web in esecuzione su una VM (con indirizzo IP 192.168.122.100 e porta 80) dall’esterno, si può configurare il port forwarding sull’host per reindirizzare le connessioni in entrata sulla porta 8080 dell’host verso la porta 80 della VM. In ambiente Linux, questo può essere realizzato con iptables o nftables. Un comando di esempio con iptables potrebbe essere:
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.122.100:80
iptables -t nat -A POSTROUTING -j MASQUERADEFile XML di configurazione per una rete NAT:
<network>
<name>nat-network</name>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>Libvirt Routed Network:
Le VM connesse a un network KVM linux di tipo rete routed sono collegate tramite il virtual switch direttamente alla rete fisica. A differenza del NAT, non c’è traduzione degli indirizzi IP. Per far funzionare questa configurazione, è necessario configurare il routing sulla rete fisica, in modo che il traffico destinato alle VM venga instradato correttamente verso l’host che esegue KVM. Questo metodo offre prestazioni migliori rispetto al NAT, ma richiede una configurazione più complessa.
File XML di configurazione per una rete routed:
Configurare il Routing sulla rete fisica
Configurare il routing sulla rete fisica per supportare una rete routed di Libvirt richiede di informare il router (o il gateway predefinito) della tua rete locale su come raggiungere la sottorete utilizzata dalle tue macchine virtuali. Ci sono diversi modi per farlo, a seconda della configurazione della tua rete. Ecco i metodi più comuni:
1. Aggiungere una rotta statica sul router/gateway:
Questo è il metodo più comune e generalmente preferibile, soprattutto in ambienti domestici o di piccole aziende. Richiede l’accesso all’interfaccia di configurazione del tuo router.
- Identifica la sottorete delle VM: Devi conoscere l’indirizzo di rete e la subnet mask che hai assegnato alla tua rete routed in Libvirt (ad esempio, 192.168.1.0/24).
- Identifica l’indirizzo IP dell’host KVM: Devi conoscere l’indirizzo IP dell’host fisico che esegue KVM sulla rete fisica (ad esempio, 192.168.0.100). Questo indirizzo fungerà da gateway per il traffico diretto alle VM.
- Accedi alla configurazione del router: Apri il browser e digita l’indirizzo IP del tuo router (di solito 192.168.0.1 o 192.168.1.1).
- Trova le impostazioni di routing statico: La posizione esatta varia a seconda del modello del router, ma cerca sezioni come “Routing”, “Routing statico”, “Rotta statica” o simili.
- Aggiungi una nuova rotta: Inserisci le seguenti informazioni:
- Destinazione/Rete di destinazione: La sottorete delle VM (es. 192.168.1.0)
- Subnet Mask/Maschera di sottorete: La subnet mask della rete delle VM (es. 255.255.255.0 o /24)
- Gateway/Hop successivo: L’indirizzo IP dell’host KVM (es. 192.168.0.100)
- Interfaccia (opzionale): In alcuni router è necessario specificare l’interfaccia di uscita. In questo caso, seleziona l’interfaccia LAN a cui è connesso l’host KVM.
Salva le modifiche e riavvia il router se necessario.
Esempio:
Supponiamo che la tua rete fisica sia 192.168.0.0/24, l’host KVM abbia l’indirizzo 192.168.0.100 e la rete routed delle VM sia 192.168.1.0/24. Sul router, dovresti aggiungere una rotta statica con:
- Destinazione: 192.168.1.0
- Subnet Mask: 255.255.255.0
- Gateway: 192.168.0.100
2. Aggiungere una rotta statica sull'host che esegue KVM (meno comune):
Se non hai accesso al router o se la tua rete è configurata in modo particolare, puoi aggiungere una rotta statica sull’host KVM. Questo metodo è meno comune e richiede che l’host KVM sia il gateway predefinito per le VM.
Su un sistema Linux, puoi usare il comando ip route add:
sudo ip route add 192.168.1.0/24 via 192.168.0.100 dev <interfaccia_di_rete_dell'host>Dove:
192.168.1.0/24è la sottorete delle VM.192.168.0.100è l’indirizzo IP dell’host KVM sulla rete fisica.<interfaccia_di_rete_dell'host>è il nome dell’interfaccia di rete dell’host connessa alla rete fisica (es. eth0, enp0s3).
Per rendere la rotta persistente al riavvio, devi aggiungere la riga appropriata al file /etc/network/interfaces (per sistemi Debian/Ubuntu) o un file di configurazione di rete equivalente per altre distribuzioni.
Libvirt Isolated Network
In una rete isolata, le VM sono collegate a uno switch virtuale che non ha alcuna connessione con la rete fisica. Questo significa che le VM possono comunicare solo tra di loro, ma non possono accedere a Internet o ad altre risorse esterne. Un caso d’uso tipico è quello di un server web con una scheda di rete virtuale (vNIC) connessa a una rete routed (per l’accesso pubblico) e una seconda vNIC connessa a una rete isolata dove risiede un server di database. In questo modo, il database è protetto da accessi esterni diretti, ma il server web può comunque comunicare con esso.
File XML di configurazione per una rete isolata:
<network>
<name>isolated-network</name>
<forward mode='none'/>
<ip address='192.168.123.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.123.2' end='192.168.123.254'/>
</dhcp>
</ip>
</network>Esempio di configurazione con rete routed e isolata per un web server:
Immaginiamo di avere un web server (VM1) con due interfacce di rete. eth0 connessa alla rete routed per l’accesso pubblico e eth1 connessa alla rete isolata. Un database server (VM2) ha una sola interfaccia di rete, connessa alla rete isolata.
VM1 (Web Server):
eth0: Indirizzo IP dalla rete routed (es. 192.168.1.101)eth1: Indirizzo IP dalla rete isolata (es. 192.168.123.2)
VM2 (Database Server):
eth0: Indirizzo IP dalla rete isolata (es. 192.168.123.3)
In questo scenario, il web server può comunicare con il database server tramite la rete isolata (192.168.123.0/24), mentre gli utenti esterni accedono al web server tramite la rete routed (192.168.1.0/24).
Formato XML per la configurazione di Libvirt
Il formato XML (Extensible Markup Language) è un linguaggio di markup utilizzato per rappresentare dati strutturati. In Libvirt, i file XML vengono utilizzati per definire la configurazione di domini (VM), reti, storage e altre risorse virtuali quindi risultano indispensabili per condigurare il network KVM linux. Le caratteristiche principali di XML sono:
- Struttura gerarchica: I dati sono organizzati in elementi nidificati, con un elemento radice che contiene tutti gli altri.
- Tag: Gli elementi sono delimitati da tag di apertura e chiusura (es.
<network>,</network>). - Attributi: I tag possono avere attributi che forniscono informazioni aggiuntive sull’elemento (es.
<forward mode='nat'>). - Leggibilità: Il formato XML è progettato per essere leggibile sia da umani che da macchine.
Configurare un nuovo Network KVM Linux
Per configurare una nuova rete virtuale con virsh, si utilizzano una serie di comandi che permettono di definire, avviare e gestire la rete. Il processo si articola nelle seguenti fasi:
- Esportazione del file XML di default: Si parte esportando la configurazione della rete di default (
default) in un file XML, che fungerà da template. Questo si fa con i comandi:
virsh net-dumpxml default > default.xml
cat default.xmlIl primo comando (
virsh net-dumpxml default > default.xml) estrae la configurazione XML della rete “default” e la salva nel filedefault.xml. Il secondo comando (cat default.xml) mostra il contenuto del file, permettendoti di esaminare la configurazione di default.
2. Copia del file XML: Si copia il file default.xml in un nuovo file, che verrà modificato per definire la nuova rete. Ad esempio, per creare una rete “routed”, si usa:
cp default.xml la-tua-rete.xml3. Modifica del file XML: Si edita il file routed.xml con un editor di testo, come vim:
vim la-tua-rete.xmlAll’interno del file, è necessario apportare le seguenti modifiche principali:
Nome della rete: Modificare il valore del tag
<name>con il nome desiderato per la nuova rete (es.<name>routed-network</name>).UUID: Generare un nuovo UUID (Universally Unique Identifier) con il comando:
uuidgene sostituire il valore esistente nel tag
<uuid>. L’UUID è un identificatore univoco per la rete.Indirizzo MAC: Generare un indirizzo MAC random per la rete con il comando:
hexdump -n6 -e '6/1 ":%02x"' /dev/urandom | awk ' { sub(/^:../, "02"); print } 'Questo comando genera un MAC address casuale che puoi inserire nel tag
<mac address='il_tuo_mac_address'/>all’interno del tag<bridge>(se presente, altrimenti puoi aggiungerlo).Configurazione IP: Definire il dominio IP per la rete. Questo include l’indirizzo IP del gateway (solitamente il primo indirizzo della sottorete) e la subnet mask. Queste informazioni vanno inserite nel tag
<ip address='indirizzo_ip' netmask='subnet_mask'>. Ad esempio:
<ip address='192.168.2.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.2.100' end='192.168.2.200'/>
</dhcp>
</ip>Questo esempio configura la rete con indirizzo 192.168.2.0/24 e abilita il DHCP per assegnare indirizzi IP alle VM in un range specificato. A seconda del tipo di rete che si vuole creare (NAT, routed o isolated) si dovranno modificare anche i tag
<forward>e la sua modalità (mode). Per una rete routed si userà<forward mode='route'/>
4. Creazione e avvio della rete: Una volta modificato il file XML, si può creare, avviare e configurare l’avvio automatico della rete con i seguenti comandi:
virsh net-define la-tua-rete.xml # Definisce la rete a partire dal file XML
virsh net-start la-tua-rete # Avvia la rete
virsh net-autostart la-tua-rete # Imposta l'avvio automatico della rete al boot del sistema
virsh net-list --all # Mostra la lista di tutte le reti (attive e non)Esempio completo di routed.xml:
<network>
<name>la-tua-rete</name>
<uuid>il_tuo_uuid_generato</uuid>
<forward mode='route'/>
<bridge name='virbr1' stp='on' delay='0'/>
<mac address='02:XX:XX:XX:XX:XX'/>
<ip address='192.168.2.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.2.100' end='192.168.2.200'/>
</dhcp>
</ip>
</network>Ricorda di sostituire il_tuo_uuid_generato e 02:XX:XX:XX:XX:XX con i valori generati dai comandi uuidgen e hexdump.
Questo processo ti permette di creare e configurare una nuova rete virtuale con virsh, offrendoti flessibilità nella gestione delle connessioni di rete delle tue macchine virtuali.
UserSpace TAP TUN
Lo spazio utente (userspace) e lo spazio kernel (kernelspace) rappresentano due domini distinti di esecuzione in un sistema operativo Linux. Il kernelspace è il dominio privilegiato dove opera il kernel del sistema operativo, con accesso diretto all’hardware e controllo completo sulle risorse del sistema. Lo userspace, invece, è l’area dove vengono eseguiti i programmi utente con privilegi limitati, isolati dall’hardware per garantire stabilità e sicurezza del sistema. In ambiente KVM linux, lo userspace gioca un ruolo fondamentale nella gestione delle comunicazioni di network, facilitando lo scambio di pacchetti tra programmi che operano in questo spazio. Per stabilire questa comunicazione, i programmi devono interfacciarsi con il dispositivo virtuale /dev/net/tun attraverso chiamate di sistema ioctl(), che consentono la registrazione di interfacce di rete virtuali. Queste interfacce possono essere di due tipi: tunXX, che opera al layer 3 del modello OSI gestendo il traffico IP, o tapXX, che lavora al layer 2 permettendo la trasmissione di frame Ethernet completi, inclusi i protocolli ARP/RARP. Questa architettura consente una gestione flessibile e sicura delle comunicazioni di rete virtualizzate, mantenendo la separazione tra i domini userspace e kernelspace.
Implementazione Linux Bridge in KVM Linux network
1. Verifica e Caricamento Modulo Bridge
# Verifica se il modulo bridge è caricato
lsmod | grep bridge
# Carica il modulo bridge se non presente
modprobe bridge2. Creazione e Configurazione Bridge
# Crea nuovo bridge chiamato 'tester'
brctl addbr tester
# Verifica la creazione del bridge
brctl show
# Abilita Spanning Tree Protocol (STP)
brctl stp br0 on3. Gestione Dispositivi di Rete
# Lista dispositivi collegati al bridge
ip link show tester
# Verifica se il modulo tun/tap è caricato
lsmod | grep tun
# Crea un device tap
ip tuntap add dev vm-tap mode tap
# Verifica la creazione del tap device
ip link show vm-tap4. Gestione Bridge e TAP Device
# Aggiungi tap device al bridge
brctl addif tester vm-tap
# Verifica l'aggiunta del tap device
brctl show
# Rimuovi tap device dal bridge
brctl delif tester vm-tap
# Verifica la rimozione
brctl show tester
# Elimina tap device dal sistema
ip tuntap del dev vm-tap mode tap
# Rimuovi il bridge
brctl delbr tester5. Configurazione Persistente al Riavvio
# Modifica il file interfaces
vim /etc/network/interfaces
# Aggiungi la configurazione:
auto tester
iface tester inet static
bridge_ports vm-tap
bridge_stp on
bridge_fd 0
bridge_maxwait 0
address 192.168.1.1
netmask 255.255.255.0Note
- Lo Spanning Tree Protocol (STP) è essenziale per prevenire loop nella topologia di rete
- I loop si verificano quando esistono percorsi ridondanti tra gli switch
- La configurazione persistente garantisce che il bridge venga ricreato al riavvio del sistema
- Tutti i comandi richiedono privilegi di root (usando sudo)
Open vSwitch e KVM libvirt Linux Network
Open vSwitch è un virtual switch progettato specificamente per ambienti virtualizzati e cloud computing. Offre un livello avanzato di astrazione e controllo del network KVM linux, funzionando come uno switch virtuale con capacità paragonabili agli switch fisici enterprise.
Supporta protocolli di rete avanzati:
- VLAN (Virtual LAN): Permette la segmentazione logica delle reti
- LACP (Link Aggregation Control Protocol): Gestisce l’aggregazione di più collegamenti fisici
- STP (Spanning Tree Protocol): Previene loop di rete in topologie ridondanti
Tra le altre funzionalità chiave: QoS per la gestione della banda, monitoraggio del traffico di rete e supporto per OpenFlow per il networking programmabile.
Installazione e configurazione:
- Installazione su Debian:
sudo apt install openvswitch-switch2. Verifica del servizio:
ovs-vsctl -V
sudo systemctl status openvswitch-switch3. Creazione bridge:
sudo ovs-vsctl add-br nome-bridge-br04. Aggiunta interfaccia a Open vSwitch:
sudo ip addr flush dev eth0
sudo ovs-vsctl add-port nome-bridge-br0 eth05. Attivazione Open vSwitch:
sudo ip addr add 10.10.10.1/24 dev nome-bridge-br0
sudo ip link set dev nome-bridge-br0 up6. Creazione rete virtuale con file .xml:
<network>
<name>ovs-network</name>
<forward mode='bridge'/>
<bridge name='nome-bridge-br0'/>
<virtualport type='openvswitch'/>
</network>sudo virsh net-define file.xml
sudo virsh net-start file.xml
sudo virsh net-autostart file.xml7. Aggiunta della rete Virtuale alle Macchine Virtuali, possiamo usare l’interfaccia GUI di virt-manager
8. Verifica delle porte:
sudo ovs-vsctl list-ports nome-bridge-br0Usare il TAG VLAN in Open vSwitch
Open vSwitch supporta il tagging VLAN attraverso il comando:
sudo ovs-vsctl add-port nome-bridge-br0 eth1 tag=5Questo meccanismo aggiunge un tag numerico (header) ai pacchetti di rete che passano attraverso quella porta, permettendo l’identificazione e l’instradamento del traffico verso la VLAN corrispondente.
I vantaggi principali includono:
- Segmentazione logica: separazione di reti per aree (produzione, sviluppo, test) sulla stessa infrastruttura fisica
- Isolamento traffico: comunicazioni separate tra dipartimenti o gruppi di lavoro
- Sicurezza migliorata: limitazione delle comunicazioni tra segmenti di rete differenti
- Efficienza risorse: gestione di multiple reti virtuali su singole connessioni fisiche, riducendo hardware e costi
SR-IOV (Single Root I/O Virtualization) per KVM Linux Network
SR-IOV (Single Root I/O Virtualization) rappresenta una tecnologia avanzata di virtualizzazione implementata da KVM che consente di partizionare una singola interfaccia PCI fisica in multiple funzioni virtuali (VF). Questa capacità permette di assegnare direttamente le funzioni virtuali alle macchine virtuali, consentendo loro di accedere direttamente all’hardware di rete bypassando completamente il kernel e lo stack di rete dell’host. Il vantaggio principale di questa architettura è la riduzione significativa della latenza, rendendola particolarmente adatta per ambienti enterprise che richiedono performance elevate, come il settore bancario e finanziario dove la latenza di rete è un fattore critico.
Per implementare SR-IOV, è necessario che l’hardware lo supporti nativamente e che sia abilitato nel BIOS del sistema. Per verificare se la propria scheda di rete supporta SR-IOV, è possibile utilizzare questi comandi:
# Prima identificare il bus PCI della scheda di rete
lspci
# Poi verificare il supporto SR-IOV sostituendo XX:XX.X con il bus corretto
lspci -s XX:XX.X -vvv | grep -i SingleSe il comando restituisce informazioni sul supporto SR-IOV, significa che la scheda di rete è compatibile con questa tecnologia.
Configurare SR-IOV per le Macchine Virtuali Linux
L’implementazione di SR-IOV richiede una configurazione accurata del sistema. Ecco i passaggi necessari per configurare correttamente SR-IOV su un server Linux KVM per impostare il network:
1. Identificazione del Driver
Per prima cosa, identificare il driver della scheda di rete:
ethtool -i enp3s0 | grep 'driver'2. Configurazione delle Funzioni Virtuali
Assumendo che il driver sia ‘igc’:
# Verificare le opzioni disponibili
modinfo igc
# Rimuovere il modulo
modprobe -r igc
# Ricaricare il modulo con 4 funzioni virtuali
modprobe igc max_vfs=4
3. Configurazione Permanente del Driver
Creare il file di configurazione per il modulo:
echo "options igc max_vfs=4" > /etc/modprobe.d/igc.conf4. Configurazione del Boot
a. Abilitazione IOMMU
Modificare /etc/default/grub, aggiungendo alla riga GRUB_CMDLINE_LINUX:
# Per CPU AMD
GRUB_CMDLINE_LINUX="... amd_iommu=on igc.max_vfs=4"
# Per CPU Intel
GRUB_CMDLINE_LINUX="... intel_iommu=on igc.max_vfs=4"b. Aggiornamento della Configurazione GRUB
grub2-mkconfig -o /boot/grub2/grub.cfgc. Aggiornamento dei Parametri del Kernel
grubby --update-kernel=ALL --args="amd_iommu=on igc.max_vfs=4"d. Verifica delle Funzioni Virtuali
Dopo il riavvio, verificare la presenza delle VF:
# Usando lspci
lspci -nn | grep "Virtual Function"
# Usando libvirt (sostituire 'xx' con il bus del NIC)
virsh nodedev-list | grep 'xx'5. Configurazione delle Macchine Virtuali
Creare un file XML per la configurazione della VF e applicarlo alla VM:
virsh attach-device macchinaVirtuale file.xml --configMACVTAP modulo KVM Linux Network
MacVTAP è un modulo di interfaccia di rete virtuale implementato nel kernel Linux che si integra perfettamente nell’ecosistema di libvirt network KVM Linux. Questo modulo consente agli utenti di creare una rete virtuale collegata direttamente a un’interfaccia fisica, operando al livello MAC per intercettare e inoltrare i pacchetti di rete.
I vantaggi principali di macvtap includono:
- Performance migliori grazie all’eliminazione del passaggio attraverso il bridge
- Configurazione più semplice rispetto ad altre soluzioni
- Minore utilizzo delle risorse hardware
MacVTAP può operare in quattro modalità distinte:
- VEPA (Virtual Ethernet Port Aggregator)
- Private
- Bridge
- Passthrough
Modalita’ VEPA
La modalità VEPA è quella standard e richiede che lo switch fisico supporti la funzionalità “hairpin”, che permette ai pacchetti di entrare e uscire dalla stessa interfaccia di rete. In questa configurazione, il traffico tra le VM viene instradato attraverso uno switch fisico esterno, rendendolo visibile alla rete fisica.
Modalita’ Private
La modalità Private di macvtap implementa un rigoroso isolamento di rete tra le macchine virtuali. In questa configurazione, tutto il traffico è forzato ad attraversare lo switch fisico esterno, ma con una caratteristica distintiva fondamentale: il traffico diretto tra le VM sulla stessa interfaccia fisica è completamente bloccato.
Questa modalità è particolarmente utile in scenari dove la sicurezza e l’isolamento sono prioritari, come:
- Ambienti multi-tenant dove è necessario garantire la separazione completa tra i diversi clienti
- Implementazione di VLAN private dove ogni macchina virtuale deve operare in totale isolamento
- Ambienti di testing dove si vuole evitare interferenze tra i diversi sistemi virtualizzati
- Infrastrutture cloud dove la segregazione del traffico è un requisito di sicurezza fondamentale
L’isolamento garantito dalla modalità Private fornisce un livello aggiuntivo di sicurezza, impedendo qualsiasi comunicazione diretta non autorizzata tra le macchine virtuali, anche se queste risiedono sullo stesso host fisico.
Modalita’ Bridge
La modalità Bridge di macvtap implementa un approccio ottimizzato alla comunicazione tra macchine virtuali, consentendo una connessione diretta tra le VM che risiedono sullo stesso host fisico attraverso i moduli macvtap. In questa configurazione, il traffico tra le VM locali non necessita di passare attraverso uno switch fisico esterno, creando così un percorso di comunicazione più efficiente.
I vantaggi principali di questa modalità includono:
- Performance ottimizzate per il traffico locale tra VM grazie all’eliminazione del passaggio attraverso l’hardware di rete esterno
- Latenza significativamente ridotta nella comunicazione tra VM locali
- Minore carico sulla rete fisica poiché il traffico locale rimane confinato all’interno dell’host
- Efficienza superiore rispetto a una configurazione bridge tradizionale
Questa modalità è particolarmente efficace in scenari dove le VM necessitano di comunicare frequentemente tra loro e dove le performance di rete sono critiche. Il modulo macvtap in modalità bridge si comporta essenzialmente come uno switch virtuale interno, gestendo il traffico locale in modo più efficiente rispetto alle soluzioni bridge tradizionali.
Modalita’ Passthrough
La modalità Passthrough di macvtap rappresenta la configurazione più diretta e performante, ma anche la più restrittiva che si possa usare in KVM Linux network. In questa modalità, l’interfaccia di rete fisica (NIC) viene dedicata esclusivamente a una singola macchina virtuale, che ottiene il controllo diretto dell’hardware di rete.
Principali casi d’uso:
- Scenari che richiedono le massime prestazioni possibili dalla scheda di rete
- Situazioni dove è necessario l’accesso diretto e completo al NIC
- Ambienti che necessitano di funzionalità hardware specifiche della scheda di rete
Limitazioni significative:
- La NIC fisica può essere utilizzata esclusivamente da una singola VM
- Non è possibile creare altri moduli macvtap sulla stessa interfaccia
- L’host perde completamente l’accesso alla scheda di rete fisica
- Non è possibile condividere la NIC tra più macchine virtuali
Questa modalità rappresenta un compromesso tra prestazioni massime e flessibilità: mentre offre le migliori performance possibili per la VM designata, limita significativamente la versatilità dell’infrastruttura di rete, rendendo l’interfaccia fisica inaccessibile sia all’host che ad altre VM.
[…] Kvm Linux Network: configurare il Networking nella Virtualizzazione […]
[…] Kvm Linux Network: configurare il Networking nella Virtualizzazione […]
[…] Kvm Linux Network: configurare il Networking nella Virtualizzazione […]