libvirtで色々な仮想NICの設定を使い分ける

virtio-netとvhost-net

参考:CentOS 6 - KVM - Enable vhost-net : Server World

modprobe vhost_net

VM起動時までにvhost_netがロードされているとvhost-netで、ロードされていないとvirtio-netで起動する模様。

ps ax|grep vhost

とかやると、vhost-netが有効なKVMプロセスは引数にvhost=onが入っているので見分けられる。

tap

参考:libvirt: Domain XML format
typeがbridgeかnetworkになっている。
標準的な構成。

    <interface type='bridge'>
      <mac address='52:54:00:94:9a:a0'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

macvtap

参考;libvirt: Domain XML format
(少なくとも0.9.0 on Ubuntu 11.10の)virt-managerには項目が無かったりするが、XMLを直に書けば対応できる。
libvirt的にはmacvtapと呼ばずにDirect attachmentらしい。
そういうのわかりにくくなるからやめて欲しい。

    <interface type='direct'>
      <mac address='52:54:00:94:9a:a0'/>
      <source dev='eth0' mode='bridge'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

macvtapのモード

bridge

NICに属するノード間の通信をブリッジする。 bridge + tapとほぼ同じ動作。

vepa

VEPA対応スイッチがパケットをヘアピンフォワードしてくれる事を期待して全てのトラフィックをスイッチに投げる、VEPAモード。

private

macvtapインタフェースはデフォルトゲートウェイとのみ通信出来る。
親インタフェースとの通信を許可しない。

passthrough

macvtapと親デバイスの間の通信を単純なパススルーにする。
SR-IOVのVFをtap経由でVMに提供するようなケースで使える。

感想

何度見ても、bridgeとmacvlan/macvtapが別の機能としてカーネルに存在するのは設計がアレだから、な気がしてくる。
あと、カーネル内でKVMでの仮想ネットワークIOを解決するのにtapを通す必要ってあるのかな。何か無駄があるような…
VFをmacvtapでフックしてKVMに流すというのも、それはVMDqの仕事ではないのかしら、と。
SR-IOVで使える、みたいな書き方だけどVMDqを念頭においてたりするのかな。