Qual é a diferença entre tun / tap vs bridge + vnet vs macvtap? (Para virtualização KVM)

Question

Acabei de encontrar muitas maneiras diferentes de fazer redes KVM. Mas eu estou preso sobre qual é o jeito certo de fazer isso. Eu descobri que o openstack usa o macvtap para fazer redes de nêutrons. E parece bom.

Mas qual é a diferença e por que usar cada um deles?

Caminho 1 [OLD? TUN / TAP]

link

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

Depreciado, certo?

Caminho 2 [Bridge + Vnet] < - Isso é o que o virt-manager faz

link

Basicamente, você cria uma interface de ponte com sua interface física dentro 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 você inicia uma máquina virtual a partir do virt-manager, uma interface vnet é criada e adicionada à ponte. Pelo menos até onde eu sei. Nenhuma interface tun / tap é necessária.

Funcionou muito bem durante muito tempo mas agora com atrevimento encontrei problemas.

link

Por que você pode adicionar uma nova interface vnet à ponte sem a interface TAP?

Caminho 3 [MACVTAP]

A última é a interface do macvtap.

link

Copia a interface do software TUN / TAP, mas funciona melhor. Não sei o que, mas parece ser melhor.

Qual é a vantagem do macvtap na segunda maneira?

O que é melhor?

Qualquer ajuda sobre isso?

    

Answer 1

Depende realmente do que exatamente você deseja alcançar

• TAP / TUN

Não importa a VM ou a máquina física. TUN traz para você uma rede de túnel e TAP um dispositivo. Em suma, você passa por uma rede encapsulada para alcançar outra rede.

Por exemplo, ao configurar uma rede OpenVPN, você receberá 10.8.0.6 em seu cliente. O servidor VPN 10.8.0.1 direciona sua solicitação para outra rede (por exemplo, 192.168.x.x) para trás. Ao usar o TAP, você receberia um IP (192.168.10.10/24) diretamente da sua rede de destino (192.168.10.x / 24). Simples.

• Ponte

"Linux Bridge" conecta o VNET (da VM) à Ethernet física. Se você quer uma VM (baseada em KVM), bridge é uma obrigação entre vnet e ethernet no host

    

Answer 2

Eu diria que isso depende do seu caso de uso.

Adições / exclusões automatizadas de hosts virtuais?

Experimente o macvtap. Deve ser também performático do que o macvlan (que é mais ou menos como adicionar outro MAC a um dispositivo físico, informações recebidas pela pilha de rede) ou uma ponte adicional, pois o macvtap ignora a pilha de rede de alguma forma e exporta um dispositivo de caractere de toque diretamente. Mas não me pregue nisso. Além de ambos (macvlan / macvtap) compartilharem os mesmos modos disponíveis (VEPA / hairpin, bridging, private), o hairpinning só funciona se o seu switch suportar o modo de relé reflexivo. (Os pacotes que chegam ao comutador físico na porta x devem poder deixar o comutador novamente na mesma porta x.)

Como o eth0 (ou o que você usa) é colocado em modo promíscuo quando usa uma ponte, os modos macvXXX têm maiores taxas de transferência.

Os modos também definem a 'quantidade' de isolamento (os vhosts podem ver o tráfego uns dos outros? E quanto ao hv?). Como isso funciona sob o capô eu ainda não sei.

veth's (pares de ethernet virtuais) são um pouco semelhantes para isolamento, você define duas interfaces virtuais, uma fica conectada a uma ponte, a outra para sua VM. Lá, o isolamento é feito colocando a interface vm em seu próprio namespace, de modo que os dispositivos estejam um pouco isolados. Todo o tráfego se reúne na ponte, mas um vhost não pode ver os vNICs de outro.

Caso você trabalhe com uma ponte, você tem configuração adicional para fazer e, quando a ponte está inativa, todas as suas conexões também estão. Ao trazer a ponte de volta, você pode ter que reconectar todas as interfaces virtuais para a ponte novamente (ou apenas reiniciar o hv completo ...).

Linha de fundo: Se você não alterar sua topologia com frequência, basta fazer a ponte enquanto encontra mais informações on-line on-line, o que é melhor do que ler o código do kernel. Heck, mesmo o pacote iproute2-doc em si não tem a maioria das informações que o iproute2 realmente possui, mesmo quando você executa versões de ponta. Tente descobrir sobre man ip-tcp_metrics nas páginas de manual disponíveis ou ip-crefs.ps ...