SR-IOV に対応したアダプタがない現状では、Hypervisorが仮想化した vNIC, vHBA を VM が使用している。このため完全仮想化では I/O 性能に問題を抱えている。一方、SR-IOV にアダプタが対応した場合、アダプタの Virtual Function (VF) を VM が直接たたくことが可能になる。CNAの場合、10GbE VFs, 8Gbps FC VFs ができることになる。
FC の場合、アダプタの VF はどのように VM からみえるかというと、やっぱり vHBA が見える。ただ、FCの場合は、NPIV を使用して VF 単位に FCID (昔は PortID の意味で PID と書くことが多かったが、FCoE では FCID と書くので、今後は FCID と書こうと思う)を割り当てることができるが、Ethernet だと VF 単位に MAC Address を割り振るという新機能が必要がある。ということで、VEPA, NIV が必要になるわけだ。
#根本的な違いは FC の場合、frame forwarding は FCIDで行われているが、Ethernet の場合、MAC addressで行われている、ということ
実アダプタの VF が FCID, MAC によって VM 単位に割り振られるとどうなるかというと、Bridge (いわゆるスイッチ)が hypervisor に無くてもよくなる。というのも外部の bridge から VM の区別ができるようになるからである。そもそも hypervisor による実装では、上記の通り、性能に問題があるのと同時に、hypervisor 間に設定などの分配を行うことが難しいということがある(だから Nexus 1000V があるわけなのだが)。
Brocade FC HBA の場合、既に Hypwer-V + SC OM/VMM の連携で VM の自由なマイグレーション(I/O QoS を担保した状態で)ができるが、当然 CNA では (繰りかえすが VEPA, NIV が前提)同じことが可能。ということはソフトウェアスイッチは本当に必要??加えて、IOV 環境ではアダプタでの bridge も実装されるはず(Virtual Ethernet Bridge:VEB)なので、ますます需要がわからない。このあたりはマーケットが決めることとはいえ、気になる。