8.17. 仮想マシンのネットワーク
8.17.1. デフォルトの Pod ネットワーク用の仮想マシンの設定
masquerade
バインディングモードを使用するようにネットワークインターフェイスを設定することで、仮想マシンをデフォルトの内部 Pod ネットワークに接続できます。
8.17.1.1. コマンドラインでのマスカレードモードの設定
マスカレードモードを使用し、仮想マシンの送信トラフィックを Pod IP アドレスの背後で非表示にすることができます。マスカレードモードは、ネットワークアドレス変換 (NAT) を使用して仮想マシンを Linux ブリッジ経由で Pod ネットワークバックエンドに接続します。
仮想マシンの設定ファイルを編集して、マスカレードモードを有効にし、トラフィックが仮想マシンに到達できるようにします。
前提条件
- 仮想マシンは、IPv4 アドレスを取得するために DHCP を使用できるように設定される必要がある。以下の例では、DHCP を使用するように設定されます。
手順
仮想マシン設定ファイルの
interfaces
仕様を編集します。kind: VirtualMachine spec: domain: devices: interfaces: - name: default masquerade: {} 1 ports: 2 - port: 80 networks: - name: default pod: {}
注記ポート 49152 および 49153 は libvirt プラットフォームで使用するために予約され、これらのポートへの他のすべての受信トラフィックは破棄されます。
仮想マシンを作成します。
$ oc create -f <vm-name>.yaml
8.17.1.2. デュアルスタック (IPv4 および IPv6) でのマスカレードモードの設定
cloud-init を使用して、新規仮想マシンを、デフォルトの Pod ネットワークで IPv6 と IPv4 の両方を使用するように設定できます。
IPv6 ネットワークアドレスは、仮想マシン設定のゲートウェイの fd10:0:2::1
で fd10:0:2::2/120
に静的に設定される必要があります。これらは IPv6 トラフィックを仮想マシンにルーティングするために virt-launcher Pod で使用され、外部では使用されません。
仮想マシンが実行されている場合、仮想マシンの送受信トラフィックは、virt-launcher Pod の IPv4 アドレスと固有の IPv6 アドレスの両方にルーティングされます。次に、virt-launcher Pod は IPv4 トラフィックを仮想マシンの DHCP アドレスにルーティングし、IPv6 トラフィックを仮想マシンの静的に設定された IPv6 アドレスにルーティングします。
前提条件
- OpenShift Container Platform クラスターは、デュアルスタック用に設定された OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダーを使用する必要があります。
手順
新規の仮想マシン設定では、
masquerade
を指定したインターフェイスを追加し、cloud-init を使用して IPv6 アドレスとデフォルトゲートウェイを設定します。apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: example-vm-ipv6 ... interfaces: - name: default masquerade: {} 1 ports: - port: 80 2 networks: - name: default pod: {} volumes: - cloudInitNoCloud: networkData: | version: 2 ethernets: eth0: dhcp4: true addresses: [ fd10:0:2::2/120 ] 3 gateway6: fd10:0:2::1 4
namespace で仮想マシンインスタンスを作成します。
$ oc create -f example-vm-ipv6.yaml
検証
- IPv6 が設定されていることを確認するには、仮想マシンを起動し、仮想マシンインスタンスのインターフェイスステータスを表示して、これに IPv6 アドレスがあることを確認します。
$ oc get vmi <vmi-name> -o jsonpath="{.status.interfaces[*].ipAddresses}"
8.17.2. 仮想マシンを公開するサービスの作成
Service
オブジェクトを使用して、クラスター内またはクラスターの外部に仮想マシンを公開することができます。
8.17.2.1. サービスについて
Kubernetes サービス は、一連の Pod で実行されるアプリケーションをネットワークサービスとして公開するための抽象的な方法です。サービスを使用すると、アプリケーションがトラフィックを受信できます。サービスは、Service
オブジェクトに spec.type
を指定して複数の異なる方法で公開できます。
- ClusterIP
-
クラスター内の内部 IP アドレスでサービスを公開します。
ClusterIP
はデフォルトのサービスタイプ
です。 - NodePort
-
クラスター内の選択した各ノードの同じポートでサービスを公開します。
NodePort
は、クラスター外からサービスにアクセスできるようにします。 - LoadBalancer
- 現在のクラウド(サポートされている場合)に外部ロードバランサーを作成し、固定の外部 IP アドレスをサービスに割り当てます。
8.17.2.1.1. デュアルスタックサポート
IPv4 および IPv6 のデュアルスタックネットワークがクラスターに対して有効にされている場合、Service
オブジェクトに spec.ipFamilyPolicy
および spec.ipFamilies
フィールドを定義して、IPv4、IPv6、またはそれら両方を使用するサービスを作成できます。
spec.ipFamilyPolicy
フィールドは以下の値のいずれかに設定できます。
- SingleStack
- コントロールプレーンは、最初に設定されたサービスクラスターの IP 範囲に基づいて、サービスのクラスター IP アドレスを割り当てます。
- PreferDualStack
- コントロールプレーンは、デュアルスタックが設定されたクラスターのサービス用に IPv4 および IPv6 クラスター IP アドレスの両方を割り当てます。
- RequireDualStack
-
このオプションは、デュアルスタックネットワークが有効にされていないクラスターの場合には失敗します。デュアルスタックが設定されたクラスターの場合、その値が
PreferDualStack
に設定されている場合と同じになります。コントロールプレーンは、IPv4 アドレスと IPv6 アドレス範囲の両方からクラスター IP アドレスを割り当てます。
単一スタックに使用する IP ファミリーや、デュアルスタック用の IP ファミリーの順序は、spec.ipFamilies
を以下のアレイ値のいずれかに設定して定義できます。
-
[IPv4]
-
[IPv6]
-
[IPv4, IPv6]
-
[IPv6, IPv4]
8.17.2.2. 仮想マシンのサービスとしての公開
ClusterIP
、NodePort
、または LoadBalancer
サービスを作成し、クラスター内外から実行中の仮想マシン (VM) に接続します。
手順
VirtualMachine
マニフェストを編集して、サービス作成のラベルを追加します。apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-ephemeral namespace: example-namespace spec: running: false template: metadata: labels: special: key 1 # ...
- 1
- ラベル
special: key
をspec.template.metadata.labels
セクションに追加します。
注記仮想マシンのラベルは Pod に渡されます。
special: キー
ラベルは、Service
マニフェストのspec.selector
属性のラベルと一致する必要があります。-
VirtualMachine
マニフェストファイルを保存して変更を適用します。 仮想マシンを公開するための
Service
マニフェストを作成します。apiVersion: v1 kind: Service metadata: name: vmservice 1 namespace: example-namespace 2 spec: externalTrafficPolicy: Cluster 3 ports: - nodePort: 30000 4 port: 27017 protocol: TCP targetPort: 22 5 selector: special: key 6 type: NodePort 7
- 1
Service
オブジェクトの名前。- 2
Service
オブジェクトが存在する namespace。これはVirtualMachine
マニフェストのmetadata.namespace
フィールドと同じである必要があります。- 3
- オプション: ノードが外部 IP アドレスで受信したサービストラフィックを分散する方法を指定します。これは
NodePort
およびLoadBalancer
サービスタイプにのみ適用されます。デフォルト値はCluster
で、トラフィックをすべてのクラスターエンドポイントに均等にルーティングします。 - 4
- オプション: 設定する場合、
nodePort
値はすべてのサービスで固有でなければなりません。指定しない場合、30000
を超える範囲内の値は動的に割り当てられます。 - 5
- オプション: サービスによって公開される VM ポート。ポートリストが仮想マシンマニフェストに定義されている場合は、オープンポートを参照する必要があります。
targetPort
が指定されていない場合は、ポート
と同じ値を取ります。 - 6
VirtualMachine
マニフェストのspec.template.metadata.labels
スタンザに追加したラベルへの参照。- 7
- サービスのタイプ。使用できる値は
ClusterIP
、NodePort
、およびLoadBalancer
です。
-
サービス
マニフェストファイルを保存します。 以下のコマンドを実行してサービスを作成します。
$ oc create -f <service_name>.yaml
- 仮想マシンを起動します。仮想マシンがすでに実行中の場合は、再起動します。
検証
Service
オブジェクトをクエリーし、これが利用可能であることを確認します。$ oc get service -n example-namespace
ClusterIP
サービスの出力例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice ClusterIP 172.30.3.149 <none> 27017/TCP 2m
NodePort
サービスの出力例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice NodePort 172.30.232.73 <none> 27017:30000/TCP 5m
LoadBalancer
サービスの出力例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice LoadBalancer 172.30.27.5 172.29.10.235,172.29.10.235 27017:31829/TCP 5s
仮想マシンに接続するための適切な方法を選択します。
ClusterIP
サービスの場合は、サービス IP アドレスとサービスポートを使用して、クラスター内から仮想マシンに接続します。以下に例を示します。$ ssh fedora@172.30.3.149 -p 27017
NodePort
サービスの場合、ノード IP アドレスとクラスターネットワーク外のノードポートを指定して仮想マシンに接続します。以下に例を示します。$ ssh fedora@$NODE_IP -p 30000
-
LoadBalancer
サービスの場合は、vinagre
クライアントを使用し、パブリック IP アドレスおよびポートで仮想マシンに接続します。外部ポートは動的に割り当てられます。
8.17.2.3. 関連情報
8.17.3. Linux ブリッジ ネットワークへの仮想マシンの接続
デフォルトでは、OpenShift Virtualization は単一の内部 Pod ネットワークとともにインストールされます。
追加のネットワークに接続するには、Linux ブリッジ ネットワーク接続定義 (NAD) を作成する必要があります。
仮想マシンを追加のネットワークに割り当てるには、以下を実行します。
- Linux ブリッジ ノード ネットワーク設定ポリシーを作成します。
- Linux ブリッジ ネットワーク接続定義を作成します。
- 仮想マシンを設定して、仮想マシンがネットワーク接続定義を認識できるようにします。
スケジューリング、インターフェイスタイプ、およびその他のノードのネットワークアクティビティーについての詳細は、node networking セクションを参照してください。
8.17.3.1. ネットワーク接続定義によるネットワークへの接続
8.17.3.1.1. Linux ブリッジ ノード ネットワーク設定ポリシーの作成
NodeNetworkConfigurationPolicy
マニフェスト YAML ファイルを使用して、Linux ブリッジを作成します。
手順
NodeNetworkConfigurationPolicy
マニフェストを作成します。この例には、独自の情報で置き換える必要のあるサンプルの値が含まれます。apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: br1-eth1-policy 1 spec: desiredState: interfaces: - name: br1 2 description: Linux bridge with eth1 as a port 3 type: linux-bridge 4 state: up 5 ipv4: enabled: false 6 bridge: options: stp: enabled: false 7 port: - name: eth1 8
8.17.3.2. Linux ブリッジネットワーク接続定義の作成
8.17.3.2.1. 前提条件
- Linux ブリッジは、すべてのノードに設定して割り当てる必要がある。詳細は、ノードのネットワーク セクションを参照してください。
仮想マシンのネットワークアタッチメント定義での IP アドレス管理 (IPAM) の設定はサポートされていません。
8.17.3.2.2. Web コンソールでの Linux ブリッジネットワーク接続定義の作成
ネットワーク接続定義は、layer-2 デバイスを OpenShift Virtualization クラスターの特定の namespace に公開するカスタムリソースです。
ネットワーク管理者は、ネットワーク接続定義を作成して既存の layer-2 ネットワークを Pod および仮想マシンに提供できます。
手順
-
Web コンソールで、Networking
Network Attachment Definitions をクリックします。 Create Network Attachment Definition をクリックします。
注記ネットワーク接続定義は Pod または仮想マシンと同じ namespace にある必要があります。
- 一意の Name およびオプションの Description を入力します。
- Network Type 一覧をクリックし、CNV Linux bridge を選択します。
- Bridge Name フィールドにブリッジの名前を入力します。
- オプション: リソースに VLAN ID が設定されている場合、 VLAN Tag Number フィールドに ID 番号を入力します。
- オプション: MAC Spoof Check を選択して、MAC スプーフ フィルターリングを有効にします。この機能により、Pod を終了するための MAC アドレスを 1 つだけ許可することで、MAC スプーフィング攻撃に対してセキュリティーを確保します。
Create をクリックします。
注記Linux ブリッジ ネットワーク接続定義は、仮想マシンを VLAN に接続するための最も効率的な方法です。
8.17.3.2.3. CLI での Linux ブリッジネットワーク接続定義の作成
ネットワーク管理者は、タイプ cnv-bridge
のネットワーク接続定義を、レイヤー 2 ネットワークを Pod および仮想マシンに提供するように設定できます。
ネットワーク接続定義は Pod または仮想マシンと同じ namespace にある必要があります。
手順
- 仮想マシンと同じ namespace にネットワーク接続定義を作成します。
次の例のように、仮想マシンをネットワーク接続定義に追加します。
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: <bridge-network> 1 annotations: k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/<bridge-interface> 2 spec: config: '{ "cniVersion": "0.3.1", "name": "<bridge-network>", 3 "type": "cnv-bridge", 4 "bridge": "<bridge-interface>", 5 "macspoofchk": true, 6 "vlan": 1 7 }'
- 1
NetworkAttachmentDefinition
オブジェクトの名前。- 2
- オプション: ノード選択のアノテーションのキーと値のペア。
bridge-interface
は一部のノードに設定されるブリッジの名前です。このアノテーションをネットワーク接続定義に追加する場合、仮想マシンインスタンスはbridge-interface
ブリッジが接続されているノードでのみ実行されます。 - 3
- 設定の名前。設定名をネットワーク接続定義の
name
値に一致させることが推奨されます。 - 4
- このネットワーク接続定義のネットワークを提供する Container Network Interface (CNI) プラグインの実際の名前。異なる CNI を使用するのでない限り、このフィールドは変更しないでください。
- 5
- ノードに設定される Linux ブリッジの名前。
- 6
- オプション:MAC スプーフィングチェックを有効にする。
true
に設定すると、Pod またはゲストインターフェイスの MAC アドレスを変更できません。この属性は、Pod からの MAC アドレスを 1 つだけ許可することで、MAC スプーフィング攻撃に対してセキュリティーを確保します。 - 7
- オプション: VLAN タグ。ノードのネットワーク設定ポリシーでは、追加の VLAN 設定は必要ありません。
注記Linux ブリッジ ネットワーク接続定義は、仮想マシンを VLAN に接続するための最も効率的な方法です。
ネットワーク接続定義を作成します。
$ oc create -f <network-attachment-definition.yaml> 1
- 1
- ここで、
<network-attachment-definition.yaml>
はネットワーク接続定義マニフェストのファイル名です。
検証
次のコマンドを実行して、ネットワーク接続定義が作成されたことを確認します。
$ oc get network-attachment-definition <bridge-network>
8.17.3.3. Linux ブリッジネットワーク用の仮想マシンの設定
8.17.3.3.1. Web コンソールでの仮想マシンの NIC の作成
Web コンソールから追加の NIC を作成し、これを仮想マシンに割り当てます。
手順
-
OpenShift Virtualization コンソールの適切なプロジェクトで、サイドメニューから Workloads
Virtualization をクリックします。 - Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Network Interfaces をクリックし、仮想マシンにすでに割り当てられている NIC を表示します。
- Add Network Interface をクリックし、一覧に新規スロットを作成します。
- Network ドロップダウンリストを使用して、追加ネットワークのネットワーク接続定義を選択します。
- 新規 NIC の Name、Model、Type、および MAC Address に入力します。
- Add をクリックして NIC を保存し、これを仮想マシンに割り当てます。
8.17.3.3.2. ネットワークフィールド
名前 | 説明 |
---|---|
名前 | ネットワークインターフェイスコントローラーの名前。 |
モデル | ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
ネットワーク | 利用可能なネットワーク接続定義の一覧。 |
Type |
利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、 |
MAC Address | ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
8.17.3.3.3. CLI で仮想マシンを追加のネットワークに接続する
ブリッジインターフェイスを追加し、仮想マシン設定でネットワーク接続定義を指定して、仮想マシンを追加のネットワークに割り当てます。
以下の手順では、YAML ファイルを使用して設定を編集し、更新されたファイルをクラスターに適用します。oc edit <object> <name>
コマンドを使用して、既存の仮想マシンを編集することもできます。
前提条件
- 設定を編集する前に仮想マシンをシャットダウンします。実行中の仮想マシンを編集する場合は、変更を有効にするために仮想マシンを再起動する必要があります。
手順
- ブリッジネットワークに接続する仮想マシンの設定を作成または編集します。
ブリッジインターフェイスを
spec.template.spec.domain.devices.interfaces
一覧に追加し、ネットワーク接続定義をspec.template.spec.networks
一覧に追加します。この例では、a-bridge-network
ネットワーク接続定義に接続されるbridge-net
というブリッジインターフェイスを追加します。apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: <example-vm> spec: template: spec: domain: devices: interfaces: - masquerade: {} name: <default> - bridge: {} name: <bridge-net> 1 ... networks: - name: <default> pod: {} - name: <bridge-net> 2 multus: networkName: <network-namespace>/<a-bridge-network> 3 ...
- 1
- ブリッジインターフェイスの名前。
- 2
- ネットワークの名前。この値は、対応する
spec.template.spec.domain.devices.interfaces
エントリーのname
値と一致する必要があります。 - 3
- ネットワーク接続定義の名前。接頭辞は、存在する namespace になります。namespace は、
default
の namespace または仮想マシンが作成される namespace と同じでなければなりません。この場合、multus
が使用されます。Multus は、Pod または仮想マシンが必要なインターフェイスを使用できるように、複数の CNI が存在できるようにするクラウドネットワークインターフェイス (CNI) プラグインです。
設定を適用します。
$ oc apply -f <example-vm.yaml>
- オプション: 実行中の仮想マシンを編集している場合は、変更を有効にするためにこれを再起動する必要があります。
8.17.4. 仮想マシンの IP アドレスの設定
動的または静的のいずれかでプロビジョニングされた仮想マシンの IP アドレスを設定できます。
前提条件
- 仮想マシンは、外部ネットワーク に接続する必要があります。
- 仮想マシンの動的 IP を設定するには、追加のネットワークで使用可能な DHCP サーバーが必要です。
8.17.4.1. cloud-init を使用した新規仮想マシンの IP アドレスの設定
仮想マシンの作成時に cloud-init を使用して IP アドレスを設定できます。IP アドレスは、動的または静的にプロビジョニングできます。
手順
仮想マシン設定を作成し、仮想マシン設定の
spec.volumes.cloudInitNoCloud.networkData
フィールドに cloud-init ネットワークの詳細を追加します。動的 IP を設定するには、インターフェイス名と
dhcp4
ブール値を指定します。kind: VirtualMachine spec: ... volumes: - cloudInitNoCloud: networkData: | version: 2 ethernets: eth1: 1 dhcp4: true 2
静的 IP を設定するには、インターフェイス名と IP アドレスを指定します。
kind: VirtualMachine spec: ... volumes: - cloudInitNoCloud: networkData: | version: 2 ethernets: eth1: 1 addresses: - 10.10.10.14/24 2
8.17.5. 仮想マシンの SR-IOV ネットワークデバイスの設定
クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。このプロセスは、OpenShift Container Platform の SR-IOV デバイスの設定と似ていますが、同じではありません。
ライブマイグレーションは、HyperConverged Cluster カスタムリソース (CR) で sriovLiveMigration
機能ゲートが有効にされている場合にのみ、SR-IOV ネットワークインターフェイスに接続されている仮想マシンでサポートされます。spec.featureGates.sriovLiveMigration
フィールドが true
に設定されている場合、virt-launcher
Pod は SYS_RESOURCE
機能と共に実行されます。これにより、セキュリティーのレベルが低下する可能性があります。
8.17.5.1. 前提条件
8.17.5.2. SR-IOV ネットワークデバイスの自動検出
SR-IOV Network Operator は、クラスターでワーカーノード上の SR-IOV 対応ネットワークデバイスを検索します。Operator は、互換性のある SR-IOV ネットワークデバイスを提供する各ワーカーノードの SriovNetworkNodeState カスタムリソース (CR) を作成し、更新します。
CR にはワーカーノードと同じ名前が割り当てられます。status.interfaces
一覧は、ノード上のネットワークデバイスについての情報を提供します。
SriovNetworkNodeState
オブジェクトは変更しないでください。Operator はこれらのリソースを自動的に作成し、管理します。
8.17.5.2.1. SriovNetworkNodeState オブジェクトの例
以下の YAML は、SR-IOV Network Operator によって作成される SriovNetworkNodeState
オブジェクトの例です。
SriovNetworkNodeState オブジェクト
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodeState metadata: name: node-25 1 namespace: openshift-sriov-network-operator ownerReferences: - apiVersion: sriovnetwork.openshift.io/v1 blockOwnerDeletion: true controller: true kind: SriovNetworkNodePolicy name: default spec: dpConfigVersion: "39824" status: interfaces: 2 - deviceID: "1017" driver: mlx5_core mtu: 1500 name: ens785f0 pciAddress: "0000:18:00.0" totalvfs: 8 vendor: 15b3 - deviceID: "1017" driver: mlx5_core mtu: 1500 name: ens785f1 pciAddress: "0000:18:00.1" totalvfs: 8 vendor: 15b3 - deviceID: 158b driver: i40e mtu: 1500 name: ens817f0 pciAddress: 0000:81:00.0 totalvfs: 64 vendor: "8086" - deviceID: 158b driver: i40e mtu: 1500 name: ens817f1 pciAddress: 0000:81:00.1 totalvfs: 64 vendor: "8086" - deviceID: 158b driver: i40e mtu: 1500 name: ens803f0 pciAddress: 0000:86:00.0 totalvfs: 64 vendor: "8086" syncStatus: Succeeded
8.17.5.3. SR-IOV ネットワークデバイスの設定
SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io
CustomResourceDefinition を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。
SriovNetworkNodePolicy
オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。
設定の変更が適用されるまでに数分かかる場合があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされている。
- ドレイン (解放) されたノードからエビクトされたワークロードを処理するために、クラスター内に利用可能な十分なノードがあること。
- SR-IOV ネットワークデバイス設定についてコントロールプレーンノードを選択していないこと。
手順
SriovNetworkNodePolicy
オブジェクトを作成してから、YAML を<name>-sriov-node-network.yaml
ファイルに保存します。<name>
をこの設定の名前に置き換えます。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: <name> 1 namespace: openshift-sriov-network-operator 2 spec: resourceName: <sriov_resource_name> 3 nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" 4 priority: <priority> 5 mtu: <mtu> 6 numVfs: <num> 7 nicSelector: 8 vendor: "<vendor_code>" 9 deviceID: "<device_id>" 10 pfNames: ["<pf_name>", ...] 11 rootDevices: ["<pci_bus_id>", "..."] 12 deviceType: vfio-pci 13 isRdma: false 14
- 1
- CR オブジェクトの名前を指定します。
- 2
- SR-IOV Operator がインストールされている namespace を指定します。
- 3
- SR-IOV デバイスプラグインのリソース名を指定します。1 つのリソース名に複数の
SriovNetworkNodePolicy
オブジェクトを作成できます。 - 4
- 設定するノードを選択するノードセレクターを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
- 5
- オプション:
0
から99
までの整数値を指定します。数値が小さいほど優先度が高くなります。したがって、10
は99
よりも優先度が高くなります。デフォルト値は99
です。 - 6
- オプション: 仮想機能 (VF) の最大転送単位 (MTU) の値を指定します。MTU の最大値は NIC モデルによって異なります。
- 7
- SR-IOV 物理ネットワークデバイス用に作成する仮想機能 (VF) の数を指定します。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は
128
よりも大きくすることはできません。 - 8
nicSelector
マッピングは、Operator が設定するイーサネットデバイスを選択します。すべてのパラメーターの値を指定する必要はありません。意図せずにイーサネットデバイスを選択する可能性を最低限に抑えるために、イーサネットアダプターを正確に特定できるようにすることが推奨されます。rootDevices
を指定する場合、vendor
、deviceID
、またはpfName
の値も指定する必要があります。pfNames
とrootDevices
の両方を同時に指定する場合、それらが同一のデバイスをポイントすることを確認します。- 9
- オプション: SR-IOV ネットワークデバイスのベンダー 16 進コードを指定します。許可される値は
8086
または15b3
のいずれかのみになります。 - 10
- オプション: SR-IOV ネットワークデバイスのデバイス 16 進コードを指定します。許可される値は
158b
、1015
、1017
のみになります。 - 11
- オプション: このパラメーターは、1 つ以上のイーサネットデバイスの物理機能 (PF) 名の配列を受け入れます。
- 12
- このパラメーターは、イーサネットデバイスの物理機能についての 1 つ以上の PCI バスアドレスの配列を受け入れます。以下の形式でアドレスを指定します:
0000:02:00.1
- 13
- OpenShift Virtualization の仮想機能には、
vfio-pci
ドライバータイプが必要です。 - 14
- オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを指定します。Mellanox カードの場合、
isRdma
をfalse
に設定します。デフォルト値はfalse
です。
注記isRDMA
フラグがtrue
に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。-
オプション: SR-IOV 対応のクラスターノードにまだラベルが付いていない場合は、
SriovNetworkNodePolicy.Spec.NodeSelector
でラベルを付けます。ノードのラベル付けについて、詳しくはノードのラベルを更新する方法についてを参照してください。 SriovNetworkNodePolicy
オブジェクトを作成します。$ oc create -f <name>-sriov-node-network.yaml
ここで、
<name>
はこの設定の名前を指定します。設定の更新が適用された後に、
sriov-network-operator
namespace のすべての Pod がRunning
ステータスに移行します。SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。
<node_name>
を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
8.17.5.4. 次のステップ
8.17.6. SR-IOV ネットワークの定義
仮想マシンの Single Root I/O Virtualization (SR-IOV) デバイスのネットワーク割り当てを作成できます。
ネットワークが定義された後に、仮想マシンを SR-IOV ネットワークに割り当てることができます。
8.17.6.1. 前提条件
8.17.6.2. SR-IOV の追加ネットワークの設定
SriovNetwork
オブジェクト を作成して、SR-IOV ハードウェアを使用する追加のネットワークを設定できます。SriovNetwork
オブジェクトの作成時に、SR-IOV Operator は NetworkAttachmentDefinition
オブジェクトを自動的に作成します。
次に、ユーザーはネットワークを仮想マシン設定で指定することで、仮想マシンを SR-IOV ネットワークに割り当てることができます。
SriovNetwork
オブジェクトが running
状態の Pod または仮想マシンに割り当てられている場合、これを変更したり、削除したりしないでください。
前提条件
-
OpenShift CLI (
oc
) をインストールしている。 -
cluster-admin
権限を持つユーザーとしてログインすること。
手順
-
以下の
SriovNetwork
オブジェクトを作成してから、YAML を<name>-sriov-network.yaml
ファイルに保存します。<name>
を、この追加ネットワークの名前に置き換えます。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: <name> 1 namespace: openshift-sriov-network-operator 2 spec: resourceName: <sriov_resource_name> 3 networkNamespace: <target_namespace> 4 vlan: <vlan> 5 spoofChk: "<spoof_check>" 6 linkState: <link_state> 7 maxTxRate: <max_tx_rate> 8 minTxRate: <min_rx_rate> 9 vlanQoS: <vlan_qos> 10 trust: "<trust_vf>" 11 capabilities: <capabilities> 12
- 1
<name>
をオブジェクトの名前に置き換えます。SR-IOV Network Operator は、同じ名前を持つNetworkAttachmentDefinition
オブジェクトを作成します。- 2
- SR-IOV ネットワーク Operator がインストールされている namespace を指定します。
- 3
<sriov_resource_name>
を、この追加ネットワークの SR-IOV ハードウェアを定義するSriovNetworkNodePolicy
オブジェクトの.spec.resourceName
パラメーターの値に置き換えます。- 4
<target_namespace>
を SriovNetwork のターゲット namespace に置き換えます。ターゲット namespace の Pod または仮想マシンのみを SriovNetwork に割り当てることができます。- 5
- オプション:
<vlan>
を、追加ネットワークの仮想 LAN (VLAN) ID に置き換えます。整数値は0
から4095
である必要があります。デフォルト値は0
です。 - 6
- オプション:
<spoof_check>
を VF の spoof check モードに置き換えます。許可される値は、文字列の"on"
および"off"
です。重要指定する値を引用符で囲む必要があります。そうしないと、CR は SR-IOV ネットワーク Operator によって拒否されます。
- 7
- オプション:
<link_state>
を仮想機能 (VF) のリンクの状態に置き換えます。許可される値は、enable
、disable
、およびauto
です。 - 8
- オプション:
<max_tx_rate>
を VF の最大伝送レート (Mbps) に置き換えます。 - 9
- オプション:
<min_tx_rate>
を VF の最小伝送レート (Mbps) に置き換えます。この値は、常に最大伝送レート以下である必要があります。注記Intel NIC は
minTxRate
パラメーターをサポートしません。詳細は、BZ#1772847 を参照してください。 - 10
- オプション:
<vlan_qos>
を VF の IEEE 802.1p 優先レベルに置き換えます。デフォルト値は0
です。 - 11
- オプション:
<trust_vf>
を VF の信頼モードに置き換えます。許可される値は、文字列の"on"
および"off"
です。重要指定する値を引用符で囲む必要があります。そうしないと、CR は SR-IOV ネットワーク Operator によって拒否されます。
- 12
- オプション:
<capabilities>
を、このネットワークに設定する機能に置き換えます。
オブジェクトを作成するには、以下のコマンドを入力します。
<name>
を、この追加ネットワークの名前に置き換えます。$ oc create -f <name>-sriov-network.yaml
オプション: 以下のコマンドを実行して、直前の手順で作成した
SriovNetwork
オブジェクトに関連付けられたNetworkAttachmentDefinition
オブジェクトが存在することを確認するには、以下のコマンドを入力します。<namespace>
を、SriovNetwork
オブジェクト で指定した namespace に置き換えます。$ oc get net-attach-def -n <namespace>
8.17.6.3. 次のステップ
8.17.7. 仮想マシンの SR-IOV ネットワークへの割り当て
SR-IOV (Single Root I/O Virtualization) ネットワークをセカンダリーネットワークとして使用するために仮想マシンを割り当てることができます。
8.17.7.1. 前提条件
8.17.7.2. 仮想マシンの SR-IOV ネットワークへの割り当て
仮想マシンの設定にネットワークの詳細を含めることで、仮想マシンを SR-IOV ネットワークに割り当てることができます。
手順
SR-IOV ネットワークの詳細を仮想マシン設定の
spec.domain.devices.interfaces
およびspec.networks
に追加します。kind: VirtualMachine ... spec: domain: devices: interfaces: - name: <default> 1 masquerade: {} 2 - name: <nic1> 3 sriov: {} networks: - name: <default> 4 pod: {} - name: <nic1> 5 multus: networkName: <sriov-network> 6 ...
仮想マシン設定を適用します。
$ oc apply -f <vm-sriov.yaml> 1
- 1
- 仮想マシン YAML ファイルの名前。
8.17.8. NIC の IP アドレスの仮想マシンへの表示
Web コンソールまたは oc
クライアントを使用して、ネットワークインターフェイスコントローラー (NIC) の IP アドレスを表示できます。QEMU ゲストエージェント は、仮想マシンのセカンダリーネットワークに関する追加情報を表示します。
8.17.8.1. CLI での仮想マシンインターフェイスの IP アドレスの表示
ネットワークインターフェイス設定は oc describe vmi <vmi_name>
コマンドに含まれます。
IP アドレス情報は、仮想マシン上で ip addr
を実行するか、または oc get vmi <vmi_name> -o yaml
を実行して表示することもできます。
手順
oc describe
コマンドを使用して、仮想マシンインターフェイス設定を表示します。$ oc describe vmi <vmi_name>
出力例
... Interfaces: Interface Name: eth0 Ip Address: 10.244.0.37/24 Ip Addresses: 10.244.0.37/24 fe80::858:aff:fef4:25/64 Mac: 0a:58:0a:f4:00:25 Name: default Interface Name: v2 Ip Address: 1.1.1.7/24 Ip Addresses: 1.1.1.7/24 fe80::f4d9:70ff:fe13:9089/64 Mac: f6:d9:70:13:90:89 Interface Name: v1 Ip Address: 1.1.1.1/24 Ip Addresses: 1.1.1.1/24 1.1.1.2/24 1.1.1.4/24 2001:de7:0:f101::1/64 2001:db8:0:f101::1/64 fe80::1420:84ff:fe10:17aa/64 Mac: 16:20:84:10:17:aa
8.17.8.2. Web コンソールでの仮想マシンインターフェイスの IP アドレスの表示
IP 情報は、仮想マシンの Virtual Machine Overview 画面に表示されます。
手順
-
OpenShift Virtualization コンソールのサイドメニューから Workloads
Virtualization をクリックします。 - Virtual Machines タブをクリックします。
- 仮想マシン名を選択して、Virtual Machine Overview 画面を開きます。
それぞれの割り当てられた NIC の情報は IP Address の下に表示されます。
8.17.9. 仮想マシンの MAC アドレスプールの使用
KubeMacPool コンポーネントは、指定の namespace の仮想マシン NIC に MAC アドレスプールサービスを提供します。
8.17.9.1. KubeMacPool について
KubeMacPool は namespace ごとに MAC アドレスプールを提供し、プールから仮想マシン NIC の MAC アドレスを割り当てます。これにより、NIC には別の仮想マシンの MAC アドレスと競合しない一意の MAC アドレスが割り当てられます。
仮想マシンから作成される仮想マシンインスタンスは、再起動時に割り当てられる MAC アドレスを保持します。
KubeMacPool は、仮想マシンから独立して作成される仮想マシンインスタンスを処理しません。
KubeMacPool は、OpenShift Virtualization のインストール時にデフォルトで有効化されます。namespace の MAC アドレスプールは、mutatevirtualmachines.kubemacpool.io=ignore
ラベルを namespace に追加して無効にできます。ラベルを削除して、namespace の KubeMacPool を再度有効にします。
8.17.9.2. CLI での namespace の MAC アドレスプールの無効化
mutatevirtualmachines.kubemacpool.io=ignore
ラベルを namespace に追加して、namespace の仮想マシンの MAC アドレスプールを無効にします。
手順
mutatevirtualmachines.kubemacpool.io=ignore
ラベルを namespace に追加します。以下の例では、KubeMacPool を 2 つの namespace (<namespace1>
および<namespace2>
) について無効にします。$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io=ignore
8.17.9.3. CLI での namespace の MAC アドレスプールを再度有効にする
namespace の KubeMacPool を無効にしている場合で、これを再度有効にする必要がある場合は、namespace から mutatevirtualmachines.kubemacpool.io=ignore
ラベルを削除します。
以前のバージョンの OpenShift Virtualization では、mutatevirtualmachines.kubemacpool.io=allocate
ラベルを使用して namespace の KubeMacPool を有効にしていました。これは引き続きサポートされますが、KubeMacPool がデフォルトで有効化されるようになったために不要になります。
手順
KubeMacPool ラベルを namespace から削除します。以下の例では、KubeMacPool を 2 つの namespace (
<namespace1>
および<namespace2>
) について再度有効にします。$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io-