wiki:TipAndDoc/network/macvlan

Version 3 (modified by mitty, 12 years ago) (diff)

--

  • macvlan/macvtap
  • twitter:mittyorz/256673272354181121 前後から始まったやりとり
    mittyorz: LXCは「lxc.network.type=macvlan lxc.network.macvlan.mode=bridge」のようにconfigに書くことで、linux bridgeをあらかじめ用意しなくてもブリッジ接続してくれるぞ。
    mittyorz: 参考: http://www.linuxcertif.com/man/5/lxc.conf/ Linux Certif - Man lxc.conf(5) qemu/kvmも1.0からかな、macvlan/macvtap使えるようになったし、Linux bridgeと共存していくのかなぁ
    mittyorz: ぐぐってたら @syuu1228 先生の資料が引っかかった http://www.nic.ad.jp/ja/materials/iw/2011/proceedings/s09/s09-02.pdf 仮想化環境における  パケットフォワーディング
    _syuu1228: やぁやぁ RT @mittyorz: ぐぐってたら @syuu1228 先生の資料が引っかかった http://www.nic.ad.jp/ja/materials/iw/2011/proceedings/s09/s09-02.pdf 仮想化環境における  パケットフォワーディング
    mittyorz: @_syuu1228 @syuu1228 どもども。macvlan/macvtapいまいち理解せずkvm/qemuで使ってたんですが、lxcでも使えないか?と思ってググってて、「結局macvlav/vtapってなんやねん」とさらにググってたらたどり着きましたー。
    mittyorz: とはいえ、ここに書いてあることも理解できているのかと言われると、かなり怪しい…。というか他のも読まないと何とも、かなぁ
    mittyorz: ホスト/ゲスト間が通信できなくなるのはどういう理由なんだろう
    _syuu1228: @mittyorz @syuu1228 KVMで使おうとして後から機能追加(macvtap)してますけど、元々LXC向けの機能(macvlan)っすね
    mittyorz: @_syuu1228 @syuu1228 ああー、そうなんですか。なるほど…。macvlanが先だったんですね。違いがよく分からずにいたので、今更ながら色々読んでます。
    mittyorz: この辺が詳しそう? http://virt.kernelnewbies.org/MacVTap MacVTap - Linux Virtualization Wiki
    mittyorz: 何らかの方法でホスト/ゲスト間で通信できるように細工したような覚えが。どうやったんだっけかな
    _syuu1228: @mittyorz 元々、カーネルの中で完結した機構で、1つのNICに複数のMACを振る仕組みをLXCの為に作ったのがmacvlan。KVMのvNICってそもそもユーザランドで動いてたからtap+bridge使ってたんやけど、vhostnetでカーネルで動くようにもなったので(続
    _syuu1228: @mittyorz より短いパス(macvlanのように)でブリッジ出来るようにしようとしたんだけど、あくまでtapのインタフェースは維持したかったっぽくて(ユーザランドから設定とかする為?よくわからない)その為にmacvlanにtapのインタフェースくっつけたのがmacvtap
    _syuu1228: @mittyorz ちなみにVEPAとか書いてあるのはスルーしていいと思います。僕らも調べてIW2011で解説したし、IW2012でも触れるかもしれないけど、現状まず使わないので
    mittyorz: @_syuu1228 なるほど。わざわざ経緯の説明ありがとうございます!tapのインタフェースくっつけたのはやはり既存のユーザランドアプリケーションとかから状態を見たり設定変更したりしたかったからですかねぇ…。若干車輪の再発明っぽい感じではありますが、利便性を取ったのかな
    _syuu1228: @mittyorz 「vhost-netもqemu-kvmも変えなくていい」というのは大きな動機になりそうですが、ずっと前からここは疑問に思ってます。
    mittyorz: @_syuu1228 なるほど。(ハードウェア)switch側の対応が必要となるとちょっと使えなさそうですね。しかしデフォルトがVEPAになっているように書かれていますが、利用者側からすると混乱しそうな気もしますね…。
    _syuu1228: @mittyorz あれー本当だてっきりbridgeだと思ってたんだけど…でもhairpin_modeが使えるってところだけが違いのはずなので(ちょっと自信なし)、これがデフォルトオフなのか、或いは対応スイッチの下でしかhairpinしないのか、って所なのではないかと妄想します
    mittyorz: @_syuu1228 ふむー。そうなるとちょっと使ってみよう、という場合でもデフォルトのVEPAにしておいて大丈夫なのかな…。やってみるか……。
    mittyorz: qemu/kvmでも書いてある通りホスト/ゲスト間で通信できなかった。ただ、 https://twitter.com/mittyorz/status/256674071159382018 で見落としていたけど、ホスト/ゲスト間用に、別にmacvlanを作ってしまえば問題ないようだ。でもそこまでするなら今までもbr0とかでもいい気もする。
    mittyorz: あとは性能次第かなぁ
    _syuu1228: @mittyorz すげー単純にいうと、同一ホスト間のブリッジングでも一旦スイッチへパケット送ってスイッチで転送先判断させようという仕組み=VEPAなので(同一ホストならパケット戻ってくる=ヘアピン)、もしデフォルトでヘアピンが実施されるなら普通のスイッチ下では通信エラーするはず
    mittyorz: @_syuu1228 それは同じVMM上に無いノード間の通信は問題なく通信できるように見えて、同じVMM上に存在するVM同士で通信しようとするととたんにはまったりしないですかね…。問題への気付きにくさが増しているような。
    mittyorz: VEPAモードにしてみたが、VMノードと、ハードウェア的に別のノードとの間の通信は問題なかった。もちろんホスト/ゲスト間は通信できない。
    _syuu1228: @mittyorz そうなる気がするけど何が起きるか厳密に考えてみた事が無いので、もしかしたら予想と違う現象になるかも。でもまさかそういう設定に最初からなってるはずはないと思うんだけどねぇ…
    _syuu1228: @mittyorz 多分このあたりは @m_asama せんせーも詳しいと思うので、と人に振ってみる
    mittyorz: virt-managerでVM作る時に、NICをmacvtapにしてsource modeをdefaultにしたら作成に失敗する…w いったんVEPAにしてから、後でDefaultにしようとしても、applyを押下した瞬間にVEPAに戻る。なんじゃこりゃ。
    mittyorz: プルダウンの順番がDefault->VEPAだから、選択出来ないdefaultの代わりにVEPAになっている感がする。virsh editで 'default'ってしたらどうなるんだろう
    mittyorz: 「error: internal error Unkown mode has been specified」ふむん…
    mittyorz: lxcコンテナA,B間で、ホストとは通信できる必要がない通信をしたい時に、まず思い浮かんだのが、物理NICとは接続されてないbridgeを用意して、それに対してA,Bを接続すればいいや、と思ったのだけれど、macvlanがあるのを思い出して調べてたらだいぶ話が膨らんだなぁ
    mittyorz: macvlan使う場合も、ホスト側は通信できる必要無い(IPアドレスとか付与しない)けど、ホスト側でmacvlanデバイスを作ってからLXCコンテナ側でそこに接続する必要があるのかな。外(ホスト側)にデバイスとして見えている必要は無い(むしろ見えない方が良い)のだけれど。
    mittyorz: 外に見える、というのはifconfig -aとかすると見えてしまうアレ。
    mittyorz: @_syuu1228 だめですが、かなりアドホックな回避策はあるようですね。アドホックすぎてちょっといやな感じですが。 ref: https://twitter.com/mittyorz/status/256680074403790848
    m_asama: @_syuu1228 @mittyorz なんでデフォルト vepa なんでしょうね。ちょっとコード眺めたかんじでは bridge と比較してそんなに vepa が軽量になってるとは思えないし。あ、もしかしたら大量に VM ぶら下げた時に差が出てくるのかも。
    

Attachments (1)

Download all attachments as: .zip