7.17. 仮想マシンのネットワーク
7.17.1. デフォルトの Pod ネットワーク用の仮想マシンの設定
masquerade
バインディングモードを使用するようにネットワークインターフェイスを設定することで、仮想マシンをデフォルトの内部 Pod ネットワークに接続できます。
KubeMacPool コンポーネントは、指定の namespace に仮想マシン NIC の MAC アドレスプールサービスを提供します。これはデフォルトで有効にされません。KubeMacPool ラベルをその namespace に適用して、namespace の MAC アドレスプールを有効にします。
7.17.1.1. コマンドラインでのマスカレードモードの設定
マスカレードモードを使用し、仮想マシンの送信トラフィックを Pod IP アドレスの背後で非表示にすることができます。マスカレードモードは、ネットワークアドレス変換 (NAT) を使用して仮想マシンを Linux ブリッジ経由で Pod ネットワークバックエンドに接続します。
仮想マシンの設定ファイルを編集して、マスカレードモードを有効にし、トラフィックが仮想マシンに到達できるようにします。
前提条件
- 仮想マシンは、IPv4 アドレスを取得するために DHCP を使用できるように設定される必要がある。以下の例では、DHCP を使用するように設定されます。
手順
仮想マシン設定ファイルの
interfaces
仕様を編集します。kind: VirtualMachine spec: domain: devices: interfaces: - name: default masquerade: {} 1 ports: - port: 80 2 networks: - name: default pod: {}
注記ポート 49152 および 49153 は libvirt プラットフォームで使用するために予約され、これらのポートへの他のすべての受信トラフィックは破棄されます。
仮想マシンを作成します。
$ oc create -f <vm-name>.yaml
7.17.1.2. 仮想マシンからのサービスの作成
仮想マシンを公開するために Service
オブジェクトを最初に作成し、実行中の仮想マシンからサービスを作成します。
ClusterIP
サービスタイプは、クラスター内で仮想マシンを内部に公開します。NodePort
または LoadBalancer
サービスタイプは、クラスター外から仮想マシンを外部に公開します。
この手順では、type: ClusterIP
の Service
オブジェクトを仮想マシンバックエンドサービスとして作成し、これに接続し、公開する方法についての例を示します。
ClusterIP
は、サービスの type
が指定されていない場合のデフォルトサービスの type
です。
手順
以下のように仮想マシンの YAML を編集します。
apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-ephemeral namespace: example-namespace spec: running: false template: metadata: labels: special: key 1 spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - masquerade: {} name: default resources: requests: memory: 1024M networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-container-disk-demo - name: cloudinitdisk cloudInitNoCloud: userData: | #!/bin/bash echo "fedora" | passwd fedora --stdin
- 1
- ラベル
special: key
をspec.template.metadata.labels
セクションに追加します。
注記仮想マシンのラベルは Pod に渡されます。
VirtualMachine
設定のラベル (例:special: key
) は、この手順の後で作成するService
YAMLselector
属性のラベルに一致する必要があります。- 仮想マシン YAML を保存して変更を適用します。
Service
YAML を編集し、Service
オブジェクトを作成し、公開するために必要な設定を行います。apiVersion: v1 kind: Service metadata: name: vmservice 1 namespace: example-namespace 2 spec: ports: - port: 27017 protocol: TCP targetPort: 22 3 selector: special: key 4 type: ClusterIP 5
- 1
- 作成および公開するサービスの
name
を指定します。 - 2
- 仮想マシン YAML に指定する
namespace
に対応するService
YAML のmetadata
セクションのnamespace
を指定します。 - 3
targetPort: 22
を追加し、SSH ポート22
にサービスを公開します。- 4
Service
YAML のspec
セクションで、special: key
をselector
属性に追加します。これは、仮想マシン YAML 設定ファイルに追加したlabels
に対応します。- 5
Service
YAML のspec
セクションで、ClusterIP サービスのtype: ClusterIP
を追加します。NodePort
やLoadBalancer
などのクラスター外にある他のタイプのサービスを作成し、公開するには、type: ClusterIP
をtype: NodePort
またはtype: LoadBalancer
に随時置き換えます。
-
Service
YAML を保存し、サービス設定を保管します。 ClusterIP
サービスを作成します。$ oc create -f <service_name>.yaml
- 仮想マシンを起動します。仮想マシンがすでに実行中の場合は、これを再起動します。
Service
オブジェクトをクエリーし、これが利用可能であり、ClusterIP
タイプで設定されていることを確認します。検証
oc get service
コマンドを実行し、仮想マシンで参照するnamespace
およびService
YAML ファイルを指定します。$ oc get service -n example-namespace
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice ClusterIP 172.30.3.149 <none> 27017/TCP 2m
-
出力で示されているように、
vmservice
が実行されています。 -
TYPE
は、Service
YAML で指定したようにClusterIP
として表示されます。
-
出力で示されているように、
サービスをサポートするために使用する仮想マシンへの接続を確立します。別の仮想マシンなど、クラスター内のオブジェクトから接続します。
以下のように仮想マシンの YAML を編集します。
apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-connect namespace: example-namespace spec: running: false template: spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - masquerade: {} name: default resources: requests: memory: 1024M networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-container-disk-demo - name: cloudinitdisk cloudInitNoCloud: userData: | #!/bin/bash echo "fedora" | passwd fedora --stdin
oc create
コマンドを実行して 2 番目の仮想マシンを作成します。ここで、file.yaml
は仮想マシン YAML の名前になります。$ oc create -f <file.yaml>
- 仮想マシンを起動します。
以下の
virtctl
コマンドを実行して仮想マシンに接続します。$ virtctl -n example-namespace console <new-vm-name>
注記サービスタイプ
LoadBalancer
の場合、vinagre
クライアントを使用し、パブリック IP およびポートを使用して仮想マシンに接続します。外部ポートは、サービスタイプLoadBalancer
を使用する場合に動的に割り当てられます。ssh
コマンドを実行して接続を認証します。ここで、172.30.3.149
はサービスの ClusterIP であり、fedora
は仮想マシンのユーザー名です。$ ssh fedora@172.30.3.149 -p 27017
検証
- 公開するサービスをサポートする仮想マシンのコマンドプロンプトが表示されます。実行中の仮想マシンがサポートするサービスの準備ができました。
7.17.2. Linux ブリッジ ネットワークへの仮想マシンの接続
デフォルトでは、OpenShift Virtualization は単一の内部 Pod ネットワークとともにインストールされます。
追加のネットワークに接続するには、Linux ブリッジ ネットワーク接続定義 (NAD) を作成する必要があります。
仮想マシンを追加のネットワークに割り当てるには、以下を実行します。
- Linux ブリッジ ノード ネットワーク設定ポリシーを作成します。
- Linux ブリッジ ネットワーク接続定義を作成します。
- 仮想マシンを設定して、仮想マシンがネットワーク接続定義を認識できるようにします。
スケジューリング、インターフェイスタイプ、およびその他のノードのネットワークアクティビティーについての詳細は、node networking セクションを参照してください。
7.17.2.1. ネットワーク接続定義によるネットワークへの接続
7.17.2.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
7.17.2.2. Linux ブリッジネットワーク接続定義の作成
7.17.2.2.1. 前提条件
- Linux ブリッジは、すべてのノードに設定して割り当てる必要がある。詳細は、ノードのネットワーク セクションを参照してください。
仮想マシンのネットワークアタッチメント定義での IP アドレス管理 (IPAM) の設定はサポートされていません。
7.17.2.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 に接続するための最も効率的な方法です。
7.17.2.2.3. CLI での Linux ブリッジネットワーク接続定義の作成
ネットワーク管理者は、タイプ cnv-bridge
のネットワーク接続定義を、レイヤー 2 ネットワークを Pod および仮想マシンに提供するように設定できます。
前提条件
-
MAC スプーフィングチェックを有効にするには、ノードが nftables をサポートして、
nft
バイナリーがデプロイされている必要があります。
手順
- 仮想マシンと同じ 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>
7.17.2.3. Linux ブリッジネットワーク用の仮想マシンの設定
7.17.2.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 を保存し、これを仮想マシンに割り当てます。
7.17.2.3.2. ネットワークフィールド
名前 | 説明 |
---|---|
名前 | ネットワークインターフェイスコントローラーの名前。 |
モデル | ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
ネットワーク | 利用可能なネットワーク接続定義の一覧。 |
Type |
利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、 |
MAC Address | ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
7.17.2.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/v1alpha3 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: <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>
- オプション: 実行中の仮想マシンを編集している場合は、変更を有効にするためにこれを再起動する必要があります。
7.17.3. 仮想マシンの IP アドレスの設定
動的または静的のいずれかでプロビジョニングされた仮想マシンの IP アドレスを設定できます。
前提条件
- 仮想マシンは、外部ネットワーク に接続する必要があります。
- 仮想マシンの動的 IP を設定するには、追加のネットワークで使用可能な DHCP サーバーが必要です。
7.17.3.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
7.17.4. 仮想マシンの SR-IOV ネットワークデバイスの設定
クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。このプロセスは、OpenShift Container Platform の SR-IOV デバイスの設定と似ていますが、同じではありません。
ライブマイグレーションは SR-IOV ネットワークインターフェイスに接続されている仮想マシンにはサポートされません。
7.17.4.1. 前提条件
7.17.4.2. SR-IOV ネットワークデバイスの自動検出
SR-IOV Network Operator は、クラスターでワーカーノード上の SR-IOV 対応ネットワークデバイスを検索します。Operator は、互換性のある SR-IOV ネットワークデバイスを提供する各ワーカーノードの SriovNetworkNodeState カスタムリソース (CR) を作成し、更新します。
CR にはワーカーノードと同じ名前が割り当てられます。status.interfaces
一覧は、ノード上のネットワークデバイスについての情報を提供します。
SriovNetworkNodeState
オブジェクトは変更しないでください。Operator はこれらのリソースを自動的に作成し、管理します。
7.17.4.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
7.17.4.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
でラベルを付けます。ノードのラベル付けについて、詳しくはノードのラベルを更新する方法についてを参照してください。
-
オプション: SR-IOV 対応のクラスターノードにまだラベルが付いていない場合は、
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}'
7.17.4.4. 次のステップ
7.17.5. SR-IOV ネットワークの定義
仮想マシンの Single Root I/O Virtualization (SR-IOV) デバイスのネットワーク割り当てを作成できます。
ネットワークが定義された後に、仮想マシンを SR-IOV ネットワークに割り当てることができます。
7.17.5.1. 前提条件
7.17.5.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>
7.17.5.3. 次のステップ
7.17.6. 仮想マシンの SR-IOV ネットワークへの割り当て
SR-IOV (Single Root I/O Virtualization) ネットワークをセカンダリーネットワークとして使用するために仮想マシンを割り当てることができます。
7.17.6.1. 前提条件
7.17.6.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 ファイルの名前。
7.17.7. NIC の IP アドレスの仮想マシンへの表示
Web コンソールまたは oc
クライアントを使用して、ネットワークインターフェイスコントローラー (NIC) の IP アドレスを表示できます。QEMU ゲストエージェント は、仮想マシンのセカンダリーネットワークに関する追加情報を表示します。
7.17.7.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
7.17.7.2. Web コンソールでの仮想マシンインターフェイスの IP アドレスの表示
IP 情報は、仮想マシンの Virtual Machine Overview 画面に表示されます。
手順
-
OpenShift Virtualization コンソールのサイドメニューから Workloads
Virtualization をクリックします。 - Virtual Machines タブをクリックします。
- 仮想マシン名を選択して、Virtual Machine Overview 画面を開きます。
それぞれの割り当てられた NIC の情報は IP Address の下に表示されます。
7.17.8. 仮想マシンの MAC アドレスプールの使用
KubeMacPool コンポーネントは、指定の namespace に仮想マシン NIC の MAC アドレスプールサービスを提供します。KubeMacPool ラベルをその namespace に適用して、namespace の MAC アドレスプールを有効にします。
7.17.8.1. KubeMacPool について
namespace の KubeMacPool コンポーネントを有効にする場合、その namespace の仮想マシン NIC には MAC アドレスプールから MAC アドレスが割り当てられます。これにより、NIC には別の仮想マシンの MAC アドレスと競合しない一意の MAC アドレスが割り当てられます。
仮想マシンから作成される仮想マシンインスタンスは、再起動時に割り当てられる MAC アドレスを保持します。
KubeMacPool は、仮想マシンから独立して作成される仮想マシンインスタンスを処理しません。
KubeMacPool はデフォルトで無効にされます。KubeMacPool ラベルを namespace に適用して、namespace の MAC アドレスプールを有効にします。
7.17.8.2. CLI での namespace の MAC アドレスプールの有効化
mutatevirtualmachines.kubemacpool.io=allocate
ラベルを namespace に適用して namespace の仮想マシンの MAC アドレスプールを有効にします。
手順
KubeMacPool ラベルを namespace に追加します。以下の例では、KubeMacPool ラベルを 2 つの namespace (
<namespace1>
および<namespace2>
) に追加します。$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io=allocate
7.17.8.3. CLI での namespace の MAC アドレスプールの無効化
mutatevirtualmachines.kubemacpool.io
ラベルを削除して、namespace の仮想マシンの MAC アドレスプールを無効にします。
手順
KubeMacPool ラベルを namespace から削除します。以下の例では、KubeMacPool ラベルを 2 つの namespace (
<namespace1>
および<namespace2>
) から削除します。$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io-