Qual è la differenza tra tun / tap vs bridge + vnet vs macvtap? (Per virtualizzazione KVM)


28

Ho appena trovato molti modi diversi per fare rete KVM. Ma sono bloccato su qual è il modo giusto per farlo. Ho scoperto che openstack utilizza macvtap per creare reti di neutroni. E sembra buono.

Ma qual è la differenza e perché usare ogni modo.

Modo 1 [VECCHIO? TUN / TAP]

http://www.shakthimaan.com/installs/debian-tun-tap-setup.html

/--------\   /----\   /----\   /----\   /--------\
|Internet|---|eth0|---|br0 |---|tap0|---|Guest NIC
\--------/   \----/   \----/   \----/   \--------/

Obsoleto, vero?

Way 2 [Bridge + Vnet] <- Questo è ciò che fa virt-manager

http://www.linux-kvm.com/content/using-bridged-networking-virt-manager

Fondamentalmente crei un'interfaccia bridge con la tua interfaccia fisica all'interno e

auto br0
#iface br0 inet dhcp
iface br0 inet static
address 172.16.0.100
network 172.16.0.0
netmask 255.255.0.0
broadcast 172.16.255.255
gateway 172.16.0.1
   bridge_ports eth2
   bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

E quando si avvia una macchina virtuale da virt-manager viene creata e aggiunta un'interfaccia vnet al bridge. Almeno fino a dove non lo so. Non è necessaria alcuna interfaccia tun / tap.

Ha funzionato abbastanza bene per molto tempo ma ora con impertinente ho riscontrato problemi.

https://bugs.launchpad.net/ubuntu/+source/core-network/+bug/1255516

Perché è possibile aggiungere una nuova interfaccia vnet al bridge senza l'interfaccia TAP?

Way 3 [MACVTAP]

L'ultima è l'interfaccia macvtap.

http://virt.kernelnewbies.org/MacVTap

Copia l'interfaccia del software TUN / TAP ma lo fa in modo migliore. Non so in che modo, ma sembra essere migliore.

Qual è il vantaggio di macvtap rispetto al secondo modo?

Cosa c'è di meglio?

Qualche aiuto su questo?

Risposte:


4

Dipende davvero da cosa esattamente vuoi ottenere

  • TAP / TUN

Non importa che sia una macchina virtuale o fisica. TUN ti offre una rete con tunnel e TAP un dispositivo. In breve, si passa attraverso una rete con tunnel per raggiungere un'altra rete.

Ad esempio, quando si configura una rete OpenVPN, si riceverà 10.8.0.6 sul client. Il server VPN 10.8.0.1 instrada la tua richiesta a un'altra rete (ad esempio 192.168.xx). Quando si utilizza TAP, si riceve un IP (192.168.10.10/24) direttamente dalla propria rete di destinazione (192.168.10.x / 24). Semplice.

  • ponte

"Linux Bridge" collega la rete virtuale (da VM) a Ethernet fisica. Se si desidera una VM (basata su KVM), il bridge è un must tra vnet ed Ethernet sull'host


MMmmm. Grazie per la risposta, ma in realtà non risolve i miei dubbi. Se vedi i link scoprirai che ci sono più motivi per usarne uno o l'altro. In effetti il ​​bridging ora non funziona bene sullo stack Linux corrente per VM. Quindi ho dovuto usare MACVTAP.
Gonzalo Aguilar Delgado,

2

Direi che dipende dal tuo caso d'uso.

Aggiunte / eliminazioni automatizzate di host virtuali?

Prova macvtap. Dovrebbe anche essere più performante di macvlan (che è più o meno come aggiungere un altro MAC a un dispositivo fisico, le informazioni che arrivano lì sono gestite dallo stack di rete) o un ponte aggiuntivo, poiché macvtap bypassa lo stack di rete in qualche modo ed esporta direttamente un dispositivo con caratteri di tocco. Ma non mi inchiodare su quello. Inoltre entrambi (macvlan / macvtap) condividono le stesse modalità disponibili (VEPA / tornante, ponte, privato), il tornante funziona solo se lo switch supporta la modalità relè riflettente. (I pacchetti che arrivano allo switch fisico sulla porta x devono poter lasciare di nuovo lo switch sulla stessa porta x.)

