Je viens de découvrir de nombreuses façons différentes de mettre en réseau KVM. Mais je ne sais pas quelle est la bonne façon de le faire. J'ai découvert que openstack utilise macvtap pour faire du réseautage neutronique. Et ça a l'air bien.
Mais quelle est la différence et pourquoi utiliser dans chaque sens.
Voie 1 [VIEUX? TUN / TAP]
http://www.shakthimaan.com/installs/debian-tun-tap-setup.html
/--------\ /----\ /----\ /----\ /--------\
|Internet|---|eth0|---|br0 |---|tap0|---|Guest NIC
\--------/ \----/ \----/ \----/ \--------/
Obsolète, non?
Way 2 [Bridge + Vnet] <- C'est ce que fait virt-manager
http://www.linux-kvm.com/content/using-bridged-networking-virt-manager
Fondamentalement, vous créez une interface de pont avec votre interface physique à l'intérieur et
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
Et lorsque vous démarrez une machine virtuelle à partir de virt-manager, une interface vnet est créée et ajoutée au pont. Du moins jusqu'à ce que je sache. Aucune interface tun / tap n'est nécessaire.
Cela a très bien fonctionné pendant une longue période, mais maintenant, avec des notes impertinentes, j'ai trouvé des problèmes.
https://bugs.launchpad.net/ubuntu/+source/core-network/+bug/1255516
Pourquoi pouvez-vous ajouter une nouvelle interface vnet au pont sans l'interface TAP?
Voie 3 [MACVTAP]
Le dernier est l'interface macvtap.
http://virt.kernelnewbies.org/MacVTap
Il copie l'interface du logiciel TUN / TAP mais il le fait d'une meilleure façon. Je ne sais pas comment, mais ça semble être mieux.
Quel est l'avantage de macvtap par rapport à la deuxième méthode?
Ce qui est mieux?
Une aide à ce sujet?
la source
Je dirais que cela dépend de votre cas d'utilisation.
Ajout / suppression automatisés d'hôtes virtuels?
Essayez macvtap. Devrait également être plus performant que macvlan (ce qui revient à peu près à ajouter un autre MAC à un périphérique physique, les informations qui y arrivent sont gérées par la pile réseau) ou un pont supplémentaire, car macvtap contourne la pile réseau d'une manière ou d'une autre et exporte directement un périphérique à caractère tactile. Mais ne me clouez pas là-dessus. En outre, les deux (macvlan / macvtap) partagent les mêmes modes disponibles (VEPA / épingle à cheveux, pontage, privé), l'épingle à cheveux ne fonctionne que si votre commutateur prend en charge le mode relais réfléchissant. (Les paquets arrivant au commutateur physique sur le port x doivent être autorisés à quitter le commutateur à nouveau sur le même port x.)
Étant donné que le eth0 (ou celui que vous utilisez) est mis en mode promiscuous lors de l'utilisation d'un pont, les modes macvXXX auraient des débits plus élevés.
Les modes définissent également la «quantité» d'isolement (les vhosts peuvent-ils voir le trafic les uns des autres? Que diriez-vous du hv?). Comment cela fonctionne sous le capot, je ne sais pas encore.
Les veth (paires Ethernet virtuelles) sont quelque peu similaires pour l'isolement, vous définissez deux interfaces virtuelles, l'une est attachée à un pont, l'autre à votre VM. Là, l'isolement se fait en plaçant l'interface vm dans son propre espace de noms afin que les périphériques soient quelque peu isolés. Tout le trafic se rassemble au pont, mais un vhost ne peut pas voir les vNIC d'un autre.
Dans le cas où vous travaillez avec un pont, vous avez une configuration supplémentaire à faire, et lorsque le pont est en panne, il en va de même pour toutes vos connexions. Lorsque vous remettez le pont en place, vous devrez peut-être reconnecter toutes les interfaces virtuelles au pont (ou simplement redémarrer le HV complet ...).
Bottom line: Si vous ne changez pas souvent votre topologie, optez simplement pour le pontage car vous trouvez le plus d'informations en ligne, ce qui est mieux que de lire le code du noyau. Heck, même le package iproute2-doc lui-même manque la plupart des informations dont iproute2 dispose réellement, même lorsque vous exécutez des versions de pointe. Essayez de vous renseigner sur
man ip-tcp_metricsles pages de manuel disponibles ou sur ip-crefs.ps ...la source
Ces méthodes font des choses fondamentalement différentes. Pour comprendre pourquoi, vous devez comprendre le modèle de réseautage en couches. Pour nos besoins ici, les couches 1, 2 et 3 sont importantes:
MACVLAN / MACVTAP
MACVLAN crée un périphérique virtuel de couche 2 ou de couche liaison, avec sa propre adresse MAC, qui partage la couche 1 ou la couche physique avec un périphérique existant. Le cas le plus compréhensible est celui où vous avez un périphérique Ethernet branché sur un réseau et où vous créez un périphérique MACVLAN basé sur ce périphérique Ethernet; vous avez maintenant deux "périphériques" Ethernet avec des adresses MAC différentes mais qui transmettent tous les deux leurs trames sur le même câble. Je parlerai de MACVTAP un peu plus loin.
Les interfaces MACVLAN peuvent interagir de plusieurs manières différentes avec l'interface Ethernet existante, notamment lorsqu'une trame apparaît sur l'une des interfaces qui est adressée à l'autre:
Notez que les interfaces MACVLAN ont une restriction importante: elles ne sont pas capables d'apprendre l'adresse. Vous ne pouvez donc pas relier une interface MACVLAN à un deuxième périphérique physique et vous attendre à pouvoir atteindre ce deuxième périphérique physique par-dessus le premier. Cela fonctionne avec l'interface Ethernet d'origine mais pas avec une interface MACVLAN qui lui est attachée.
TUN / TAP
Une interface TAP est également un nouveau périphérique virtuel de couche 2 mais sans couche 1 qui lui est attachée. Au lieu de cela, un programme peut obtenir un descripteur de fichier représentant la couche physique. Il peut ensuite écrire des données de trame Ethernet brutes dans ce descripteur de fichier et le noyau les traitera comme tout autre paquet Ethernet qu'il reçoit sur une véritable interface physique.
La grande chose au sujet des interfaces TAP est que la couche physique est en mode utilisateur; n'importe quel logiciel avec les autorisations appropriées peut générer des trames Ethernet comme bon lui semble et les insérer dans quelque chose que le noyau traite de la même manière qu'une véritable interface physique. Cela les rend très utiles pour des choses comme les VPN et le tunneling; vous pouvez écrire n'importe quel type de logiciel de tunneling que vous aimez dans l'espace utilisateur et il n'est pas nécessaire de se mêler de l'espace du noyau pour obtenir les trames dans la pile réseau, il vous suffit de créer un périphérique TAP et d'écrire les trames dans son descripteur de fichier.
Les périphériques TUN sont exactement comme les périphériques TAP, sauf qu'ils fonctionnent sur la couche 3 au lieu de la couche 2 et que le logiciel en mode utilisateur doit écrire des paquets IP bruts dans le descripteur de fichier au lieu de trames Ethernet brutes.
Pour en revenir aux périphériques MACVTAP , il s'agit d'une sorte de confusion entre les interfaces MACVLAN et TAP. Comme les interfaces TAP, un programme en mode utilisateur peut obtenir un descripteur de fichier et y écrire des trames Ethernet brutes. Comme une interface MACVLAN, ces trames sont ensuite envoyées sur la couche physique d'un véritable périphérique Ethernet. Cela vous permet d'adapter facilement un logiciel écrit pour utiliser des appareils TAP pour utiliser un appareil MACVLAN à la place.
VNet
Ceci est conceptuellement similaire à la mise en réseau TUN / TAP mais a un plan de contrôle plus développé (de sorte que le logiciel en mode utilisateur l'utilisant peut configurer l'interface de manière plus flexible) et un plan de données plus optimisé (afin que vous puissiez déplacer les données via le périphérique réseau virtuel plus efficacement).
Tous ces éléments font des choses similaires mais ont des capacités légèrement différentes. Tous peuvent être utilisés pour connecter une machine virtuelle à un réseau Ethernet:
la source