vm-host2つのqemu-kvm仮想マシンを実行する仮想マシンホスト（）があります。蛇口モデル。これは、ネットワークトポロジが次のようになることを意味します。
VLAN 123を介して管理する必要があるため、vm-host3つのアプローチがあります。
eth0.123インターフェイスを作成し、管理vm-hostIPを次のように設定します。eth0.123eth0.123との間にブリッジを作成し、br0管理IPを次のように設定します。br0- タグ123に送信する前に、管理IPを直接設定し、
eth0管理トラフィック用のVLANを削除するようにvm-host設定しました。r1vm-host
他のデザインよりも確かに良いデザインがありますか？ 3番目のデザインオプションが視点で最高だと思います。vm-hostサーバーは最初の2つのオプションのようにVLANタグを表示する必要はなく、管理トラフィックフレームは最初の2つのオプションのようにbr0Linuxスイッチを通過しないためです。 。 2番目のオプション。つまり、これが最も簡単なデザインオプションのようです。 2番目のオプションは、Linuxブリッジを介してトラフィックをルーティングする利点がないため、最悪のオプションのようです。
ベストアンサー1
ボックスに複数のVLAN（同じインターフェイス上にある）がある場合は、すべてタグを付けます。 （たとえば、2つはタグ付けされ、1つはタグ付けされていない代わりに）これにより、問題のVLANが何であるかが明確になるため、後で設定を簡単に把握できます。とにかく、ボックスはVLANタグを処理する必要があり、ボトルネックは発生しません（IP / TCP / SSH /何かを解析するのと比較して）。
また、管理VLANをどのデバイスにもブリッジする必要がない場合は、それをブリッジに配置する必要はありません。ブリッジを作成しないことは、問題のVLANが仮想マシンには適用されず、ホスト自体に適用されるという明確な表示です。 （VLANごとのブリッジを想定します。）
だからこれらの選択の中で私はeth0.123に管理を任せました。
一方、独立したNIC全体を管理専用として使用できます。クリーンで分離された状態を維持することに加えて、管理トラフィックと仮想マシンが同じ帯域幅で競合しないという利点もあります。仮想マシンネットワークの極端なトラフィックも、管理アクセスを直接圧倒することはできません。 （もちろん、箱自体とスイッチがそれに従うことができると仮定しています。）
（これらのいずれかを実行するのに「難しい」理由があるかどうかはわかりません。あなたが言ったように、いくつかの方法があり、個人的な好みに応じて変わることがあります。わからない場合は、最も簡単な方法を使用してください。）