web-dev-qa-db-ja.com

tun / tap vs bridge + vnet vs macvtapの違いは何ですか？ （仮想化KVMの場合）

KVMネットワーキングを行うためのさまざまな方法を見つけました。しかし、私はそれを行うための正しい方法は何かにこだわっています。 openstackがmacvtapを使用してneutronネットワーキングを行うことを発見しました。そしてそれはよさそうだ。

しかし、違いは何であり、各方法を使用する理由は何ですか。

方法1 [古い？ TUN/TAP]

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

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

非推奨ですよね？

方法2 [Bridge + Vnet] <-それがvirt-managerのすることです

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

基本的に、物理インターフェイスを内部に持つブリッジインターフェイスを作成し、

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

また、virt-managerから仮想マシンを起動すると、vnetインターフェースが作成され、ブリッジに追加されます。少なくとも私の知るところまで。 tun/tapインターフェイスは必要ありません。

それは長い間非常にうまく機能しましたが、今では生意気で私は問題を見つけました。

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

TAPインターフェイスなしで新しいvnetインターフェイスをブリッジに追加できるのはなぜですか？

方法3 [MACVTAP]

最後はmacvtapインターフェースです。

http://virt.kernelnewbies.org/MacVTap

TUN/TAPソフトウェアインターフェイスをコピーしますが、より良い方法で行います。どのような方法がわからないが、それは良いようです。

2番目の方法に対するmacvtapの利点は何ですか？

何がいいですか？

これに関する助けはありますか？

networkingvirtualization
28
Gonzalo Aguilar Delgado

本当に何を達成したいかによって異なります

  • TAP/TUN

VMまたは物理マシンは関係ありません。 TUNはトンネル化されたネットワークをもたらし、デバイスをTAPします。つまり、トンネル化されたネットワークを経由して別のネットワークに到達します。

たとえば、OpenVPNネットワークを構成すると、クライアントに10.8.0.6が与えられます。 VPNサーバー10.8.0.1は、リクエストを背後の別のネットワーク（192.168.x.xなど）にルーティングします。 TAPを使用する場合、ターゲットネットワーク（192.168.10.x/24）から直接IP（192.168.10.10/24）を受け取ります。シンプル。

  • ブリッジ

「Linux Bridge」は、VNET（VMから）を物理イーサネットにブリッジします。 VM（KVMベース）が必要な場合、ブリッジはホスト上のvnetとイーサネットの間で必須です

4
j3ffyang

ユースケースに依存すると思います。

仮想ホストの自動追加/削除？

Macvtapを試してみてください。 Shouldまた、macvtapがネットワークスタックをバイパスし、タップキャラクターデバイスを直接エクスポートします。しかし、それに私を釘付けしないでください。両方（macvlan/macvtap）が同じ利用可能なモード（VEPA /ヘアピン、ブリッジング、プライベート）を共有することに加えて、スイッチが反射リレーモードをサポートしている場合にのみヘアピニングが機能します。 （ポートxの物理スイッチに到着したパケットは、同じポートxで再びスイッチを離れることができなければなりません。）

Eth0（または使用する方）はブリッジを使用すると無差別モードになるため、macvXXXモードはスループットが高いと言われています。

モードは分離の「量」も定義します（vhostはお互いのトラフィックを見ることができますか？hvはどうですか？）。これが内部でどのように機能するかはまだわかりません。

veth（仮想イーサネットペア）は分離に関して多少似ています。2つの仮想インターフェイスを定義します。1つはブリッジに接続され、もう1つはVMに接続されます。そこで、vm-interfaceを独自の名前空間に配置することで分離が行われるため、デバイスはある程度分離されます。すべてのトラフィックはブリッジでまとめられますが、ある仮想ホストは別の仮想ホストを見ることができません。

ブリッジを使用する場合、追加の設定が必要です。ブリッジがダウンすると、すべての接続もダウンします。ブリッジを再起動するとき、すべての仮想インターフェイスをブリッジに再接続する必要があります（または、完全なhv ...を再起動するだけです）。

結論：トポロジを頻繁に変更しない場合は、オンラインで最も多くの情報を見つけるので、ブリッジングを行ってください。カーネルコードを読むよりも優れています。ちなみに、iproute2-docパッケージ自体でさえ、bleeding-Edgeバージョンを実行していても、iproute2が実際に持っている情報のほとんどが欠けています。利用可能なマンページまたはip-crefs.psからman ip-tcp_metricsについて調べてみてください...

2
sjas