Poiché eth0 (o quello che usi) viene messo in modalità promiscua quando si utilizza un bridge, si dice che le modalità macvXXX abbiano un throughput più elevato.

Le modalità definiscono anche la 'quantità' di isolamento (i vhosts possono vedere ogni altro traffico? Che ne dici dell'hv?). Come funziona sotto il cofano non lo so ancora.

I veth (coppie ethernet virtuali) sono in qualche modo simili per l'isolamento, si definiscono due interfacce virtuali, una si collega a un bridge, l'altra alla propria VM. Lì l'isolamento viene eseguito inserendo l'interfaccia vm nel suo spazio dei nomi in modo che i dispositivi siano in qualche modo isolati. Tutto il traffico arriva sul ponte, ma un vhost non può vedere le vNIC di un altro.

Nel caso in cui lavori con un bridge, hai una configurazione aggiuntiva da fare, e quando il bridge è inattivo, lo sono anche tutte le tue connessioni. Quando si ripristina il bridge, potrebbe essere necessario ricollegare tutte le interfacce virtuali al bridge (o semplicemente riavviare l'hv completo ...).

In conclusione: se non cambi spesso la tua topologia, procedi con il bridging poiché trovi la maggior parte delle informazioni su di essa online, il che è meglio che leggere il codice del kernel. Diamine, anche il pacchetto iproute2-doc stesso manca della maggior parte delle informazioni che iproute2 ha effettivamente, anche quando si eseguono versioni all'avanguardia. Prova a scoprire man ip-tcp_metricsdalle manpage disponibili o ip-crefs.ps ...


Non ricordo nemmeno di aver scritto questo, tanto meno dove ho trovato tutte quelle informazioni. :(
sjas,

0

Questi metodi stanno facendo cose sostanzialmente diverse. Per capire perché, è necessario comprendere il modello a più livelli di rete. Per i nostri scopi qui, i livelli 1, 2 e 3 sono importanti:

  • Il livello 1 è il livello fisico: specifica cose come i cavi che è possibile utilizzare, quali schemi di tensione / corrente rappresentano 1 e 0 su quel cavo, in che modo i dispositivi alle estremità di un cavo negoziano la velocità di trasmissione in cui operano e così via.
  • Il livello 2 è il livello del collegamento: questo specifica quali lingue gli elementi alle estremità di un cavo comunicano tra loro. I dispositivi Ethernet a questo livello hanno elementi come frame e indirizzi MAC.
  • Il livello 3 è il livello di rete: specifica come i dispositivi utilizzano un collegamento di livello 2 diretto a un altro dispositivo per raggiungere un terzo dispositivo che non possono raggiungere direttamente al livello 2. I dispositivi in ​​questo livello hanno indirizzi IP e tabelle di routing.

MACVLAN / MACVTAP

MACVLAN crea un dispositivo di livello 2 o link virtuale, con un proprio indirizzo MAC, che condivide il livello 1 o il livello fisico con un dispositivo esistente. Il caso più evidentemente comprensibile è quando si dispone di un dispositivo Ethernet collegato a una rete e si crea un dispositivo MACVLAN basato su quel dispositivo Ethernet; ora hai due "dispositivi" Ethernet con indirizzi MAC diversi ma che trasmettono entrambi i loro frame sullo stesso cavo. Parlerò di MACVTAP un po 'più in basso.

Le interfacce MACVLAN possono interagire in diversi modi con l'interfaccia Ethernet esistente, in particolare quando appare una trama su una delle interfacce che è indirizzata all'altra:

  • In modalità privata , il frame viene gettato via; non è possibile che le due interfacce comunichino tra loro, solo con dispositivi esterni.
  • In modalità vepa , il frame viene inviato sul livello fisico come qualsiasi altro frame. Se il dispositivo è collegato a uno switch abbastanza intelligente da individuare che il frame deve essere rispedito giù dalla stessa porta su cui è arrivato, allora verrà ricevuto dallo stesso layer fisico che lo ha inviato e quindi il layer 2 utilizzare il MAC per inviarlo all'interfaccia di rete desiderata.
  • In modalità bridge , quando un frame appare su un dispositivo, viene controllato per vedere se è destinato all'altro e, in tal caso, viene inviato lì senza passare attraverso il layer 1.
  • Ci sono anche un paio di modalità più oscure.

Si noti che le interfacce MACVLAN hanno un'importante limitazione: non sono in grado di indirizzare l'apprendimento. Quindi non è possibile collegare un'interfaccia MACVLAN a un secondo dispositivo fisico e aspettarsi di essere in grado di raggiungere quel secondo dispositivo fisico sul primo. Funziona con l'interfaccia Ethernet originale ma non con un'interfaccia MACVLAN ad essa collegata.

TUN / TAP

Un'interfaccia TAP è anche un nuovo dispositivo di livello 2 virtuale ma senza livello 1 collegato. Invece, un programma può ottenere un descrittore di file che rappresenta il livello fisico. Può quindi scrivere dati di frame Ethernet grezzi in quel descrittore di file e il kernel li tratterà come qualsiasi altro pacchetto Ethernet che riceve su una vera interfaccia fisica.

La cosa importante delle interfacce TAP è che il livello fisico è in modalità utente; qualsiasi bit di software con le autorizzazioni appropriate può generare frame Ethernet nel modo che preferisce e inserirli in qualcosa che il kernel considera lo stesso di una vera interfaccia fisica. Questo li rende molto utili per cose come VPN e tunneling; puoi scrivere qualunque tipo di software di tunneling ti piaccia nello spazio utente e non c'è bisogno di immischiarsi nello spazio del kernel per inserire i frame nello stack di rete, basta creare un dispositivo TAP e scrivere i frame nel suo descrittore di file.

I dispositivi TUN sono esattamente come i dispositivi TAP, tranne per il fatto che operano al livello 3 anziché al livello 2 e il software in modalità utente deve scrivere pacchetti IP grezzi nel descrittore di file anziché in frame Ethernet grezzi.

Tornando ai dispositivi MACVTAP , si tratta di una sorta di confusione tra le interfacce MACVLAN e TAP. Come le interfacce TAP, un programma in modalità utente può ottenere un descrittore di file e scrivere in esso frame Ethernet grezzi. Come un'interfaccia MACVLAN, questi frame vengono quindi inviati sul livello fisico di un dispositivo Ethernet reale. Ciò consente di adattare facilmente il software scritto per utilizzare i dispositivi TAP per utilizzare invece un dispositivo MACVLAN.

VNET

Questo è concettualmente simile alla rete TUN / TAP ma ha un piano di controllo più sviluppato (quindi il software in modalità utente che lo utilizza può configurare l'interfaccia in modo più flessibile) e un piano dati più ottimizzato (in modo da poter spostare i dati attraverso il dispositivo di rete virtuale più in modo efficiente).

Tutti questi fanno cose simili ma hanno capacità leggermente diverse. Tutti possono essere utilizzati per connettere una VM a una rete Ethernet:

  • Un prodotto di virtualizzazione può prendere frame Ethernet dal guest e scriverli nel descrittore di file per un dispositivo TAP. A quel dispositivo TAP può essere assegnato il proprio indirizzo IP dall'host, oppure può essere asservito a un bridge insieme a un'interfaccia Ethernet per condividere l'indirizzo IP dell'host, oppure iptables può essere configurato per inoltrare il traffico su di esso utilizzando NAT.
  • Un prodotto di virtualizzazione può quel frame Ethernet dal guest e scriverli nel descrittore di file per un dispositivo MACVTAP; questi vengono poi trasmessi direttamente sul livello fisico di un dispositivo Ethernet, dando alla VM un dispositivo Ethernet "reale" (sebbene si noti che è possibile creare dispositivi MACVLAN / MACVTAP per altri tipi di interfacce di rete come i bridge).
  • Un prodotto di virtualizzazione può connettere un driver virtio nel guest al driver virtio nell'host per un networking molto efficiente.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.