Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第23章 仮想ネットワークの SR-IOV サポート
RHEL OpenStack Platform 6 で初めて導入された Single Root I/O Virtualization (SR-IOV) のサポートが、仮想マシンネットワークに拡張されました。SR-IOV により、OpenStack は従来の仮想ブリッジの要件に縛られること無く、代わりに物理 NIC の機能を直接インスタンスに拡張することができます。さらに IEEE 802.1br のサポートにより、仮想 NIC と物理スイッチを統合し、物理スイッチで仮想 NIC を管理することができます。
ネットワーク機能仮想化 (NFV) の詳細は、『ネットワーク機能仮想化 (NFV) の設定ガイド』を参照してください。
23.1. Red Hat OpenStack Platform デプロイメントでの SR-IOV の設定
SR-IOV により、Virtual Function の概念がサポートされるようになりました。これは、ハードウェア上の PCI デバイスとして提供されるものの、Physical Function が提供する 仮想インターフェース です。
本章では、SR-IOV を設定して 物理 NIC を仮想インスタンスに渡す手順について説明します。以下の手順では、コントローラーノード、OpenStack Networking (neutron) ノード、および複数の Compute (nova) ノードを使用するデプロイメントを前提としています。
仮想マシンインスタンスは、SR-IOV ポートまたは通常の vSwitch ポートを使用することができます。フラットまたは VLAN L2 設定が使用される場合は、SR-IOV ポートと通常の vSwitch ポートは、ネットワークを通じて、または同じコンピュートノード上の異なる Physical Function から相互に通信することができます。両方のインスタンスが同じコンピュートノードにあり、ネットワークアダプター上の Physical Function を共有する場合、両方のインスタンスが同じ種別のポートを使用する場合に限り (共に SR-IOV を使用する、または共に通常の vSwitch を使用する)、通信することができます。
23.2. コンピュートノードでの Virtual Function の作成
サポート対象のハードウェアを持つすべてのコンピュートノードで、以下の手順を実施します。
注記: サポートされるドライバーの詳細は、この アーティクル を参照してください。
以下の手順では、Intel 82576 ネットワークデバイスをパススルーするようにシステムを設定します。また、Virtual Function も作成され、インスタンスがデバイスへの SR-IOV アクセス用に使用することができます。
1. システムの BIOS で Intel VT-d または AMD IOMMU が有効になるようにします。マシンの BIOS 設定メニュー、またはメーカーから提供されているその他のリソースを参照してください。
2. オペレーティングシステムで Intel VT-d または AMD IOMMU が有効になるようにします。
3. lspci コマンドを実行して、ネットワークデバイスがシステムによって認識されることを確認します。
[root@compute ~]# lspci | grep 82576
ネットワークデバイスが結果に含まれます。
03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
4. 以降のステップを実施して、コンピュートノード上で Virtual Function をアクティブ化します。
4a. カーネルモジュールを削除します。これにより、カーネルモジュールを次のステップで設定できるようになります。
[root@compute ~]# modprobe -r igb
注記: ステップ 4 では、他の NIC 用の igb
ではなく、SRIOV 対応の NIC が使用するモジュール (例: ixgbe
または mlx4_core
) を使用する必要があります。ethtool コマンドを実行してドライバーを確認します。この例では、em1
が使用する PF です。
[root@compute ~]# ethtool -i em1 | grep ^driver
4b. max_vfs を 7 に設定して (またはサポートされる最大値まで) モジュールを起動します。
[root@compute ~]# modprobe igb max_vfs=7
4c. Virtual Function を永続化します。
[root@compute ~]# echo "options igb max_vfs=7" >>/etc/modprobe.d/igb.conf
注記: Red Hat Enterprise Linux 7 では、上記の変更を永続化するには、ステップ 4 の完了後に 初期 ramdisk イメージを再ビルドします。
注記: ステップ 4c および 4d の設定の永続化について: modprobe
コマンドにより同じカーネルモジュールを使用するすべての NIC で Virtual Function が有効になり、システムをリブートしても変更が維持されます。特定の NIC に対してのみ VF を有効にすることができますが、問題が発生する場合があります。たとえば、以下のコマンドは enp4s0f1
インターフェースの VF を有効にします。
# echo 7 > /sys/class/net/enp4s0f1/device/sriov_numvfs
ただし、この設定はリブート後に維持されません。回避策としては、以下の設定を rc.local に追加する方法が挙げられますが、以下の注記に示すように、これには制限があります。
# chmod +x /etc/rc.d/rc.local # echo "echo 7 > /sys/class/net/enp4s0f1/device/sriov_numvfs" >> /etc/rc.local
注記: systemd の追加以降、Red Hat Enterprise Linux は順番にではなく並行してサービスを起動します。つまり、ブートプロセス中に rc.local が実行される時期を予測できなくなりました。その結果、予期しない動作が発生する可能性があるので、この設定は推奨されません。
4d. カーネルコマンドラインに intel_iommu=pt および igb.max_vfs=7 パラメーターを追加して、カーネルの Intel VT-d をアクティブ化します。常にカーネルをこのようにブートする場合は、現在の設定を変更することができます。あるいは、これらのパラメーターでカスタムメニューエントリーを作成することができます。この場合、システムはデフォルトではこれらのパラメーターを使用してブートしますが、必要に応じて、これらのパラメーターを使用せずにカーネルをブートすることもできます。
• 現在のカーネルコマンドラインパラメーターを変更するには、以下のコマンドを実行します。
[root@compute ~]# grubby --update-kernel=ALL --args="intel_iommu=pt igb.max_vfs=7"
grubby 使用の詳細については、『システム管理者のガイド』の「grubby ツールを使用した GRUB 2 メニューの永続的な変更」を参照してください。
注記: Dell Power Edge R630 ノードを使用する場合は、intel_iommu=pt
ではなく intel_iommu=on
を使用する必要があります。grubby を使用してこれを有効にすることができます。
# grubby --update-kernel=ALL --args="intel_iommu=on"
• カスタムメニューエントリーを作成するには、以下の手順を実施します。
i. grub でデフォルトのエントリーを探します。
[root@compute ~]# grub2-editenv list saved_entry=Red Hat Enterprise Linux Server (3.10.0-123.9.2.el7.x86_64) 7.0 (Maipo)
ii. a. saved_entry の値で始まる必要な menuentry を /boot/grub2/grub.cfg から /etc/grub.d/40_custom にコピーします。エントリーは「menuentry」で始まる行で始まり、「}」が含まれる行で終わります。b. menuentry の後のタイトルを変更します。c. linux16 で始まる行の最後に intel_iommu=pt igb.max_vfs=7 を追加します。
以下に例を示します。
menuentry 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 - SRIOV' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-123.el7.x86_64-advanced-4718717c-73ad-4f5f-800f-f415adfccd01' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos2' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2' 5edd1db4-1ebc-465c-8212-552a9c97456e else search --no-floppy --fs-uuid --set=root 5edd1db4-1ebc-465c-8212-552a9c97456e fi linux16 /vmlinuz-3.10.0-123.el7.x86_64 root=UUID=4718717c-73ad-4f5f-800f-f415adfccd01 ro vconsole.font=latarcyrheb-sun16 biosdevname=0 crashkernel=auto vconsole.keymap=us nofb console=ttyS0,115200 LANG=en_US.UTF-8 intel_iommu=pt igb.max_vfs=7 initrd16 /initramfs-3.10.0-123.el7.x86_64.img }
iii. grub.cfg を更新して、変更を設定ファイルを適用します。
[root@compute ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
iv. デフォルトのエントリーを変更します。
[root@compute ~]# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 - SRIOV'
v. dist.conf 設定ファイルを作成します。
注記: このステップを実施する前に、allow_unsafe_interrupts の影響を説明するセクション (「allow_unsafe_interrupts 設定の確認」) を確認してください。
[root@compute ~]# echo "options vfio_iommu_type1 allow_unsafe_interrupts=1" > /etc/modprobe.d/dist.conf
5. サーバーをリブートして、新しいカーネルパラメーターを適用します。
[root@compute ~]# systemctl reboot
6. コンピュートノードで SR-IOV カーネルモジュールを確認します。lsmod を実行して、モジュールが読み込まれていることを確認します。
[root@compute ~]# lsmod |grep igb
絞り込んだ結果に、必要なモジュールが含まれているはずです。
igb 87592 0 dca 6708 1 igb
7. PCI ベンダー ID を確認し、ネットワークアダプターの PCI ベンダー ID (vendor_id:product_id の形式) を書き留めておきます。-nn フラグを指定した lspci コマンドの出力から、この情報を抽出します。以下に例を示します。
[root@compute ~]# lspci -nn | grep -i 82576 05:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01) 05:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01) 05:10.0 Ethernet controller [0200]: Intel Corporation 82576 Virtual Function [8086:10ca] (rev 01)
注記: このパラメーターは、ネットワークアダプターのハードウェアによって異なる可能性があります。
8. 新しい Virtual Function を確認します。lspci を使用して、新たに作成された VF を一覧表示します。
[root@compute ~]# lspci | grep 82576
結果に、デバイスおよび Virtual Function が含まれるようになりました。
0b:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 0b:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection(rev 01) 0b:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:10.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:10.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:10.6 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:10.7 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:11.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:11.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:11.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:11.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0b:11.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
23.3. ネットワークノードでの SR-IOV の設定
OpenStack Networking (neutron) は、ML2 メカニズムドライバーを使用して SR-IOV をサポートします。SR-IOV ドライバーを設定するには、ネットワークノードで以下の手順を実施します。以下の手順では、メカニズムドライバーを追加し、vlan
が有効にしたドライバーに含まれる状態にし、続いて VLAN 範囲を定義します。
1. /etc/neutron/plugins/ml2/ml2_conf.ini ファイルで sriovnicswitch を有効にします。たとえば、この設定により、Open vSwitch と共に SR-IOV メカニズムドライバーが有効になります。
sriovnicswitch は、現在の DHCP エージェント 用インターフェースドライバーをサポートしません。SR-IOV で DHCP によって割り当てられたアドレスを使用するには、ネットワークノードが openvswitch インターフェース (または VLAN をサポートするその他のメカニズムドライバー) を使用するように、ノードの neutron-dhcp-agent を設定します。
[ml2] tenant_network_types = vlan type_drivers = vlan mechanism_drivers = openvswitch, sriovnicswitch [ml2_type_vlan] network_vlan_ranges = physnet1:15:20
- network_vlan_ranges: この例では、ネットワークラベルに physnet1 を使用し、続いて VLAN 範囲として 15-20 を指定しています。
注記: メカニズムドライバー sriovnicswitch
は、現在 flat ドライバーおよび vlan ドライバーのみをサポートしています。ただし、sriovnicswitch
を有効しても、テナントネットワークが flat および vlan だけに制限される訳ではありません。VXLAN および GRE などは、引き続き SR-IOV ポートを使用しないインスタンスに使用することができます。
2. (オプション) サポートされる vendor_id/product_id の組み合わせは 15b3:1004, 8086:10ca です。実際の NIC ベンダーの製品 ID がこれとは異なる場合、その ID を指定します。さらに、PF パススルーを使用している場合は、この一覧を変更しなければならない場合があります。以下に例を示します。
[ml2_sriov] supported_pci_vendor_devs = 15b3:1004,8086:10ca
3. neutron-server サービスを再起動して設定を適用します。
[root@network ~]# systemctl restart neutron-server.service
23.4. コントローラーノードでの SR-IOV の設定
1. SR-IOV デバイスを適切にスケジューリングするには、Compute のスケジューラーは PciPassthroughFilter フィルターの設定で FilterScheduler を使用する必要があります。この設定をコントローラーノードの nova.conf ファイルに適用します。以下に例を示します。
scheduler_available_filters=nova.scheduler.filters.all_filters scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter, PciPassthroughFilter
2. Compute のスケジューラーを再起動して変更を適用します。
[root@compute ~]# systemctl restart openstack-nova-scheduler.service
23.5. コンピュートでの SR-IOV の設定
すべてのコンピュートノードで、利用可能な VF を各物理ネットワークに関連付けます。
1. nova.conf ファイルでエントリーを定義します。以下の例では、enp5s0f1 と一致する VF ネットワークを追加して、physical_network を physnet1 (前の手順で network_vlan_ranges に設定されたネットワークラベル) としてタグ付けしています。
pci_passthrough_whitelist={"devname": "enp5s0f1", "physical_network":"physnet1"}
以下の例では、ベンダー ID 8086 と一致する PF ネットワークを追加して、physical_network を physnet1 としてタグを付けしています。~ pci_passthrough_whitelist = \{"vendor_id": "8086","product_id": "10ac", "physical_network":"physnet1"} ~
PCI パススルーのホワイトリストエントリーは、以下の構文を使用します。
["device_id": "<id>",] ["product_id": "<id>",] ["address": "[[[[<domain>]:]<bus>]:][<slot>][.[<function>]]" | "devname": "Ethernet Interface Name",] "physical_network":"Network label string"
- id: id の設定には、* ワイルドカードの値または有効なデバイス/製品 ID を使用することができます。lspci を使用して、有効なデバイス名を一覧表示することができます。
- address: address の値には、-s スイッチを使用して lspci で表示されるものと同じ構文を使用します。
- devname: devname は、有効な PCI デバイス名です。ifconfig -a を使用して、利用可能な名前を一覧表示することができます。このエントリーは、仮想 NIC に関連付けられる PF または VF いずれかの値に対応している必要があります。address または devname で定義するデバイスが SR-IOV PF に対応している場合、PF の配下にあるすべての VF はエントリーと一致します。エントリーにタグを関連付けないことも、1 つまたは複数のタグを関連付けることもできます。
- physical_network: SR-IOV ネットワークを使用する場合には、「physical_network」を使用して、デバイスの接続先となる物理ネットワークを定義します。
ホストごとに、複数のホワイトリストエントリーを設定することができます。フィールド device_id、product_id、および address または devname は、libvirt のクエリー結果として返される PCI デバイスに対して照合されます。
2. nova-compute サービスを再起動して変更を適用します。
[root@compute ~]# systemctl restart openstack-nova-compute
23.6. OpenStack Networking の SR-IOV エージェントの有効化
1. 以下の手順を実行するために、sriov-nic-agent パッケージをインストールします。
[root@compute ~]# yum install openstack-neutron-sriov-nic-agent
2. /etc/neutron/plugins/ml2/openvswitch_agent.ini ファイルで NoopFirewallDriver を有効にします。
[root@compute ~]# openstack-config --set /etc/neutron/plugins/ml2/openvswitch_agent.ini securitygroup firewall_driver neutron.agent.firewall.NoopFirewallDriver
3. /etc/neutron/plugins/ml2/sriov_agent.ini ファイルにマッピングを追加します。以下の例では、physnet1 が物理ネットワークで、enp4s0f1 が Physical Function になります。exclude_devices を空白のままにして、エージェントが関連付けられたすべての VF を管理できるようにします。
[sriov_nic] physical_device_mappings = physnet1:enp4s0f1 exclude_devices =
4. (オプション) VF を除外します。エージェントの設定から特定の VF を除外するには、その VF を sriov_nic セクションの一覧に追加します。以下に例を示します。
exclude_devices = eth1:0000:07:00.2; 0000:07:00.3, eth2:0000:05:00.1; 0000:05:00.2
5. OpenStack Networking の SR-IOV エージェントを起動します。
[root@compute ~]# systemctl enable neutron-sriov-nic-agent.service [root@compute ~]# systemctl start neutron-sriov-nic-agent.service
23.7. SR-IOV ポートを使用するためのインスタンスの設定
SR-IOV 機能の概要
SR-IOV により、Physical Function (PF) および Virtual Function (VF) を使用して、インスタンスが直接 NIC にアクセスすることができます。PF は VF を使用して、複数のインスタンスが同じ PCI カードに直接アクセスできるようにします。その結果、PCI カードは、複数のインスタンスが使用できるように論理的に VF に分割されていると考えることができます。このことから、SR-IOV は、PCI デバイスへの独占的アクセスを 1 つのインスタンスだけに付与する PCI パススルーとは異なります。
PF と VF の両方を使用する場合、SR-IOV の NIC は複数のインスタンスに同時にバインドすることはできません。メモリーアドレスの保護により、他のインスタンスが VF を使用している場合、インスタンスは PF を制御することができません。つまり、1 つのインスタンスが PF に直接バインドしてカードを使用している (PCI パススルーとほぼ同等) 場合を除き、多くの場合 neutron はインスタンスに VF を渡してホストに PF を制御させます。
Virtual Functions の制限次項
特定のユースケースでは、Physical Function のパススルーがより適している場合があります。以下に例を示します。
- Residential vCPE
- BNG/BRAS (IPoE または PPPoE)
- VPLS または VLL 向けの PE
- VPN L3 (ポートにより複数の VLAN を使用する場合)
- レベル 2 のカプセル化により、特定のトラフィック処理が必要なその他のユースケース (例: MAN ネットワークの QinQ カプセル化)
- VF を使用する場合、サーバーの NIC ポートがトラフィックをブロックしてしまう可能性があります。これは想定された動作で、同じ NIC からの VF を共有するインスタンスからのスプーフィング攻撃を軽減するのに役立ちます。したがって、NIC ベンダーは、プロミスキャスモードのユニキャストを許可し、アンチスプーフィングおよび受信 VLAN フィルタリングを無効にすることを推奨する場合があります。
- NIC は、Physical Function または Virtual Function のいずれかを使用するように設定する必要があり、両方を同時に使用するように設定することはできません。
設定例
以下の例では、SR-IOV ポートが web
ネットワークに追加されます。
1. 利用可能なネットワークの一覧を取得します。
[root@network ~]# neutron net-list +--------------------------------------+---------+------------------------------------------------------+ | id | name | subnets | +--------------------------------------+---------+------------------------------------------------------+ | 3c97eb09-957d-4ed7-b80e-6f052082b0f9 | corp | 78328449-796b-49cc-96a8-1daba7a910be 172.24.4.224/28 | | 721d555e-c2e8-4988-a66f-f7cbe493afdb | web | 140e936e-0081-4412-a5ef-d05bacf3d1d7 10.0.0.0/24 | +--------------------------------------+---------+------------------------------------------------------+
この出力結果には、OpenStack Networking で作成したネットワークの一覧が表示され、サブネットの詳細が含まれます。
2. web
ネットワーク内にポートを作成します。
[root@network ~]# neutron port-create web --name sr-iov --binding:vnic-type direct Created a new port: +-----------------------+---------------------------------------------------------------------------------+ | Field | Value | +-----------------------+---------------------------------------------------------------------------------+ | admin_state_up | True | | allowed_address_pairs | | | binding:host_id | | | binding:profile | {} | | binding:vif_details | {} | | binding:vif_type | unbound | | binding:vnic_type | normal | | device_id | | | device_owner | | | fixed_ips | {"subnet_id": "140e936e-0081-4412-a5ef-d05bacf3d1d7", "ip_address": "10.0.0.2"} | | id | a2122b4d-c9a9-4a40-9b67-ca514ea10a1b | | mac_address | fa:16:3e:b1:53:b3 | | name | sr-iov | | network_id | 721d555e-c2e8-4988-a66f-f7cbe493afdb | | security_groups | 3f06b19d-ec28-427b-8ec7-db2699c63e3d | | status | DOWN | | tenant_id | 7981849293f24ed48ed19f3f30e69690 | +-----------------------+---------------------------------------------------------------------------------+
3. 新しいポートを使用するインスタンスを作成します。
webserver01 という名前の新規インスタンスを作成し、前のステップの出力の id フィールドに書かれたポート ID を使用して、新しいポートを使用するように設定します。
注記: glance image-list コマンドを使用して、利用可能なイメージとその UUID の一覧を取得することができます。
[root@compute ~]# nova boot --flavor m1.tiny --image 59a66200-45d2-4b21-982b-d06bc26ff2d0 --nic port-id=a2122b4d-c9a9-4a40-9b67-ca514ea10a1b webserver01
新規インスタンス webserver01 が作成され、SR-IOV ポートを使用するように設定されました。
23.8. allow_unsafe_interrupts 設定の確認
デバイスが割り当てられたゲストをホストから完全に分離するには、プラットフォームが割り込みの再マッピングをサポートしている必要があります。このようなサポートがないと、ホストは悪意のあるゲストからの割り込み注入攻撃に対して脆弱となる可能性があります。ゲストが信頼できる環境では、管理者は allow_unsafe_interrupts オプションを使用して引き続き PCI デバイスの割り当てを許可することを選択できます。ホストで allow_unsafe_interrupts を有効にする必要があるかどうかを確認します。ホストの IOMMU が割り込みの再マッピングをサポートする場合、この機能を有効にする必要はありません。
1. dmesg を使用して、ホストの IOMMU が割り込みの再マッピングをサポートしているかどうかを確認します。
[root@compute ~]# dmesg |grep ecap
ecap (0xf020ff → …1111) のビット 3 が 1 の場合、IOMMU が割り込みの再マッピングをサポートすることを意味します。
2. IRQ 再マッピングが有効かどうかを確認します。
[root@compute ~]# dmesg |grep "Enabled IRQ" [ 0.033413] Enabled IRQ remapping in x2apic mode
注記: grub.conf に intremap=off を追加することで、「IRQ 再マッピング」を手動で無効にすることができます。
3. ホストの IOMMU が割り込みの再マッピングをサポートしていない場合は、kvm モジュールで allow_unsafe_assigned_interrupts=1 を有効にする必要があります。
23.9. インスタンスへの Physical Function の追加
Physical Functions (PF) をインスタンスに公開するように Compute を設定することができます。インスタンスに物理ポートに対する完全な制御を付与することで、このユースケースは NFV アプリケーションに役立ちます。これにより、インスタンスは Virtual Functions (VF) では利用できない一部機能を使用することができます。これらのインスタンスは、特定のカードが VF に適用する制限の一部を回避することや、ポートの全帯域幅を独占して使用することができます。
インスタンスに割り当てられている子 VF がない場合に、Compute では未使用の PF をインスタンスに割り当てることができます。PF が割り当てられると、その VF はいずれも使用できなくなります。インスタンスがシャットダウンされ、PF が未使用の状態になると、VF は再び使用できるようになります。逆に、子 VF のいずれかがすでに割り当てられている場合、Compute は PF が割り当てられないようにします。
23.9.1. Physical Function 向けの Compute 設定
nova.conf
ホワイトリストに device_type:type-PF を追加して、Physical Function を公開します。以下に例を示します。
pci_passthrough_whitelist={"product_id":"10ed", "vendor_id":"8086", "physical_network":"physnet1",'device_type': 'type-PF}
23.9.2. Physical Function の設定
SR-IOV PF は neutron ポートであるかのように管理することができます。Neutron は 新たな vnic_type
の direct-physical
をサポートしています。nova はこれによって作成される仮想 NIC を使用して、新しい VIF の種別でホスト上の PF を選択し、さらにゲストへのパススルーを実施します。その結果、nova は選択したホスト上の PF の MAC アドレスで neutron ポートを更新します。
たとえば、Network1
というネットワーク上に PF を作成するには、以下のコマンドを実行します。
$ neutron port-create Network1 --name pf-port --binding:vnic_type direct-physical
続いて、PF にアクセスできるように作成されたポートをインスタンスにアタッチすることができます。
23.10. その他の考慮事項
- 仮想 NIC の種別を選択する際には、現在 vnic_type=macvtap がサポートされていないことに注意してください。
- SR-IOV がアタッチされたインスタンスの仮想マシン移行はサポートされていません。
- 現在、SR-IOV が有効なポートでは、セキュリティーグループを使用することはできません。