Acabei de encontrar várias maneiras diferentes de criar redes KVM. Mas eu estou preso sobre o que é o caminho certo para fazê-lo. Descobri que o openstack usa o macvtap para criar redes de nêutrons. E parece bom.
Mas qual é a diferença e por que usar cada caminho.
Caminho 1 [VELHO? TUN / TAP]
http://www.shakthimaan.com/installs/debian-tun-tap-setup.html
/--------\ /----\ /----\ /----\ /--------\
|Internet|---|eth0|---|br0 |---|tap0|---|Guest NIC
\--------/ \----/ \----/ \----/ \--------/
Preterido, certo?
Caminho 2 [Bridge + Vnet] <- É isso que o virt-manager faz
http://www.linux-kvm.com/content/using-bridged-networking-virt-manager
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 por um longo tempo, mas agora com atrevido eu encontrei problemas.
https://bugs.launchpad.net/ubuntu/+source/core-network/+bug/1255516
Por que você pode adicionar uma nova interface vnet à ponte sem a interface TAP?
Caminho 3 [MACVTAP]
Última é a interface macvtap.
http://virt.kernelnewbies.org/MacVTap
Ele copia a interface do software TUN / TAP, mas funciona de maneira melhor. Não sei de que maneira, mas parece ser melhor.
Qual é a vantagem do macvtap na segunda maneira?
O que é melhor?
Alguma ajuda nisso?
fonte
Eu diria que depende do seu caso de uso.
Adições / exclusões automatizadas de hosts virtuais?
Experimente o macvtap. Também deve ter um desempenho superior ao macvlan (que é mais ou menos como adicionar outro MAC a um dispositivo físico, as informações que chegam são manipuladas pela pilha de rede) ou uma ponte adicional, pois o macvtap ignora a pilha de rede de alguma forma e exporta diretamente um dispositivo de caractere de toque. Mas não me preste atenção nisso. Além de ambos (macvlan / macvtap) compartilharem os mesmos modos disponíveis (VEPA / hairpin, bridging, private), o hairpinning funcionará apenas se o seu switch suportar o modo de retransmissão reflexiva. (Os pacotes que chegam ao comutador físico na porta x devem ter permissão para deixar o comutador novamente na mesma porta x.)
Como o eth0 (ou o que você usar) é colocado no modo promíscuo ao usar uma ponte, diz-se que os modos macvXXX têm taxas de transferência mais altas.
Os modos também definem a 'quantidade' de isolamento (os fantasmas podem ver o tráfego um do outro? E quanto ao hv?). Ainda não sei como isso funciona.
Os veth (pares virtuais de ethernet) são um pouco semelhantes para isolamento, você define duas interfaces virtuais, uma é conectada a uma ponte e a outra à sua VM. Lá, o isolamento é feito colocando a interface vm em seu próprio espaço para nome, para que os dispositivos fiquem um pouco isolados. Todo o tráfego se reúne na ponte, mas um host não pode ver os vNICs de outro.
Caso você trabalhe com uma ponte, você terá uma configuração adicional a fazer e, quando a ponte estiver inoperante, todas as suas conexões também serão. Ao trazer a ponte de volta, talvez seja necessário reconectar todas as interfaces virtuais à ponte novamente (ou apenas reiniciar o hv completo ...).
Conclusão: se você não alterar sua topologia com frequência, basta usar a ponte, pois você encontra mais informações online on-line, o que é melhor do que ler o código do kernel. Heck, mesmo o pacote iproute2-doc não possui a maioria das informações que o iproute2 realmente possui, mesmo quando você executa versões de ponta. Tente descobrir sobre
man ip-tcp_metricsas páginas de manual disponíveis ou ip-crefs.ps ...fonte
Esses métodos estão fazendo coisas fundamentalmente diferentes. Para entender o porquê, você precisa entender o modelo em camadas de rede. Para nossos propósitos aqui, as camadas 1, 2 e 3 são importantes:
MACVLAN / MACVTAP
O MACVLAN cria um dispositivo de camada virtual 2 ou de camada de link, com seu próprio endereço MAC, que compartilha a camada 1 ou física com um dispositivo existente. O caso mais obviamente compreensível é quando você tem um dispositivo Ethernet conectado a uma rede e cria um dispositivo MACVLAN com base nesse dispositivo Ethernet; agora você tem dois "dispositivos" Ethernet com endereços MAC diferentes, mas que transmitem seus quadros no mesmo cabo. Vou falar um pouco mais sobre o MACVTAP.
As interfaces MACVLAN podem interagir de várias maneiras diferentes com a interface Ethernet existente, principalmente quando um quadro aparece em uma das interfaces que é endereçada à outra:
Observe que as interfaces MACVLAN têm uma restrição importante: elas não são capazes de aprender sobre endereços. Portanto, você não pode conectar uma interface MACVLAN a um segundo dispositivo físico e espera poder alcançar esse segundo dispositivo físico pelo primeiro. Isso funciona com a interface Ethernet original, mas não com uma interface MACVLAN conectada a ela.
TUN / TAP
Uma interface TAP também é um novo dispositivo virtual da camada 2, mas sem a camada 1 anexada. Em vez disso, um programa pode obter um descritor de arquivo representando a camada física. Ele pode gravar dados brutos do quadro Ethernet nesse descritor de arquivo e o kernel os tratará como qualquer outro pacote Ethernet que receber em uma interface física real.
O grande problema das interfaces TAP é que a camada física está no modo de usuário; qualquer software com as permissões apropriadas pode gerar quadros Ethernet da maneira que desejar e transformá-los em algo que o kernel trata da mesma forma que uma interface física real. Isso os torna muito úteis para coisas como VPNs e encapsulamento; você pode escrever qualquer tipo de software de encapsulamento que desejar no espaço do usuário e não há necessidade de se intrometer no espaço do kernel para colocar os quadros na pilha de rede, basta criar um dispositivo TAP e gravar os quadros no seu descritor de arquivo.
Os dispositivos TUN são exatamente como os dispositivos TAP, exceto que operam na camada 3, em vez da camada 2, e o software no modo de usuário precisa gravar pacotes IP brutos no descritor de arquivo em vez de quadros Ethernet brutos.
Voltando aos dispositivos MACVTAP , essas são uma espécie de confusão entre as interfaces MACVLAN e TAP. Como as interfaces TAP, um programa no modo usuário pode obter um descritor de arquivo e gravar quadros Ethernet brutos nele. Como uma interface MACVLAN, esses quadros são enviados pela camada física de um dispositivo Ethernet real. Isso permite que você adapte facilmente o software que foi escrito para usar dispositivos TAP para usar um dispositivo MACVLAN.
VNet
Isso é conceitualmente semelhante à rede TUN / TAP, mas possui um plano de controle mais desenvolvido (para que o software no modo usuário possa configurar a interface com mais flexibilidade) e um plano de dados mais otimizado (para que você possa mover mais os dados pelo dispositivo de rede virtual) eficientemente).
Tudo isso faz coisas semelhantes, mas tem recursos ligeiramente diferentes. Todos eles podem ser usados para conectar uma VM a uma rede Ethernet:
fonte