| | 54 | > mittyorz: @m_asama @_syuu1228 パケット送り先の判断をスイッチにオフロード出来るから、ということなのですかね…。対応しているスイッチが少ない状況ではあまり嬉しくないように思えますけれど。 |
| | 55 | > syuu1228: @mittyorz @m_asama VEPAモードじゃなくてbridgeモードでもホストと通信できないんでしたっけ？ |
| | 56 | > syuu1228: @mittyorz @m_asama なんとなくだけど、その状況ってVEPAモードで対応スイッチがあればヘアピンされて通信出来るような気がしなくもないのだけれど。どうなんだろ。 |
| | 57 | > m_asama: @syuu1228 @mittyorz いや、 bridge ならいけると思ってましたけど、試してはないです。 |
| | 58 | > syuu1228: @m_asama @mittyorz ちょっと理解し難いですね。むしろmacvtapの位置付けがVEPA対応用な感じなんだろうか？？ |
| | 59 | > syuu1228: @m_asama @mittyorz あるいはアレかな、VEPAモードでヘアピンオフだとルータとはスイッチを経由して喋れるけど、同一ノードの別VMやホストとは通信出来ない状態になるとかで、それを意図してるのかな |
| | 60 | > m_asama: @syuu1228 @mittyorz macvlan/macvtap は zero copy のためのものなんじゃないですかね。 legacy bridge や Open vSwitch では zero copy 実現不可能とおもわれるので。 |
| | 61 | > syuu1228: @m_asama @mittyorz だと思うんだけども、ならなんでこういうデフォルト値になってんだろなー…と |
| | 62 | > m_asama: @syuu1228 @mittyorz それは謎w たぶん最初は vepa しかなくて後から bridge 追加したので最初からあった vepa がデフォルトになってるとかそんな理由なのかも。 |
| | 63 | > mittyorz: @m_asama @syuu1228 試した限りではbridgeでホスト/ゲスト間の通信は出来ませんねー。 |
| | 64 | > m_asama: @mittyorz @syuu1228 まじですか…。なにが違うんでしょうね…。ちょうど今日 macvlan/macvtap 読もうと思ってたのでなんかわかったらご報告します。 |
| | 65 | > m_asama: @mittyorz @syuu1228 あー、なんかゲスト間通信できるようにしたのを bridge と言ってるみたいすね。よく考えたら送信はそのまま NIC から出すし、受信はすぐさま rx_handler に奪われるんだからホストと通信できるわけ無かったですね…。すんません…。 |
