Version 3 (modified by mitty, 12 years ago) (diff) |
---|
- macvlan/macvtap
- MacVTap - Linux Virtualization Wiki
Macvtap is a new device driver meant to simplify virtualized bridged networking. It replaces the combination of the tun/tap and bridge drivers with a single module based on the macvlan device driver.
- macvlanを使ってみる - 驟雨のカーネル探検隊(只今遭難中w
eth0をpromiscuousモードに切り替える事で、「fe:7b:40:b0:fc:f8」宛のパケットを受け取っているようです。 今度はMACアドレスが異なるので新しいIPをDHCPサーバからもらうことも出来ちゃいますね。 この機能、普通にLinux上で生きていても何の用途も無さそうですが、LXCで使われているようですし、後付で実装されたmacvtapを使えばKVM/QEMUからも使えます。
- macvtap でつないだ kvm ゲストとホスト間の通信 - TenForwardの日記 (defiantの日記改め)
この際,ゲスト~ホスト間の通信はできません.まあ,きちんとしたサービスとしてやるときは必要ないかもしれませんが,手元でちょっとテストをやってる時なんかは,ゲスト~ホスト間通信ができると便利な事もあります. macvtap というのは Linux kernel の持つ機能で macvlan というインターフェースを作れますが,これを Tap として利用するモノのようです.ということは macvlan/macvtap 間の通信は "bridgeモード" に設定しておけば可能です(この辺りのモードについては前述の参考文書を参照) ので,ホスト上に macvlan インターフェースを作成して,そこにホストのアドレスを割り当ててしまえば,ゲスト~ホスト間の通信は可能なはず,ということでやってみました.
- libvirtで色々な仮想NICの設定を使い分ける - 驟雨のカーネル探検隊(只今遭難中w
- 仮想化環境における パケットフォワーディング
- 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)
- nesting_macvlan-inVM.png (21.3 KB) - added by mitty 7 years ago.
Download all attachments as: .zip