Virtualization
OpenShift Virtualization のインストール、使用方法、およびリリースノート
概要
第1章 概要 リンクのコピーリンクがクリップボードにコピーされました!
1.1. OpenShift Virtualization について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization の機能およびサポート範囲を確認します。
1.1.1. OpenShift Virtualization の機能 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization は OpenShift Container Platform のアドオンであり、仮想マシンのワークロードを実行し、このワークロードをコンテナーのワークロードと共に管理することを可能にします。
OpenShift Virtualization は、Kubernetes カスタムリソースにより新規オブジェクトを OpenShift Container Platform クラスターに追加し、仮想化タスクを有効にします。これらのタスクには、以下が含まれます。
- Linux および Windows 仮想マシン (VM) の作成と管理
- クラスター内で Pod と仮想マシンのワークロードの同時実行
- 各種コンソールおよび CLI ツールの使用による仮想マシンへの接続
- 既存の仮想マシンのインポートおよびクローン作成
- ネットワークインターフェイスコントローラーおよび仮想マシンに割り当てられたストレージディスクの管理
- 仮想マシンのノード間でのライブマイグレーション
機能強化された Web コンソールは、これらの仮想化されたリソースを OpenShift Container Platform クラスターコンテナーおよびインフラストラクチャーと共に管理するためのグラフィカルポータルを提供します。
OpenShift Virtualization は、Red Hat OpenShift Data Foundation の機能とうまく連携するように設計およびテストされています。
OpenShift Data Foundation を使用して OpenShift Virtualization をデプロイする場合は、Windows 仮想マシンディスク用の専用ストレージクラスを作成する必要があります。詳細は Optimizing ODF PersistentVolumes for Windows VMs を参照してください。
OpenShift Virtualization は、OVN-Kubernetes、OpenShift SDN、または 認定 OpenShift CNI プラグイン にリストされているその他の認定ネットワークプラグインのいずれかで使用できます。
Compliance Operator をインストールし、ocp4-moderate および ocp4-moderate-nodeプロファイル を使用してスキャンを実行することで、OpenShift Virtualization クラスターのコンプライアンス問題を確認できます。Compliance Operator は、NIST 認定ツール である OpenSCAP を使用して、セキュリティーポリシーをスキャンし、適用します。
特殊なストレージ、ネットワーク、バックアップ、および追加機能に関して、独立系ソフトウェアベンダー (ISV) およびサービスパートナーと連携する方法は、Red Hat Ecosystem Catalog を参照してください。
1.1.1.1. OpenShift Virtualization サポートのクラスターバージョン リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization 4.16 の最新の安定リリースは 4.16.21 です。
OpenShift Virtualization 4.16 は、OpenShift Container Platform 4.16 クラスターでの使用がサポートされます。OpenShift Virtualization の最新の z-stream リリースを使用するには、最初に OpenShift Container Platform の最新バージョンにアップグレードする必要があります。
1.1.2. 仮想マシンディスクのボリュームとアクセスモードについて リンクのコピーリンクがクリップボードにコピーされました!
既知のストレージプロバイダーでストレージ API を使用する場合、ボリュームモードとアクセスモードは自動的に選択されます。ただし、ストレージプロファイルのないストレージクラスを使用する場合は、ボリュームとアクセスモードを設定する必要があります。
OpenShift Virtualization に対応している既知のストレージプロバイダーのリストは、Red Hat Ecosystem Catalog を参照してください。
最良の結果を得るには、ReadWriteMany (RWX) アクセスモードと Block ボリュームモードを使用してください。これは、以下の理由により重要です。
-
ライブマイグレーションには
ReadWriteMany(RWX) アクセスモードが必要です。 Blockボリュームモードは、Filesystemボリュームモードよりもパフォーマンスが大幅に優れています。これは、Filesystemボリュームモードでは、ファイルシステムレイヤーやディスクイメージファイルなどを含め、より多くのストレージレイヤーが使用されるためです。仮想マシンのディスクストレージに、これらのレイヤーは必要ありません。たとえば、Red Hat OpenShift Data Foundation を使用する場合は、CephFS ボリュームよりも Ceph RBD ボリュームの方が推奨されます。
次の設定の仮想マシンをライブマイグレーションすることはできません。
-
ReadWriteOnce(RWO) アクセスモードのストレージボリューム - GPU などのパススルー機能
これらの仮想マシンの evictionStrategy フィールドを None に設定します。None ストラテジーでは、ノードの再起動中に仮想マシンの電源がオフになります。
1.1.3. シングルノード OpenShift の違い リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization はシングルノード OpenShift にインストールできます。
ただし、シングルノード OpenShift は次の機能をサポートしていないことに注意してください。
- 高可用性
- Pod の中断
- ライブマイグレーション
- エビクションストラテジーが設定されている仮想マシンまたはテンプレート
1.2. 適用される制限 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization 用の OpenShift Container Platform 環境を計画するときには、オブジェクトのテスト済み最大値を参考にしてください。ただし、最大値に近いと、パフォーマンスが低下し、レイテンシーが増加する可能性があります。必ず具体的なユースケースを計画し、クラスターのスケーリングに影響を与える可能性のあるすべての要素を考慮してください。
クラスター設定とパフォーマンスに影響するオプションの詳細は、Red Hat ナレッジベースの OpenShift Virtualization - Tuning & Scaling Guide を参照してください。
1.2.1. OpenShift Virtualization のテスト済み最大値 リンクのコピーリンクがクリップボードにコピーされました!
大規模な OpenShift Virtualization 4.x 環境には、次の制限が適用されます。これらの制限は、作成可能な最大サイズの単一クラスターに基づくものです。環境を計画するときは、複数の小規模なクラスターがユースケースに最適な選択肢になる可能性があることに留意してください。
1.2.1.1. 仮想マシンの最大値 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization 上で実行される仮想マシン (VM) には、次の最大値が適用されます。これらの値は、Virtualization limits for Red Hat Enterprise Linux with KVM に記載されている制限に準じます。
| 対象 (仮想マシンあたり) | テスト済みの制限 | 理論上の制限 |
|---|---|---|
| 仮想 CPU | 216 個の仮想 CPU | 255 個の仮想 CPU |
| メモリー | 6 TB | 16 TB |
| 1 つのディスクのサイズ | 20 TB | 100 TB |
| ホットプラグ可能なディスク | 255 個のディスク | 該当なし |
各仮想マシンには少なくとも 512 MB のメモリーが必要です。
1.2.1.2. ホストの最大値 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization に使用される OpenShift Container Platform ホストには、次の最大値が適用されます。
| 対象 (ホストあたり) | テスト済みの制限 | 理論上の制限 |
|---|---|---|
| 論理 CPU コアまたはスレッド | Red Hat Enterprise Linux (RHEL) と同じ | N/A |
| RAM | RHEL と同じ | 該当なし |
| 同時ライブマイグレーション | デフォルトでは、ノードあたり 2 つのアウトバウンドマイグレーション、クラスターあたり 5 つの同時マイグレーション | NIC 帯域幅に依存 |
| ライブマイグレーション帯域幅 | デフォルトの制限なし | NIC 帯域幅に依存 |
1.2.1.3. クラスターの最大値 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization で定義されたオブジェクトには、次の最大値が適用されます。
| 対象 (クラスターあたり) | テスト済みの制限 | 理論上の制限 |
|---|---|---|
| ノードあたりの接続 PV 数 | 該当なし | CSI ストレージプロバイダーに依存 |
| PV 最大サイズ | 該当なし | CSI ストレージプロバイダーに依存 |
| ホスト | 500 台のホスト (100 以下を推奨) [1] | OpenShift Container Platform と同じ |
| 定義された仮想マシン | 10,000 台の仮想マシン [2] | OpenShift Container Platform と同じ |
100 を超えるノードを使用する場合は、単一のコントロールプレーンをスケールアウトするのではなく、Red Hat Advanced Cluster Management (RHACM) を使用して複数のクラスターを管理することを検討してください。クラスターが大きくなると複雑さが増し、更新に長い時間が必要になります。また、ノードのサイズとオブジェクトの合計密度によっては、コントロールプレーンのストレスが増加する可能性があります。
複数のクラスターを使用すると、クラスターごとの分離や高可用性などの面でメリットが得られます。
ノードあたりの仮想マシンの最大数は、ホストのハードウェアとリソース容量によって異なります。また、次のパラメーターによって制限されます。
-
ノードにスケジュールできる Pod の数を制限する設定。たとえば、
maxPodsなどです。 -
KVM デバイスのデフォルトの数。たとえば、
devices.kubevirt.io/kvm: 1kなどです。
-
ノードにスケジュールできる Pod の数を制限する設定。たとえば、
1.3. セキュリティーポリシー リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization のセキュリティーと認可を説明します。
主なポイント
-
OpenShift Virtualization は、Pod セキュリティーの現在のベストプラクティスを強制することを目的とした、
restrictedKubernetes pod security standards プロファイルに準拠しています。 - 仮想マシン (VM) のワークロードは、特権のない Pod として実行されます。
-
Security Context Constraints (SCC) は、
kubevirt-controllerサービスアカウントに対して定義されます。 - OpenShift Virtualization コンポーネントの TLS 証明書は更新され、自動的にローテーションされます。
1.3.1. ワークロードのセキュリティーについて リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、OpenShift Virtualization の仮想マシン (VM) ワークロードは root 権限では実行されず、root 権限を必要とするサポート対象の OpenShift Virtualization 機能はありません。
仮想マシンごとに、virt-launcher Pod が libvirt のインスタンスを セッションモード で実行し、仮想マシンプロセスを管理します。セッションモードでは、libvirt デーモンは root 以外のユーザーアカウントとして実行され、同じユーザー識別子 (UID) で実行されているクライアントからの接続のみを許可します。したがって、仮想マシンは権限のない Pod として実行し、最小権限のセキュリティー原則に従います。
1.3.2. TLS 証明書 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization コンポーネントの TLS 証明書は更新され、自動的にローテーションされます。手動で更新する必要はありません。
自動更新スケジュール
TLS 証明書は自動的に削除され、以下のスケジュールに従って置き換えられます。
- KubeVirt 証明書は毎日更新されます。
- Containerized Data Importer controller (CDI) 証明書は、15 日ごとに更新されます。
- MAC プール証明書は毎年更新されます。
TLS 証明書の自動ローテーションはいずれの操作も中断しません。たとえば、以下の操作は中断せずに引き続き機能します。
- 移行
- イメージのアップロード
- VNC およびコンソールの接続
1.3.3. 認可 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization は、ロールベースのアクセス制御 (RBAC) を使用して、人間のユーザーとサービスアカウントの権限を定義します。サービスアカウントに定義された権限は、OpenShift Virtualization コンポーネントが実行できるアクションを制御します。
RBAC ロールを使用して、仮想化機能へのユーザーアクセスを管理することもできます。たとえば管理者は、仮想マシンの起動に必要な権限を提供する RBAC ロールを作成できます。管理者は、ロールを特定のユーザーにバインドすることでアクセスを制限できます。
1.3.3.1. OpenShift Virtualization のデフォルトのクラスターロール リンクのコピーリンクがクリップボードにコピーされました!
クラスターロール集約を使用することで、OpenShift Virtualization はデフォルトの OpenShift Container Platform クラスターロールを拡張して、仮想化オブジェクトにアクセスするための権限を組み込みます。
| デフォルトのクラスターロール | OpenShift Virtualization のクラスターロール | OpenShift Virtualization クラスターロールの説明 |
|---|---|---|
|
|
| クラスター内の OpenShift Virtualization リソースをすべて表示できるユーザー。ただし、リソースの作成、削除、変更、アクセスはできません。たとえば、ユーザーは仮想マシン (VM) が実行中であることを確認できますが、それをシャットダウンしたり、そのコンソールにアクセスしたりすることはできません。 |
|
|
| クラスター内のすべての OpenShift Virtualization リソースを変更できるユーザー。たとえば、ユーザーは仮想マシンの作成、VM コンソールへのアクセス、仮想マシンの削除を行えます。 |
|
|
|
リソースコレクションの削除を含め、すべての OpenShift Virtualization リソースに対する完全な権限を持つユーザー。このユーザーは、 |
1.3.3.2. OpenShift Virtualization のストレージ機能の RBAC ロール リンクのコピーリンクがクリップボードにコピーされました!
cdi-operator および cdi-controller サービスアカウントを含む、次のパーミッションがコンテナー化データインポーター (CDI) に付与されます。
1.3.3.2.1. クラスター全体の RBAC のロール リンクのコピーリンクがクリップボードにコピーされました!
| CDI クラスターのロール | リソース | 動詞 |
|---|---|---|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
| API グループ | リソース | 動詞 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
許可リスト: |
|
|
|
許可リスト: |
|
|
|
|
|
| API グループ | リソース | 動詞 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1.3.3.2.2. namespace 付きの RBAC ロール リンクのコピーリンクがクリップボードにコピーされました!
| API グループ | リソース | 動詞 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| API グループ | リソース | 動詞 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1.3.3.3. kubevirt-controller サービスアカウントの追加の SCC とパーミッション リンクのコピーリンクがクリップボードにコピーされました!
SCC (Security Context Constraints) は Pod のパーミッションを制御します。これらのパーミッションには、コンテナーのコレクションである Pod が実行できるアクションおよびそれがアクセスできるリソース情報が含まれます。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行に関する条件の一覧を定義できます。
virt-controller は、クラスター内の仮想マシンの virt-launcher Pod を作成するクラスターコントローラーです。
デフォルトでは、virt-launcher Pod は namespace 内の default サービスアカウントで実行されます。コンプライアンス制御に一意のサービスアカウントが必要な場合は、仮想マシンに割り当てます。この設定は、VirtualMachineInstance オブジェクトと virt-launcher Pod に適用されます。
kubevirt-controller サービスアカウントには追加の SCC および Linux 機能が付与され、これにより適切なパーミッションを持つ virt-launcher Pod を作成できます。これらの拡張パーミッションにより、仮想マシンは通常の Pod の範囲外の OpenShift Virtualization 機能を利用できます。
kubevirt-controller サービスアカウントには以下の SCC が付与されます。
-
scc.AllowHostDirVolumePlugin = true
これは、仮想マシンが hostpath ボリュームプラグインを使用することを可能にします。 -
scc.AllowPrivilegedContainer = false
これは、virt-launcherPod が特権コンテナーとして実行されないようにします。 scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE"}-
SYS_NICEを使用すると、CPU アフィニティーを設定できます。 -
NET_BIND_SERVICEは、DHCP および Slirp 操作を許可します。
-
kubevirt-controller の SCC および RBAC 定義の表示
oc ツールを使用して kubevirt-controller の SecurityContextConstraints 定義を表示できます。
oc get scc kubevirt-controller -o yaml
$ oc get scc kubevirt-controller -o yaml
oc ツールを使用して kubevirt-controller クラスターロールの RBAC 定義を表示できます。
oc get clusterrole kubevirt-controller -o yaml
$ oc get clusterrole kubevirt-controller -o yaml
1.4. OpenShift Virtualization アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は、OpenShift Virtualization の各コンポーネントのオペレーター Pod をデプロイします。
-
コンピューティング:
virt-operator -
ストレージ:
cdi-operator -
ネットワーク:
cluster-network-addons-operator -
スケーリング:
ssp-operator
OLM は、他のコンポーネントのデプロイ、設定、およびライフサイクルを担当する hyperconverged-cluster-operator Pod と、いくつかのヘルパー Pod (hco-webhook および hyperconverged-cluster-cli-download) もデプロイします。
すべての Operator Pod が正常にデプロイされたら、HyperConverged カスタムリソース (CR) を作成する必要があります。HyperConverged CR で設定された設定は、信頼できる唯一の情報源および OpenShift Virtualization のエントリーポイントとして機能し、CR の動作をガイドします。
HyperConverged CR は、リコンシリエーションループに含まれる他の全コンポーネントの Operator に対して対応する CR を作成します。その後、各 Operator は、デーモンセット、config map、および OpenShift Virtualization コントロールプレーン用の追加コンポーネントなどのリソースを作成します。たとえば、HyperConverged Operator (HCO) が KubeVirt CR を作成すると、OpenShift Virtualization Operator がそれを調整し、virt-controller、virt-handler、virt-api などの追加リソースを作成します。
OLM は Hostpath Provisioner (HPP) Operator をデプロイしますが、hostpath-provisioner CR を作成するまで機能しません。
1.4.1. HyperConverged Operator (HCO) について リンクのコピーリンクがクリップボードにコピーされました!
HCO (hco-operator) は、OpenShift Virtualization と複数のヘルパー Operator を、推奨のデフォルト設定を使用してデプロイおよび管理するための単一のエントリーポイントを提供します。また、これらの Operator のカスタムリソース (CR) も作成します。
| コンポーネント | 説明 |
|---|---|
|
|
|
|
|
クラスターから直接ダウンロードできるように、 |
|
| OpenShift Virtualization に必要なすべての Operator、CR、およびオブジェクトが含まれています。 |
|
| Scheduling, Scale, and Performance (SSP) CR。これは、HCO によって自動的に作成されます。 |
|
| Containerized Data Importer (CDI) CR。これは、HCO によって自動的に作成されます。 |
|
|
|
1.4.2. Containerized Data Importer (CDI) Operator について リンクのコピーリンクがクリップボードにコピーされました!
CDI Operator cdi-operator は、CDI とその関連リソースを管理し、データボリュームを使用して仮想マシンイメージを永続ボリューム要求 (PVC) にインポートします。
| コンポーネント | 説明 |
|---|---|
|
| 安全なアップロードトークンを発行して、VM ディスクを PVC にアップロードするための承認を管理します。 |
|
| 外部ディスクのアップロードトラフィックを適切なアップロードサーバー Pod に転送して、正しい PVC に書き込むことができるようにします。有効なアップロードトークンが必要です。 |
|
| データボリュームの作成時に仮想マシンイメージを PVC にインポートするヘルパー Pod。 |
1.4.3. Cluster Network Addons Operator について リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Addons Operator (cluster-network-addons-operator) は、クラスターにネットワークコンポーネントをデプロイし、拡張ネットワーク機能の関連リソースを管理します。
| コンポーネント | 説明 |
|---|---|
|
| Kubemacpool の Webhook の TLS 証明書を管理します。 |
|
| 仮想マシン (VM) ネットワークインターフェイスカード (NIC) の MAC アドレスプールサービスを提供します。 |
|
| ノードで使用可能なネットワークブリッジをノードリソースとしてマークします。 |
|
| クラスターノードに Container Network Interface (CNI) プラグインをインストールし、Network Attachment Definition を介して Linux ブリッジに VM を接続できるようにします。 |
1.4.4. Hostpath Provisioner (HPP) Operator について リンクのコピーリンクがクリップボードにコピーされました!
HPP オペレーター hostpath-provisioner-operator は、マルチノード HPP および関連リソースをデプロイおよび管理します。
| コンポーネント | 説明 |
|---|---|
|
| HPP の実行が指定されている各ノードにワーカーを提供します。Pod は、指定されたバッキングストレージをノードにマウントします。 |
|
| HPP の Container Storage Interface (CSI) ドライバーインターフェイスを実装します。 |
|
| HPP のレガシードライバーインターフェイスを実装します。 |
1.4.5. Scheduling, Scale, and Performance (SSP) Operator について リンクのコピーリンクがクリップボードにコピーされました!
SSP オペレーター ssp-operator は、共通テンプレート、関連するデフォルトのブートソース、パイプラインタスク、およびテンプレートバリデーターをデプロイします。
1.4.6. OpenShift Virtualization Operator について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization Operator virt-operator は、現在の仮想マシンワークロードを中断することなく OpenShift Virtualization をデプロイ、アップグレード、管理します。さらに、OpenShift Virtualization Operator は、共通のインスタンスタイプと共通の設定をデプロイします。
| コンポーネント | 説明 |
|---|---|
|
| すべての仮想化関連フローのエントリーポイントとして機能する HTTP API サーバー。 |
|
|
新しい VM インスタンスオブジェクトの作成を監視し、対応する Pod を作成します。Pod がノードでスケジュールされると、 |
|
|
仮想マシンへの変更を監視し、必要な操作を実行するように |
|
|
|
第2章 リリースノート リンクのコピーリンクがクリップボードにコピーされました!
2.1. OpenShift Virtualization リリースノート リンクのコピーリンクがクリップボードにコピーされました!
2.1.1. ドキュメントに関するフィードバックの提供 リンクのコピーリンクがクリップボードにコピーされました!
エラーを報告したり、ドキュメントを改善したりするには、Red Hat Jira アカウント にログインし、Jira issue を送信してください。
2.1.2. Red Hat OpenShift Virtualization について リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Virtualization を使用すると、従来の仮想マシン (VM) を OpenShift Container Platform に導入し、コンテナーと一緒に実行できます。OpenShift Virtualization では、仮想マシンとは OpenShift Container Platform Web コンソールまたはコマンドラインを使用して管理できるネイティブ Kubernetes オブジェクトです。
OpenShift Virtualization は、
アイコンで表されます。
OVN-Kubernetes または OpenShiftSDN のデフォルトの Container Network Interface (CNI) ネットワークプロバイダーで、OpenShift Virtualization を使用できます。
OpenShift Virtualization の機能 を参照してください。
OpenShift Virtualization のアーキテクチャーとデプロイメント の詳細を参照してください。
OpenShift Virtualization 用に クラスターを準備します。
2.1.2.1. OpenShift Virtualization サポートのクラスターバージョン リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization 4.16 の最新の安定リリースは 4.16.21 です。
OpenShift Virtualization 4.16 は、OpenShift Container Platform 4.16 クラスターでの使用がサポートされます。OpenShift Virtualization の最新の z-stream リリースを使用するには、最初に OpenShift Container Platform の最新バージョンにアップグレードする必要があります。
2.1.2.2. サポート対象のゲストオペレーティングシステム リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization でサポートされているゲストオペレーティングシステムを確認するには、Red Hat OpenStack Platform、Red Hat Virtualization、OpenShift Virtualization、Red Hat Enterprise Linux with KVM の認定ゲストオペレーティングシステム を参照してください。
2.1.2.3. Microsoft Windows SVVP 認定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization は、Windows Server のワークロードを実行する Microsoft の Windows Server Virtualization Validation Program (SVVP) で認定されています。
SVVP 認定は以下に適用されます。
- Red Hat Enterprise Linux CoreOS ワーカー。Microsoft SVVP Catalog では、Red Hat OpenShift Container Platform 4 on RHEL CoreOS 9 という名前が付けられます。
- Intel および AMD CPU。
2.1.3. クイックスタート リンクのコピーリンクがクリップボードにコピーされました!
クイックスタートツアーは、複数の OpenShift Virtualization 機能で利用できます。ツアーを表示するには、OpenShift Container Platform Web コンソールのヘッダーのメニューバーにある Help アイコン ? をクリックし、Quick Starts を選択します。Filter フィールドにキーワードとして virtualization を入力すると、利用可能なツアーをフィルタリングできます。
2.1.4. 新機能および変更された機能 リンクのコピーリンクがクリップボードにコピーされました!
このリリースでは、次のコンポーネントと概念に関連する新機能と機能拡張が追加されています。
2.1.4.1. インストールおよび更新 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Virtualization 4.16 にアップグレードすると、ガベージコレクションにより削除されていたデータボリュームが再作成される可能性があります。この動作は想定されています。データボリュームのガベージコレクションは無効になったため、再作成されたデータボリュームは無視できます。
2.1.4.2. Virtualization リンクのコピーリンクがクリップボードにコピーされました!
- Windows 10 仮想マシンは、TPM を使用した UEFI を使用して起動するようになりました。
-
AutoResourceLimitsフィーチャーゲートを有効にすると、仮想マシンの CPU とメモリーの制限が自動的に管理されます。 - KubeVirt Tekton タスクは、OpenShift Container Platform Pipelines catalog の一部として出荷されるようになりました。
2.1.4.3. ネットワーク リンクのコピーリンクがクリップボードにコピーされました!
- ヘッドレスサービスを使用して、安定した完全修飾ドメイン名 (FQDN) 上のデフォルトの内部 Pod ネットワークに接続されている 仮想マシンにアクセスできる ようになりました。
2.1.4.4. Web コンソール リンクのコピーリンクがクリップボードにコピーされました!
-
仮想 CPU (vCPU)の仮想マシンへのホットプラグが一般提供されるようになりました。vCPU をホットプラグできない場合は、
RestartRequired条件が VM に適用されます。この状態は、Web コンソールの Diagnostics タブで確認できます。
-
インスタンスタイプから Microsoft Windows 仮想マシンを作成するときに、
sysprepオプションを選択できるようになりました。以前は、仮想マシンを作成した後にカスタマイズしてsysprepオプションを設定する必要がありました。
2.1.4.5. モニタリング リンクのコピーリンクがクリップボードにコピーされました!
管理者は、
downwardMetricsフィーチャーゲートを有効にし、downwardMetricsデバイスを設定することで、OpenShift Virtualization の virtio-serial ポートを介してホストおよび仮想マシン (VM) メトリクスの限定セットをゲスト仮想マシンに公開 できるようになりました。ユーザーは、vm-dump-metricsツールまたはコマンドラインからメトリクスを取得します。Red Hat Enterprise Linux (RHEL) 9 では、コマンドラインを使用して downward metrics を表示します。
vm-dump-metricsツールは、Red Hat Enterprise Linux (RHEL) 9 プラットフォームではサポートされていません。
2.1.4.6. 主な技術上の変更点 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンでは、メモリーホットプラグを有効にするために、少なくとも 1 GiB のメモリー割り当てが必要です。仮想マシンに割り当てられたメモリーが 1 GiB 未満の場合、メモリーホットプラグは無効になります。
-
OpenShift Virtualization アラートの runbook は、
openshift/runbooksgit repository 内でのみ管理されるようになりました。削除された runbook の代わりに、runbook ソースファイルへのリンク が利用できるようになりました。
2.1.5. 非推奨の機能と削除された機能 リンクのコピーリンクがクリップボードにコピーされました!
2.1.5.1. 非推奨の機能 リンクのコピーリンクがクリップボードにコピーされました!
非推奨の機能は現在のリリースに含まれており、引き続きサポートされています。ただし、非推奨の機能は今後のリリースで削除されるため、新しいデプロイメントには推奨されません。
-
tekton-tasks-operatorは非推奨になり、Tekton タスクとサンプルパイプラインはssp-operatorによってデプロイされるようになりました。
-
copy-template、modify-vm-template、およびcreate-vm-from-templateタスクは非推奨になりました。
- Windows Server 2012 R2 テンプレートのサポートは廃止されました。
-
KubeVirtComponentExceedsRequestedMemoryアラートとKubeVirtComponentExceedsRequestedCPUアラートは非推奨になりました。それらを安全に サイレンス にすることができます。
2.1.5.2. 削除された機能 リンクのコピーリンクがクリップボードにコピーされました!
削除された機能は、現在のリリースではサポートされません。
- 現在、CentOS 7 および CentOS Stream 8 はライフサイクル終了段階にあります。そのため、これらのオペレーティングシステムのコンテナーイメージは OpenShift Virtualization から削除され、コミュニティーによるサポート もありません。
2.1.6. テクノロジープレビュー機能 リンクのコピーリンクがクリップボードにコピーされました!
現在、今回のリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。これらの機能に関しては、Red Hat カスタマーポータルの以下のサポート範囲を参照してください。
- クラスター全体 の 仮想マシンエビクションストラテジー を設定できるようになりました。
- OpenShift Virtualization ホストでネストされた仮想化 を有効化できるようになりました。
- クラスター管理者は、OpenShift Container Platform Web コンソールの Overview → Settings → Preview features で、namespace の CPU リソース制限を有効にできるようになりました。
-
クラスター管理者は
wasp-agentツールを使用して、RAM 内のメモリー量をオーバーコミットし、スワップリソースを仮想マシンワークロードに割り当てることで、クラスター内の 仮想マシンワークロード密度を高く設定できる ようになりました。
- OpenShift Virtualization は、Red Hat OpenShift Data Foundation (ODF) Regional Disaster Recovery との互換性をサポートするようになりました。
2.1.7. バグ修正 リンクのコピーリンクがクリップボードにコピーされました!
- Web コンソールで Upload Data フォームを使用した Persistent Volume Claim (PVC)にデータをアップロードできない問題を修正しました(CNV-37607)。
2.1.8. 既知の問題 リンクのコピーリンクがクリップボードにコピーされました!
モニタリング
Pod Disruption Budget (PDB) は、移行可能な仮想マシンイメージに関する Pod の中断を防ぎます。PDB が Pod の中断を検出する場合、
openshift-monitoringはLiveMigrateエビクションストラテジーを使用する仮想マシンイメージに対して 60 分ごとにPodDisruptionBudgetAtLimitアラートを送信します。(CNV-33834)- 回避策として、アラートをサイレンス にします。
ネットワーク
OpenShift Container Platform 4.12 から新しいマイナーバージョンに更新すると、
cnv-bridgeContainer Network Interface (CNI) を使用する仮想マシンがライブマイグレーションに失敗します。(https://access.redhat.com/solutions/7069807)-
回避策として、更新を実行する前に、
NetworkAttachmentDefinitionマニフェストのspec.config.typeフィールドをcnv-bridgeからbridgeに変更します。
-
回避策として、更新を実行する前に、
Nodes
-
OpenShift Virtualization をアンインストールしても、OpenShift Virtualization によって作成された
feature.node.kubevirt.ioノードラベルは削除されません。ラベルは手動で削除する必要があります。(CNV-38543)
- さまざまなコンピュートノードが含まれる異種クラスターでは、HyperV reenlightenment が有効な仮想マシンを、タイムスタンプカウンター (TSC) スケーリングをサポートしていないノードまたは TSC の周波数が不適切なノードでスケジュールできません。(BZ#2151169)
ストレージ
AWS 上のストレージソリューションとして Portworx を使用し、仮想マシンのディスクイメージを作成する場合、ファイルシステムのオーバーヘッドが 2 回考慮されるため、作成されるイメージは予想よりも小さくなる可能性があります。(CNV-40217)
- 回避策として、最初のプロビジョニングプロセスが完了した後に、永続ボリューム要求 (PVC) を手動で拡張して利用可能なスペースを増やせます。
場合によっては、複数の仮想マシンが読み取り/書き込みモードで同じ PVC をマウントできるため、データが破損する可能性があります。(CNV-13500)
- 回避策として、複数の仮想マシンで読み取り/書き込みモードで単一の PVC を使用しないでください。
csi-cloneクローンストラテジーを使用して 100 台以上の仮想マシンのクローンを作成する場合、Ceph CSI はクローンをパージしない可能性があります。クローンの手動削除も失敗する可能性があります。(CNV-23501)-
回避策として、
ceph-mgrを再起動して仮想マシンのクローンをパージすることができます。
-
回避策として、
仮想化
CPU タイプが混在するクラスターでは、仮想マシンの移行が失敗する可能性があります。(CNV-43195)
- 回避策として、仮想マシン仕様レベル または クラスターレベル で CPU モデルを設定できます。
-
仮想 Trusted Platform Module (vTPM) デバイスを Windows 仮想マシンに追加すると、vTPM デバイスが永続的でない場合でも、BitLocker ドライブ暗号化システムチェックに合格します。これは、
virt-launcherPod の存続期間中、永続的ではない vTPM デバイスが一時ストレージを使用して暗号化キーを保存および復元するためです。仮想マシンが移行するか、シャットダウンして再起動すると、vTPM データは失われます。(CNV-36448)
OpenShift Virtualization は、Pod によって使用されるサービスアカウントトークンをその特定の Pod にリンクします。OpenShift Virtualization は、トークンが含まれるディスクイメージを作成してサービスアカウントボリュームを実装します。仮想マシンを移行すると、サービスアカウントボリュームが無効になります。(CNV-33835)
- 回避策として、サービスアカウントではなくユーザーアカウントを使用してください。ユーザーアカウントトークンは特定の Pod にバインドされていないためです。
RHSA-2023:3722 アドバイザリーのリリースにより、FIPS 対応 Red Hat Enterprise Linux (RHEL) 9 システム上の TLS 1.2 接続には TLS
Extended Master Secret(EMS) 拡張機能 (RFC 7627) が必須になりました。これは FIPS-140-3 要件に準拠しています。TLS 1.3 は影響を受けません。EMS または TLS 1.3 をサポートしていないレガシー OpenSSL クライアントは、RHEL 9 で実行されている FIPS サーバーに接続できなくなりました。同様に、FIPS モードの RHEL 9 クライアントは、EMS なしでは TLS 1.2 のみをサポートするサーバーに接続できません。これは実際には、これらのクライアントが RHEL 6、RHEL 7、および RHEL 以外のレガシーオペレーティングシステム上のサーバーに接続できないことを意味します。これは、OpenSSL のレガシー 1.0.x バージョンが EMS または TLS 1.3 をサポートしていないためです。詳細は、TLS Extension "Extended Master Secret" enforced with Red Hat Enterprise Linux 9.2 を参照してください。
-
回避策として、レガシー OpenSSL クライアントを TLS 1.3 をサポートするバージョンに更新し、FIPS モードの場合に OpenShift Virtualization が
ModernTLS セキュリティープロファイル型で TLS 1.3 を使用するようにを設定します。
-
回避策として、レガシー OpenSSL クライアントを TLS 1.3 をサポートするバージョンに更新し、FIPS モードの場合に OpenShift Virtualization が
Web コンソール
cluster-admin権限がない場合、OpenShift Container Platform クラスターの初回デプロイ時に、Web コンソールを使用してテンプレートまたはインスタンスタイプから仮想マシンを作成すると失敗します。- 回避策として、クラスター管理者は最初に config map を作成 し、他のユーザーがテンプレートとインスタンスタイプを使用して仮想マシンを作成できるようにする必要があります。(CNV-38284)
第3章 スタートガイド リンクのコピーリンクがクリップボードにコピーされました!
3.1. OpenShift Virtualization の開始 リンクのコピーリンクがクリップボードにコピーされました!
基本的な環境をインストールして設定することにより、OpenShift Virtualization の特徴と機能を調べることができます。
クラスター設定手順には、cluster-admin 権限が必要です。
3.1.1. OpenShift Virtualization の計画とインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで OpenShift Virtualization を計画およびインストールします。
計画およびインストールのリソース
3.1.2. 仮想マシンの作成と管理 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンを作成します。
Red Hat テンプレートまたは インスタンスタイプ を使用して仮想マシンを作成できます。
仮想マシンを作成するには、コンテナーレジストリーまたは Web ページからカスタムイメージをインポートするか、ローカルマシンからイメージをアップロードするか、永続ボリューム要求 (PVC) を複製することによって実行できます。
仮想マシンをセカンダリーネットワークに接続します。
- Linux ブリッジネットワーク。
- オープン仮想ネットワーク (OVN)- Kubernetes セカンダリーネットワーク。
シングルルート I/O 仮想化 (SR-IOV) ネットワーク。
注記仮想マシンはデフォルトで Pod ネットワークに接続されます。
仮想マシンに接続します。
- 仮想マシンの シリアルコンソール または VNC コンソール に接続します。
- SSH を使用して仮想マシンに接続します。
- Windows 仮想マシンのデスクトップビューアーに接続します。
仮想マシンを管理します。
3.1.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
3.2. CLI ツールの使用 リンクのコピーリンクがクリップボードにコピーされました!
virtctl コマンドラインツールを使用して、OpenShift Virtualization リソースを管理できます。
libguestfs コマンドラインツールを使用すると、仮想マシン (VM) のディスクイメージにアクセスして変更できます。libguestfs をデプロイするには、virtctl libguestfs コマンドを使用します。
3.2.1. virtctl のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux (RHEL) 9、Linux、Windows、および MacOS オペレーティングシステムに virtctl をインストールするには、virtctl バイナリーファイルをダウンロードしてインストールします。
RHEL 8 に virtctl をインストールするには、OpenShift Virtualization リポジトリーを有効にしてから、kubevirt-virtctl パッケージをインストールします。
3.2.1.1. RHEL 9、Linux、Windows、macOS への virtctl バイナリーのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールからオペレーティングシステムの virtctl バイナリーをダウンロードし、それをインストールできます。
手順
- Web コンソールの Virtualization → Overview ページに移動します。
-
Download virtctl リンクをクリックして、オペレーティングシステム用の
virtctlバイナリーをダウンロードします。 virtctlをインストールします。RHEL 9 およびその他の Linux オペレーティングシステムの場合:
アーカイブファイルを解凍します。
tar -xvf <virtctl-version-distribution.arch>.tar.gz
$ tar -xvf <virtctl-version-distribution.arch>.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
virtctlバイナリーを実行可能にします。chmod +x <path/virtctl-file-name>
$ chmod +x <path/virtctl-file-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow virtctlバイナリーをPATH環境変数内のディレクトリーに移動します。次のコマンドを実行して、パスを確認できます。
echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow KUBECONFIG環境変数を設定します。export KUBECONFIG=/home/<user>/clusters/current/auth/kubeconfig
$ export KUBECONFIG=/home/<user>/clusters/current/auth/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows の場合:
- アーカイブファイルを展開します。
-
展開したフォルダー階層に移動し、
virtctl実行可能ファイルをダブルクリックしてクライアントをインストールします。 virtctlバイナリーをPATH環境変数内のディレクトリーに移動します。次のコマンドを実行して、パスを確認できます。
path
C:\> pathCopy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS の場合:
- アーカイブファイルを展開します。
virtctlバイナリーをPATH環境変数内のディレクトリーに移動します。次のコマンドを実行して、パスを確認できます。
echo $PATH
echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2.1.2. RHEL 8 への virtctl RPM のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization リポジトリーを有効にし、kubevirt-virtctl パッケージをインストールすることで、Red Hat Enterprise Linux (RHEL) 8 に virtctl RPM をインストールできます。
前提条件
- クラスター内の各ホストは Red Hat Subscription Manager (RHSM) に登録されており、アクティブな OpenShift Container Platform サブスクリプションを持つ必要があります。
手順
subscription-managerCLI ツールを使用して次のコマンドを実行し、OpenShift Virtualization リポジトリーを有効にします。subscription-manager repos --enable cnv-4.16-for-rhel-8-x86_64-rpms
# subscription-manager repos --enable cnv-4.16-for-rhel-8-x86_64-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
kubevirt-virtctlパッケージをインストールします。yum install kubevirt-virtctl
# yum install kubevirt-virtctlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2.2. virtctl コマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl クライアントは、OpenShift Virtualization リソースを管理するためのコマンドラインユーティリティーです。
特に指定がない限り、仮想マシンコマンドは仮想マシンインスタンスにも適用されます。
3.2.2.1. virtctl 情報コマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl information コマンドを使用して、virtctl クライアントに関する情報を表示します。
| コマンド | 説明 |
|---|---|
|
|
|
|
|
|
|
| 特定のコマンドのオプションのリストを表示します。 |
|
|
任意の |
3.2.2.2. 仮想マシン情報コマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl を使用すると、仮想マシンおよび仮想マシンインスタンス (VMI) に関する情報を表示できます。
| コマンド | 説明 |
|---|---|
|
| ゲストマシンで使用可能なファイルシステムを表示します。 |
|
| ゲストマシンのオペレーティングシステムに関する情報を表示します。 |
|
| ゲストマシンにログインしているユーザーを表示します。 |
3.2.2.3. 仮想マシンマニフェスト作成コマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl create コマンドを使用して、仮想マシン、インスタンスタイプ、および設定のマニフェストを作成できます。
| コマンド | 説明 |
|---|---|
|
|
|
| 仮想マシンの名前を指定して、仮想マシンのマニフェストを作成します。 |
|
| 既存のクラスター全体のインスタンスの種類を使用する仮想マシンのマニフェストを作成します。 |
|
| 既存の namespaced 付きのインスタンスタイプを使用する仮想マシンのマニフェストを作成します。 |
|
| クラスター全体のインスタンスタイプのマニフェストを作成します。 |
|
| namespace 付きのインスタンスタイプのマニフェストを作成します。 |
|
| 設定の名前を指定して、クラスター全体の仮想マシン設定のマニフェストを作成します。 |
|
| namespace 付きの仮想マシン設定のマニフェストを作成します。 |
3.2.2.4. 仮想マシン管理コマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl 仮想マシン管理コマンドを使用して、仮想マシンおよび仮想マシンインスタンスを管理および移行します。
| コマンド | 説明 |
|---|---|
|
| 仮想マシンを開始します。 |
|
| 仮想マシンを一時停止状態で起動します。このオプションを使用すると、VNC コンソールからブートプロセスを中断できます。 |
|
| 仮想マシンを停止します。 |
|
| 仮想マシンを強制停止します。このオプションは、データの不整合またはデータ損失を引き起こす可能性があります。 |
|
| 仮想マシンを一時停止します。マシンの状態がメモリーに保持されます。 |
|
| 仮想マシンの一時停止を解除します。 |
|
| 仮想マシンを移行します。 |
|
| 仮想マシンの移行をキャンセルします。 |
|
| 仮想マシンを再起動します。 |
3.2.2.5. 仮想マシン接続コマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl 接続コマンドを使用してポートを公開し、仮想マシンおよび仮想マシンインスタンスに接続します。
| コマンド | 説明 |
|---|---|
|
| 仮想マシンのシリアルコンソールに接続します。 |
|
| 仮想マシンの指定されたポートを転送するサービスを作成し、ノードの指定されたポートでサービスを公開します。
例: |
|
| マシンから仮想マシンにファイルをコピーします。このコマンドは、SSH 鍵ペアの秘密鍵を使用します。仮想マシンは公開鍵を使用して設定する必要があります。 |
|
| 仮想マシンからマシンにファイルをコピーします。このコマンドは、SSH 鍵ペアの秘密鍵を使用します。仮想マシンは公開鍵を使用して設定する必要があります。 |
|
| 仮想マシンとの SSH 接続を開きます。このコマンドは、SSH 鍵ペアの秘密鍵を使用します。仮想マシンは公開鍵を使用して設定する必要があります。 |
|
| 仮想マシンの VNC コンソールに接続します。
|
|
| ポート番号を表示し、VNC 接続を介してビューアーを使用して手動で VM に接続します。 |
|
| ポートが利用可能な場合、その指定されたポートでプロキシーを実行するためにポート番号を指定します。 ポート番号が指定されていない場合、プロキシーはランダムポートで実行されます。 |
3.2.2.6. 仮想マシンエクスポートコマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl vmexport コマンドを使用して、仮想マシン、仮想マシンスナップショット、または永続ボリューム要求 (PVC) からエクスポートされたボリュームを作成、ダウンロード、または削除できます。特定のマニフェストには、OpenShift Virtualization が使用できる形式でディスクイメージをインポートするためのエンドポイントへのアクセスを許可するヘッダーシークレットも含まれています。
| コマンド | 説明 |
|---|---|
|
|
仮想マシン、仮想マシンスナップショット、または PVC からボリュームをエクスポートするには、
|
|
|
|
|
|
オプション:
|
|
|
|
|
| 既存のエクスポートのマニフェストを取得します。マニフェストにはヘッダーシークレットが含まれていません。 |
|
| 仮想マシンサンプルの仮想マシンエクスポートを作成し、マニフェストを取得します。マニフェストにはヘッダーシークレットが含まれていません。 |
|
| 仮想マシンスナップショットの例の仮想マシンエクスポートを作成し、マニフェストを取得します。マニフェストにはヘッダーシークレットが含まれていません。 |
|
| 既存のエクスポートのマニフェストを取得します。マニフェストにはヘッダーシークレットが含まれています。 |
|
| 既存のエクスポートのマニフェストを json 形式で取得します。マニフェストにはヘッダーシークレットが含まれていません。 |
|
| 既存のエクスポートのマニフェストを取得します。マニフェストにはヘッダーシークレットが含まれており、指定されたファイルにそれを書き込みます。 |
3.2.2.7. 仮想マシンメモリーダンプコマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl memory-dump コマンドを使用して、PVC に仮想マシンのメモリーダンプを出力できます。既存の PVC を指定するか、--create-claim フラグを使用して新しい PVC を作成できます。
前提条件
-
PVC ボリュームモードは
FileSystemである必要があります。 PVC は、メモリーダンプを格納するのに十分な大きさである必要があります。
PVC サイズを計算する式は
(VMMemorySize + 100Mi) * FileSystemOverheadです。ここで、100Miはメモリーダンプのオーバーヘッドです。次のコマンドを実行して、
HyperConvergedカスタムリソースでホットプラグフィーチャーゲートを有効にする必要があります。oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "add", "path": "/spec/featureGates", \ "value": "HotplugVolumes"}]'$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "add", "path": "/spec/featureGates", \ "value": "HotplugVolumes"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
メモリーダンプのダウンロード
メモリーダンプをダウンロードするには、virtctl vmexport download コマンドを使用する必要があります。
virtctl vmexport download <vmexport_name> --vm|pvc=<object_name> \ --volume=<volume_name> --output=<output_file>
$ virtctl vmexport download <vmexport_name> --vm|pvc=<object_name> \
--volume=<volume_name> --output=<output_file>
| コマンド | 説明 |
|---|---|
|
|
仮想マシンのメモリーダンプを PVC に保存します。メモリーダンプのステータスは、 オプション:
|
|
|
同じ PVC で このコマンドは、以前のメモリーダンプを上書きします。 |
|
| メモリーダンプを削除します。 ターゲット PVC を変更する場合は、メモリーダンプを手動で削除する必要があります。
このコマンドは、 |
3.2.2.8. ホットプラグおよびホットアンプラグコマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl を使用して、実行中の仮想マシンおよび仮想マシンインスタンス (VMI) にリソースを追加または削除します。
| コマンド | 説明 |
|---|---|
|
| データボリュームまたは永続ボリューム要求 (PVC) をホットプラグします。 オプション:
|
|
| 仮想ディスクをホットアンプラグします。 |
|
| Linux ブリッジネットワークインターフェイスをホットプラグします。 |
|
| Linux ブリッジネットワークインターフェイスをホットアンプラグします。 |
3.2.2.9. イメージアップロードコマンド リンクのコピーリンクがクリップボードにコピーされました!
virtctl image-upload コマンドを使用して、VM イメージをデータボリュームにアップロードできます。
| コマンド | 説明 |
|---|---|
|
| VM イメージを既存のデータボリュームにアップロードします。 |
|
| 指定された要求されたサイズの新しいデータボリュームに VM イメージをアップロードします。 |
3.2.3. virtctl を使用した libguestfs のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
virtctl guestfs コマンドを使用して、libguestfs-tools および永続ボリューム要求 (PVC) がアタッチされた対話型コンテナーをデプロイできます。
手順
libguestfs-toolsでコンテナーをデプロイして PVC をマウントし、シェルを割り当てるには、以下のコマンドを実行します。virtctl guestfs -n <namespace> <pvc_name>
$ virtctl guestfs -n <namespace> <pvc_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- PVC 名は必須の引数です。この引数を追加しないと、エラーメッセージが表示されます。
3.2.3.1. Libguestfs および virtctl guestfs コマンド リンクのコピーリンクがクリップボードにコピーされました!
Libguestfs ツールは、仮想マシン (VM) のディスクイメージにアクセスして変更するのに役立ちます。libguestfs ツールを使用して、ゲスト内のファイルの表示および編集、仮想マシンのクローンおよびビルド、およびディスクのフォーマットおよびサイズ変更を実行できます。
virtctl guestfs コマンドおよびそのサブコマンドを使用して、PVC で仮想マシンディスクを変更して検査し、デバッグすることもできます。使用可能なサブコマンドの完全なリストを表示するには、コマンドラインで virt- と入力して Tab を押します。以下に例を示します。
| コマンド | 説明 |
|---|---|
|
| ターミナルでファイルを対話的に編集します。 |
|
| ゲストに ssh 鍵を注入し、ログインを作成します。 |
|
| 仮想マシンによって使用されるディスク容量を確認します。 |
|
| 完全なリストを含む出力ファイルを作成して、ゲストにインストールされているすべての RPM の全リストを表示します。 |
|
|
ターミナルで |
|
| テンプレートとして使用する仮想マシンディスクイメージをシールします。 |
デフォルトでは、virtctl guestfs は、仮想ディスク管理に必要な項目を含めてセッションを作成します。ただし、動作をカスタマイズできるように、コマンドは複数のフラグオプションもサポートしています。
| フラグオプション | 説明 |
|---|---|
|
|
|
|
| 特定の namespace から PVC を使用します。
|
|
|
|
|
|
デフォルトでは、
クラスターに
設定されていない場合、 |
|
|
|
このコマンドは、PVC が別の Pod によって使用されているかどうかを確認します。使用されている場合には、エラーメッセージが表示されます。ただし、libguestfs-tools プロセスが開始されると、設定では同じ PVC を使用する新規 Pod を回避できません。同じ PVC にアクセスする仮想マシンを起動する前に、アクティブな virtctl guestfs Pod がないことを確認する必要があります。
virtctl guestfs コマンドは、インタラクティブな Pod に割り当てられている PVC 1 つだけを受け入れます。
3.2.4. Ansible の使用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization 用の Ansible コレクションを使用するには、Red Hat Ansible Automation Hub (Red Hat Hybrid Cloud Console) を参照してください。
第4章 インストール リンクのコピーリンクがクリップボードにコピーされました!
4.1. OpenShift Virtualization のクラスターの準備 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization をインストールする前にこのセクションを確認して、クラスターが要件を満たしていることを確認してください。
- インストール方法の考慮事項
- ユーザープロビジョニング、インストーラープロビジョニング、またはアシステッドインストーラーなど、任意のインストール方法を使用して、OpenShift Container Platform をデプロイできます。ただし、インストール方法とクラスタートポロジーは、スナップショットや ライブマイグレーション などの OpenShift Virtualization 機能に影響を与える可能性があります。
- Red Hat OpenShift Data Foundation
- Red Hat OpenShift Data Foundation を使用して OpenShift Virtualization をデプロイする場合は、Windows 仮想マシンディスク用の専用ストレージクラスを作成する必要があります。詳細は Optimizing ODF PersistentVolumes for Windows VMs を参照してください。
- IPv6
- シングルスタックの IPv6 クラスターで OpenShift Virtualization は実行できません。
FIPS モード
クラスターを FIPS モード でインストールする場合、OpenShift Virtualization に追加の設定は必要ありません。
4.1.1. サポート対象のプラットフォーム リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization では、以下のプラットフォームを使用できます。
- オンプレミスのベアメタルサーバー。OpenShift Virtualization で使用するベアメタルクラスターの計画 を参照してください。
- Amazon Web Services ベアメタルインスタンス。カスタマイズを使用して AWS にクラスターをインストールする を参照してください。
IBM Cloud® ベアメタルサーバー。Deploy OpenShift Virtualization on IBM Cloud® Bare Metal nodes を参照してください。
重要IBM Cloud® ベアメタルサーバーへの OpenShift Virtualization のインストールは、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
他のクラウドプロバイダーが提供するベアメタルインスタンスまたはサーバーはサポートされていません。
4.1.1.1. AWS ベアメタル上の OpenShift Virtualization リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization は、Amazon Web Services (AWS) ベアメタル OpenShift Container Platform クラスターで実行できます。
OpenShift Virtualization は、AWS ベアメタルクラスターと同じ設定要件を持つ Red Hat OpenShift Service on AWS (ROSA) Classic クラスターでもサポートされています。
クラスターを設定する前に、サポート対象の機能と制限に関する以下の要約を確認してください。
- インストール
インストーラーでプロビジョニングされるインフラストラクチャーを使用してクラスターをインストールし、ワーカーノードにベアメタルインスタンスタイプを指定する必要があります。たとえば、x86_64 アーキテクチャーをベースとするマシンの
c5n.metalタイプの値を使用できます。install-config.yamlファイルを編集して、ベアメタルインスタンスタイプを指定します。詳細は、AWS へのインストールに関する OpenShift Container Platform ドキュメントを参照してください。
- 仮想マシン (VM) へのアクセス
-
virtctlCLI ツールまたは OpenShift Container Platform Web コンソールを使用して仮想マシンにアクセスする方法に変更はありません。 NodePortまたはLoadBalancerサービスを使用して、仮想マシンを公開できます。- OpenShift Container Platform は AWS でロードバランサーを自動的に作成し、そのライフサイクルを管理するため、ロードバランサーのアプローチが推奨されます。また、セキュリティーグループはロードバランサー用にも作成され、アノテーションを使用して既存のセキュリティーグループをアタッチできます。サービスを削除すると、OpenShift Container Platform はロードバランサーとそれに関連付けられたリソースを削除します。
- ネットワーク
- Single Root I/O Virtualization (SR-IOV) またはブリッジ Container Network Interface (CNI) ネットワーク (仮想 LAN (VLAN) を含む) は使用できません。アプリケーションにフラットレイヤー 2 ネットワークが必要な場合や、IP プールを制御する必要がある場合は、OVN-Kubernetes セカンダリーオーバーレイネットワークを使用することを検討してください。
- ストレージ
基盤となるプラットフォームとの連携がストレージベンダーによって認定されている任意のストレージソリューションを使用できます。
重要AWS ベアメタルクラスターと ROSA クラスターでは、サポートされているストレージソリューションが異なる場合があります。ストレージベンダーにサポートを確認してください。
OpenShift Virtualization で Amazon Elastic File System (EFS) または Amazon Elastic Block Store (EBS) を使用すると、次の表に示すようにパフォーマンスと機能の制限が発生する可能性があります。
Expand 表4.1 EFS と EBS のパフォーマンスと機能の制限 機能 EBS ボリューム EFS ボリューム 共有ストレージソリューション gp2
gp3
io2
仮想マシンライブマイグレーション
利用不可
利用不可
利用可能
利用可能
利用可能
クローン作成による高速仮想マシン作成
利用可能
利用不可
利用可能
スナップショットを使用した仮想マシンのバックアップと復元
利用可能
利用不可
利用可能
ライブマイグレーション、高速仮想マシンの作成、仮想マシンスナップショット機能の有効化を行うには、ReadWriteMany (RWX)、クローン作成、スナップショットをサポートする CSI ストレージの使用を検討してください。
- Hosted Control Plane (HCP)
- OpenShift Virtualization の HCP は現在、AWS インフラストラクチャーではサポートされていません。
4.1.2. ハードウェアとオペレーティングシステムの要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization の次のハードウェアおよびオペレーティングシステム要件を確認してください。
4.1.2.1. CPU の要件 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux (RHEL) 9 でサポート。
サポートされている CPU の Red Hat Ecosystem Catalog を参照してください。
注記ワーカーノードの CPU が異なる場合は、CPU ごとに機能が異なるため、ライブマイグレーションが失敗する可能性があります。この問題は、ワーカーノードに適切な容量の CPU が搭載されていることを確認し、仮想マシンのノードアフィニティールールを設定することで軽減できます。
詳細は、ノードアフィニティーの required (必須) ルールの設定 を参照してください。
- AMD および Intel 64 ビットアーキテクチャー (x86-64-v2) のサポート。
- Intel 64 または AMD64 CPU 拡張機能のサポート。
- Intel VT または AMD-V ハードウェア仮想化拡張機能が有効化されている。
- NX (実行なし) フラグが有効。
4.1.2.2. オペレーティングシステム要件 リンクのコピーリンクがクリップボードにコピーされました!
ワーカーノードにインストールされた Red Hat Enterprise Linux CoreOS (RHCOS)。
詳細は、RHCOS について を参照してください。
注記RHEL ワーカーノードはサポートされていません。
4.1.2.3. ストレージ要件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform によるサポート。ストレージの最適化 を参照してください。
- デフォルトの OpenShift Virtualization または OpenShift Container Platform ストレージクラスを作成する必要があります。これは、仮想マシンワークロード固有のストレージニーズに対応し、最適化されたパフォーマンス、信頼性、ユーザーエクスペリエンスを提供することを目的としています。OpenShift Virtualization と OpenShift Container Platform の両方にデフォルトのストレージクラスが存在する場合、仮想マシンディスクの作成時には OpenShift Virtualization のクラスが優先されます。
ストレージクラスを仮想化ワークロードのデフォルトとしてマークするには、アノテーション storageclass.kubevirt.io/is-default-virt-class を "true" に設定します。
-
ストレージプロビジョナーがスナップショットをサポートしている場合は、
VolumeSnapshotClassオブジェクトをデフォルトのストレージクラスに関連付ける必要があります。
4.1.2.3.1. 仮想マシンディスクのボリュームとアクセスモードについて リンクのコピーリンクがクリップボードにコピーされました!
既知のストレージプロバイダーでストレージ API を使用する場合、ボリュームモードとアクセスモードは自動的に選択されます。ただし、ストレージプロファイルのないストレージクラスを使用する場合は、ボリュームとアクセスモードを設定する必要があります。
OpenShift Virtualization に対応している既知のストレージプロバイダーのリストは、Red Hat Ecosystem Catalog を参照してください。
最良の結果を得るには、ReadWriteMany (RWX) アクセスモードと Block ボリュームモードを使用してください。これは、以下の理由により重要です。
-
ライブマイグレーションには
ReadWriteMany(RWX) アクセスモードが必要です。 Blockボリュームモードは、Filesystemボリュームモードよりもパフォーマンスが大幅に優れています。これは、Filesystemボリュームモードでは、ファイルシステムレイヤーやディスクイメージファイルなどを含め、より多くのストレージレイヤーが使用されるためです。仮想マシンのディスクストレージに、これらのレイヤーは必要ありません。たとえば、Red Hat OpenShift Data Foundation を使用する場合は、CephFS ボリュームよりも Ceph RBD ボリュームの方が推奨されます。
次の設定の仮想マシンをライブマイグレーションすることはできません。
-
ReadWriteOnce(RWO) アクセスモードのストレージボリューム - GPU などのパススルー機能
これらの仮想マシンの evictionStrategy フィールドを None に設定します。None ストラテジーでは、ノードの再起動中に仮想マシンの電源がオフになります。
4.1.3. ライブマイグレーションの要件 リンクのコピーリンクがクリップボードにコピーされました!
-
ReadWriteMany(RWX) アクセスモードの共有ストレージ 十分な RAM およびネットワーク帯域幅
注記ノードのドレインに伴うライブマイグレーションを実行できるように、クラスター内に十分なメモリーリクエスト容量があることを確認する必要があります。以下の計算を使用して、必要な予備のメモリーを把握できます。
Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)
Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターで 並行して実行できるデフォルトの移行数 は 5 です。
- 仮想マシンがホストモデルの CPU を使用する場合、ノードは仮想マシンのホストモデルの CPU をサポートする必要があります。
- ライブマイグレーション 専用の Multus ネットワーク を強く推奨します。専用ネットワークは、移行中のテナントワークロードに対するネットワークの飽和状態の影響を最小限に抑えます。
4.1.4. 物理リソースのオーバーヘッド要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization は OpenShift Container Platform のアドオンであり、クラスターの計画時に考慮する必要のある追加のオーバーヘッドを強要します。各クラスターマシンは、OpenShift Container Platform の要件に加えて、以下のオーバーヘッドの要件を満たす必要があります。クラスター内の物理リソースを過剰にサブスクライブすると、パフォーマンスに影響する可能性があります。
このドキュメントに記載されている数は、Red Hat のテスト方法およびセットアップに基づいています。これらの数は、独自のセットアップおよび環境に応じて異なります。
メモリーのオーバーヘッド
以下の式を使用して、OpenShift Virtualization のメモリーオーバーヘッドの値を計算します。
クラスターメモリーのオーバーヘッド
Memory overhead per infrastructure node ≈ 150 MiB
Memory overhead per infrastructure node ≈ 150 MiB
Memory overhead per worker node ≈ 360 MiB
Memory overhead per worker node ≈ 360 MiB
さらに、OpenShift Virtualization 環境リソースには、すべてのインフラストラクチャーノードに分散される合計 2179 MiB の RAM が必要です。
仮想マシンのメモリーオーバーヘッド
Memory overhead per virtual machine ≈ (0.002 × requested memory) \
+ 218 MiB \
+ 8 MiB × (number of vCPUs) \
+ 16 MiB × (number of graphics devices) \
+ (additional memory overhead)
Memory overhead per virtual machine ≈ (0.002 × requested memory) \
+ 218 MiB \
+ 8 MiB × (number of vCPUs) \
+ 16 MiB × (number of graphics devices) \
+ (additional memory overhead)
- 1
virt-launcherPod で実行されるプロセスに必要です。- 2
- 仮想マシンが要求する仮想 CPU の数。
- 3
- 仮想マシンが要求する仮想グラフィックスカードの数。
- 4
- 追加のメモリーオーバーヘッド:
- お使いの環境に Single Root I/O Virtualization (SR-IOV) ネットワークデバイスまたは Graphics Processing Unit (GPU) が含まれる場合、それぞれのデバイスに 1 GiB の追加のメモリーオーバーヘッドを割り当てます。
- Secure Encrypted Virtualization (SEV) が有効な場合は、256 MiB を追加します。
- Trusted Platform Module (TPM) が有効な場合は、53 MiB を追加します。
CPU オーバーヘッド
以下の式を使用して、OpenShift Virtualization のクラスタープロセッサーのオーバーヘッド要件を計算します。仮想マシンごとの CPU オーバーヘッドは、個々の設定によって異なります。
クラスターの CPU オーバーヘッド
CPU overhead for infrastructure nodes ≈ 4 cores
CPU overhead for infrastructure nodes ≈ 4 cores
OpenShift Virtualization は、ロギング、ルーティング、およびモニタリングなどのクラスターレベルのサービスの全体的な使用率を増加させます。このワークロードに対応するには、インフラストラクチャーコンポーネントをホストするノードに、4 つの追加コア (4000 ミリコア) の容量があり、これがそれらのノード間に分散されていることを確認します。
CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine
CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine
仮想マシンをホストする各ワーカーノードには、仮想マシンのワークロードに必要な CPU に加えて、OpenShift Virtualization 管理ワークロード用に 2 つの追加コア (2000 ミリコア) の容量が必要です。
仮想マシンの CPU オーバーヘッド
専用の CPU が要求される場合は、仮想マシン 1 台につき CPU 1 つとなり、クラスターの CPU オーバーヘッド要件に影響が出てきます。それ以外の場合は、仮想マシンに必要な CPU の数に関する特別なルールはありません。
ストレージのオーバーヘッド
以下のガイドラインを使用して、OpenShift Virtualization 環境のストレージオーバーヘッド要件を見積もります。
クラスターストレージオーバーヘッド
Aggregated storage overhead per node ≈ 10 GiB
Aggregated storage overhead per node ≈ 10 GiB
10 GiB は、OpenShift Virtualization のインストール時にクラスター内の各ノードに関するディスク上のストレージの予想される影響に相当します。
仮想マシンのストレージオーバーヘッド
仮想マシンごとのストレージオーバーヘッドは、仮想マシン内のリソース割り当ての特定の要求により異なります。この要求は、クラスター内の別の場所でホストされるノードまたはストレージリソースの一時ストレージに対するものである可能性があります。OpenShift Virtualization は現在、実行中のコンテナー自体に追加の一時ストレージを割り当てていません。
例
クラスター管理者が、クラスター内の 10 台の (それぞれ 1 GiB の RAM と 2 つの仮想 CPU の) 仮想マシンをホストする予定の場合、クラスター全体で影響を受けるメモリーは 11.68 GiB になります。クラスターの各ノードについて予想されるディスク上のストレージの影響は 10 GiB で示され、仮想マシンのワークロードをホストするワーカーノードに関する CPU の影響は最小 2 コアで示されます。
4.1.5. シングルノード OpenShift の違い リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization はシングルノード OpenShift にインストールできます。
ただし、シングルノード OpenShift は次の機能をサポートしていないことに注意してください。
- 高可用性
- Pod の中断
- ライブマイグレーション
- エビクションストラテジーが設定されている仮想マシンまたはテンプレート
4.1.6. オブジェクトの最大値 リンクのコピーリンクがクリップボードにコピーされました!
クラスターを計画するときは、次のテスト済みオブジェクトの最大数を考慮する必要があります。
4.1.7. クラスターの高可用性オプション リンクのコピーリンクがクリップボードにコピーされました!
クラスターには、次の高可用性 (HA) オプションのいずれかを設定できます。
nstaller-provisioned infrastructure (IPI) の自動高可用性は、マシンヘルスチェック をデプロイすることで利用できます。
注記インストーラーによってプロビジョニングされたインフラストラクチャーを使用し、適切に設定された
MachineHealthCheckリソースを使用してインストールされた OpenShift Container Platform クラスターでは、ノードがマシンヘルスチェックに失敗し、クラスターで使用できなくなった場合、そのノードはリサイクルされます。障害が発生したノードで実行された仮想マシンでは、一連の条件によって次に起こる動作が変わります。潜在的な結果と実行ストラテジーがその結果にどのように影響するかについての詳細は、実行ストラテジー を参照してください。-
IPI と非 IPI の両方の自動高可用性は、OpenShift Container Platform クラスターで Node Health Check Operator を使用して
NodeHealthCheckコントローラーをデプロイすることで利用できます。コントローラーは異常なノードを特定し、Self Node Remediation Operator や Fence Agents Remediation Operator などの修復プロバイダーを使用して異常なノードを修復します。ノードの修復、フェンシング、メンテナンスの詳細は、Red Hat OpenShift のワークロードの可用性 を参照してください。 モニタリングシステムまたは有資格者を使用してノードの可用性をモニターすることにより、あらゆるプラットフォームの高可用性を利用できます。ノードが失われた場合は、これをシャットダウンして
oc delete node <lost_node>を実行します。注記外部モニタリングシステムまたは資格のある人材によるノードの正常性の監視が行われない場合、仮想マシンは高可用性を失います。
4.2. OpenShift Virtualization のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization をインストールし、仮想化機能を OpenShift Container Platform クラスターに追加します。
インターネット接続のない制限された環境に OpenShift Virtualization をインストールする場合は、制限されたネットワーク用に Operator Lifecycle Manager (OLM) を設定 する必要があります。
インターネット接続が制限されている場合は、OLM でプロキシーサポートを設定 して OperatorHub にアクセスできます。
4.2.1. OpenShift Virtualization Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールまたはコマンドラインを使用して、OpenShift Virtualization Operator をインストールします。
4.2.1.1. Web コンソールを使用した OpenShift Virtualization Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、OpenShift Virtualization Operator をデプロイできます。
前提条件
- OpenShift Container Platform 4.16 をクラスターにインストールしている。
-
cluster-adminパーミッションを持つユーザーとして OpenShift Container Platform Web コンソールにログインしている。
手順
- Administrator パースペクティブから、Operators → OperatorHub をクリックします。
- Filter by keyword に Virtualization と入力します。
- Red Hat ソースラベルが示されている OpenShift Virtualization Operator タイルを選択します。
- Operator の情報を確認してから、Install をクリックします。
Install Operator ページで以下を行います。
- 選択可能な Update Channel オプションの一覧から stable を選択します。これにより、OpenShift Container Platform バージョンと互換性がある OpenShift Virtualization のバージョンをインストールすることができます。
インストールされた namespace の場合、Operator recommended namespace オプションが選択されていることを確認します。これにより、Operator が必須の
openshift-cnvnamespace にインストールされます。この namespace は存在しない場合は、自動的に作成されます。警告OpenShift Virtualization Operator を
openshift-cnv以外の namespace にインストールしようとすると、インストールが失敗します。Approval Strategy の場合に、stable 更新チャネルで新しいバージョンが利用可能になったときに OpenShift Virtualization が自動更新されるように、デフォルト値である Automatic を選択することを強く推奨します。
Manual 承認ストラテジーを選択することは可能ですが、クラスターのサポート容易性および機能に対応するリスクが高いため、推奨できません。これらのリスクを完全に理解していて、Automatic を使用できない場合のみ、Manual を選択してください。
警告OpenShift Virtualization は対応する OpenShift Container Platform バージョンで使用される場合にのみサポートされるため、OpenShift Virtualization が更新されないと、クラスターがサポートされなくなる可能性があります。
-
Install をクリックし、Operator を
openshift-cnvnamespace で利用可能にします。 - Operator が正常にインストールされたら、Create HyperConverged をクリックします。
- オプション: OpenShift Virtualization コンポーネントの Infra および Workloads ノード配置オプションを設定します。
- Create をクリックして OpenShift Virtualization を起動します。
検証
- Workloads → Pods ページに移動して、OpenShift Virtualization Pod がすべて Running 状態になるまでこれらの Pod をモニターします。すべての Pod で Running 状態が表示された後に、OpenShift Virtualization を使用できます。
4.2.1.2. コマンドラインを使用した OpenShift Virtualization Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization カタログをサブスクライブし、クラスターにマニフェストを適用して OpenShift Virtualization Operator をインストールします。
4.2.1.2.1. CLI を使用した OpenShift Virtualization カタログのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization をインストールする前に、OpenShift Virtualization カタログにサブスクライブする必要があります。サブスクライブにより、openshift-cnv namespace に OpenShift Virtualization Operator へのアクセスが付与されます。
単一マニフェストをクラスターに適用して Namespace、OperatorGroup、および Subscription オブジェクトをサブスクライブし、設定します。
前提条件
- OpenShift Container Platform 4.16 をクラスターにインストールしている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
以下のマニフェストを含む YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
stableチャネルを使用することで、OpenShift Container Platform バージョンと互換性のある OpenShift Virtualization のバージョンをインストールすることができます。
以下のコマンドを実行して、OpenShift Virtualization に必要な
Namespace、OperatorGroup、およびSubscriptionオブジェクトを作成します。oc apply -f <file name>.yaml
$ oc apply -f <file name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
YAML ファイルで、証明書のローテーションパラメーターを設定 できます。
4.2.1.2.2. CLI を使用した OpenShift Virtualization Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
oc CLI を使用して OpenShift Virtualization Operator をデプロイすることができます。
前提条件
-
openshift-cnvnamespace の OpenShift Virtualization カタログへのサブスクリプション。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
以下のマニフェストを含む YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して OpenShift Virtualization Operator をデプロイします。
oc apply -f <file_name>.yaml
$ oc apply -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
openshift-cnvnamespace の Cluster Service Version (CSV) のPHASEを監視して、OpenShift Virtualization が正常にデプロイされたことを確認します。以下のコマンドを実行します。watch oc get csv -n openshift-cnv
$ watch oc get csv -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の出力は、デプロイメントに成功したかどうかを表示します。
出力例
NAME DISPLAY VERSION REPLACES PHASE kubevirt-hyperconverged-operator.v4.16.21 OpenShift Virtualization 4.16.21 Succeeded
NAME DISPLAY VERSION REPLACES PHASE kubevirt-hyperconverged-operator.v4.16.21 OpenShift Virtualization 4.16.21 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- ホストパスプロビジョナー は、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。
4.3. OpenShift Virtualization のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールまたはコマンドラインインターフェイス (CLI) を使用して OpenShift Virtualization をアンインストールし、OpenShift Virtualization のワークロード、Operator、およびそのリソースを削除します。
4.3.1. Web コンソールを使用した OpenShift Virtualization のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization をアンインストールするには、Web コンソール を使用して次のタスクを実行します。
まず、すべての 仮想マシン と 仮想マシンインスタンス を削除する必要があります。
ワークロードがクラスターに残っている間は、OpenShift Virtualization をアンインストールできません。
4.3.1.1. HyperConverged カスタムリソースの削除 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization をアンインストールするには、最初に HyperConverged カスタムリソース (CR) を削除します。
前提条件
-
cluster-adminパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
- Operators → Installed Operators ページに移動します。
- OpenShift Virtualization Operator を選択します。
- OpenShift Virtualization Deployment タブをクリックします。
-
kubevirt-hyperconvergedの横にある Options メニュー
をクリックし、Delete HyperConverged を選択します。
- 確認ウィンドウで Delete をクリックします。
4.3.1.2. Web コンソールの使用によるクラスターからの Operator の削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は Web コンソールを使用して、選択した namespace からインストールされた Operators を削除できます。
前提条件
-
cluster-adminパーミッションを持つアカウントを使用して OpenShift Container Platform クラスター Web コンソールにアクセスできる。
手順
- Operators → Installed Operators ページに移動します。
- スクロールするか、キーワードを Filter by name フィールドに入力して、削除する Operator を見つけます。次に、それをクリックします。
Operator Details ページの右側で、Actions 一覧から Uninstall Operator を選択します。
Uninstall Operator? ダイアログボックスが表示されます。
Uninstall を選択し、Operator、Operator デプロイメント、および Pod を削除します。このアクションの後には、Operator は実行を停止し、更新を受信しなくなります。
注記このアクションは、カスタムリソース定義 (CRD) およびカスタムリソース (CR) など、Operator が管理するリソースは削除されません。Web コンソールおよび継続して実行されるクラスター外のリソースによって有効にされるダッシュボードおよびナビゲーションアイテムには、手動でのクリーンアップが必要になる場合があります。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。
4.3.1.3. Web コンソールを使用した namespace の削除 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して namespace を削除できます。
前提条件
-
cluster-adminパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
- Administration → Namespaces に移動します。
- namespace の一覧で削除する必要のある namespace を見つけます。
-
namespace の一覧の右端で、Options メニュー
から Delete Namespace を選択します。
- Delete Namespace ペインが表示されたら、フィールドから削除する namespace の名前を入力します。
- Delete をクリックします。
4.3.1.4. OpenShift Virtualization カスタムリソース定義の削除 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、OpenShift Virtualization カスタムリソース定義 (CRD) を削除できます。
前提条件
-
cluster-adminパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
- Administration → CustomResourceDefinitions に移動します。
-
Label フィルターを選択し、Search フィールドに
operators.coreos.com/kubevirt-hyperconverged.openshift-cnvと入力して OpenShift Virtualization CRD を表示します。 -
各 CRD の横にある Options メニュー
をクリックし、Delete CustomResourceDefinition の削除を選択します。
4.3.2. CLI を使用した OpenShift Virtualization のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc) を使用して OpenShift Virtualization をアンインストールできます。
前提条件
-
cluster-adminパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。 - すべての仮想マシンと仮想マシンインスタンスを削除した。ワークロードがクラスターに残っている間は、OpenShift Virtualization をアンインストールできません。
手順
HyperConvergedカスタムリソースを削除します。oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnv
$ oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Virtualization Operator サブスクリプションを削除します。
oc delete subscription kubevirt-hyperconverged -n openshift-cnv
$ oc delete subscription kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Virtualization
ClusterServiceVersionリソースを削除します。oc delete csv -n openshift-cnv -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv
$ oc delete csv -n openshift-cnv -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Virtualization namespace を削除します。
oc delete namespace openshift-cnv
$ oc delete namespace openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow dry-runオプションを指定してoc delete crdコマンドを実行し、OpenShift Virtualization カスタムリソース定義 (CRD) を一覧表示します。oc delete crd --dry-run=client -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv
$ oc delete crd --dry-run=client -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dry-runオプションを指定せずにoc delete crdコマンドを実行して、CRD を削除します。oc delete crd -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv
$ oc delete crd -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第5章 インストール後の設定 リンクのコピーリンクがクリップボードにコピーされました!
5.1. インストール後の設定 リンクのコピーリンクがクリップボードにコピーされました!
通常、次の手順は OpenShift Virtualization のインストール後に実行されます。環境に関連するコンポーネントを設定できます。
- OpenShift Virtualization Operator、ワークロード、およびコントローラーのノード配置ルール
- Kubernetes NMState および SR-IOV Operator のインストール
- 仮想マシンへの外部アクセスのための Linux ブリッジネットワークの設定
- ライブマイグレーション用の専用セカンダリーネットワークの設定
- SR-IOV ネットワークの設定
- OpenShift Container Platform Web コンソールを使用したロードバランサーサービスの作成の有効化
- Container Storage Interface (CSI) のデフォルトのストレージクラスの定義
- ホストパスプロビジョナー (HPP) を使用したローカルストレージの設定
5.2. OpenShift Virtualization コンポーネントのノードの指定 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルノード上の仮想マシンのデフォルトのスケジューリングは適切です。任意で、ノードの配置ルールを設定して、OpenShift Virtualization Operator、ワークロード、およびコントローラーをデプロイするノードを指定できます。
OpenShift Virtualization のインストール後に一部のコンポーネントに対してノード配置ルールを設定できますが、ワークロードに対してノード配置ルールを設定する場合は仮想マシンが存在できません。
5.2.1. OpenShift Virtualization コンポーネントのノード配置ルールについて リンクのコピーリンクがクリップボードにコピーされました!
ノード配置ルールは次のタスクに使用できます。
- 仮想マシンは、仮想化ワークロードを対象としたノードにのみデプロイしてください。
- Operator はインフラストラクチャーノードにのみデプロイメントします。
- ワークロード間の分離を維持します。
オブジェクトに応じて、以下のルールタイプを 1 つ以上使用できます。
nodeSelector- このフィールドで指定したキーと値のペアでラベル付けされたノードで Pod をスケジュールできるようにします。ノードには、リスト表示されたすべてのペアに一致するラベルがなければなりません。
affinity- より表現的な構文を使用して、ノードと Pod に一致するルールを設定できます。アフィニティーを使用すると、ルールの適用方法に追加のニュアンスを持たせることができます。たとえば、ルールが要件ではなく設定であると指定できます。ルールが優先の場合、ルールが満たされていない場合でも Pod はスケジュールされます。
tolerations- 一致する taint を持つノードに Pod をスケジュールすることを許容します。ノードに taint が適用されると、そのノードはその taint を許容する Pod のみを受け入れます。
5.2.2. ノード配置ルールの適用 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して Subscription、HyperConverged、または HostPathProvisioner オブジェクトを編集することで、ノード配置ルールを適用できます。
前提条件
-
ocCLI ツールがインストールされている。 - クラスター管理者の権限でログインしています。
手順
次のコマンドを実行して、デフォルトのエディターでオブジェクトを編集します。
oc edit <resource_type> <resource_name> -n openshift-cnv
$ oc edit <resource_type> <resource_name> -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。
5.2.3. ノード配置ルールの例 リンクのコピーリンクがクリップボードにコピーされました!
Subscription、HyperConverged、または HostPathProvisioner オブジェクトを編集することで、OpenShift Virtualization コンポーネントのノード配置ルールを指定できます。
5.2.3.1. サブスクリプションオブジェクトノード配置ルールの例 リンクのコピーリンクがクリップボードにコピーされました!
OLM が OpenShift Virtualization Operator をデプロイするノードを指定するには、OpenShift Virtualization のインストール時に Subscription オブジェクトを編集します。
現時点では、Web コンソールを使用して Subscription オブジェクトのノードの配置ルールを設定することはできません。
Subscription オブジェクトは、affinity ノードの配置ルールをサポートしていません。
nodeSelector ルールを使用した Subscription オブジェクトの例
- 1
- OLM は、
example.io/example-infra-key = example-infra-valueというラベルのノードに OpenShift Virtualization Operator をデプロイします。
tolerations ルールを備えた Subscription オブジェクトの例
- 1
- OLM は、
key = virtualization:NoScheduletaint のラベルが付けられているノードに OpenShift Virtualization Operator をデプロイします。このノードには、一致する toleration を持つ Pod のみがスケジュールされます。
5.2.3.2. HyperConverged オブジェクトノード配置ルールの例 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization がそのコンポーネントをデプロイするノードを指定するには、OpenShift Virtualization のインストール時に作成する HyperConverged カスタムリソース (CR) ファイルに nodePlacement オブジェクトを編集できます。
nodeSelector ルールを使用した HyperConverged オブジェクトの例
affinity ルールを使用した HyperConverged オブジェクトの例
tolerations ルールを備えた HyperConverged オブジェクトの例
- 1
- OpenShift Virtualization コンポーネント用に予約されているノードには、
key = virtualization:NoScheduletaint のラベルが付けられています。予約済みノードには、一致する toleration を持つ Pod のみがスケジュールされます。
5.2.3.3. HostPathProvisioner オブジェクトノード配置ルールの例 リンクのコピーリンクがクリップボードにコピーされました!
HostPathProvisioner オブジェクトは、直接編集することも、Web コンソールを使用して編集することもできます。
ホストパスプロビジョナーと OpenShift Virtualization コンポーネントを同じノード上でスケジュールする必要があります。スケジュールしない場合は、ホストパスプロビジョナーを使用する仮想化 Pod を実行できません。仮想マシンを実行することはできません。
ホストパスプロビジョナー (HPP) ストレージクラスを使用して仮想マシン (VM) をデプロイした後、ノードセレクターを使用して同じノードからホストパスプロビジョナー Pod を削除できます。ただし、少なくともその特定のノードは、まずその変更を元に戻し、仮想マシンを削除しようとする前に Pod が実行されるのを待つ必要があります。
ノード配置ルールを設定するには、ホストパスプロビジョナーのインストール時に作成する HostPathProvisioner オブジェクトの spec.workload フィールドに nodeSelector、affinity、または tolerations を指定します。
nodeSelector ルールを使用した HostPathProvisioner オブジェクトの例
- 1
- ワークロードは、
example.io/example-workloads-key = example-workloads-valueというラベルの付いたノードに配置されます。
5.3. インストール後のネットワーク設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、OpenShift Virtualization は単一の内部 Pod ネットワークとともにインストールされます。
OpenShift Virtualization をインストールした後、ネットワーク Operator をインストールし、追加のネットワークを設定できます。
5.3.1. ネットワーク Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
ライブマイグレーションまたは仮想マシン (VM) への外部アクセス用に Linux ブリッジネットワークを設定するには、Kubernetes NMState Operator をインストールする必要があります。インストール手順は、Web コンソールを使用した Kubernetes NMState Operator のインストール を参照してください。
SR-IOV Operator をインストールして、SR-IOV ネットワークデバイスとネットワークアタッチメントを管理できます。インストール手順は、SR-IOV Network Operator のインストール を参照してください。
MetalLB と MetalLB Operator を追加すると、クラスター上の MetalLB インスタンスのライフサイクルを管理できます。インストール手順は、Web コンソールを使用した OperatorHub からの MetalLB Operator のインストール を参照してください。
5.3.2. Linux ブリッジネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes NMState Operator をインストールしたら、ライブマイグレーションまたは仮想マシン (VM) への外部アクセス用に Linux ブリッジネットワークを設定できます。
5.3.2.1. Linux ブリッジ NNCP の作成 リンクのコピーリンクがクリップボードにコピーされました!
Linux ブリッジネットワークの NodeNetworkConfigurationPolicy (NNCP) マニフェストを作成できます。
前提条件
- Kubernetes NMState Operator がインストールされている。
手順
NodeNetworkConfigurationPolicyマニフェストを作成します。この例には、独自の情報で置き換える必要のあるサンプルの値が含まれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.2.2. Web コンソールを使用した Linux ブリッジ NAD の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、Network Attachment Definition (NAD) を作成して、Pod および仮想マシンに layer-2 ネットワークを提供できます。
Linux ブリッジ Network Attachment Definition は、仮想マシンを VLAN に接続するための最も効率的な方法です。
仮想マシンのネットワークアタッチメント定義での IP アドレス管理 (IPAM) の設定はサポートされていません。
手順
- Web コンソールで、Networking → NetworkAttachmentDefinitions をクリックします。
Create Network Attachment Definition をクリックします。
注記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 をクリックします。
次のステップ
5.3.3. ライブマイグレーション用のネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
Linux ブリッジネットワークを設定した後、ライブマイグレーション用の専用ネットワークを設定できます。専用ネットワークは、ライブマイグレーション中のテナントワークロードに対するネットワークの飽和状態の影響を最小限に抑えます。
5.3.3.1. ライブマイグレーション用の専用セカンダリーネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
ライブマイグレーション用に専用のセカンダリーネットワークを設定するには、まず CLI を使用してブリッジ Network Attachment Definition (NAD) を作成する必要があります。次に、NetworkAttachmentDefinition オブジェクトの名前を HyperConverged カスタムリソース (CR) に追加します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインしている。 - 各ノードには少なくとも 2 つのネットワークインターフェイスカード (NIC) があります。
- ライブマイグレーション用の NIC は同じ VLAN に接続されます。
手順
次の例に従って、
NetworkAttachmentDefinitionマニフェストを作成します。設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow NetworkAttachmentDefinitionオブジェクトの名前をHyperConvergedCR のspec.liveMigrationConfigスタンザに追加します。HyperConvergedマニフェストの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ライブマイグレーションに使用される Multus
NetworkAttachmentDefinitionオブジェクトの名前を指定します。
-
変更を保存し、エディターを終了します。
virt-handlerPod が再起動し、セカンダリーネットワークに接続されます。
検証
仮想マシンが実行されるノードがメンテナンスモードに切り替えられると、仮想マシンは自動的にクラスター内の別のノードに移行します。仮想マシンインスタンス (VMI) メタデータのターゲット IP アドレスを確認して、デフォルトの Pod ネットワークではなく、セカンダリーネットワーク上で移行が発生したことを確認できます。
oc get vmi <vmi_name> -o jsonpath='{.status.migrationState.targetNodeAddress}'$ oc get vmi <vmi_name> -o jsonpath='{.status.migrationState.targetNodeAddress}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.3.2. Web コンソールを使用して専用ネットワークを選択する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、ライブマイグレーション用の専用ネットワークを選択できます。
前提条件
- ライブマイグレーション用に Multus ネットワークが設定されている。
- ネットワークの Network Attachment Definition を作成している。
手順
- OpenShift Container Platform Web コンソールで Virtualization > Overview に移動します。
- Settings タブをクリックし、Live migration をクリックします。
- Live migration network リストからネットワークを選択します。
5.3.4. SR-IOV ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Operator をインストールした後、SR-IOV ネットワークを設定できます。
5.3.4.1. SR-IOV ネットワークデバイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。
SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。再起動は次の場合にのみ行われます。
-
Mellanox NIC (
mlx5ドライバー) の場合、Physical Function (PF) 上の Virtual Function (VF) の数が増加するたびにノードの再起動が行われます。 -
Intel NIC の場合、カーネルパラメーターに
intel_iommu=onとiommu=ptが含まれていない場合にのみ再起動が行われます。
設定の変更が適用されるまでに数分かかる場合があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされている。
- ドレイン (解放) されたノードからエビクトされたワークロードを処理するために、クラスター内に利用可能な十分なノードがある。
- SR-IOV ネットワークデバイス設定にコントロールプレーンノードを選択していない。
手順
SriovNetworkNodePolicyオブジェクトを作成してから、YAML を<name>-sriov-node-network.yamlファイルに保存します。<name>をこの設定の名前に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
- オプション: Virtual Function の最大転送単位 (MTU) の値を指定します。MTU の最大値は NIC モデルによって異なります。
- 7
- SR-IOV 物理ネットワークデバイス用に作成する仮想機能 (VF) の数を指定します。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は
127よりも大きくすることはできません。 - 8
nicSelectorマッピングは、Operator が設定するイーサネットデバイスを選択します。すべてのパラメーターの値を指定する必要はありません。意図せずにイーサネットデバイスを選択する可能性を最低限に抑えるために、イーサネットアダプターを正確に特定できるようにすることが推奨されます。rootDevicesを指定する場合は、vendor、deviceID、またはpfNamesの値も指定する必要があります。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
$ oc create -f <name>-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<name>はこの設定の名前を指定します。設定の更新が適用された後に、
sriov-network-operatornamespace のすべての Pod がRunningステータスに移行します。SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。
<node_name>を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
5.3.5. Web コンソールを使用したロードバランサーサービスの作成の有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシン (VM) のロードバランサーサービスの作成を有効にすることができます。
前提条件
- クラスターのロードバランサーが設定されました。
-
cluster-adminロールを持つユーザーとしてログインしている。 - ネットワークの Network Attachment Definition を作成している。
手順
- Virtualization → Overview に移動します。
- Settings タブで、Cluster をクリックします。
- Expand General settings と SSH configuration を展開します。
- SSH over LoadBalancer service をオンに設定します。
5.4. インストール後のストレージ設定 リンクのコピーリンクがクリップボードにコピーされました!
次のストレージ設定タスクは必須です。
- クラスターの デフォルトのストレージクラス を設定する必要があります。そうしないと、クラスターは自動ブートソース更新を受信できません。
- ストレージプロバイダーが CDI によって認識されない場合は、storage profiles を設定する必要があります。ストレージプロファイルは、関連付けられたストレージクラスに基づいて推奨されるストレージ設定を提供します。
オプション: ホストパスプロビジョナー (HPP) を使用して、ローカルストレージを設定できます。
Containerized Data Importer (CDI)、データボリューム、自動ブートソース更新の設定など、その他のオプションは、ストレージ設定の概要 を参照してください。
5.4.1. HPP を使用したローカルストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization Operator のインストール時に、Hostpath Provisioner (HPP) Operator は自動的にインストールされます。HPP Operator は HPP プロビジョナーを作成します。
HPP は、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。HPP を使用するには、HPP カスタムリソース (CR) を作成する必要があります。
HPP ストレージプールは、オペレーティングシステムと同じパーティションにあってはなりません。そうしないと、ストレージプールがオペレーティングシステムパーティションをいっぱいにする可能性があります。オペレーティングシステムのパーティションがいっぱいになると、パフォーマンスに影響が生じたり、ノードが不安定になったり使用できなくなったりする可能性があります。
5.4.1.1. storagePools スタンザを使用した CSI ドライバーのストレージクラスの作成 リンクのコピーリンクがクリップボードにコピーされました!
ホストパスプロビジョナー (HPP) を使用するには、コンテナーストレージインターフェイス (CSI) ドライバーに関連するストレージクラスを作成する必要があります。
ストレージクラスの作成時に、ストレージクラスに属する永続ボリューム (PV) の動的プロビジョニングに影響するパラメーターを設定します。StorageClass オブジェクトの作成後には、このオブジェクトのパラメーターを更新できません。
仮想マシンは、ローカル PV に基づくデータボリュームを使用します。ローカル PV は特定のノードにバインドされます。ディスクイメージは仮想マシンで使用するために準備されますが、ローカルストレージ PV がすでに固定されたノードに仮想マシンをスケジュールすることができない可能性があります。
この問題を解決するには、Kubernetes Pod スケジューラーを使用して、永続ボリューム要求 (PVC) を正しいノードの PV にバインドします。volumeBindingMode パラメーターが WaitForFirstConsumer に設定された StorageClass 値を使用することにより、PV のバインディングおよびプロビジョニングは、Pod が PVC を使用して作成されるまで遅延します。
手順
storageclass_csi.yamlファイルを作成して、ストレージクラスを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
reclaimPolicyには、DeleteおよびRetainの 2 つの値があります。値を指定しない場合、デフォルト値はDeleteです。- 2
volumeBindingModeパラメーターは、動的プロビジョニングとボリュームのバインディングが実行されるタイミングを決定します。WaitForFirstConsumerを指定して、永続ボリューム要求 (PVC) を使用する Pod が作成されるまで PV のバインディングおよびプロビジョニングを遅延させます。これにより、PV が Pod のスケジュール要件を満たすようになります。- 3
- HPP CR で定義されているストレージプールの名前を指定します。
- ファイルを保存して終了します。
次のコマンドを実行して、
StorageClassオブジェクトを作成します。oc create -f storageclass_csi.yaml
$ oc create -f storageclass_csi.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5. より高い仮想マシンワークロード密度の設定 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンの数を増やすには、メモリー (RAM) の量をオーバーコミットして、クラスター内の仮想マシンワークロード密度を高く設定します。
より高いワークロード密度を設定する機能は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
次のワークロードは、高いワークロード密度に特に適しています。
- 多数の類似ワークロード
- 過少使用されたワークロード
メモリーがオーバーコミットされると、ワークロード密度が高くなりますが、使用率の高いシステムのワークロードパフォーマンスが低下する可能性もあります。
5.5.1. wasp-agent を使用して仮想マシンワークロード密度を高く設定する リンクのコピーリンクがクリップボードにコピーされました!
wasp-agent コンポーネントにより、OpenShift Container Platform クラスターはスワップリソースを仮想マシンワークロードに割り当てることができます。スワップの使用は、ワーカーノードでのみサポートされます。
スワップリソースは、Burstable Quality of Service (QoS) クラスの仮想マシンワークロード (VM Pod) にのみ割り当てることができます。Guaranteed QoS クラスの仮想マシン Pod と、仮想マシンに属していない任意の QoS クラスの Pod は、リソースをスワップできません。
QoS クラスの説明は、Configure Quality of Service for Pods (Kubernetes ドキュメント) を参照してください。
前提条件
-
ocツールが利用できる。 - cluster-admin ロールでクラスターにログイン済みである。
- メモリーのオーバーコミット率が定義済みである。
- ノードはワーカープールに属している。
手順
次のコマンドを入力して、特権サービスアカウントを作成します。
oc adm new-project wasp
$ oc adm new-project waspCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc create sa -n wasp wasp
$ oc create sa -n wasp waspCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc create clusterrolebinding wasp --clusterrole=cluster-admin --serviceaccount=wasp:wasp
$ oc create clusterrolebinding wasp --clusterrole=cluster-admin --serviceaccount=wasp:waspCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm policy add-scc-to-user -n wasp privileged -z wasp
$ oc adm policy add-scc-to-user -n wasp privileged -z waspCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記wasp-agentコンポーネントは、OCI フックをデプロイして、ノードレベルでコンテナーのスワップ使用を有効にします。低レベルの性質上、DaemonSetオブジェクトには特権が必要です。次のように
DaemonSetオブジェクトを作成してwasp-agentをデプロイします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow スワップを許可するように
kubeletサービスを設定します。例に示すように、
KubeletConfigurationファイルを作成します。KubeletConfigurationファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターが既存の
KubeletConfigurationファイルをすでに使用している場合は、specセクションに以下を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行します。
$ oc wait mcp worker --for condition=Updated=True
$ oc wait mcp worker --for condition=Updated=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のとおり、スワップをプロビジョニングするための
MachineConfigオブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最悪のシナリオに備えて十分なスワップ領域を確保するには、オーバーコミットされた RAM と同量以上のスワップ領域をプロビジョニングしておく必要があります。次の式を使用して、ノードにプロビジョニングするスワップ領域の量を計算します。
NODE_SWAP_SPACE = NODE_RAM * (MEMORY_OVER_COMMIT_PERCENT / 100% - 1)
NODE_SWAP_SPACE = NODE_RAM * (MEMORY_OVER_COMMIT_PERCENT / 100% - 1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
NODE_SWAP_SPACE = 16 GB * (150% / 100% - 1) = 16 GB * (1.5 - 1) = 16 GB * (0.5) = 8 GBNODE_SWAP_SPACE = 16 GB * (150% / 100% - 1) = 16 GB * (1.5 - 1) = 16 GB * (0.5) = 8 GBCopy to Clipboard Copied! Toggle word wrap Toggle overflow アラートルールを次のようにデプロイします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform Web コンソールを使用するか、次の例のとおり HyperConverged カスタムリソース (CR) ファイルを編集して、メモリーオーバーコミットを使用するように OpenShift Virtualization を設定します。
Web コンソール
- OpenShift Container Platform Web コンソールで、Virtualization → Overview → Settings → General settings → Memory density に移動します。
- Enable memory density をオンに設定します。
CLI
より高いメモリー密度を有効にし、オーバーコミットレートを設定するように OpenShift Virtualization を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 正常な出力
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
注記すべての設定を適用すると、すべての
MachineConfigPoolロールアウトの完了後にのみスワップ機能が完全に利用可能になります。
検証
wasp-agentのデプロイメントを確認するには、次のコマンドを実行します。oc rollout status ds wasp-agent -n wasp
$ oc rollout status ds wasp-agent -n waspCopy to Clipboard Copied! Toggle word wrap Toggle overflow デプロイメントが成功すると、次のメッセージが表示されます。
daemon set "wasp-agent" successfully rolled out
daemon set "wasp-agent" successfully rolled outCopy to Clipboard Copied! Toggle word wrap Toggle overflow スワップが正しくプロビジョニングされていることを確認するには、次の手順を実行します。
以下のコマンドを実行します。
oc get nodes -l node-role.kubernetes.io/worker
$ oc get nodes -l node-role.kubernetes.io/workerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提供されたリストからノードを選択し、次のコマンドを実行します。
oc debug node/<selected-node> -- free -m
$ oc debug node/<selected-node> -- free -mCopy to Clipboard Copied! Toggle word wrap Toggle overflow スワップが正しくプロビジョニングされている場合、次のようにゼロより大きい値が表示されます。
Expand total
used
free
shared
buff/cache
available
Mem:
31846
23155
1044
6014
14483
8690
Swap:
8191
2337
5854
次のコマンドを実行して、OpenShift Virtualization のメモリーオーバーコミットメント設定を確認します。
oc -n openshift-cnv get HyperConverged/kubevirt-hyperconverged -o jsonpath='{.spec.higherWorkloadDensity}{"\n"}'$ oc -n openshift-cnv get HyperConverged/kubevirt-hyperconverged -o jsonpath='{.spec.higherWorkloadDensity}{"\n"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{"memoryOvercommitPercentage":150}{"memoryOvercommitPercentage":150}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 返される値は、以前に設定した値と一致する必要があります。
第6章 更新 リンクのコピーリンクがクリップボードにコピーされました!
6.1. OpenShift Virtualization の更新 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization を最新の状態に保ち、OpenShift Container Platform との互換性を維持する方法を説明します。
6.1.1. OpenShift Virtualization の更新について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization をインストールするときに、更新チャネルと承認ストラテジーを選択します。更新チャネルによって、OpenShift Virtualization が更新されるバージョンが決まります。承認ストラテジー設定により、更新が自動的に行われるか、手動の承認が必要かどうかが決まります。どちらの設定もサポート性に影響を与える可能性があります。
6.1.1.1. 推奨設定 リンクのコピーリンクがクリップボードにコピーされました!
サポート可能な環境を維持するには、次の設定を使用します。
- 更新チャネル: stable
- 承認ストラテジー: Automatic
これらの設定により、Operator の新しいバージョンが stable チャネルで利用可能になると、更新プロセスが自動的に開始されます。これにより、OpenShift Virtualization と OpenShift Container Platform のバージョンの互換性が維持され、OpenShift Virtualization のバージョンが実稼働環境に適したものになります。
OpenShift Virtualization の各マイナーバージョンは、対応する OpenShift Container Platform バージョンを実行する場合にのみサポートされます。たとえば、OpenShift Virtualization 4.16 は OpenShift Container Platform 4.16 で実行する必要があります。
6.1.1.2. 予想されること リンクのコピーリンクがクリップボードにコピーされました!
- 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。
- OpenShift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
- データボリュームとそれに関連付けられた永続ボリューム要求は、更新中に保持されます。
ホストパスプロビジョナーストレージを使用する仮想マシンを実行している場合、それらをライブマイグレーションすることはできず、OpenShift Container Platform クラスターの更新をブロックする可能性があります。
回避策として、仮想マシンを再設定し、クラスターの更新時にそれらの電源を自動的にオフになるようにできます。evictionStrategy フィールドを None に、runStrategy フィールドを Always に設定します。
6.1.1.3. 更新の仕組み リンクのコピーリンクがクリップボードにコピーされました!
- Operator Lifecycle Manager(OLM) は OpenShift Virtualization Operator のライフサイクルを管理します。OpenShift Container Platform のインストール時にデプロイされる Marketplace Operator により、クラスターで外部 Operator が利用できるようになります。
- OLM は、OpenShift Virtualization の z-stream およびマイナーバージョンの更新を提供します。OpenShift Container Platform を次のマイナーバージョンに更新すると、マイナーバージョンの更新が利用可能になります。OpenShift Container Platform を最初に更新しない限り、OpenShift Virtualization を次のマイナーバージョンに更新できません。
6.1.1.4. RHEL 9 の互換性 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization 4.16 は、Red Hat Enterprise Linux (RHEL) 9 をベースにしています。標準の OpenShift Virtualization 更新手順に従って、RHEL 8 をベースとするバージョンから OpenShift Virtualization 4.16 に更新できます。追加の手順は必要ありません。
以前のバージョンと同様に、実行中のワークロードを中断することなく更新を実行できます。OpenShift Virtualization 4.16 では、RHEL 8 ノードから RHEL 9 ノードへのライブマイグレーションがサポートされています。
6.1.1.4.1. RHEL 9 マシンタイプ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization に含まれるすべての仮想マシンテンプレートは、デフォルトで RHEL 9 マシンタイプ machineType: pc-q35-rhel9.<y>.0 を使用するようになりました。この場合の <y> は RHEL 9 の最新のマイナーバージョンに対応する 1 桁の数字です。たとえば、RHEL 9.2 の場合は pc-q35-rhel9.2.0 の値が使用されます。
OpenShift Virtualization を更新しても、既存仮想マシンの machineType 値は変更されません。これらの仮想マシンは、引き続き更新前と同様に機能します。RHEL 9 での改良を反映するために、オプションで仮想マシンのマシンタイプを変更できます。
仮想マシンの machineType 値を変更する前に、仮想マシンをシャットダウンする必要があります。
6.1.2. 更新ステータスの監視 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization Operator の更新のステータスをモニターするには、クラスターサービスバージョン (CSV) PHASE を監視します。Web コンソールを使用するか、ここに提供されているコマンドを実行して CSV の状態をモニターすることもできます。
PHASE および状態の値は利用可能な情報に基づく近似値になります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにログインしている。 -
OpenShift CLI (
oc) がインストールされている。
手順
以下のコマンドを実行します。
oc get csv -n openshift-cnv
$ oc get csv -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力を確認し、
PHASEフィールドをチェックします。以下に例を示します。出力例
VERSION REPLACES PHASE 4.9.0 kubevirt-hyperconverged-operator.v4.8.2 Installing 4.9.0 kubevirt-hyperconverged-operator.v4.9.0 Replacing
VERSION REPLACES PHASE 4.9.0 kubevirt-hyperconverged-operator.v4.8.2 Installing 4.9.0 kubevirt-hyperconverged-operator.v4.9.0 ReplacingCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 以下のコマンドを実行して、すべての OpenShift Virtualization コンポーネントの状態の集約されたステータスをモニターします。
oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv \ -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv \ -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow アップグレードが成功すると、以下の出力が得られます。
出力例
ReconcileComplete True Reconcile completed successfully Available True Reconcile completed successfully Progressing False Reconcile completed successfully Degraded False Reconcile completed successfully Upgradeable True Reconcile completed successfully
ReconcileComplete True Reconcile completed successfully Available True Reconcile completed successfully Progressing False Reconcile completed successfully Degraded False Reconcile completed successfully Upgradeable True Reconcile completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.1.3. 仮想マシンワークロードの更新 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization を更新すると、ライブマイグレーションをサポートしている場合には libvirt、virt-launcher、および qemu などの仮想マシンのワークロードが自動的に更新されます。
各仮想マシンには、仮想マシンインスタンス (VMI) を実行する virt-launcher Pod があります。virt-launcher Pod は、仮想マシン (VM) のプロセスを管理するために使用される libvirt のインスタンスを実行します。
HyperConverged カスタムリソース (CR) の spec.workloadUpdateStrategy スタンザを編集して、ワークロードの更新方法を設定できます。ワークロードの更新方法として、LiveMigrate と Evict の 2 つが利用可能です。
Evict メソッドは VMI Pod をシャットダウンするため、デフォルトでは LiveMigrate 更新ストラテジーのみが有効になっています。
LiveMigrate が有効な唯一の更新ストラテジーである場合:
- ライブマイグレーションをサポートする VMI は更新プロセス時に移行されます。VM ゲストは、更新されたコンポーネントが有効になっている新しい Pod に移動します。
ライブマイグレーションをサポートしない VMI は中断または更新されません。
-
VMI に
LiveMigrateエビクションストラテジーがあるが、ライブマイグレーションをサポートしていない場合、VMI は更新されません。
-
VMI に
LiveMigrate と Evict の両方を有効にした場合:
-
ライブマイグレーションをサポートする VMI は、
LiveMigrate更新ストラテジーを使用します。 -
ライブマイグレーションをサポートしない VMI は、
Evict更新ストラテジーを使用します。VMI がrunStrategy: Alwaysに設定されたVirtualMachineオブジェクトによって制御される場合、新規の VMI は、更新されたコンポーネントを使用して新規 Pod に作成されます。
移行の試行とタイムアウト
ワークロードを更新するときに、Pod が次の期間 Pending 状態の場合、ライブマイグレーションは失敗します。
- 5 分間
-
Pod が
Unschedulableであるために保留中の場合。 - 15 分
- 何らかの理由で Pod が保留状態のままになっている場合。
VMI が移行に失敗すると、virt-controller は VMI の移行を再試行します。すべての移行可能な VMI が新しい virt-launcher Pod で実行されるまで、このプロセスが繰り返されます。ただし、VMI が不適切に設定されている場合、これらの試行は無限に繰り返される可能性があります。
各試行は、移行オブジェクトに対応します。直近の 5 回の試行のみがバッファーに保持されます。これにより、デバッグ用の情報を保持しながら、移行オブジェクトがシステムに蓄積されるのを防ぎます。
6.1.3.1. ワークロードの更新方法の設定 リンクのコピーリンクがクリップボードにコピーされました!
HyperConverged カスタムリソース (CR) を編集することにより、ワークロードの更新方法を設定できます。
前提条件
ライブマイグレーションを更新方法として使用するには、まずクラスターでライブマイグレーションを有効にする必要があります。
注記VirtualMachineInstanceCR にevictionStrategy: LiveMigrateが含まれており、仮想マシンインスタンス (VMI) がライブマイグレーションをサポートしない場合には、VMI は更新されません。
手順
デフォルトエディターで
HyperConvergedCR を作成するには、以下のコマンドを実行します。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow HyperConvergedCR のworkloadUpdateStrategyスタンザを編集します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ワークロードの自動更新を実行するのに使用できるメソッド。設定可能な値は
LiveMigrateおよびEvictです。上記の例のように両方のオプションを有効にした場合に、ライブマイグレーションをサポートする VMI にはLiveMigrateを、ライブマイグレーションをサポートしない VMI にはEvictを、更新に使用します。ワークロードの自動更新を無効にするには、workloadUpdateStrategyスタンザを削除するか、workloadUpdateMethods: []を設定して配列を空のままにします。 - 2
- 中断を最小限に抑えた更新メソッド。ライブマイグレーションをサポートする VMI は、仮想マシン (VM) ゲストを更新されたコンポーネントが有効なっている新規 Pod に移行することで更新されます。
LiveMigrateがリストされている唯一のワークロード更新メソッドである場合には、ライブマイグレーションをサポートしない VMI は中断または更新されません。 - 3
- アップグレード時に VMI Pod をシャットダウンする破壊的な方法。
Evictは、ライブマイグレーションがクラスターで有効でない場合に利用可能な唯一の更新方法です。VMI がrunStrategy: Alwaysに設定されたVirtualMachineオブジェクトによって制御される場合には、新規の VMI は、更新されたコンポーネントを使用して新規 Pod に作成されます。 - 4
Evictメソッドを使用して一度に強制的に更新できる VMI の数。これは、LiveMigrateメソッドには適用されません。- 5
- 次のワークロードバッチをエビクトするまで待機する間隔。これは、
LiveMigrateメソッドには適用されません。
注記HyperConvergedCR のspec.liveMigrationConfigスタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。- 変更を適用するには、エディターを保存し、終了します。
6.1.3.2. 古くなった仮想マシンワークロードの表示 リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して、古くなった仮想マシン (VM) ワークロードのリストを表示できます。
クラスターに以前の仮想化 Pod がある場合には、OutdatedVirtualMachineInstanceWorkloads アラートが実行されます。
手順
以前の仮想マシンインスタンス (VMI) の一覧を表示するには、以下のコマンドを実行します。
oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
VMI が自動的に更新されるようにするには、ワークロードの更新を設定します。
6.1.4. コントロールプレーンのみの更新 リンクのコピーリンクがクリップボードにコピーされました!
4.10 および 4.12 を含む OpenShift Container Platform の偶数番号のマイナーバージョンはすべて、Extended Update Support (EUS) バージョンです。ただし、Kubernetes の設計ではシリアルマイナーバージョンの更新が義務付けられているため、ある EUS バージョンから次の EUS バージョンに直接更新することはできません。
ソース EUS バージョンから次の奇数番号のマイナーバージョンに更新した後、更新パス上にあるそのマイナーバージョンのすべての z-stream リリースに OpenShift Virtualization を順次更新する必要があります。適用可能な最新の z-stream バージョンにアップグレードしたら、OpenShift Container Platform をターゲットの EUS マイナーバージョンに更新できます。
OpenShift Container Platform の更新が成功すると、対応する OpenShift Virtualization の更新が利用可能になります。OpenShift Virtualization をターゲットの EUS バージョンに更新できるようになりました。
EUS バージョンの詳細は、Red Hat OpenShift Container Platform ライフサイクルポリシー を参照してください。
6.1.4.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンのみの更新を開始する前に、以下を行う必要があります。
- コントロールプレーンのみの更新を開始する前に、ワーカーノードのマシン設定プールを一時停止して、ワーカーが 2 回再起動しないようにします。
- 更新プロセスを開始する前に、ワークロードの自動更新を無効にします。これは、ターゲットの EUS バージョンに更新するまで、OpenShift Virtualization が仮想マシン (VM) を移行または削除しないようにするためです。
デフォルトでは、OpenShift Virtualization Operator を更新すると、OpenShift Virtualization は virt-launcher Pod などのワークロードを自動的に更新します。この動作は、HyperConverged カスタムリソースの spec.workloadUpdateStrategy スタンザで設定できます。
詳細は、コントロールプレーンのみの更新を実行する を参照してください。
6.1.4.2. コントロールプレーンのみの更新中にワークロードの更新を防止する リンクのコピーリンクがクリップボードにコピーされました!
ある Extended Update Support (EUS) バージョンから次のバージョンに更新する場合、自動ワークロード更新を手動で無効にして、更新プロセス中に OpenShift Virtualization がワークロードを移行または削除しないようにする必要があります。
前提条件
- OpenShift Container Platform の EUS バージョンを実行中で、次の EUS バージョンに更新する予定である。中間の奇数番号のバージョンにはまだ更新していない。
- 「コントロールプレーンのみの更新を実行するための準備」を読み、OpenShift Container Platform クラスターに関連する注意事項と要件を確認した。
- OpenShift Container Platform のドキュメントの説明に従って、ワーカーノードのマシン設定プールを一時停止した。
- デフォルトの Automatic 承認ストラテジーを使用することを推奨します。Manual 承認ストラテジーを使用する場合は、Web コンソールで保留中のすべての更新を承認する必要があります。詳細は、「保留中の Operator の更新を手動で承認する」セクションを参照してください。
手順
次のコマンドを実行し、
workloadUpdateMethods設定を記録します。oc get kv kubevirt-kubevirt-hyperconverged \ -n openshift-cnv -o jsonpath='{.spec.workloadUpdateStrategy.workloadUpdateMethods}'$ oc get kv kubevirt-kubevirt-hyperconverged \ -n openshift-cnv -o jsonpath='{.spec.workloadUpdateStrategy.workloadUpdateMethods}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、すべてのワークロード更新方法をオフにします。
oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/workloadUpdateStrategy/workloadUpdateMethods", "value":[]}]'$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/workloadUpdateStrategy/workloadUpdateMethods", "value":[]}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 続行する前に、
HyperConvergedOperator がアップグレード可能であることを確認してください。次のコマンドを入力して、出力をモニターします。oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例6.1 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenShift Virtualization Operator のステータスは
Upgradeableです。
クラスターをソース EUS バージョンから OpenShift Container Platform の次のマイナーバージョンに手動で更新します。
oc adm upgrade
$ oc adm upgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 検証
次のコマンドを実行して、現在のバージョンを確認します。
oc get clusterversion
$ oc get clusterversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift Container Platform を次のバージョンに更新することは、OpenShift Virtualization を更新するための前提条件です。詳細は、OpenShift Container Platform ドキュメントの「クラスターの更新」セクションを参照してください。
OpenShift Virtualization を更新します。
- デフォルトの 自動 承認ストラテジーでは、OpenShift Container Platform を更新した後、OpenShift Virtualization は対応するバージョンに自動的に更新します。
- 手動 承認ストラテジーを使用する場合は、Web コンソールを使用して保留中の更新を承認します。
次のコマンドを実行して、OpenShift Virtualization の更新をモニターします。
oc get csv -n openshift-cnv
$ oc get csv -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Virtualization を非 EUS マイナーバージョンで使用可能なすべての z-stream バージョンに更新し、前の手順で示したコマンドを実行して各更新を監視します。
以下のコマンドを実行して、OpenShift Virtualization が非 EUS バージョンの最新の z-stream リリースに正常に更新されたことを確認します。
oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の更新を実行する前に、
HyperConvergedOperator がUpgradeableステータスになるまで待ちます。次のコマンドを入力して、出力をモニターします。oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Container Platform をターゲットの EUS バージョンに更新します。
クラスターのバージョンを確認して、更新が成功したことを確認します。
oc get clusterversion
$ oc get clusterversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Virtualization をターゲットの EUS バージョンに更新します。
- デフォルトの 自動 承認ストラテジーでは、OpenShift Container Platform を更新した後、OpenShift Virtualization は対応するバージョンに自動的に更新します。
- 手動 承認ストラテジーを使用する場合は、Web コンソールを使用して保留中の更新を承認します。
次のコマンドを実行して、OpenShift Virtualization の更新をモニターします。
oc get csv -n openshift-cnv
$ oc get csv -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow VERSIONフィールドがターゲットの EUS バージョンと一致し、PHASEフィールドがSucceededになると、更新が完了します。次のコマンドを使用して、ステップ 1 で記録した
workloadUpdateMethods設定を復元します。oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p \ "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":{WorkloadUpdateMethodConfig}}]"$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p \ "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":{WorkloadUpdateMethodConfig}}]"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 検証
次のコマンドを実行して、VM 移行のステータスを確認します。
oc get vmim -A
$ oc get vmim -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- ワーカーノードのマシン設定プールの一時停止を解除できるようになりました。
6.1.5. 高度なオプション リンクのコピーリンクがクリップボードにコピーされました!
ほとんどの OpenShift Virtualization インストールでは、stable リリースチャネルと Automatic 承認ストラテジーが推奨されます。リスクを理解している場合にのみ、他の設定を使用してください。
6.1.5.1. 更新設定の変更 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、OpenShift Virtualization Operator サブスクリプションの更新チャネルと承認ストラテジーを変更できます。
前提条件
- OpenShift Virtualization Operator がインストールされている。
- 管理者権限がある。
手順
- Operators → Installed Operators をクリックします。
- リストから OpenShift Virtualization を選択します。
- Subscription タブをクリックします。
- Subscription details セクションで、変更する設定をクリックします。たとえば、承認ストラテジーを Manual から Automatic に変更するには、Manual をクリックします。
- 開いたウィンドウで、新しい更新チャネルまたは承認ストラテジーを選択します。
- Save をクリックします。
6.1.5.2. 手動承認ストラテジー リンクのコピーリンクがクリップボードにコピーされました!
Manual 承認ストラテジーを使用する場合は、すべての保留中の更新を手動で承認する必要があります。OpenShift Container Platform および OpenShift Virtualization の更新の同期が取れていない場合には、クラスターはサポートされなくなります。クラスターのサポート性と機能性を危険にさらさないようにするには、Automatic 承認ストラテジーを使用します。
Manual 承認ストラテジーを使用する必要がある場合は、保留中の Operator 更新が利用可能になり次第承認し、サポート可能なクラスターを維持します。
6.1.5.3. 保留中の Operator 更新の手動による承認 リンクのコピーリンクがクリップボードにコピーされました!
インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。
前提条件
- Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- 更新が保留中の Operator は Upgrade available のステータスを表示します。更新する Operator の名前をクリックします。
- Subscription タブをクリックします。承認が必要な更新は、Upgrade status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
- 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
- 更新に利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
- Operators → Installed Operators ページに戻り、更新の進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。
6.1.6. 早期アクセスリリース リンクのコピーリンクがクリップボードにコピーされました!
ご使用の OpenShift Virtualization バージョンの candidate 更新チャネルをサブスクライブすると、開発中のビルドにアクセスできます。早期アクセスリリースは、Red Hat によって完全にテストされておらず、サポート対象でもありませんが、そのバージョン用に開発している機能やバグ修正をテストするために、非実稼働クラスターで使用することができます。
stable チャネルは実稼働システムに適しています。このチャネルは基盤となる OpenShift Container Platform のバージョンと一致し、完全にテストされています。Operator Hub で stable チャネルと candidate チャネルを切り替えることができます。ただし、candidate チャネルリリースから stable チャネルリリースへの更新は Red Hat によってテストされていません。
一部の candidate リリースは stable チャネルに昇格されます。ただし、candidate チャネルにのみ存在するリリースには、一般提供 (GA) されるすべての機能が含まれていない可能性があります。また、candidate ビルドの一部の機能は GA の前に削除される可能性があります。さらに、candidate リリースには、後の GA リリースへの更新パスがない場合があります。
candidate チャネルは、クラスターの破棄と再作成が許容されるテスト目的にのみ適しています。
第7章 仮想マシン リンクのコピーリンクがクリップボードにコピーされました!
7.1. Red Hat イメージからの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
7.1.1. Red Hat イメージからの仮想マシン作成の概要 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat イメージは ゴールデンイメージ です。これらは、安全なレジストリー内のコンテナーディスクとして公開されます。Containerized Data Importer (CDI) は、コンテナーディスクをポーリングしてクラスターにインポートし、スナップショットまたは永続ボリュームクレーム (PVC) として openshift-virtualization-os-images プロジェクトに保存します。
Red Hat イメージは自動的に更新されます。これらのイメージの自動更新を無効にして再度有効にすることができます。Red Hat ブートソースの更新の管理 を参照してください。
クラスター管理者は、OpenShift Virtualization Web コンソール で Red Hat Enterprise Linux (RHEL) 仮想マシンの自動サブスクリプションを有効にできるようになりました。
次のいずれかの方法を使用して、Red Hat が提供するオペレーティングシステムイメージから仮想マシンを作成できます。
デフォルトの openshift-* namespace に仮想マシンを作成しないでください。代わりに、openshift 接頭辞なしの新規 namespace を作成するか、既存 namespace を使用します。
7.1.1.1. ゴールデンイメージについて リンクのコピーリンクがクリップボードにコピーされました!
ゴールデンイメージは、新しい仮想マシンをデプロイメントするためのリソースとして使用できる、仮想マシンの事前設定されたスナップショットです。たとえば、ゴールデンイメージを使用すると、同じシステム環境を一貫してプロビジョニングし、システムをより迅速かつ効率的にデプロイメントできます。
7.1.1.1.1. ゴールデンイメージはどのように機能しますか? リンクのコピーリンクがクリップボードにコピーされました!
ゴールデンイメージは、リファレンスマシンまたは仮想マシンにオペレーティングシステムとソフトウェアアプリケーションをインストールして設定することによって作成されます。これには、システムのセットアップ、必要なドライバーのインストール、パッチと更新の適用、特定のオプションと設定の指定が含まれます。
ゴールデンイメージは、作成後、複数のクラスターに複製してデプロイできるテンプレートまたはイメージファイルとして保存されます。ゴールデンイメージは、メンテナーによって定期的に更新されて、必要なソフトウェア更新とパッチが組み込まれるため、イメージが最新かつ安全な状態に保たれ、新しく作成された仮想マシンはこの更新されたイメージに基づいています。
7.1.1.1.2. Red Hat のゴールデンイメージの実装 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat は、Red Hat Enterprise Linux (RHEL) のバージョンのレジストリー内のコンテナーディスクとしてゴールデンイメージを公開します。コンテナーディスクは、コンテナーイメージレジストリーにコンテナーイメージとして保存される仮想マシンイメージです。公開されたイメージは、OpenShift Virtualization のインストール後に、接続されたクラスターで自動的に使用できるようになります。イメージがクラスター内で使用可能になると、仮想マシンの作成に使用できるようになります。
7.1.1.2. 仮想マシンブートソースについて リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンは、仮想マシン定義と、データボリュームによってバックアップされる 1 つ以上のディスクで構成されます。仮想マシンテンプレートを使用すると、事前定義された仕様を使用して仮想マシンを作成できます。
すべてのテンプレートにはブートソースが必要です。ブートソースは、設定されたドライバーを含む完全に設定されたディスクイメージです。各テンプレートには、ブートソースへのポインターを含む仮想マシン定義が含まれています。各ブートソースには、事前に定義された名前および namespace があります。オペレーティングシステムによっては、ブートソースは自動的に提供されます。これが提供されない場合、管理者はカスタムブートソースを準備する必要があります。
提供されたブートソースは、オペレーティングシステムの最新バージョンに自動的に更新されます。自動更新されるブートソースの場合、永続ボリュームクレーム (PVC) とボリュームスナップショットはクラスターのデフォルトストレージクラスで作成されます。設定後に別のデフォルトストレージクラスを選択した場合は、以前のデフォルトストレージクラスで設定されたクラスター namespace 内の既存のブートソースを削除する必要があります。
7.1.2. インスタンスタイプからの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールまたは CLI を使用して仮想マシンを作成する場合でも、インスタンスタイプを使用することで仮想マシン (仮想マシン) の作成を簡素化できます。
7.1.2.1. インスタンスタイプについて リンクのコピーリンクがクリップボードにコピーされました!
インスタンスタイプは、新しい仮想マシンに適用するリソースと特性を定義できる再利用可能なオブジェクトです。カスタムインスタンスタイプを定義したり、OpenShift Virtualization のインストール時に含まれるさまざまなインスタンスタイプを使用したりできます。
新しいインスタンスタイプを作成するには、まず手動で、または virtctl CLI ツールを使用してマニフェストを作成する必要があります。次に、マニフェストをクラスターに適用してインスタンスタイプオブジェクトを作成します。
OpenShift Virtualization は、インスタンスタイプを設定するための 2 つの CRD を提供します。
-
namespace 付きのオブジェクト:
VirtualMachineInstancetype -
クラスター全体のオブジェクト:
VirtualMachineClusterInstancetype
これらのオブジェクトは同じ VirtualMachineInstancetypeSpec を使用します。
7.1.2.1.1. 必須の属性 リンクのコピーリンクがクリップボードにコピーされました!
インスタンスタイプを設定するときは、cpu および memory 属性を定義する必要があります。その他の属性はオプションです。
インスタンスタイプから仮想マシンを作成する場合は、インスタンスタイプで定義されているパラメーターをオーバーライドすることはできません。
インスタンスタイプには定義された CPU およびメモリー属性が必要であるため、OpenShift Virtualization は、インスタンスタイプから仮想マシンを作成するときに、これらのリソースに対する追加の要求を常に拒否します。
インスタンスタイプマニフェストを手動で作成できます。以下に例を示します。
必須フィールドを含む YAML ファイルの例
virtctl CLI ユーティリティーを使用してインスタンスタイプマニフェストを作成できます。以下に例を示します。
必須フィールドを含む virtctl コマンドの例
virtctl create instancetype --cpu 2 --memory 256Mi
$ virtctl create instancetype --cpu 2 --memory 256Mi
ここでは、以下のようになります。
--cpu <value>- ゲストに割り当てる仮想 CPU の数を指定します。必須。
--memory <value>- ゲストに割り当てるメモリーの量を指定します。必須。
次のコマンドを実行すると、新しいマニフェストからオブジェクトをすぐに作成できます。
virtctl create instancetype --cpu 2 --memory 256Mi | oc apply -f -
$ virtctl create instancetype --cpu 2 --memory 256Mi | oc apply -f -
7.1.2.1.2. オプション属性 リンクのコピーリンクがクリップボードにコピーされました!
必須の cpu および memory 属性に加えて、VirtualMachineInstancetypeSpec に次のオプション属性を含めることができます。
annotations- 仮想マシンに適用するアノテーションをリスト表示します。
gpus- パススルー用の vGPU をリスト表示します。
hostDevices- パススルー用のホストデバイスをリスト表示します。
ioThreadsPolicy- 専用ディスクアクセスを管理するための IO スレッドポリシーを定義します。
launchSecurity- セキュア暗号化仮想化 (SEV) を設定します。
nodeSelector- この仮想マシンがスケジュールされているノードを制御するためのノードセレクターを指定します。
schedulerName- デフォルトのスケジューラーの代わりに、この仮想マシンに使用するカスタムスケジューラーを定義します。
7.1.2.2. 定義済みのインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization には、common-instancetypes と呼ばれる事前定義されたインスタンスタイプのセットが含まれています。特定のワークロードに特化したものもあれば、ワークロードに依存しないものもあります。
これらのインスタンスタイプリソースは、シリーズ、バージョン、サイズに応じて名前が付けられます。サイズの値は . 区切り文字に続き、範囲は nano から 8xlarge です。
| ユースケース | シリーズ | 特徴 | 仮想 CPU とメモリーの比率 | リソースの例 |
|---|---|---|---|---|
| Universal | U |
| 1:4 |
|
| 過剰コミットメント | O |
| 1:4 |
|
| コンピュート専用 | CX |
| 1:2 |
|
| NVIDIA GPU | GN |
| 1:4 |
|
| メモリー集約型 | M |
| 1:8 |
|
| ネットワーク集約型 | N |
| 1:2 |
|
7.1.2.3. virtctl ツールを使用したマニフェストの作成 リンクのコピーリンクがクリップボードにコピーされました!
virtctl CLI ユーティリティーを使用すると、仮想マシン、仮想マシンインスタンスタイプ、および仮想マシン設定のマニフェストの作成を簡素化できます。詳細は、仮想マシンマニフェスト作成コマンド を参照してください。
VirtualMachine マニフェストがある場合は、コマンドライン から仮想マシンを作成できます。
7.1.2.4. Web コンソールを使用して、インスタンスタイプから仮想マシンを作成します。 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、インスタンスタイプから仮想マシンを作成できます。Web コンソールを使用して、既存のスナップショットをコピーするか仮想マシンを複製して、仮想マシンを作成することもできます。
使用可能な起動可能なボリュームのリストから仮想マシンを作成できます。Linux ベースまたは Windows ベースのボリュームをリストに追加できます。
手順
Web コンソールで、Virtualization → Catalog に移動します。
InstanceTypes タブがデフォルトで開きます。
次のオプションのいずれかを選択します。
リストから適切な起動可能なボリュームを選択します。リストが切り捨てられている場合は、Show all ボタンをクリックしてリスト全体を表示します。
注記ブート可能ボリュームテーブルには、
openshift-virtualization-os-imagesnamespace 内のinstancetype.kubevirt.io/default-preferenceラベルを持つボリュームのみリストされます。- オプション: 星アイコンをクリックして、ブート可能ボリュームをお気に入りとして指定します。星付きのブート可能ボリュームは、ボリュームリストの最初に表示されます。
新しいボリュームをアップロードするか、既存の永続ボリューム要求 (PVC)、ボリュームスナップショット、または
containerDiskボリュームを使用するには Add volume をクリックします。Save をクリックします。クラスターで使用できないオペレーティングシステムのロゴは、リストの下部に表示されます。Add volume リンクをクリックすると、必要なオペレーティングシステムのボリュームを追加できます。
さらに、Create a Windows boot source クイックスタートへのリンクもあります。Select volume to boot from の横にある疑問符アイコンの上にポインターを置くと、ポップオーバーに同じリンクが表示されます。
環境をインストールした直後、または環境が切断された直後は、起動元のボリュームのリストは空になります。その場合、Windows、RHEL、Linux の 3 つのオペレーティングシステムのロゴが表示されます。Add volume ボタンをクリックすると、要件を満たす新しいボリュームを追加できます。
- インスタンスタイプのタイルをクリックし、ワークロードに適したリソースサイズを選択します。
オプション: 起動元のボリュームに適用される仮想マシンの詳細 (仮想マシンの名前を含む) を選択します。
Linux ベースのボリュームの場合は、次の手順に従って SSH を設定します。
- プロジェクトに SSH 公開鍵をまだ追加していない場合は、VirtualMachine details セクションの Authorized SSH key の横にある編集アイコンをクリックします。
以下のオプションのいずれかを選択します。
- Use existing: シークレットリストからシークレットを選択します。
Add new: 以下の手順に従ってください。
- SSH 公開鍵ファイルを参照するか、ファイルを鍵のフィールドに貼り付けます。
- シークレット名を入力します。
- オプション: Automatically apply this key to any new VirtualMachine you create in this project を選択します。
- Save をクリックします。
Windows ボリュームの場合は、次のいずれかの手順に従って sysprep オプションを設定します。
Windows ボリュームに sysprep オプションをまだ追加していない場合は、次の手順に従います。
- VirtualMachine details セクションの Sysprep の横にある編集アイコンをクリックします。
- Autoattend.xml アンサーファイルを追加します。
- Unattend.xml アンサーファイルを追加します。
- Save をクリックします。
Windows ボリュームに既存の sysprep オプションを使用する場合は、次の手順に従います。
- 既存の sysprep を添付 をクリックします。
- 既存の sysprep Unattend.xml アンサーファイルの名前を入力します。
- Save をクリックします。
オプション: Windows 仮想マシンを作成する場合は、Windows ドライバーディスクをマウントできます。
- Customize VirtualMachine ボタンをクリックします。
- VirtualMachine details ページで、Storage をクリックします。
- Mount Windows drivers disk チェックボックスを選択します。
- オプション: View YAML & CLI をクリックして YAML ファイルを表示します。CLI をクリックして CLI コマンドを表示します。YAML ファイルの内容または CLI コマンドをダウンロードまたはコピーすることもできます。
- Create VirtualMachine をクリックします。
仮想マシンの作成後、VirtualMachine details ページでステータスを監視できます。
7.1.3. テンプレートからの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、Red Hat テンプレートから仮想マシン (VM) を作成できます。
7.1.3.1. 仮想マシンテンプレートについて リンクのコピーリンクがクリップボードにコピーされました!
- ブートソース
利用可能なブートソースを持つテンプレートを使用すると、仮想マシンの作成を効率化できます。ブートソースのあるテンプレートには、カスタムラベルがない場合、Available boot source ラベルが付けられます。
ブートソースのないテンプレートには、Boot source required というラベルが付けられます。カスタムイメージからの仮想マシンの作成 を参照してください。
- カスタマイズ
- 仮想マシンを起動する前に、ディスクソースと仮想マシンパラメーターをカスタマイズできます。
ディスクソース設定の詳細は、ストレージボリュームタイプ と ストレージフィールド を参照してください。
すべてのラベルとアノテーションとともに仮想マシンテンプレートをコピーすると、新しいバージョンの Scheduling、Scale、and Performance (SSP) Operator がデプロイされたときに、そのバージョンのテンプレートが非推奨に指定されます。この指定は削除できます。Web コンソールを使用した仮想マシンテンプレートのカスタマイズ 参照してください。
- シングルノード OpenShift
-
ストレージの動作の違いにより、一部のテンプレートはシングルノード OpenShift と互換性がありません。互換性を確保するには、データボリュームまたはストレージプロファイルを使用するテンプレートまたは仮想マシンに
evictionStrategyフィールドを設定しないでください。
7.1.3.2. テンプレートから仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、使用可能なブートソースを持つテンプレートから仮想マシンを作成できます。
オプション: 仮想マシンを起動する前に、データソース、cloud-init、SSH キーなどのテンプレートまたは仮想マシンパラメーターをカスタマイズできます。
手順
- Web コンソールで Virtualization → Catalog に移動します。
利用可能なブートソース をクリックして、テンプレートをブートソースでフィルタリングします。
カタログにはデフォルトのテンプレートが表示されます。All Items をクリックして、フィルターに使用できるすべてのテンプレートを表示します。
- テンプレートタイルをクリックして詳細を表示します。
- オプション: Windows テンプレートを使用している場合は、Mount Windows drivers disk チェックボックスを選択することで、Windows ドライバーディスクをマウントできます。
テンプレートまたは仮想マシンパラメーターをカスタマイズする必要がない場合は、Quick create VirtualMachine をクリックして、テンプレートから仮想マシンを作成します。
テンプレートまたは仮想マシンパラメーターをカスタマイズする必要がある場合は、次の手順を実行します。
- Customize VirtualMachine をクリックします。
- Storage または Optional parameters をデプロイメントして、データソース設定を編集します。
VirtualMachine パラメーターのカスタマイズ をクリックします。
Customize and create VirtualMachine ペインには、Overview、YAML、Scheduling、Environment、Network interfaces、Disks、Scripts、および Metadata タブが表示されます。
- 仮想マシンの起動前に設定する必要があるパラメーター (cloud-init や静的 SSH キーなど) を編集します。
Create VirtualMachine をクリックします。
VirtualMachine details ページには、プロビジョニングステータスが表示されます。
7.1.3.2.1. ストレージボリュームタイプ リンクのコピーリンクがクリップボードにコピーされました!
| 型 | 説明 |
|---|---|
| ephemeral | ネットワークボリュームを読み取り専用のバッキングストアとして使用するローカルの copy-on-write (COW) イメージ。バッキングボリュームは PersistentVolumeClaim である必要があります。一時イメージは仮想マシンの起動時に作成され、すべての書き込みをローカルに保存します。一時イメージは、仮想マシンの停止、再起動または削除時に破棄されます。バッキングボリューム (PVC) はいずれの方法でも変更されません。 |
| persistentVolumeClaim | 利用可能な PV を仮想マシンに割り当てます。PV の割り当てにより、仮想マシンデータのセッション間での永続化が可能になります。 CDI を使用して既存の仮想マシンディスクを PVC にインポートし、PVC を仮想マシンインスタンスに割り当てる方法は、既存の仮想マシンを OpenShift Container Platform にインポートするための推奨される方法です。ディスクを PVC 内で使用できるようにするためのいくつかの要件があります。 |
| dataVolume |
データボリュームは、インポート、クローンまたはアップロード操作で仮想マシンディスクの準備プロセスを管理することによって
|
| cloudInitNoCloud | 参照される cloud-init NoCloud データソースが含まれるディスクを割り当て、ユーザーデータおよびメタデータを仮想マシンに提供します。cloud-init インストールは仮想マシンディスク内で必要になります。 |
| containerDisk | コンテナーイメージレジストリーに保存される、仮想マシンディスクなどのイメージを参照します。イメージはレジストリーからプルされ、仮想マシンの起動時にディスクとして仮想マシンに割り当てられます。
RAW および QCOW2 形式のみがコンテナーイメージレジストリーのサポートされるディスクタイプです。QCOW2 は、縮小されたイメージサイズの場合に推奨されます。 注記
|
| emptyDisk | 仮想マシンインターフェイスのライフサイクルに関連付けられるスパースの QCOW2 ディスクを追加で作成します。データは仮想マシンのゲストによって実行される再起動後も存続しますが、仮想マシンが Web コンソールから停止または再起動する場合には破棄されます。空のディスクは、アプリケーションの依存関係および一時ディスクの一時ファイルシステムの制限を上回るデータを保存するために使用されます。 ディスク 容量 サイズも指定する必要があります。 |
7.1.3.2.2. ストレージフィールド リンクのコピーリンクがクリップボードにコピーされました!
| フィールド | 説明 |
|---|---|
| 空白 (PVC の作成) | 空のディスクを作成します。 |
| URL を使用したインポート (PVC の作成) | URL (HTTP または HTTPS エンドポイント) を介してコンテンツをインポートします。 |
| 既存 PVC の使用 | クラスターですでに利用可能な PVC を使用します。 |
| 既存の PVC のクローン作成 (PVC の作成) | クラスターで利用可能な既存の PVC を選択し、このクローンを作成します。 |
| レジストリーを使用したインポート (PVC の作成) | コンテナーレジストリーを使用してコンテンツをインポートします。 |
| コンテナー (一時的) | クラスターからアクセスできるレジストリーにあるコンテナーからコンテンツをアップロードします。コンテナーディスクは、CD-ROM や一時的な仮想マシンなどの読み取り専用ファイルシステムにのみ使用する必要があります。 |
| Name |
ディスクの名前。この名前には、小文字 ( |
| Size | ディスクのサイズ (GiB 単位)。 |
| 型 | ディスクのタイプ。例: Disk または CD-ROM |
| Interface | ディスクデバイスのタイプ。サポートされるインターフェイスは、virtIO、SATA、および SCSI です。 |
| Storage Class | ディスクの作成に使用されるストレージクラス。 |
ストレージの詳細設定
以下のストレージの詳細設定はオプションであり、Blank、Import via URL、および Clone existing PVC ディスクで利用できます。
これらのパラメーターを指定しない場合、システムはデフォルトのストレージプロファイル値を使用します。
| パラメーター | オプション | パラメーターの説明 |
|---|---|---|
| ボリュームモード | Filesystem | ファイルシステムベースのボリュームで仮想ディスクを保存します。 |
| Block |
ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 | |
| アクセスモード | ReadWriteOnce (RWO) | ボリュームはシングルノードで読み取り/書き込みとしてマウントできます。 |
| ReadWriteMany (RWX) | ボリュームは、一度に多くのノードで読み取り/書き込みとしてマウントできます。 注記 このモードはライブマイグレーションに必要です。 |
7.1.3.2.3. Web コンソールを使用した仮想マシンテンプレートのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンを起動する前に、データソース、cloud-init、SSH キーなど、仮想マシンまたはテンプレートのパラメーターを変更することで、既存の仮想マシン (VM) テンプレートをカスタマイズできます。テンプレートをコピーし、すべてのラベルとアノテーションを含めてテンプレートをカスタマイズすると、新しいバージョンの Scheduling、Scale、and Performance (SSP) Operator がデプロイされたときに、カスタマイズしたテンプレートが非推奨に指定されます。
この非推奨の指定は、カスタマイズしたテンプレートから削除できます。
手順
- Web コンソールで Virtualization → Templates に移動します。
- 仮想マシンテンプレートのリストから、非推奨とマークされているテンプレートをクリックします。
- Labels の近くにある鉛筆アイコンの横にある Edit をクリックします。
次の 2 つのラベルを削除します。
-
template.kubevirt.io/type: "base" -
template.kubevirt.io/version: "version"
-
- Save をクリックします。
- 既存の Annotations の数の横にある鉛筆アイコンをクリックします。
次のアノテーションを削除します。
-
template.kubevirt.io/deprecated
-
- Save をクリックします。
7.1.3.2.4. Web コンソールでのカスタム仮想マシンテンプレートの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールで YAML ファイルの例を編集して、仮想マシンテンプレートを作成します。
手順
- Web コンソールのサイドメニューで、Virtualization → Templates をクリックします。
-
オプション: Project ドロップダウンメニューを使用して、新しいテンプレートに関連付けられたプロジェクトを変更します。すべてのテンプレートは、デフォルトで
openshiftプロジェクトに保存されます。 - Create Template をクリックします。
- YAML ファイルを編集して、テンプレートパラメーターを指定します。
Create をクリックします。
テンプレートが Templates ページに表示されます。
- オプション: Download をクリックして、YAML ファイルをダウンロードして保存します。
7.1.4. コマンドラインからの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
VirtualMachine マニフェストを編集または作成することで、コマンドラインから仮想マシン (VM) を作成できます。仮想マシンマニフェストで インスタンスタイプ を使用すると、仮想マシン設定を簡素化できます。
Web コンソールを使用してインスタンスタイプから仮想マシンを作成する こともできます。
7.1.4.1. VirtualMachine マニフェストからの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
VirtualMachine マニフェストから仮想マシンを作成できます。これらのマニフェストの作成を簡素化するには、virtctl コマンドラインツールを使用できます。
前提条件
-
virtctlコマンドラインツールがインストールされている。
手順
仮想マシンの
VirtualMachineマニフェストを作成し、YAML ファイルとして保存します。たとえば、最小限の Red Hat Enterprise Linux (RHEL) 仮想マシンを作成するには、次のコマンドを実行します。virtctl create vm --name rhel-9-minimal --volume-datasource src:openshift-virtualization-os-images/rhel9
$ virtctl create vm --name rhel-9-minimal --volume-datasource src:openshift-virtualization-os-images/rhel9Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンの
VirtualMachineマニフェストを確認します。注記このサンプルマニフェストでは、仮想マシン認証は設定されません。
RHEL 仮想マシンのマニフェストの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マニフェストファイルを使用して仮想マシンを作成します。
oc create -f <vm_manifest_file>.yaml
$ oc create -f <vm_manifest_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 仮想マシンを起動します。
virtctl start <vm_name>
$ virtctl start <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
7.2. カスタムイメージからの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
7.2.1. カスタムイメージからの仮想マシン作成の概要 リンクのコピーリンクがクリップボードにコピーされました!
次のいずれかの方法を使用して、カスタムオペレーティングシステムイメージから仮想マシンを作成できます。
レジストリーからイメージをコンテナーディスクとしてインポートします。
オプション: コンテナーディスクの自動更新を有効にすることができます。詳細は、ブートソースの自動更新の管理 を参照してください。
- Web ページからイメージをインポートします。
- ローカルマシンからイメージをアップロードします。
- イメージを含む永続ボリューム要求 (PVC) のクローンを作成します。
Containerized Data Importer (CDI) は、データボリュームを使用してイメージを PVC にインポートします。OpenShift Container Platform Web コンソールまたはコマンドラインを使用して、PVC を仮想マシンに追加します。
Red Hat が提供していないオペレーティングシステムイメージから作成された仮想マシンには、QEMU ゲストエージェント をインストールする必要があります。
Windows 仮想マシンにも VirtIO ドライバー をインストールする必要があります。
QEMU ゲストエージェントは Red Hat イメージに含まれています。
7.2.2. コンテナーディスクを使用した仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
オペレーティングシステムイメージから構築されたコンテナーディスクを使用して、仮想マシンを作成できます。
コンテナーディスクの自動更新を有効にすることができます。詳細は、ブートソースの自動更新の管理 を参照してください。
コンテナーディスクが大きい場合は、I/O トラフィックが増加し、ワーカーノードが使用できなくなる可能性があります。この問題を解決するには、次のタスクを実行できます。
次の手順を実行して、コンテナーディスクから仮想マシンを作成します。
- オペレーティングシステムイメージをコンテナーディスクに構築し、それをコンテナーレジストリーにアップロードします。
- コンテナーレジストリーに TLS がない場合は、レジストリーの TLS を無効にするように環境を設定します。
- Web コンソール または コマンドライン を使用して、コンテナーディスクをディスクソースとして使用する仮想マシンを作成します。
Red Hat が提供していないオペレーティングシステムイメージから作成された仮想マシンには、QEMU ゲストエージェント をインストールする必要があります。
7.2.2.1. コンテナーディスクの構築とアップロード リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンイメージをコンテナーディスクに構築し、レジストリーにアップロードできます。
コンテナーディスクのサイズは、コンテナーディスクがホストされているレジストリーの最大レイヤーサイズによって制限されます。
Red Hat Quay の場合、Red Hat Quay の初回デプロイ時に作成される YAML 設定ファイルを編集して、最大レイヤーサイズを変更できます。
前提条件
-
podmanがインストールされている必要があります。 - QCOW2 または RAW イメージファイルが必要です。
手順
Dockerfile を作成して、仮想マシンイメージをコンテナーイメージにビルドします。仮想マシンイメージは、UID
107を持つ QEMU によって所有され、コンテナー内の/disk/ディレクトリーに配置される必要があります。次に、/disk/ディレクトリーのパーミッションは0440に設定する必要があります。以下の例では、Red Hat Universal Base Image (UBI) を使用して最初の段階でこれらの設定変更を処理し、2 番目の段階で最小の
scratchイメージを使用して結果を保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<vm_image>は、QCOW2 または RAW 形式のイメージです。リモートイメージを使用する場合は、<vm_image>.qcow2を完全な URL に置き換えます。
コンテナーをビルドし、これにタグ付けします。
podman build -t <registry>/<container_disk_name>:latest .
$ podman build -t <registry>/<container_disk_name>:latest .Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンテナーイメージをレジストリーにプッシュします。
podman push <registry>/<container_disk_name>:latest
$ podman push <registry>/<container_disk_name>:latestCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2.2.2. コンテナーレジストリーの TLS を無効にする リンクのコピーリンクがクリップボードにコピーされました!
HyperConverged カスタムリソースの insecureRegistries フィールドを編集して、1 つ以上のコンテナーレジストリーの TLS(トランスポート層セキュリティー) を無効にできます。
前提条件
以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow セキュアでないレジストリーのリストを
spec.storageImport.insecureRegistriesフィールドに追加します。HyperConvergedカスタムリソースの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このリストのサンプルを、有効なレジストリーホスト名に置き換えます。
7.2.2.3. Web コンソールを使用してコンテナーディスクから仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用してコンテナーレジストリーからコンテナーディスクをインポートすることで、仮想マシンを作成できます。
手順
- Web コンソールで Virtualization → Catalog に移動します。
- 使用可能なブートソースのないテンプレートタイルをクリックします。
- Customize VirtualMachine をクリックします。
- Customize template parameters ページで、Storage を展開し、Disk source リストから Registry (creates PVC) を選択します。
-
コンテナーイメージの URL を入力します。例:
https://mirror.arizona.edu/fedora/linux/releases/38/Cloud/x86_64/images/Fedora-Cloud-Base-38-1.6.x86_64.qcow2 - ディスクサイズを設定します。
- Next をクリックします。
- Create VirtualMachine をクリックします。
7.2.2.4. コマンドラインを使用したコンテナーディスクからの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して、コンテナーディスクから仮想マシンを作成できます。
前提条件
- コンテナーディスクを含むコンテナーレジストリーへのアクセス認証情報が必要です。
-
virtctlコマンドラインツールがインストールされている。
手順
仮想マシンの
VirtualMachineマニフェストを作成し、YAML ファイルとして保存します。たとえば、コンテナーディスクから最小限の Red Hat Enterprise Linux (RHEL) 仮想マシンを作成するには、次のコマンドを実行します。virtctl create vm --name vm-rhel-9 --instancetype u1.small --preference rhel.9 --volume-containerdisk src:registry.redhat.io/rhel9/rhel-guest-image:9.5
$ virtctl create vm --name vm-rhel-9 --instancetype u1.small --preference rhel.9 --volume-containerdisk src:registry.redhat.io/rhel9/rhel-guest-image:9.5Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンの
VirtualMachineマニフェストを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して VM を作成します。
oc create -f <vm_manifest_file>.yaml
$ oc create -f <vm_manifest_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
仮想マシンのステータスを監視します。
oc get vm <vm_name>
$ oc get vm <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロビジョニングが成功すると、仮想マシンのステータスが
Runningになります。出力例
NAME AGE STATUS READY vm-rhel-9 18s Running True
NAME AGE STATUS READY vm-rhel-9 18s Running TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロビジョニングが完了し、シリアルコンソールにアクセスして仮想マシンが起動したことを確認します。
virtctl console <vm_name>
$ virtctl console <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンが実行中でシリアルコンソールにアクセスできる場合、出力は次のようになります。
出力例
Successfully connected to vm-rhel-9 console. The escape sequence is ^]
Successfully connected to vm-rhel-9 console. The escape sequence is ^]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2.3. Web ページからイメージをインポートして仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
Web ページからオペレーティングシステムイメージをインポートすることで、仮想マシンを作成できます。
Red Hat が提供していないオペレーティングシステムイメージから作成された仮想マシンには、QEMU ゲストエージェント をインストールする必要があります。
7.2.3.1. Web コンソールを使用して Web ページ上のイメージから仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して Web ページからイメージをインポートすることで、仮想マシンを作成できます。
前提条件
- イメージを含む Web ページにアクセスできる。
手順
- Web コンソールで Virtualization → Catalog に移動します。
- 使用可能なブートソースのないテンプレートタイルをクリックします。
- Customize VirtualMachine をクリックします。
- Customize template parameters ページで、Storage を展開し、Disk source リストから URL (creates PVC) を選択します。
-
イメージの URL を入力します。例:
https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.9/x86_64/product-software - ディスクサイズを設定します。
- Next をクリックします。
- Create VirtualMachine をクリックします。
7.2.3.2. コマンドラインを使用して Web ページ上のイメージから仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して、Web ページ上のイメージから仮想マシンを作成できます。
仮想マシンが作成されると、イメージを含むデータボリュームが永続ストレージにインポートされます。
前提条件
- イメージが含まれている Web ページへのアクセス認証情報を持っている。
-
virtctlコマンドラインツールがインストールされている。
手順
仮想マシンの
VirtualMachineマニフェストを作成し、YAML ファイルとして保存します。たとえば、Web ページ上のイメージから最小限の Red Hat Enterprise Linux (RHEL) 仮想マシンを作成するには、次のコマンドを実行します。virtctl create vm --name vm-rhel-9 --instancetype u1.small --preference rhel.9 --volume-import type:http,url:https://example.com/rhel9.qcow2,size:10Gi
$ virtctl create vm --name vm-rhel-9 --instancetype u1.small --preference rhel.9 --volume-import type:http,url:https://example.com/rhel9.qcow2,size:10GiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンの
VirtualMachineマニフェストを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して VM を作成します。
oc create -f <vm_manifest_file>.yaml
$ oc create -f <vm_manifest_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc createコマンドは、データボリュームと仮想マシンを作成します。CDI コントローラーは適切なアノテーションを使用して基礎となる PVC を作成し、インポートプロセスが開始されます。インポートが完了すると、データボリュームのステータスがSucceededに変わります。仮想マシンを起動できます。データボリュームのプロビジョニングはバックグランドで実行されるため、これをプロセスをモニターする必要はありません。
検証
インポーター Pod は、指定された URL からイメージをダウンロードし、プロビジョニングされた永続ボリュームに保存します。インポーター Pod のステータスを表示します。
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow データボリュームの状態を監視します。
oc get dv <data_volume_name>
$ oc get dv <data_volume_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロビジョニングが成功すると、データボリュームのフェーズが
Succeededになります。出力例
NAME PHASE PROGRESS RESTARTS AGE imported-volume-6dcpf Succeeded 100.0% 18s
NAME PHASE PROGRESS RESTARTS AGE imported-volume-6dcpf Succeeded 100.0% 18sCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロビジョニングが完了し、シリアルコンソールにアクセスして仮想マシンが起動したことを確認します。
virtctl console <vm_name>
$ virtctl console <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンが実行中でシリアルコンソールにアクセスできる場合、出力は次のようになります。
出力例
Successfully connected to vm-rhel-9 console. The escape sequence is ^]
Successfully connected to vm-rhel-9 console. The escape sequence is ^]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2.4. イメージをアップロードして仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
ローカルマシンからオペレーティングシステムイメージをアップロードすることで、仮想マシンを作成できます。
Windows イメージを PVC にアップロードすることで、Windows 仮想マシンを作成できます。次に、仮想マシンの作成時に PVC のクローンを作成します。
Red Hat が提供していないオペレーティングシステムイメージから作成された仮想マシンには、QEMU ゲストエージェント をインストールする必要があります。
Windows 仮想マシンにも VirtIO ドライバー をインストールする必要があります。
7.2.4.1. Web コンソールを使用してアップロードしたイメージから仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、アップロードしたオペレーティングシステムイメージから仮想マシン (VM) を作成できます。
前提条件
-
IMG、ISO、またはQCOW2イメージファイルが必要です。
手順
- Web コンソールで Virtualization → Catalog に移動します。
- 使用可能なブートソースのないテンプレートタイルをクリックします。
- Customize VirtualMachine をクリックします。
- Customize template parameters ページで、Storage を展開し、Disk source リストから Upload (Upload a new file to a PVC) を選択します。
- ローカルマシン上のイメージを参照し、ディスクサイズを設定します。
- Customize VirtualMachine をクリックします。
- Create VirtualMachine をクリックします。
7.2.4.2. Windows 仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
Windows 仮想マシンを作成するには、Windows イメージを永続ボリューム要求 (PVC) にアップロードし、OpenShift Container Platform Web コンソールを使用して仮想マシンを作成するときに PVC のクローンを作成します。
前提条件
- Windows Media Creation Tool を使用して Windows インストール DVD または USB が作成されている。Microsoft ドキュメントの Create Windows 10 installation media を参照してください。
-
autounattend.xmlアンサーファイルを作成しました。Microsoft ドキュメントの Answer files (unattend.xml) を参照してください。
手順
Windows イメージを新しい PVC としてアップロードします。
- Web コンソールで Storage → PersistentVolumeClaims に移動します。
- Create PersistentVolumeClaim → With Data upload form をクリックします。
- Windows イメージを参照して選択します。
PVC 名を入力し、ストレージクラスとサイズを選択して、Upload をクリックします。
Windows イメージは PVC にアップロードされます。
アップロードされた PVC のクローンを作成して、新しい仮想マシンを設定します。
- Virtualization → Catalog に移動します。
- Windows テンプレートタイルを選択し、Customize VirtualMachine をクリックします。
- Disk source リストから Clone (clone PVC) を選択します。
- PVC プロジェクト、Windows イメージ PVC、およびディスクサイズを選択します。
アンサーファイルを仮想マシンに適用します。
- VirtualMachine パラメーターのカスタマイズ をクリックします。
- Scripts タブの Sysprep セクションで、Edit をクリックします。
-
autounattend.xml応答ファイルを参照し、Save をクリックします。
仮想マシンの実行ストラテジーを設定します。
- 仮想マシンがすぐに起動しないように、Start this VirtualMachine after creation をオフにします。
- Create VirtualMachine をクリックします。
-
YAML タブで、
running:falseをrunStrategy: RerunOnFailureに置き換え、Save をクリックします。
オプションメニュー
をクリックして Start を選択します。
仮想マシンは、
autounattend.xmlアンサーファイルを含むsysprepディスクから起動します。
7.2.4.2.1. Windows 仮想マシンイメージの一般化 リンクのコピーリンクがクリップボードにコピーされました!
Windows オペレーティングシステムイメージを一般化して、イメージを使用して新しい仮想マシンを作成する前に、システム固有の設定データをすべて削除できます。
仮想マシンを一般化する前に、Windows の無人インストール後に sysprep ツールが応答ファイルを検出できないことを確認する必要があります。
前提条件
- QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。
手順
- OpenShift Container Platform コンソールで、Virtualization → VirtualMachines をクリックします。
- Windows 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Configuration → Disks をクリックします。
-
sysprepディスクの横にある Options メニュー
をクリックし、Detach を選択します。
- Detach をクリックします。
-
sysprepツールによる検出を回避するために、C:\Windows\Panther\unattend.xmlの名前を変更します。 次のコマンドを実行して、
sysprepプログラムを開始します。%WINDIR%\System32\Sysprep\sysprep.exe /generalize /shutdown /oobe /mode:vm
%WINDIR%\System32\Sysprep\sysprep.exe /generalize /shutdown /oobe /mode:vmCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
sysprepツールが完了すると、Windows 仮想マシンがシャットダウンします。これで、仮想マシンのディスクイメージを Windows 仮想マシンのインストールイメージとして使用できるようになりました。
これで、仮想マシンを特殊化できます。
7.2.4.2.2. Windows 仮想マシンイメージの特殊化 リンクのコピーリンクがクリップボードにコピーされました!
Windows 仮想マシンを特殊化すると、一般化された Windows イメージから VM にコンピューター固有の情報が設定されます。
前提条件
- 一般化された Windows ディスクイメージが必要です。
-
unattend.xml応答ファイルを作成する必要があります。詳細は、Microsoft のドキュメント を参照してください。
手順
- OpenShift Container Platform コンソールで、Virtualization → Catalog をクリックします。
- Windows テンプレートを選択し、Customize VirtualMachine をクリックします。
- Disk source リストから PVC (clone PVC) を選択します。
- 一般化された Windows イメージの PVC プロジェクトと PVC 名を選択します。
- VirtualMachine パラメーターのカスタマイズ をクリックします。
- Scripts タブをクリックします。
-
Sysprep セクションで、Edit をクリックし、
unattend.xml応答ファイルを参照して、Save をクリックします。 - Create VirtualMachine をクリックします。
Windows は初回起動時に、unattend.xml 応答ファイルを使用して VM を特殊化します。これで、仮想マシンを使用する準備が整いました。
7.2.4.3. コマンドラインを使用して、アップロードされたイメージから仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
virtctl コマンドラインツールを使用して、オペレーティングシステムイメージをアップロードできます。既存のデータボリュームを使用することも、イメージ用に新しいデータボリュームを作成することもできます。
前提条件
-
ISO、IMG、またはQCOW2オペレーティングシステムイメージファイルがある。 -
最高のパフォーマンスを得るには、virt-sparsify ツールまたは
xzユーティリティーまたはgzipユーティリティーを使用してイメージファイルを圧縮しておく。 -
virtctlがインストールされている。 - クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されている。
手順
virtctl image-uploadコマンドを実行してイメージをアップロードします。virtctl image-upload dv <datavolume_name> \ --size=<datavolume_size> \ --image-path=</path/to/image> \
$ virtctl image-upload dv <datavolume_name> \1 --size=<datavolume_size> \2 --image-path=</path/to/image> \3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記-
新規データボリュームを作成する必要がない場合は、
--sizeパラメーターを省略し、--no-createフラグを含めます。 - ディスクイメージを PVC にアップロードする場合、PVC サイズは圧縮されていない仮想ディスクのサイズよりも大きくなければなりません。
-
HTTPS を使用したセキュアでないサーバー接続を許可するには、
--insecureパラメーターを使用します。--insecureフラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。
-
新規データボリュームを作成する必要がない場合は、
オプション: データボリュームが作成されたことを確認するには、以下のコマンドを実行してすべてのデータボリュームを表示します。
oc get dvs
$ oc get dvsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2.5. QEMU ゲストエージェントと VirtIO ドライバーのインストール リンクのコピーリンクがクリップボードにコピーされました!
QEMU ゲストエージェントは、仮想マシンで実行され、仮想マシン、ユーザー、ファイルシステム、およびセカンダリーネットワークに関する情報をホストに渡すデーモンです。
Red Hat が提供していないオペレーティングシステムイメージから作成された仮想マシンには、QEMU ゲストエージェントをインストールする必要があります。
7.2.5.1. QEMU ゲストエージェントのインストール リンクのコピーリンクがクリップボードにコピーされました!
7.2.5.1.1. Linux 仮想マシンへの QEMU ゲストエージェントのインストール リンクのコピーリンクがクリップボードにコピーされました!
qemu-guest-agent は広範な使用が可能で、Red Hat Enterprise Linux (RHEL) 仮想マシン (VM) においてデフォルトで使用できます。このエージェントをインストールし、サービスを起動します。
整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。
QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。
手順
- コンソールまたは SSH を使用して仮想マシンにログインします。
次のコマンドを実行して、QEMU ゲストエージェントをインストールします。
yum install -y qemu-guest-agent
$ yum install -y qemu-guest-agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスに永続性があることを確認し、これを起動します。
systemctl enable --now qemu-guest-agent
$ systemctl enable --now qemu-guest-agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、
AgentConnectedが仮想マシンの spec にリストされていることを確認します。oc get vm <vm_name>
$ oc get vm <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2.5.1.2. Windows 仮想マシンへの QEMU ゲストエージェントのインストール リンクのコピーリンクがクリップボードにコピーされました!
Windows 仮想マシンの場合には、QEMU ゲストエージェントは VirtIO ドライバーに含まれます。ドライバーは、Windows のインストール中または既存の Windows 仮想マシンにインストールできます。
整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。
QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。
手順
-
Windows ゲストオペレーティングシステムで、File Explorer を使用して、
virtio-winCD ドライブのguest-agentディレクトリーに移動します。 -
qemu-ga-x86_64.msiインストーラーを実行します。
検証
次のコマンドを実行して、ネットワークサービスのリストを取得します。
net start
$ net startCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
出力に
QEMU Guest Agentが含まれていることを確認します。
7.2.5.2. Windows 仮想マシンへの VirtIO ドライバーのインストール リンクのコピーリンクがクリップボードにコピーされました!
VirtIO ドライバーは、Microsoft Windows 仮想マシンが OpenShift Virtualization で実行されるために必要な準仮想化デバイスドライバーです。ドライバーは残りのイメージと同梱されるされるため、個別にダウンロードする必要はありません。
container-native-virtualization/virtio-win コンテナーディスクは、ドライバーのインストールを有効にするために SATA CD ドライブとして仮想マシンに割り当てられる必要があります。VirtIO ドライバーは、Windows のインストール中にインストールすることも、既存の Windows インストールに追加することもできます。
ドライバーのインストール後に、container-native-virtualization/virtio-win コンテナーディスクは仮想マシンから削除できます。
| ドライバー名 | ハードウェア ID | 説明 |
|---|---|---|
| viostor |
VEN_1AF4&DEV_1001 | ブロックドライバー。Other devices グループの SCSI Controller としてラベル付けされる場合があります。 |
| viorng |
VEN_1AF4&DEV_1005 | エントロピーソースドライバー。Other devices グループの PCI Device としてラベル付けされる場合があります。 |
| NetKVM |
VEN_1AF4&DEV_1000 | ネットワークドライバー。Other devices グループの Ethernet Controller としてラベル付けされる場合があります。VirtIO NIC が設定されている場合にのみ利用できます。 |
7.2.5.2.1. インストール中に VirtIO コンテナーディスクを Windows 仮想マシンにアタッチする リンクのコピーリンクがクリップボードにコピーされました!
必要な Windows ドライバーをインストールするには、VirtIO コンテナーディスクを Windows 仮想マシンにアタッチする必要があります。これは、仮想マシンの作成時に実行できます。
手順
- テンプレートから Windows 仮想マシンを作成する場合は、Customize VirtualMachine をクリックします。
- Mount Windows drivers disk を選択します。
- Customize VirtualMachine parameters をクリックします。
- Create VirtualMachine をクリックします。
仮想マシンの作成後、virtio-win SATA CD ディスクが仮想マシンにアタッチされます。
7.2.5.2.2. VirtIO コンテナーディスクを既存の Windows 仮想マシンにアタッチする リンクのコピーリンクがクリップボードにコピーされました!
必要な Windows ドライバーをインストールするには、VirtIO コンテナーディスクを Windows 仮想マシンにアタッチする必要があります。これは既存の仮想マシンに対して実行できます。
手順
- 既存の Windows 仮想マシンに移動し、Actions → Stop をクリックします。
- VM Details → Configuration → Storage に移動します。
- Mount Windows drivers disk チェックボックスを選択します。
- Save をクリックします。
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
7.2.5.2.3. Windows インストール時の VirtIO ドライバーのインストール リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンに Windows をインストールする際に VirtIO ドライバーをインストールできます。
この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンに関するドキュメントを参照してください。
前提条件
-
virtioドライバーを含むストレージデバイスを仮想マシンに接続している。
手順
-
Windows オペレーティングシステムでは、
File Explorerを使用してvirtio-winCD ドライブに移動します。 ドライブをダブルクリックして、仮想マシンに適切なインストーラーを実行します。
64 ビット仮想 CPU の場合は、
virtio-win-gt-x64インストーラーを選択します。32 ビット仮想 CPU はサポート対象外になりました。- オプション: インストーラーの Custom Setup 手順で、インストールするデバイスドライバーを選択します。デフォルトでは、推奨ドライバーセットが選択されています。
- インストールが完了したら、Finish を選択します。
- 仮想マシンを再起動します。
検証
-
PC でシステムディスクを開きます。これは通常
C:です。 - Program Files → Virtio-Win に移動します。
Virtio-Win ディレクトリーが存在し、各ドライバーのサブディレクトリーが含まれていればインストールは成功です。
7.2.5.2.4. 既存の Windows 仮想マシン上の SATA CD ドライブから VirtIO ドライバーのインストール リンクのコピーリンクがクリップボードにコピーされました!
VirtIO ドライバーは、SATA CD ドライブから既存の Windows 仮想マシンにインストールできます。
この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。特定のインストール手順は、お使いの Windows バージョンに関するインストールドキュメントを参照してください。
前提条件
- virtio ドライバーを含むストレージデバイスは、SATA CD ドライブとして仮想マシンに接続する必要があります。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- Windows ユーザーセッションにログインします。
Device Manager を開き、Other devices を拡張して、Unknown device をリスト表示します。
- Device Properties を開いて、不明なデバイスを特定します。
- デバイスを右クリックし、Properties を選択します。
- Details タブをクリックし、Property リストで Hardware Ids を選択します。
- Hardware Ids の Value をサポートされる VirtIO ドライバーと比較します。
- デバイスを右クリックし、Update Driver Software を選択します。
- Browse my computer for driver software をクリックし、VirtIO ドライバーが置かれている割り当て済みの SATA CD ドライブの場所に移動します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
- Next をクリックしてドライバーをインストールします。
- 必要なすべての VirtIO ドライバーに対してこのプロセスを繰り返します。
- ドライバーのインストール後に、Close をクリックしてウィンドウを閉じます。
- 仮想マシンを再起動してドライバーのインストールを完了します。
7.2.5.2.5. SATA CD ドライブとして追加されたコンテナーディスクからの VirtIO ドライバーのインストール リンクのコピーリンクがクリップボードにコピーされました!
Windows 仮想マシンに SATA CD ドライブとして追加するコンテナーディスクから VirtIO ドライバーをインストールできます。
コンテナーディスクがクラスター内に存在しない場合、コンテナーディスクは Red Hat レジストリーからダウンロードされるため、Red Hat エコシステムカタログ からの container-native-virtualization/virtio-win コンテナーディスクのダウンロードは必須ではありません。ただし、ダウンロードするとインストール時間が短縮されます。
前提条件
-
制限された環境では、Red Hat レジストリー、またはダウンロードされた
container-native-virtualization/virtio-winコンテナーディスクにアクセスできる必要があります。
手順
VirtualMachineマニフェストを編集して、container-native-virtualization/virtio-winコンテナーディスクを CD ドライブとして追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenShift Virtualization は、
VirtualMachineマニフェストで定義された順序で仮想マシンディスクを起動します。container-native-virtualization/virtio-winコンテナーディスクの前に起動する他の仮想マシンディスクを定義するか、オプションのbootOrderパラメーターを使用して仮想マシンが正しいディスクから起動するようにすることができます。ディスクのブート順序を設定する場合は、他のディスクのブート順序も設定する必要があります。
変更を適用します。
仮想マシンを実行していない場合は、次のコマンドを実行します。
virtctl start <vm> -n <namespace>
$ virtctl start <vm> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンが実行中の場合は、仮想マシンを再起動するか、次のコマンドを実行します。
oc apply -f <vm.yaml>
$ oc apply -f <vm.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 仮想マシンが起動したら、SATA CD ドライブから VirtIO ドライバーをインストールします。
7.2.5.3. VirtIO ドライバーの更新 リンクのコピーリンクがクリップボードにコピーされました!
7.2.5.3.1. Windows 仮想マシンでの VirtIO ドライバーの更新 リンクのコピーリンクがクリップボードにコピーされました!
Windows Update サービスを使用して、Windows 仮想マシン上の virtio ドライバーを更新します。
前提条件
- クラスターはインターネットに接続されている必要があります。切断されたクラスターは Windows Update サービスにアクセスできません。
手順
- Windows ゲストオペレーティングシステムで、Windows キーをクリックし、Settings を選択します。
- Windows Update → Advanced Options → Optional Updates に移動します。
- Red Hat, Inc. からのすべての更新をインストールします。
- 仮想マシンを再起動します。
検証
- Windows 仮想マシンで、Device Manager に移動します。
- デバイスを選択します。
- Driver タブを選択します。
-
Driver Details をクリックし、
virtioドライバーの詳細に正しいバージョンが表示されていることを確認します。
7.2.6. 仮想マシンのクローン作成 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンのクローンを作成するか、スナップショットから新しい仮想マシンを作成できます。
vTPM デバイスが接続された VM のクローン作成はサポートされていません。
7.2.6.1. Web コンソールを使用して仮想マシンを複製する リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、既存の仮想マシンを複製できます。
手順
- Web コンソールで Virtualization → VirtualMachines に移動します。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Actions をクリックします。
- Clone を選択します。
- Clone VirtualMachine ページで、新しい仮想マシンの名前を入力します。
- (オプション) Start cloned VM チェックボックスを選択して、複製された仮想マシンを開始します。
- Clone をクリックします。
7.2.6.2. Web コンソールを使用して既存のスナップショットから仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
既存のスナップショットをコピーすることで、新しい仮想マシンを作成できます。
手順
- Web コンソールで Virtualization → VirtualMachines に移動します。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Snapshots タブをクリックします。
-
コピーするスナップショットのアクションメニュー
をクリックします。
- Create VirtualMachine を選択します。
- 仮想マシンの名前を入力します。
- (オプション) Start this VirtualMachine after creation チェックボックスを選択して、新しい仮想マシンを起動します。
- Create をクリックします。
7.2.7. PVC のクローン作成による仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
カスタムイメージを使用して既存の永続ボリューム要求 (PVC) のクローンを作成することで、仮想マシンを作成できます。
Red Hat が提供していないオペレーティングシステムイメージから作成された仮想マシンには、QEMU ゲストエージェント をインストールする必要があります。
PVC のクローンを作成するには、ソース PVC を参照するデータボリュームを作成します。
7.2.7.1. クローン作成について リンクのコピーリンクがクリップボードにコピーされました!
データボリュームのクローンを作成する場合、Containerized Data Importer (CDI) は、次の Container Storage Interface (CSI) クローンメソッドのいずれかを選択します。
- CSI ボリュームのクローン作成
- スマートクローン作成
CSI ボリュームのクローン作成方法とスマートクローン作成方法はどちらも効率的ですが、使用するには特定の要件があります。要件が満たされていない場合、CDI はホスト支援型クローン作成を使用します。ホスト支援型クローン作成は、最も時間がかかり、最も効率の悪いクローン作成方法ですが、他の 2 つのクローン作成方法よりも要件の数が少ないです。
7.2.7.1.1. CSI ボリュームのクローン作成 リンクのコピーリンクがクリップボードにコピーされました!
Container Storage Interface (CSI) のクローン作成では、CSI ドライバー機能を使用して、ソースデータボリュームのクローンをより効率的に作成します。
CSI ボリュームのクローン作成には次の要件があります。
- 永続ボリューム要求 (PVC) のストレージクラスをサポートする CSI ドライバーは、ボリュームのクローン作成をサポートする必要があります。
-
CDI によって認識されないプロビジョナーの場合、対応するストレージプロファイルの
cloneStrategyが CSI Volume Cloning に設定されている必要があります。 - ソース PVC とターゲット PVC は、同じストレージクラスとボリュームモードを持つ必要があります。
-
データボリュームを作成する場合は、ソース namespace に
datavolumes/sourceリソースを作成するパーミッションが必要です。 - ソースボリュームは使用されていない状態である必要があります。
7.2.7.1.2. スマートクローン作成 リンクのコピーリンクがクリップボードにコピーされました!
スナップショット機能を備えた Container Storage Interface (CSI) プラグインが使用可能な場合、Containerized Data Importer (CDI) はスナップショットから永続ボリューム要求 (PVC) を作成し、これにより、追加の PVC の効率的なクローン作成を可能にします。
スマートクローン作成には次の要件があります。
- ストレージクラスに関連付けられたスナップショットクラスが存在する必要があります。
- ソース PVC とターゲット PVC は、同じストレージクラスとボリュームモードを持つ必要があります。
-
データボリュームを作成する場合は、ソース namespace に
datavolumes/sourceリソースを作成するパーミッションが必要です。 - ソースボリュームは使用されていない状態である必要があります。
7.2.7.1.3. ホスト支援型クローン作成 リンクのコピーリンクがクリップボードにコピーされました!
Container Storage Interface (CSI) ボリュームのクローン作成もスマートクローン作成の要件も満たされていない場合、ホスト支援型クローン作成がフォールバック方法として使用されます。ホスト支援型クローン作成は、他の 2 つのクローン作成方法と比べると効率が悪いです。
ホスト支援型クローン作成では、ソース Pod とターゲット Pod を使用して、ソースボリュームからターゲットボリュームにデータをコピーします。ターゲットの永続ボリューム要求 (PVC) には、ホスト支援型クローン作成が使用された理由を説明するフォールバック理由のアノテーションが付けられ、イベントが作成されます。
PVC ターゲットアノテーションの例
イベント例
NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE test-ns 0s Warning IncompatibleVolumeModes persistentvolumeclaim/test-target The volume modes of source and target are incompatible
NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE
test-ns 0s Warning IncompatibleVolumeModes persistentvolumeclaim/test-target The volume modes of source and target are incompatible
7.2.7.2. Web コンソールを使用した PVC からの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して永続ボリューム要求 (PVC) のクローンを作成することにより、仮想マシンを作成できます。
前提条件
- ソース PVC を含む namespace にアクセスできる。
手順
- Web コンソールで Virtualization → Catalog に移動します。
- 使用可能なブートソースのないテンプレートタイルをクリックします。
- Customize VirtualMachine をクリックします。
- テンプレートパラメーターのカスタマイズ ページで、Storage を展開し、Disk source リストから PVC (clone PVC) を選択します。
- PVC プロジェクトと PVC 名を選択します。
- ディスクサイズを設定します。
- Next をクリックします。
- Create VirtualMachine をクリックします。
7.2.7.3. コマンドラインを使用した PVC からの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して既存の仮想マシンの永続ボリューム要求 (PVC) のクローンを作成することで、仮想マシンを作成できます。
次のオプションのいずれかを使用して、PVC のクローンを作成できます。
PVC を新しいデータボリュームに複製します。
この方法では、ライフサイクルが元の仮想マシンから独立したデータボリュームが作成されます。元の仮想マシンを削除しても、新しいデータボリュームやそれに関連付けられた PVC には影響しません。
dataVolumeTemplatesスタンザを含むVirtualMachineマニフェストを作成して、PVC を複製します。この方法では、ライフサイクルが元の仮想マシンに依存するデータボリュームが作成されます。元の仮想マシンを削除すると、クローン作成されたデータボリュームとそれに関連付けられた PVC も削除されます。
7.2.7.3.1. OpenShift Data Foundation における大規模なクローンパフォーマンスの最適化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Data Foundation を使用する場合、ストレージプロファイルはデフォルトのクローン作成ストラテジーを csi-clone として設定します。ただし、次のリンクに示すように、この方法には制限があります。永続ボリューム要求 (PVC) から一定数のクローンが作成されると、バックグラウンドでフラット化プロセスが開始され、大規模なクローン作成のパフォーマンスが大幅に低下する可能性があります。
単一のソース PVC から数百のクローンを作成する際のパフォーマンスを高めるためには、デフォルトの csi-clone ストラテジーの代わりに VolumeSnapshot クローン作成メソッドを使用します。
手順
次のコンテンツを使用して、ソースイメージの VolumeSnapshot カスタムリソース (CR) を作成します。
-
VolumeSnapshotをDataVolume cloneのソースとして参照するためのspec.source.snapshotスタンザを追加します。
spec:
source:
snapshot:
namespace: golden-ns
name: golden-volumesnapshot
spec:
source:
snapshot:
namespace: golden-ns
name: golden-volumesnapshot
7.2.7.3.2. データボリュームへの PVC のクローン作成 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して、既存の仮想マシンディスクの永続ボリューム要求 (PVC) のクローンをデータボリュームに作成できます。
元のソース PVC を参照するデータボリュームを作成します。新しいデータボリュームのライフサイクルは、元の仮想マシンから独立しています。元の仮想マシンを削除しても、新しいデータボリュームやそれに関連付けられた PVC には影響しません。
異なるボリュームモード間のクローン作成は、ソース PV とターゲット PV が kubevirt コンテンツタイプに属している限り、ブロック永続ボリューム (PV) からファイルシステム PV へのクローン作成など、ホスト支援型クローン作成でサポートされます。
スマートクローン作成は、スナップショットを使用して PVC のクローンを作成するため、ホスト支援型クローン作成よりも高速かつ効率的です。スマートクローン作成は、Red Hat OpenShift Data Foundation など、スナップショットをサポートするストレージプロバイダーによってサポートされています。
異なるボリュームモード間のクローン作成は、スマートクローン作成ではサポートされていません。
前提条件
- ソース PVC を含む仮想マシンの電源をオフにする必要があります。
- PVC を別の namespace に複製する場合は、ターゲットの namespace にリソースを作成するパーミッションが必要です。
スマートクローン作成の追加の前提条件:
- ストレージプロバイダーはスナップショットをサポートする必要がある。
- ソース PVC とターゲット PVC には、同じストレージプロバイダーとボリュームモードがある必要があります。
次の例に示すように、
VolumeSnapshotClassオブジェクトのdriverキーの値は、StorageClassオブジェクトのprovisionerキーの値と一致する必要があります。VolumeSnapshotClassオブジェクトの例kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 driver: openshift-storage.rbd.csi.ceph.com # ...
kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1 driver: openshift-storage.rbd.csi.ceph.com # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow StorageClassオブジェクトの例kind: StorageClass apiVersion: storage.k8s.io/v1 # ... provisioner: openshift-storage.rbd.csi.ceph.com
kind: StorageClass apiVersion: storage.k8s.io/v1 # ... provisioner: openshift-storage.rbd.csi.ceph.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
次の例に示すように、
DataVolumeマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してデータボリュームを作成します。
oc create -f <datavolume>.yaml
$ oc create -f <datavolume>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記データ量により、PVC が準備される前に仮想マシンが起動できなくなります。PVC のクローン作成中に、新しいデータボリュームを参照する仮想マシンを作成できます。
7.2.7.3.3. データボリュームテンプレートを使用したクローン PVC からの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
データボリュームテンプレートを使用して、既存の仮想マシンの永続ボリューム要求 (PVC) のクローンを作成する仮想マシンを作成できます。この方法では、ライフサイクルが元の仮想マシンから独立したデータボリュームが作成されます。
前提条件
- ソース PVC を含む仮想マシンの電源をオフにする必要があります。
-
virtctlコマンドラインツールがインストールされている。
手順
仮想マシンの
VirtualMachineマニフェストを作成し、YAML ファイルとして保存します。次に例を示します。virtctl create vm --name rhel-9-clone --volume-import type:pvc,src:my-project/imported-volume-q5pr9
$ virtctl create vm --name rhel-9-clone --volume-import type:pvc,src:my-project/imported-volume-q5pr9Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンの
VirtualMachineマニフェストを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow PVC のクローンが作成されたデータボリュームで仮想マシンを作成します。
oc create -f <vm_manifest_file>.yaml
$ oc create -f <vm_manifest_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3. 仮想マシンコンソールへの接続 リンクのコピーリンクがクリップボードにコピーされました!
次のコンソールに接続して、実行中の仮想マシンにアクセスできます。
7.3.1. VNC コンソールへの接続 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールまたは virtctl コマンドラインツールを使用して、仮想マシンの VNC コンソールに接続できます。
7.3.1.1. Web コンソールを使用した VNC コンソールへの接続 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシンの VNC コンソールに接続できます。
vGPU が仲介デバイスとして割り当てられている Windows 仮想マシンに接続すると、デフォルトの表示と vGPU 表示を切り替えることができます。
手順
- Virtualization → VirtualMachines ページで仮想マシンをクリックして、VirtualMachine details ページを開きます。
- Console タブをクリックします。VNC コンソールセッションが自動的に開始します。
オプション: Windows 仮想マシンの vGPU 表示に切り替えるには、Send key リストから Ctl + Alt + 2 を選択します。
- デフォルトの表示に戻すには、Send key リストから Ctl + Alt + 1 を選択します。
- コンソールセッションを終了するには、コンソールペインの外側をクリックし、Disconnect をクリックします。
7.3.1.2. virtctl を使用した VNC コンソールへの接続 リンクのコピーリンクがクリップボードにコピーされました!
virtctl コマンドラインツールを使用して、実行中の仮想マシンの VNC コンソールに接続できます。
SSH 接続経由でリモートマシン上で virtctl vnc コマンドを実行する場合は、-X フラグまたは -Y フラグを指定して ssh コマンドを実行して、X セッションをローカルマシンに転送する必要があります。
前提条件
-
virt-viewerパッケージをインストールする必要があります。
手順
次のコマンドを実行して、コンソールセッションを開始します。
virtctl vnc <vm_name>
$ virtctl vnc <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接続に失敗した場合は、次のコマンドを実行してトラブルシューティング情報を収集します。
virtctl vnc <vm_name> -v 4
$ virtctl vnc <vm_name> -v 4Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3.1.3. VNC コンソールの一時トークンの生成 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes API が仮想マシン (VM) の VNC にアクセスするための一時的な認証ベアラートークンを生成します。
Kubernetes は、curl コマンドを変更することで、ベアラートークンの代わりにクライアント証明書を使用した認証もサポートします。
前提条件
-
OpenShift Virtualization 4.14 以降および
ssp-operator4.14 以降を搭載した実行中の仮想マシン。
手順
HyperConverged (
HCO) カスタムリソース (CR) の機能ゲートを有効にします。oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op": "replace", "path": "/spec/featureGates/deployVmConsoleProxy", "value": true}]'$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op": "replace", "path": "/spec/featureGates/deployVmConsoleProxy", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力してトークンを生成します。
curl --header "Authorization: Bearer ${TOKEN}" \ "https://api.<cluster_fqdn>/apis/token.kubevirt.io/v1alpha1/namespaces/<namespace>/virtualmachines/<vm_name>/vnc?duration=<duration>"$ curl --header "Authorization: Bearer ${TOKEN}" \ "https://api.<cluster_fqdn>/apis/token.kubevirt.io/v1alpha1/namespaces/<namespace>/virtualmachines/<vm_name>/vnc?duration=<duration>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow <duration>パラメーターは時間と分で設定でき、最小期間は 10 分です。たとえば、5h30mです。このパラメーターが設定されていない場合、トークンはデフォルトで 10 分間有効です。出力サンプル
{ "token": "eyJhb..." }{ "token": "eyJhb..." }Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 出力で提供されたトークンを使用して変数を作成します。
export VNC_TOKEN="<token>"
$ export VNC_TOKEN="<token>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
これで、トークンを使用して、仮想マシンの VNC コンソールにアクセスできるようになります。
検証
次のコマンドを入力してクラスターにログインします。
oc login --token ${VNC_TOKEN}$ oc login --token ${VNC_TOKEN}Copy to Clipboard Copied! Toggle word wrap Toggle overflow virtctlコマンドを使用して、仮想マシンの VNC コンソールへのアクセスをテストします。virtctl vnc <vm_name> -n <namespace>
$ virtctl vnc <vm_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
現在、特定のトークンを取り消すことはできません。
トークンを取り消すには、トークンの作成に使用したサービスアカウントを削除する必要があります。ただし、これにより、サービスアカウントを使用して作成された他のすべてのトークンも取り消されます。次のコマンドは注意して使用してください。
virtctl delete serviceaccount --namespace "<namespace>" "<vm_name>-vnc-access"
$ virtctl delete serviceaccount --namespace "<namespace>" "<vm_name>-vnc-access"
7.3.1.3.1. クラスターロールを使用して VNC コンソールにトークン生成パーミッションを付与する リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターロールをインストールし、それをユーザーまたはサービスアカウントにバインドして、VNC コンソールのトークンを生成するエンドポイントへのアクセスを許可できます。
手順
クラスターロールをユーザーまたはサービスアカウントにバインドすることを選択します。
クラスターロールをユーザーにバインドするには、次のコマンドを実行します。
kubectl create rolebinding "${ROLE_BINDING_NAME}" --clusterrole="token.kubevirt.io:generate" --user="${USER_NAME}"$ kubectl create rolebinding "${ROLE_BINDING_NAME}" --clusterrole="token.kubevirt.io:generate" --user="${USER_NAME}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してクラスターロールをサービスアカウントにバインドします。
kubectl create rolebinding "${ROLE_BINDING_NAME}" --clusterrole="token.kubevirt.io:generate" --serviceaccount="${SERVICE_ACCOUNT_NAME}"$ kubectl create rolebinding "${ROLE_BINDING_NAME}" --clusterrole="token.kubevirt.io:generate" --serviceaccount="${SERVICE_ACCOUNT_NAME}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3.2. シリアルコンソールへの接続 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールまたは virtctl コマンドラインツールを使用して、仮想マシンのシリアルコンソールに接続できます。
単一の仮想マシンに対する同時 VNC 接続の実行は、現在サポートされていません。
7.3.2.1. Web コンソールを使用したシリアルコンソールへの接続 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシンのシリアルコンソールに接続できます。
vGPU が仲介デバイスとして割り当てられている Windows 仮想マシンに接続すると、デフォルトの表示と vGPU 表示を切り替えることができます。
手順
- Virtualization → VirtualMachines ページで仮想マシンをクリックして、VirtualMachine details ページを開きます。
- Console タブをクリックします。VNC コンソールセッションが自動的に開始します。
- Disconnect をクリックして、VNC コンソールセッションを終了します。それ以外の場合、VNC コンソールセッションは引き続きバックグラウンドで実行されます。
- コンソールリストから Serial console を選択します。
オプション: Windows 仮想マシンの vGPU 表示に切り替えるには、Send key リストから Ctl + Alt + 2 を選択します。
- デフォルトの表示に戻すには、Send key リストから Ctl + Alt + 1 を選択します。
- コンソールセッションを終了するには、コンソールペインの外側をクリックし、Disconnect をクリックします。
7.3.2.2. virtctl を使用したシリアルコンソールへの接続 リンクのコピーリンクがクリップボードにコピーされました!
virtctl コマンドラインツールを使用して、実行中の仮想マシンのシリアルコンソールに接続できます。
SSH 接続経由でリモートマシン上で virtctl vnc コマンドを実行する場合は、-X フラグまたは -Y フラグを指定して ssh コマンドを実行して、X セッションをローカルマシンに転送する必要があります。
前提条件
-
virt-viewerパッケージをインストールする必要があります。
手順
次のコマンドを実行して、コンソールセッションを開始します。
virtctl console <vm_name>
$ virtctl console <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ctrl+]を押してコンソールセッションを終了します。virtctl vnc <vm_name>
$ virtctl vnc <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接続に失敗した場合は、次のコマンドを実行してトラブルシューティング情報を収集します。
virtctl vnc <vm_name> -v 4
$ virtctl vnc <vm_name> -v 4Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3.3. デスクトップビューアーに接続する リンクのコピーリンクがクリップボードにコピーされました!
デスクトップビューアーとリモートデスクトッププロトコル (RDP) を使用して、Windows 仮想マシンに接続できます。
7.3.3.1. Web コンソールを使用したデスクトップビューアーへの接続 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシン (VM) のデスクトップビューアーに接続できます。OpenShift Container Platform Web コンソールを使用して、Windows 仮想マシンのデスクトップビューアーに接続できます。
vGPU が仲介デバイスとして割り当てられている Windows 仮想マシンに接続すると、デフォルトの表示と vGPU 表示を切り替えることができます。
前提条件
- QEMU ゲストエージェントが Windows 仮想マシンにインストールされている。
- RDP クライアントがインストールされている。
手順
- Virtualization → VirtualMachines ページで仮想マシンをクリックして、VirtualMachine details ページを開きます。
- Console タブをクリックします。VNC コンソールセッションが自動的に開始します。
- Disconnect をクリックして、VNC コンソールセッションを終了します。それ以外の場合、VNC コンソールセッションは引き続きバックグラウンドで実行されます。
- コンソールのリストから Desktop viewer を選択します。
- RDP サービスの作成 をクリックして、RDP サービス ダイアログを開きます。
- Expose RDP Service を選択し、Save をクリックしてノードポートサービスを作成します。
-
Launch Remote Desktop をクリックして
.rdpファイルをダウンロードし、デスクトップビューアーを起動します。 オプション: Windows 仮想マシンの vGPU 表示に切り替えるには、Send key リストから Ctl + Alt + 2 を選択します。
- デフォルトの表示に戻すには、Send key リストから Ctl + Alt + 1 を選択します。
- コンソールセッションを終了するには、コンソールペインの外側をクリックし、Disconnect をクリックします。
7.4. インスタンスタイプまたは設定の指定 リンクのコピーリンクがクリップボードにコピーされました!
インスタンスタイプまたは優先度、またはその両方を指定して、複数の仮想マシンで再利用するためのワークロードサイジングとランタイム特性を定義できます。
7.4.1. フラグを使用したインスタンスタイプと設定の指定 リンクのコピーリンクがクリップボードにコピーされました!
フラグを使用して、インスタンスタイプおよび設定を指定します。
前提条件
- クラスターにインスタンスタイプ、プリファレンス、またはその両方がある。
手順
仮想マシンを作成するときにインスタンスタイプを指定するには、
--instancetypeフラグを使用します。設定を指定するには、--preferenceフラグを使用します。次の例には両方のフラグが含まれています。virtctl create vm --instancetype <my_instancetype> --preference <my_preference>
$ virtctl create vm --instancetype <my_instancetype> --preference <my_preference>Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: namespace 付きのインスタンスタイプまたは設定を指定するには、
--instancetypeまたは--preferenceフラグコマンドに渡される値にkindを含めます。namespace 付きのインスタンスタイプまたは設定は、仮想マシンを作成するのと同じ namespace に存在する必要があります。次の例には、namespace 付きインスタンスタイプと namespace 付き設定のフラグが含まれています。virtctl create vm --instancetype virtualmachineinstancetype/<my_instancetype> --preference virtualmachinepreference/<my_preference>
$ virtctl create vm --instancetype virtualmachineinstancetype/<my_instancetype> --preference virtualmachinepreference/<my_preference>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4.2. インスタンスタイプまたは設定の推測 リンクのコピーリンクがクリップボードにコピーされました!
インスタンスタイプの推論、設定、またはその両方がデフォルトで有効になっており、inferFromVolume 属性の inferFromVolumeFailure ポリシーは Ignore に設定されています。ブートボリュームから推測する場合、エラーは無視され、インスタンスタイプと設定が未設定のままで仮想マシンが作成されます。
ただし、フラグが適用されると、inferFromVolumeFailure ポリシーはデフォルトで Reject に設定されます。ブートボリュームから推測する場合、エラーが発生すると、その仮想マシンの作成が拒否されます。
--infer-instancetype フラグと --infer-preference フラグを使用すると、仮想マシンのワークロードのサイズ設定と実行時特性を定義するために使用するインスタンスタイプ、設定、またはその両方を推測できます。
前提条件
-
virtctlツールがインストールされている。
手順
仮想マシンの起動に使用されるボリュームからインスタンスタイプを明示的に推測するには、
--infer-instancetypeフラグを使用します。設定を明示的に推測するには、--infer-preferenceフラグを使用します。次のコマンドには両方のフラグが含まれます。virtctl create vm --volume-import type:pvc,src:my-ns/my-pvc --infer-instancetype --infer-preference
$ virtctl create vm --volume-import type:pvc,src:my-ns/my-pvc --infer-instancetype --infer-preferenceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4.3. inferFromVolume ラベルの設定 リンクのコピーリンクがクリップボードにコピーされました!
PVC、データソース、またはデータボリュームで次のラベルを使用して、ボリュームから起動するときに使用するインスタンスタイプ、設定、またはその両方を推論メカニズムに指示します。
-
クラスター全体のインスタンスのタイプ:
instancetype.kubevirt.io/default-instancetypeラベル。 -
namespace 付きのインスタンスタイプ:
instancetype.kubevirt.io/default-instancetype-kindラベル。空のままにすると、デフォルトでVirtualMachineClusterInstancetypeラベルになります。 -
クラスター全体の設定:
instancetype.kubevirt.io/default-preferenceラベル。 -
namespace 付きの設定:
instancetype.kubevirt.io/default-preference-kindラベル。空のままにすると、デフォルトでVirtualMachineClusterPreferenceラベルになります。
前提条件
- クラスターにインスタンスタイプ、プリファレンス、またはその両方がある。
手順
データソースにラベルを適用するには、
oc labelを使用します。次のコマンドは、クラスター全体のインスタンスタイプを指すラベルを適用します。oc label DataSource foo instancetype.kubevirt.io/default-instancetype=<my_instancetype>
$ oc label DataSource foo instancetype.kubevirt.io/default-instancetype=<my_instancetype>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5. 仮想マシンへの SSH アクセスの設定 リンクのコピーリンクがクリップボードにコピーされました!
次の方法を使用して、仮想マシンへの SSH アクセスを設定できます。
SSH 鍵ペアを作成し、公開鍵を仮想マシンに追加し、秘密鍵を使用して
virtctl sshコマンドを実行して仮想マシンに接続します。cloud-init データソースを使用して設定できるゲストオペレーティングシステムを使用して、実行時または最初の起動時に Red Hat Enterprise Linux (RHEL) 9 仮想マシンに SSH 公開鍵を追加できます。
virtctl port-fowardコマンドを.ssh/configファイルに追加し、OpenSSH を使用して仮想マシンに接続します。サービスを作成し、そのサービスを仮想マシンに関連付け、サービスによって公開されている IP アドレスとポートに接続します。
セカンダリーネットワークを設定し、仮想マシンをセカンダリーネットワークインターフェイスに接続し、DHCP によって割り当てられた IP アドレスに接続します。
7.5.1. アクセス設定の考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンへのアクセスを設定する各方法には、トラフィックの負荷とクライアントの要件に応じて利点と制限があります。
サービスは優れたパフォーマンスを提供するため、クラスターの外部からアクセスされるアプリケーションに推奨されます。
内部クラスターネットワークがトラフィック負荷を処理できない場合は、セカンダリーネットワークを設定できます。
virtctl sshおよびvirtctl port-forwardingコマンド- 設定が簡単。
- 仮想マシンのトラブルシューティングに推奨されます。
-
Ansible を使用した仮想マシンの自動設定には、
virtctl port-forwardingが推奨されます。 - 動的 SSH 公開鍵を使用して、Ansible で仮想マシンをプロビジョニングできます。
- API サーバーに負担がかかるため、Rsync やリモートデスクトッププロトコルなどの高トラフィックのアプリケーションには推奨されません。
- API サーバーはトラフィック負荷を処理できる必要があります。
- クライアントは API サーバーにアクセスできる必要があります。
- クライアントはクラスターへのアクセス認証情報を持っている必要があります。
- クラスター IP サービス
- 内部クラスターネットワークはトラフィック負荷を処理できる必要があります。
- クライアントは内部クラスター IP アドレスにアクセスできる必要があります。
- ノードポートサービス
- 内部クラスターネットワークはトラフィック負荷を処理できる必要があります。
- クライアントは少なくとも 1 つのノードにアクセスできる必要があります。
- ロードバランサーサービス
- ロードバランサーを設定する必要があります。
- 各ノードは、1 つ以上のロードバランサーサービスのトラフィック負荷を処理できなければなりません。
- セカンダリーネットワーク
- トラフィックが内部クラスターネットワークを経由しないため、優れたパフォーマンスが得られます。
- ネットワークトポロジーへの柔軟なアプローチを可能にします。
- 仮想マシンはセカンダリーネットワークに直接公開されるため、ゲストオペレーティングシステムは適切なセキュリティーを備えて設定する必要があります。仮想マシンが侵害されると、侵入者がセカンダリーネットワークにアクセスする可能性があります。
7.5.2. virtctl ssh の使用 リンクのコピーリンクがクリップボードにコピーされました!
virtctl ssh コマンドを実行することで、仮想マシン (VM) に SSH 公開鍵を追加し、仮想マシンに接続できます。
この方法の設定は簡単です。ただし、API サーバーに負担がかかるため、トラフィック負荷が高い場合には推奨されません。
7.5.2.1. 静的および動的 SSH 鍵の管理について リンクのコピーリンクがクリップボードにコピーされました!
SSH 公開鍵は、最初の起動時に静的に、または実行時に動的に仮想マシン (VM) に追加できます。
Red Hat Enterprise Linux (RHEL) 9 のみが動的キーインジェクションをサポートしています。
静的 SSH 鍵の管理
cloud-init データソースを使用した設定をサポートするゲストオペレーティングシステムを搭載した仮想マシンに、静的に管理される SSH 鍵を追加できます。鍵は最初の起動時に仮想マシン (VM) に追加されます。
次のいずれかの方法を使用して鍵を追加できます。
- Web コンソールまたはコマンドラインを使用して単一の仮想マシンを作成する場合は、その仮想マシンに鍵を追加します。
- Web コンソールを使用してプロジェクトに鍵を追加します。その後、このプロジェクトで作成した仮想マシンに鍵が自動的に追加されます。
ユースケース
- 仮想マシンの所有者は、新しく作成したすべての仮想マシンを 1 つの鍵でプロビジョニングできます。
動的 SSH 鍵の管理
Red Hat Enterprise Linux (RHEL) 9 がインストールされている仮想マシンに対して、動的 SSH 鍵の管理を有効にできます。その後、実行時に鍵を更新できます。鍵は、Red Hat ブートソースとともにインストールされる QEMU ゲストエージェントによって追加されます。
動的鍵の管理が無効になっている場合、仮想マシンのデフォルトの鍵管理設定は、その仮想マシンに使用されるイメージによって決まります。
ユースケース
-
仮想マシンへのアクセスの付与または取り消し: クラスター管理者は、namespace 内のすべての仮想マシンに適用される
Secretオブジェクトに個々のユーザーのキーを追加または削除することで、リモート仮想マシンアクセスを付与または取り消すことができます。 - ユーザーアクセス: 作成および管理するすべての仮想マシンにアクセス認証情報を追加できます。
Ansible プロビジョニング:
- 運用チームのメンバーは、Ansible プロビジョニングに使用されるすべてのキーを含む 1 つのシークレットを作成できます。
- 仮想マシン所有者は、仮想マシンを作成し、Ansible プロビジョニングに使用されるキーをアタッチできます。
キーのローテーション:
- クラスター管理者は、namespace 内の仮想マシンによって使用される Ansible プロビジョナーキーをローテーションできます。
- ワークロード所有者は、管理する仮想マシンのキーをローテーションできます。
7.5.2.2. 静的キー管理 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールまたはコマンドラインを使用して仮想マシン (VM) を作成するときに、静的に管理される SSH 公開鍵を追加できます。鍵は、仮想マシンが初めて起動するときに、cloud-init データソースとして追加されます。
Web コンソールを使用して仮想マシンを作成するときに、公開 SSH 鍵をプロジェクトに追加することもできます。鍵はシークレットとして保存され、作成するすべての仮想マシンに自動的に追加されます。
シークレットは namespace リソースであるため、シークレットをプロジェクトに追加し、その後仮想マシンを削除しても、シークレットは保持されます。シークレットは、手動で削除する必要があります。
7.5.2.2.1. テンプレートから仮想マシンを作成するときに鍵を追加する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して仮想マシン (VM) を作成するときに、静的に管理される SSH 公開鍵を追加できます。鍵は、最初の起動時に cloud-init データソースとして仮想マシンに追加されます。この方法は、cloud-init ユーザーデータには影響しません。
オプション: プロジェクトにキーを追加できます。その後、このキーはプロジェクトで作成した仮想マシンに自動的に追加されます。
前提条件
-
ssh-keygenコマンドを実行して、SSH 鍵ペアを生成しました。
手順
- Web コンソールで Virtualization → Catalog に移動します。
テンプレートタイルをクリックします。
ゲストオペレーティングシステムは、cloud-init データソースからの設定をサポートする必要があります。
- Customize VirtualMachine をクリックします。
- Next をクリックします。
- Scripts タブをクリックします。
プロジェクトに SSH 公開鍵をまだ追加していない場合は、Authorized SSH key の横にある編集アイコンをクリックし、次のいずれかのオプションを選択します。
- Use existing: シークレットリストからシークレットを選択します。
Add new:
- SSH 鍵ファイルを参照するか、ファイルを鍵のフィールドに貼り付けます。
- シークレット名を入力します。
- オプション: Automatically apply this key to any new VirtualMachine you create in this project を選択します。
- Save をクリックします。
Create VirtualMachine をクリックします。
VirtualMachine details ページには、仮想マシン作成の進行状況が表示されます。
検証
Configuration タブの Scripts タブをクリックします。
シークレット名は Authorized SSH key セクションに表示されます。
7.5.2.2.2. Web コンソールを使用してインスタンスタイプから仮想マシンを作成するときにキーを追加する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、インスタンスタイプから仮想マシンを作成できます。Web コンソールを使用して、既存のスナップショットをコピーするか仮想マシンを複製して、仮想マシンを作成することもできます。
使用可能な起動可能なボリュームのリストから仮想マシンを作成できます。Linux ベースまたは Windows ベースのボリュームをリストに追加できます。
OpenShift Container Platform Web コンソールを使用してインスタンスタイプから仮想マシン (VM) を作成するときに、静的に管理される SSH 鍵を追加できます。鍵は、最初の起動時に cloud-init データソースとして仮想マシンに追加されます。この方法は、cloud-init ユーザーデータには影響しません。
手順
Web コンソールで、Virtualization → Catalog に移動します。
InstanceTypes タブがデフォルトで開きます。
次のオプションのいずれかを選択します。
リストから適切な起動可能なボリュームを選択します。リストが切り捨てられている場合は、Show all ボタンをクリックしてリスト全体を表示します。
注記ブート可能ボリュームテーブルには、
openshift-virtualization-os-imagesnamespace 内のinstancetype.kubevirt.io/default-preferenceラベルを持つボリュームのみリストされます。- オプション: 星アイコンをクリックして、ブート可能ボリュームをお気に入りとして指定します。星付きのブート可能ボリュームは、ボリュームリストの最初に表示されます。
新しいボリュームをアップロードするか、既存の永続ボリューム要求 (PVC)、ボリュームスナップショット、または
containerDiskボリュームを使用するには Add volume をクリックします。Save をクリックします。クラスターで使用できないオペレーティングシステムのロゴは、リストの下部に表示されます。Add volume リンクをクリックすると、必要なオペレーティングシステムのボリュームを追加できます。
さらに、Create a Windows boot source クイックスタートへのリンクもあります。Select volume to boot from の横にある疑問符アイコンの上にポインターを置くと、ポップオーバーに同じリンクが表示されます。
環境をインストールした直後、または環境が切断された直後は、起動元のボリュームのリストは空になります。その場合、Windows、RHEL、Linux の 3 つのオペレーティングシステムのロゴが表示されます。Add volume ボタンをクリックすると、要件を満たす新しいボリュームを追加できます。
- インスタンスタイプのタイルをクリックし、ワークロードに適したリソースサイズを選択します。
オプション: 起動元のボリュームに適用される仮想マシンの詳細 (仮想マシンの名前を含む) を選択します。
Linux ベースのボリュームの場合は、次の手順に従って SSH を設定します。
- プロジェクトに SSH 公開鍵をまだ追加していない場合は、VirtualMachine details セクションの Authorized SSH key の横にある編集アイコンをクリックします。
以下のオプションのいずれかを選択します。
- Use existing: シークレットリストからシークレットを選択します。
Add new: 以下の手順に従ってください。
- SSH 公開鍵ファイルを参照するか、ファイルを鍵のフィールドに貼り付けます。
- シークレット名を入力します。
- オプション: Automatically apply this key to any new VirtualMachine you create in this project を選択します。
- Save をクリックします。
Windows ボリュームの場合は、次のいずれかの手順に従って sysprep オプションを設定します。
Windows ボリュームに sysprep オプションをまだ追加していない場合は、次の手順に従います。
- VirtualMachine details セクションの Sysprep の横にある編集アイコンをクリックします。
- Autoattend.xml アンサーファイルを追加します。
- Unattend.xml アンサーファイルを追加します。
- Save をクリックします。
Windows ボリュームに既存の sysprep オプションを使用する場合は、次の手順に従います。
- 既存の sysprep を添付 をクリックします。
- 既存の sysprep Unattend.xml アンサーファイルの名前を入力します。
- Save をクリックします。
オプション: Windows 仮想マシンを作成する場合は、Windows ドライバーディスクをマウントできます。
- Customize VirtualMachine ボタンをクリックします。
- VirtualMachine details ページで、Storage をクリックします。
- Mount Windows drivers disk チェックボックスを選択します。
- オプション: View YAML & CLI をクリックして YAML ファイルを表示します。CLI をクリックして CLI コマンドを表示します。YAML ファイルの内容または CLI コマンドをダウンロードまたはコピーすることもできます。
- Create VirtualMachine をクリックします。
仮想マシンの作成後、VirtualMachine details ページでステータスを監視できます。
7.5.2.2.3. コマンドラインを使用して仮想マシンを作成するときにキーを追加する リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して仮想マシンを作成するときに、静的に管理される公開 SSH キーを追加できます。鍵は最初の起動時に仮想マシンに追加されます。
鍵は、cloud-init データソースとして仮想マシンに追加されます。この方法では、cloud-init ユーザーデータ内のアプリケーションデータからアクセス認証情報が分離されます。この方法は、cloud-init ユーザーデータには影響しません。
前提条件
-
ssh-keygenコマンドを実行して、SSH 鍵ペアを生成しました。
手順
VirtualMachineオブジェクトとSecretオブジェクトのマニフェストファイルを作成します。マニフェストの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
VirtualMachineオブジェクトとSecretオブジェクトを作成します。oc create -f <manifest_file>.yaml
$ oc create -f <manifest_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して仮想マシンを起動します。
virtctl start vm example-vm -n example-namespace
$ virtctl start vm example-vm -n example-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
仮想マシン設定を取得します。
oc describe vm example-vm -n example-namespace
$ oc describe vm example-vm -n example-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.2.3. 動的なキー管理 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールまたはコマンドラインを使用して、仮想マシンの動的キーインジェクションを有効にできます。その後、実行時にキーを更新できます。
Red Hat Enterprise Linux (RHEL) 9 のみが動的キーインジェクションをサポートしています。
動的キーインジェクションを無効にすると、仮想マシンは作成元のイメージのキー管理方法を継承します。
7.5.2.3.1. テンプレートから仮想マシンを作成するときに動的キーインジェクションを有効にする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用してテンプレートから仮想マシンを作成するときに、動的パブリック SSH キーインジェクションを有効にすることができます。その後、実行時にキーを更新できます。
Red Hat Enterprise Linux (RHEL) 9 のみが動的キーインジェクションをサポートしています。
鍵は、RHEL 9 とともにインストールされる QEMU ゲストエージェントによって仮想マシンに追加されます。
前提条件
-
ssh-keygenコマンドを実行して、SSH 鍵ペアを生成しました。
手順
- Web コンソールで Virtualization → Catalog に移動します。
- Red Hat Enterprise Linux 9 VM タイルをクリックします。
- Customize VirtualMachine をクリックします。
- Next をクリックします。
- Scripts タブをクリックします。
プロジェクトに SSH 公開鍵をまだ追加していない場合は、Authorized SSH key の横にある編集アイコンをクリックし、次のいずれかのオプションを選択します。
- Use existing: シークレットリストからシークレットを選択します。
Add new:
- SSH 鍵ファイルを参照するか、ファイルを鍵のフィールドに貼り付けます。
- シークレット名を入力します。
- オプション: Automatically apply this key to any new VirtualMachine you create in this project を選択します。
- Dynamic SSH key injection をオンに設定します。
- Save をクリックします。
Create VirtualMachine をクリックします。
VirtualMachine details ページには、仮想マシン作成の進行状況が表示されます。
検証
Configuration タブの Scripts タブをクリックします。
シークレット名は Authorized SSH key セクションに表示されます。
7.5.2.3.2. Web コンソールを使用してインスタンスタイプから仮想マシンを作成するときに動的キーインジェクションを有効にする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、インスタンスタイプから仮想マシンを作成できます。Web コンソールを使用して、既存のスナップショットをコピーするか仮想マシンを複製して、仮想マシンを作成することもできます。
使用可能な起動可能なボリュームのリストから仮想マシンを作成できます。Linux ベースまたは Windows ベースのボリュームをリストに追加できます。
OpenShift Container Platform Web コンソールを使用してインスタンスタイプから仮想マシンを作成するときに、動的 SSH キーインジェクションを有効にできます。その後、実行時にキーを追加または取り消すことができます。
Red Hat Enterprise Linux (RHEL) 9 のみが動的キーインジェクションをサポートしています。
鍵は、RHEL 9 とともにインストールされる QEMU ゲストエージェントによって仮想マシンに追加されます。
手順
Web コンソールで、Virtualization → Catalog に移動します。
InstanceTypes タブがデフォルトで開きます。
次のオプションのいずれかを選択します。
リストから適切な起動可能なボリュームを選択します。リストが切り捨てられている場合は、Show all ボタンをクリックしてリスト全体を表示します。
注記ブート可能ボリュームテーブルには、
openshift-virtualization-os-imagesnamespace 内のinstancetype.kubevirt.io/default-preferenceラベルを持つボリュームのみリストされます。- オプション: 星アイコンをクリックして、ブート可能ボリュームをお気に入りとして指定します。星付きのブート可能ボリュームは、ボリュームリストの最初に表示されます。
新しいボリュームをアップロードするか、既存の永続ボリューム要求 (PVC)、ボリュームスナップショット、または
containerDiskボリュームを使用するには Add volume をクリックします。Save をクリックします。クラスターで使用できないオペレーティングシステムのロゴは、リストの下部に表示されます。Add volume リンクをクリックすると、必要なオペレーティングシステムのボリュームを追加できます。
さらに、Create a Windows boot source クイックスタートへのリンクもあります。Select volume to boot from の横にある疑問符アイコンの上にポインターを置くと、ポップオーバーに同じリンクが表示されます。
環境をインストールした直後、または環境が切断された直後は、起動元のボリュームのリストは空になります。その場合、Windows、RHEL、Linux の 3 つのオペレーティングシステムのロゴが表示されます。Add volume ボタンをクリックすると、要件を満たす新しいボリュームを追加できます。
- インスタンスタイプのタイルをクリックし、ワークロードに適したリソースサイズを選択します。
- Red Hat Enterprise Linux 9 VM タイルをクリックします。
オプション: 起動元のボリュームに適用される仮想マシンの詳細 (仮想マシンの名前を含む) を選択します。
Linux ベースのボリュームの場合は、次の手順に従って SSH を設定します。
- プロジェクトに SSH 公開鍵をまだ追加していない場合は、VirtualMachine details セクションの Authorized SSH key の横にある編集アイコンをクリックします。
以下のオプションのいずれかを選択します。
- Use existing: シークレットリストからシークレットを選択します。
Add new: 以下の手順に従ってください。
- SSH 公開鍵ファイルを参照するか、ファイルを鍵のフィールドに貼り付けます。
- シークレット名を入力します。
- オプション: Automatically apply this key to any new VirtualMachine you create in this project を選択します。
- Save をクリックします。
Windows ボリュームの場合は、次のいずれかの手順に従って sysprep オプションを設定します。
Windows ボリュームに sysprep オプションをまだ追加していない場合は、次の手順に従います。
- VirtualMachine details セクションの Sysprep の横にある編集アイコンをクリックします。
- Autoattend.xml アンサーファイルを追加します。
- Unattend.xml アンサーファイルを追加します。
- Save をクリックします。
Windows ボリュームに既存の sysprep オプションを使用する場合は、次の手順に従います。
- 既存の sysprep を添付 をクリックします。
- 既存の sysprep Unattend.xml アンサーファイルの名前を入力します。
- Save をクリックします。
- VirtualMachine details セクションで Dynamic SSH key injection をオンに設定します。
オプション: Windows 仮想マシンを作成する場合は、Windows ドライバーディスクをマウントできます。
- Customize VirtualMachine ボタンをクリックします。
- VirtualMachine details ページで、Storage をクリックします。
- Mount Windows drivers disk チェックボックスを選択します。
- オプション: View YAML & CLI をクリックして YAML ファイルを表示します。CLI をクリックして CLI コマンドを表示します。YAML ファイルの内容または CLI コマンドをダウンロードまたはコピーすることもできます。
- Create VirtualMachine をクリックします。
仮想マシンの作成後、VirtualMachine details ページでステータスを監視できます。
7.5.2.3.3. Web コンソールを使用した動的 SSH キーインジェクションの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシンの動的キーインジェクションを有効にできます。その後、実行時に SSH 公開鍵を更新できます。
鍵は、Red Hat Enterprise Linux (RHEL) 9 とともにインストールされる QEMU ゲストエージェントによって仮想マシンに追加されます。
前提条件
- ゲストオペレーティングシステムは RHEL 9 です。
手順
- Web コンソールで Virtualization → VirtualMachines に移動します。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Configuration タブで、Scripts をクリックします。
プロジェクトに SSH 公開鍵をまだ追加していない場合は、Authorized SSH key の横にある編集アイコンをクリックし、次のいずれかのオプションを選択します。
- Use existing: シークレットリストからシークレットを選択します。
Add new:
- SSH 鍵ファイルを参照するか、ファイルを鍵のフィールドに貼り付けます。
- シークレット名を入力します。
- オプション: Automatically apply this key to any new VirtualMachine you create in this project を選択します。
- Dynamic SSH key injection をオンに設定します。
- Save をクリックします。
7.5.2.3.4. コマンドラインを使用して動的キーインジェクションを有効にする リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して、仮想マシンの動的キーインジェクションを有効にすることができます。その後、実行時に SSH 公開鍵を更新できます。
Red Hat Enterprise Linux (RHEL) 9 のみが動的キーインジェクションをサポートしています。
キーは QEMU ゲストエージェントによって仮想マシンに追加され、RHEL 9 とともに自動的にインストールされます。
前提条件
-
ssh-keygenコマンドを実行して、SSH 鍵ペアを生成しました。
手順
VirtualMachineオブジェクトとSecretオブジェクトのマニフェストファイルを作成します。マニフェストの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
VirtualMachineオブジェクトとSecretオブジェクトを作成します。oc create -f <manifest_file>.yaml
$ oc create -f <manifest_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して仮想マシンを起動します。
virtctl start vm example-vm -n example-namespace
$ virtctl start vm example-vm -n example-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
仮想マシン設定を取得します。
oc describe vm example-vm -n example-namespace
$ oc describe vm example-vm -n example-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.2.4. virtctl ssh コマンドの使用 リンクのコピーリンクがクリップボードにコピーされました!
virtcl ssh コマンドを使用して、実行中の仮想マシンにアクセスできます。
前提条件
-
virtctlコマンドラインツールがインストールされている。 - 仮想マシンに SSH 公開鍵が追加されている。
- SSH クライアントがインストールされている。
-
virtctlツールをインストールした環境に、仮想マシンにアクセスするために必要なクラスター権限がある。たとえば、oc loginを実行するか、KUBECONFIG環境変数を設定します。
手順
virtctl sshコマンドを実行します。virtctl -n <namespace> ssh <username>@example-vm -i <ssh_key>
$ virtctl -n <namespace> ssh <username>@example-vm -i <ssh_key>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- namespace、ユーザー名、SSH 秘密鍵を指定します。デフォルトの SSH 鍵の場所は
/home/user/.sshです。キーを別の場所に保存する場合は、パスを指定する必要があります。
例
virtctl -n my-namespace ssh cloud-user@example-vm -i my-key
$ virtctl -n my-namespace ssh cloud-user@example-vm -i my-keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow
VirtualMachines ページの仮想マシンの横にあるオプション
メニューから、Copy SSH command を選択すると、Web コンソールで virtctl ssh コマンドをコピーできます。
7.5.3. virtctl port-forward コマンドの使用 リンクのコピーリンクがクリップボードにコピーされました!
ローカルの OpenSSH クライアントと virtctl port-forward コマンドを使用して、実行中の仮想マシン (VM) に接続できます。Ansible でこの方法を使用すると、VM の設定を自動化できます。
ポート転送トラフィックはコントロールプレーン経由で送信されるため、この方法はトラフィックの少ないアプリケーションに推奨されます。ただし、API サーバーに負荷が大きいため、Rsync や Remote Desktop Protocol などのトラフィックの高いアプリケーションには推奨されません。
前提条件
-
virtctlクライアントをインストールしている。 - アクセスする仮想マシンが実行されている。
-
virtctlツールをインストールした環境に、仮想マシンにアクセスするために必要なクラスター権限がある。たとえば、oc loginを実行するか、KUBECONFIG環境変数を設定します。
手順
以下のテキストをクライアントマシンの
~/.ssh/configファイルに追加します。Host vm/* ProxyCommand virtctl port-forward --stdio=true %h %p
Host vm/* ProxyCommand virtctl port-forward --stdio=true %h %pCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、仮想マシンに接続します。
ssh <user>@vm/<vm_name>.<namespace>
$ ssh <user>@vm/<vm_name>.<namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.4. SSH アクセス用のサービスを使用する リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンのサービスを作成し、サービスによって公開される IP アドレスとポートに接続できます。
サービスは優れたパフォーマンスを提供するため、クラスターの外部またはクラスター内からアクセスされるアプリケーションに推奨されます。受信トラフィックはファイアウォールによって保護されます。
クラスターネットワークがトラフィック負荷を処理できない場合は、仮想マシンアクセスにセカンダリーネットワークを使用することを検討してください。
7.5.4.1. サービスについて リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes サービスは一連の Pod で実行されているアプリケーションへのクライアントのネットワークアクセスを公開します。サービスは抽象化、負荷分散を提供し、タイプ NodePort と LoadBalancer の場合は外部世界への露出を提供します。
- ClusterIP
-
内部 IP アドレスでサービスを公開し、クラスター内の他のアプリケーションに DNS 名として公開します。1 つのサービスを複数の仮想マシンにマッピングできます。クライアントがサービスに接続しようとすると、クライアントのリクエストは使用可能なバックエンド間で負荷分散されます。
ClusterIPはデフォルトのサービスタイプです。 - NodePort
-
クラスター内の選択した各ノードの同じポートでサービスを公開します。
NodePortは、ノード自体がクライアントから外部にアクセスできる限り、クラスターの外部からポートにアクセスできるようにします。 - LoadBalancer
- 現在のクラウドに外部ロードバランサーを作成し (サポートされている場合)、固定の外部 IP アドレスをサービスに割り当てます。
オンプレミスクラスターの場合、MetalLB Operator をデプロイすることで負荷分散サービスを設定できます。
7.5.4.2. サービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソール、virtctl コマンドラインツール、または YAML ファイルを使用して、仮想マシン (VM) を公開するサービスを作成できます。
7.5.4.2.1. Web コンソールを使用したロードバランサーサービスの作成の有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシン (VM) のロードバランサーサービスの作成を有効にすることができます。
前提条件
- クラスターのロードバランサーが設定されました。
-
cluster-adminロールを持つユーザーとしてログインしている。 - ネットワークの Network Attachment Definition を作成している。
手順
- Virtualization → Overview に移動します。
- Settings タブで、Cluster をクリックします。
- Expand General settings と SSH configuration を展開します。
- SSH over LoadBalancer service をオンに設定します。
7.5.4.2.2. Web コンソールを使用したサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシンのノードポートまたはロードバランサーサービスを作成できます。
前提条件
- ロードバランサーまたはノードポートをサポートするようにクラスターネットワークが設定されている。
- ロードバランサーサービスを作成するためにロードバランサーサービスの作成が有効化されている。
手順
- VirtualMachines に移動し、仮想マシンを選択して、VirtualMachine details ページを表示します。
- Details タブで、SSH service type リストから SSH over LoadBalancer を選択します。
-
オプション: コピーアイコンをクリックして、
SSHコマンドをクリップボードにコピーします。
検証
- Details タブの Services ペインをチェックして、新しいサービスを表示します。
7.5.4.2.3. virtctl を使用したサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
virtctl コマンドラインツールを使用して、仮想マシン (VM) のサービスを作成できます。
前提条件
-
virtctlコマンドラインツールがインストールされている。 - サービスをサポートするようにクラスターネットワークを設定しました。
-
virtctlをインストールした環境には、仮想マシンにアクセスするために必要なクラスター権限があります。たとえば、oc loginを実行するか、KUBECONFIG環境変数を設定します。
手順
次のコマンドを実行してサービスを作成します。
virtctl expose vm <vm_name> --name <service_name> --type <service_type> --port <port>
$ virtctl expose vm <vm_name> --name <service_name> --type <service_type> --port <port>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterIP、NodePort、またはLoadBalancerサービスタイプを指定します。
例
virtctl expose vm example-vm --name example-service --type NodePort --port 22
$ virtctl expose vm example-vm --name example-service --type NodePort --port 22Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを実行してサービスを確認します。
oc get service
$ oc get serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
virtctl を使用してサービスを作成した後、VirtualMachine マニフェストの spec.template.metadata.labels スタンザに special: key を追加する必要があります。コマンドラインを使用したサービスの作成 を参照してください。
7.5.4.2.4. コマンドラインを使用したサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して、サービスを作成し、それを仮想マシンに関連付けることができます。
前提条件
- サービスをサポートするようにクラスターネットワークを設定しました。
手順
VirtualMachineマニフェストを編集して、サービス作成のラベルを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
special: keyをspec.template.metadata.labelsスタンザに追加します。
注記仮想マシンのラベルは Pod に渡されます。
special: keyラベルは、Serviceマニフェストのspec.selector属性のラベルと一致する必要があります。-
VirtualMachineマニフェストファイルを保存して変更を適用します。 仮想マシンを公開するための
Serviceマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Serviceマニフェストファイルを保存します。 以下のコマンドを実行してサービスを作成します。
oc create -f example-service.yaml
$ oc create -f example-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 仮想マシンを再起動して変更を適用します。
検証
Serviceオブジェクトをクエリーし、これが利用可能であることを確認します。oc get service -n example-namespace
$ oc get service -n example-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.4.3. SSH を使用してサービスによって公開される仮想マシンに接続する リンクのコピーリンクがクリップボードにコピーされました!
SSH を使用して、サービスによって公開されている仮想マシンに接続できます。
前提条件
- 仮想マシンを公開するサービスを作成しました。
- SSH クライアントがインストールされている。
- クラスターにログインしている。
手順
次のコマンドを実行して仮想マシンにアクセスします。
ssh <user_name>@<ip_address> -p <port>
$ ssh <user_name>@<ip_address> -p <port>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター IP サービスの場合はクラスター IP、ノードポートサービスの場合はノード IP、またはロードバランサーサービスの場合は外部 IP アドレスを指定します。
7.5.5. SSH アクセスにセカンダリーネットワークを使用する リンクのコピーリンクがクリップボードにコピーされました!
SSH を使用して、セカンダリーネットワークを設定し、仮想マシンをセカンダリーネットワークインターフェイスに接続し、DHCP によって割り当てられた IP アドレスに接続できます。
セカンダリーネットワークは、トラフィックがクラスターネットワークスタックによって処理されないため、優れたパフォーマンスを提供します。ただし、仮想マシンはセカンダリーネットワークに直接公開されており、ファイアウォールによって保護されません。仮想マシンが侵害されると、侵入者がセカンダリーネットワークにアクセスする可能性があります。この方法を使用する場合は、仮想マシンのオペレーティングシステム内で適切なセキュリティーを設定する必要があります。
ネットワークオプションの詳細は OpenShift Virtualization Tuning & Scaling Guide の Multus および SR-IOV ドキュメントを参照してください。
前提条件
- Linux ブリッジ や SR-IOV などのセカンダリーネットワークを設定しました。
-
Linux ブリッジネットワーク のネットワークアタッチメント定義を作成したか、
SriovNetworkオブジェクトの作成時に SR-IOV ネットワークオペレータが ネットワークアタッチメント定義 を作成しました。
7.5.5.1. Web コンソールを使用した仮想マシンネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシンのネットワークインターフェイスを設定できます。
前提条件
- ネットワークの Network Attachment Definition を作成している。
手順
- Virtualization → VirtualMachines に移動します。
- 仮想マシンをクリックして、VirtualMachine details ページを表示します。
- Configuration タブで、Network interfaces タブをクリックします。
- Add network interface をクリックします。
- インターフェイス名を入力し、Network リストから Network Attachment Definition を選択します。
- Save をクリックします。
- 仮想マシンを再起動またはライブマイグレーションして、変更を適用します。
7.5.5.2. SSH を使用したセカンダリーネットワークに接続された仮想マシンへの接続 リンクのコピーリンクがクリップボードにコピーされました!
SSH を使用して、セカンダリーネットワークに接続されている仮想マシンに接続できます。
前提条件
- DHCP サーバーを使用して仮想マシンをセカンダリーネットワークに接続しました。
- SSH クライアントがインストールされている。
手順
次のコマンドを実行して、仮想マシンの IP アドレスを取得します。
oc describe vm <vm_name> -n <namespace>
$ oc describe vm <vm_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、仮想マシンに接続します。
ssh <user_name>@<ip_address> -i <ssh_key>
$ ssh <user_name>@<ip_address> -i <ssh_key>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例
ssh cloud-user@10.244.0.37 -i ~/.ssh/id_rsa_cloud-user
$ ssh cloud-user@10.244.0.37 -i ~/.ssh/id_rsa_cloud-userCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.6. 仮想マシンの編集 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシン設定を更新できます。YAML ファイルまたは VirtualMachine details ページを更新できます。
コマンドラインを使用して仮想マシンを編集することもできます。
仮想マシンを編集して仮想ディスクまたは LUN を用いたディスク共有を設定する場合は、仮想マシンの共有ボリュームの設定 を参照してください。
6190-6220
7.6.1. 仮想マシン上でのメモリーのホットプラグ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシンを再起動することなく、仮想マシンに割り当てられたメモリーの量を追加または削除できます。
手順
- Virtualization → VirtualMachines に移動します。
- 目的の仮想マシンを選択して、VirtualMachine details ページを開きます。
- Configuration タブで、Edit CPU|Memory をクリックします。
- 必要なメモリー量を入力し、Save をクリックします。
システムはこれらの変更をすぐに適用します。仮想マシンが移行可能な場合は、ライブマイグレーションがトリガーされます。そうでない場合、または変更をライブ更新できない場合は、RestartRequired 条件が仮想マシンに追加されます。
-
仮想マシンのメモリーのホットプラグを実行するには、
virtio-memドライバーに対するゲストオペレーティングシステムのサポートが必要です。このサポートは、特定のアップストリームのカーネルバージョンではなく、ゲストオペレーティングシステム内に含まれる有効なドライバーに依存します。
サポートされているゲストオペレーティングシステム:
- RHEL 9.4 以降
- RHEL 8.10 以降 (ホットアンプラグはデフォルトで無効)
-
その他の Linux ゲストには、カーネルバージョン 5.16 以降と
virtio-memカーネルモジュールが必要です。 -
Windows ゲストには、
virtio-memドライバーバージョン 100.95.104.26200 以降が必要です。
7.6.2. コマンドラインを使用した仮想マシンの編集 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して仮想マシンを編集できます。
前提条件
-
ocCLI がインストールされている。
手順
次のコマンドを実行して、仮想マシンの設定を取得します。
oc edit vm <vm_name>
$ oc edit vm <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - YAML 設定を編集します。
実行中の仮想マシンを編集する場合は、以下のいずれかを実行する必要があります。
- 仮想マシンを再起動します。
新規の設定を有効にするために、以下のコマンドを実行します。
oc apply vm <vm_name> -n <namespace>
$ oc apply vm <vm_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.6.3. 仮想マシンへのディスクの追加 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想ディスクを仮想マシンに追加できます。
手順
- Web コンソールで Virtualization → VirtualMachines に移動します。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Disks タブで、Add disk をクリックします。
Source、Name、Size、Type、Interface、および Storage Class を指定します。
- オプション: 空のディスクソースを使用し、データボリュームの作成時に最大の書き込みパフォーマンスが必要な場合に、事前割り当てを有効にできます。そのためには、Enable preallocation チェックボックスをオンにします。
-
オプション: Apply optimized StorageProfile settings をクリアして、仮想ディスクの Volume Mode と Access Mode を変更できます。これらのパラメーターを指定しない場合、システムは
kubevirt-storage-class-defaultsconfig map のデフォルト値を使用します。
- Add をクリックします。
仮想マシンが実行中の場合は、仮想マシンを再起動して変更を適用する必要があります。
7.6.3.1. ストレージフィールド リンクのコピーリンクがクリップボードにコピーされました!
| フィールド | 説明 |
|---|---|
| 空白 (PVC の作成) | 空のディスクを作成します。 |
| URL を使用したインポート (PVC の作成) | URL (HTTP または HTTPS エンドポイント) を介してコンテンツをインポートします。 |
| 既存 PVC の使用 | クラスターですでに利用可能な PVC を使用します。 |
| 既存の PVC のクローン作成 (PVC の作成) | クラスターで利用可能な既存の PVC を選択し、このクローンを作成します。 |
| レジストリーを使用したインポート (PVC の作成) | コンテナーレジストリーを使用してコンテンツをインポートします。 |
| コンテナー (一時的) | クラスターからアクセスできるレジストリーにあるコンテナーからコンテンツをアップロードします。コンテナーディスクは、CD-ROM や一時的な仮想マシンなどの読み取り専用ファイルシステムにのみ使用する必要があります。 |
| Name |
ディスクの名前。この名前には、小文字 ( |
| Size | ディスクのサイズ (GiB 単位)。 |
| 型 | ディスクのタイプ。例: Disk または CD-ROM |
| Interface | ディスクデバイスのタイプ。サポートされるインターフェイスは、virtIO、SATA、および SCSI です。 |
| Storage Class | ディスクの作成に使用されるストレージクラス。 |
ストレージの詳細設定
以下のストレージの詳細設定はオプションであり、Blank、Import via URL、および Clone existing PVC ディスクで利用できます。
これらのパラメーターを指定しない場合、システムはデフォルトのストレージプロファイル値を使用します。
| パラメーター | オプション | パラメーターの説明 |
|---|---|---|
| ボリュームモード | Filesystem | ファイルシステムベースのボリュームで仮想ディスクを保存します。 |
| Block |
ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 | |
| アクセスモード | ReadWriteOnce (RWO) | ボリュームはシングルノードで読み取り/書き込みとしてマウントできます。 |
| ReadWriteMany (RWX) | ボリュームは、一度に多くのノードで読み取り/書き込みとしてマウントできます。 注記 このモードはライブマイグレーションに必要です。 |
7.6.4. 仮想マシンに Windows ドライバーディスクをマウントする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、Windows ドライバーディスクを仮想マシン (VM) にマウントできます。
手順
- Virtualization → VirtualMachines に移動します。
- 目的の仮想マシンを選択して、VirtualMachine details ページを開きます。
- Configuration タブで、Storage をクリックします。
Mount Windows drivers disk チェックボックスを選択します。
マウント済みディスクのリストに、Windows ドライバーディスクが表示されます。
7.6.5. シークレット、設定マップ、またはサービスアカウントの仮想マシンへの追加 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、シークレット、設定マップ、またはサービスアカウントを仮想マシンに追加します。
これらのリソースは、ディスクとして仮想マシンに追加されます。他のディスクをマウントするように、シークレット、設定マップ、またはサービスアカウントをマウントします。
仮想マシンが実行中の場合、仮想マシンを再起動するまで、変更は有効になりません。新しく追加されたリソースは、ページの上部で保留中の変更としてマークされます。
前提条件
- 追加するシークレット、設定マップ、またはサービスアカウントは、ターゲット仮想マシンと同じ namespace に存在する必要がある。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Configuration → Environment をクリックします。
- Add Config Map, Secret or Service Account をクリックします。
- Select a resource をクリックし、リストから resource を選択します。6 文字のシリアル番号が、選択したリソースに対して自動的に生成されます。
- オプション: Reload をクリックして、環境を最後に保存した状態に戻します。
- Save をクリックします。
検証
- VirtualMachine details ページで、Configuration → Disks をクリックし、リソースがディスクのリストに表示されていることを確認します。
- Actions → Restart をクリックして、仮想マシンを再起動します。
他のディスクをマウントするように、シークレット、設定マップ、またはサービスアカウントをマウントできるようになりました。
config map、シークレット、サービスアカウントの追加リソース
7.7. ブート順序の編集 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールまたは CLI を使用して、ブート順序リストの値を更新できます。
Virtual Machine Overview ページの Boot Order で、以下を実行できます。
- ディスクまたはネットワークインターフェイスコントローラー (NIC) を選択し、これをブート順序のリストに追加します。
- ブート順序の一覧でディスクまたは NIC の順序を編集します。
- ブート順序のリストからディスクまたは NIC を削除して、起動可能なソースのインベントリーに戻します。
7.7.1. Web コンソールでのブート順序リストへの項目の追加 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、ブート順序リストに項目を追加します。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Details タブをクリックします。
- Boot Order の右側にある鉛筆アイコンをクリックします。YAML 設定が存在しない場合や、これがブート順序リストの初回作成時の場合、以下のメッセージが表示されます。No resource selected.仮想マシンは、YAML ファイルでの出現順にディスクからの起動を試行します。
- Add Source をクリックして、仮想マシンのブート可能なディスクまたはネットワークインターフェイスコントローラー (NIC) を選択します。
- 追加のディスクまたは NIC をブート順序一覧に追加します。
- Save をクリックします。
仮想マシンが実行されている場合、Boot Order への変更は仮想マシンを再起動するまで反映されません。
Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更のリストが表示されます。
7.7.2. Web コンソールでのブート順序リストの編集 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールで起動順序リストを編集します。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Details タブをクリックします。
- Boot Order の右側にある鉛筆アイコンをクリックします。
ブート順序リストで項目を移動するのに適した方法を選択します。
- スクリーンリーダーを使用しない場合、移動する項目の横にある矢印アイコンにカーソルを合わせ、項目を上下にドラッグし、選択した場所にドロップします。
- スクリーンリーダーを使用する場合は、上矢印キーまたは下矢印を押して、ブート順序リストで項目を移動します。次に Tab キーを押して、選択した場所に項目をドロップします。
- Save をクリックします。
仮想マシンが実行されている場合、ブート順序の変更は仮想マシンが再起動されるまで反映されません。
Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更のリストが表示されます。
7.7.3. YAML 設定ファイルでのブート順序リストの編集 リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して、YAML 設定ファイルのブート順序のリストを編集します。
手順
以下のコマンドを実行して、仮想マシンの YAML 設定ファイルを開きます。
oc edit vm <vm_name> -n <namespace>
$ oc edit vm <vm_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルを編集し、ディスクまたはネットワークインターフェイスコントローラー (NIC) に関連付けられたブート順序の値を変更します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - YAML ファイルを保存します。
7.7.4. Web コンソールでのブート順序リストからの項目の削除 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、ブート順序のリストから項目を削除します。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Details タブをクリックします。
- Boot Order の右側にある鉛筆アイコンをクリックします。
-
項目の横にある Remove アイコン
をクリックします。この項目はブート順序のリストから削除され、使用可能なブートソースのリストに保存されます。ブート順序リストからすべての項目を削除する場合、以下のメッセージが表示されます。No resource selected.仮想マシンは、YAML ファイルでの出現順にディスクからの起動を試行します。
仮想マシンが実行されている場合、Boot Order への変更は仮想マシンを再起動するまで反映されません。
Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更のリストが表示されます。
7.8. 仮想マシンの削除 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールまたは oc コマンドラインインターフェイスを使用して、仮想マシンを削除できます。
7.8.1. Web コンソールの使用による仮想マシンの削除 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンを削除すると、仮想マシンはクラスターから永続的に削除されます。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
仮想マシンの横にある Options メニュー
をクリックし、Delete を選択します。
または、仮想マシン名をクリックして VirtualMachine details ページを開き、Actions → Delete をクリックします。
- オプション: With grace period を選択するか、Delete disks をクリアします。
- Delete をクリックして、仮想マシンを完全に削除します。
7.8.2. CLI の使用による仮想マシンの削除 リンクのコピーリンクがクリップボードにコピーされました!
oc コマンドラインインターフェイス (CLI) を使用して仮想マシンを削除できます。oc クライアントを使用すると、複数の仮想マシンでアクションを実行できます。
前提条件
- 削除する仮想マシンの名前を特定している。
手順
以下のコマンドを実行し、仮想マシンを削除します。
oc delete vm <vm_name>
$ oc delete vm <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記このコマンドは、現在のプロジェクト内の VM のみを削除します。削除する仮想マシンが別のプロジェクトまたは namespace にある場合は、
-n <project_name>オプションを指定します。
7.9. 仮想マシンのエクスポート リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンを別のクラスターにインポートしたり、フォレンジック目的でボリュームを分析したりするために、仮想マシン (VM) とそれに関連付けられたディスクをエクスポートできます。
コマンドラインインターフェイスを使用して、VirtualMachineExport カスタムリソース (CR) を作成します。
または、virtctl vmexport コマンド を使用して VirtualMachineExport CR を作成し、エクスポートされたボリュームをダウンロードすることもできます。
Migration Toolkit for Virtualization を使用して、OpenShift Virtualization クラスター間で仮想マシンを移行できます。
7.9.1. VirtualMachineExport カスタムリソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
VirtualMachineExport カスタムリソース (CR) を作成して、次のオブジェクトをエクスポートできます。
- 仮想マシン (VM): 指定された仮想マシンの永続ボリューム要求 (PVC) をエクスポートします。
-
VM スナップショット:
VirtualMachineSnapshotCR に含まれる PVC をエクスポートします。 -
PVC: PVC をエクスポートします。PVC が
virt-launcherPod などの別の Pod で使用されている場合、エクスポートは PVC が使用されなくなるまでPending状態のままになります。
VirtualMachineExport CR は、エクスポートされたボリュームの内部および外部リンクを作成します。内部リンクはクラスター内で有効です。外部リンクには、Ingress または Route を使用してアクセスできます。
エクスポートサーバーは、次のファイル形式をサポートしています。
-
raw: raw ディスクイメージファイル。 -
gzip: 圧縮されたディスクイメージファイル。 -
dir: PVC ディレクトリーとファイル。 -
tar.gz: 圧縮された PVC ファイル。
前提条件
- 仮想マシンをエクスポートするために、仮想マシンがシャットダウンされている。
手順
次の例に従って
VirtualMachineExportマニフェストを作成し、VirtualMachine、VirtualMachineSnapshot、またはPersistentVolumeClaimCR からボリュームをエクスポートし、example-export.yamlとして保存します。VirtualMachineExportの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow VirtualMachineExportCR を作成します。oc create -f example-export.yaml
$ oc create -f example-export.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow VirtualMachineExportCR を取得します。oc get vmexport example-export -o yaml
$ oc get vmexport example-export -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow エクスポートされたボリュームの内部および外部リンクは、
statusスタンザに表示されます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.9.2. エクスポートされた仮想マシンマニフェストへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) またはスナップショットをエクスポートすると、エクスポートサーバーから VirtualMachine マニフェストと関連情報を取得できます。
前提条件
VirtualMachineExportカスタムリソース (CR) を作成して、仮想マシンまたは VM スナップショットをエクスポートしている。注記spec.source.kind: PersistentVolumeClaimパラメーターを持つVirtualMachineExportオブジェクトは、仮想マシンマニフェストを生成しません。
手順
マニフェストにアクセスするには、まず証明書をソースクラスターからターゲットクラスターにコピーする必要があります。
- ソースクラスターにログインします。
次のコマンドを実行して、証明書を
cacert.crtファイルに保存します。oc get vmexport <export_name> -o jsonpath={.status.links.external.cert} > cacert.crt$ oc get vmexport <export_name> -o jsonpath={.status.links.external.cert} > cacert.crt1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<export_name>を、VirtualMachineExportオブジェクトのmetadata.name値に置き換えます。
-
cacert.crtファイルをターゲットクラスターにコピーします。
次のコマンドを実行して、ソースクラスター内のトークンをデコードし、
token_decodeファイルに保存します。oc get secret export-token-<export_name> -o jsonpath={.data.token} | base64 --decode > token_decode$ oc get secret export-token-<export_name> -o jsonpath={.data.token} | base64 --decode > token_decode1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<export_name>を、VirtualMachineExportオブジェクトのmetadata.name値に置き換えます。
-
token_decodeファイルをターゲットクラスターにコピーします。 次のコマンドを実行して、
VirtualMachineExportカスタムリソースを取得します。oc get vmexport <export_name> -o yaml
$ oc get vmexport <export_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow status.linksスタンザを確認します。このスタンザはexternalセクションとinternalセクションに分かれています。各セクション内のmanifests.urlフィールドに注意してください。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
VirtualMachineマニフェスト、存在する場合はDataVolumeマニフェスト、外部 URL の Ingress またはルートの公開証明書を含むConfigMapマニフェストが含まれます。- 2
- Containerized Data Importer (CDI) と互換性のあるヘッダーを含むシークレットが含まれます。ヘッダーには、エクスポートトークンのテキストバージョンが含まれています。
- 3
VirtualMachineマニフェスト、存在する場合はDataVolumeマニフェスト、および内部 URL のエクスポートサーバーの証明書を含むConfigMapマニフェストが含まれます。
- ターゲットクラスターにログインします。
次のコマンドを実行して
Secretマニフェストを取得します。curl --cacert cacert.crt <secret_manifest_url> -H \ "x-kubevirt-export-token:token_decode" -H \ "Accept:application/yaml"
$ curl --cacert cacert.crt <secret_manifest_url> -H \1 "x-kubevirt-export-token:token_decode" -H \2 "Accept:application/yaml"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
curl --cacert cacert.crt https://vmexport-proxy.test.net/api/export.kubevirt.io/v1alpha1/namespaces/example/virtualmachineexports/example-export/external/manifests/secret -H "x-kubevirt-export-token:token_decode" -H "Accept:application/yaml"
$ curl --cacert cacert.crt https://vmexport-proxy.test.net/api/export.kubevirt.io/v1alpha1/namespaces/example/virtualmachineexports/example-export/external/manifests/secret -H "x-kubevirt-export-token:token_decode" -H "Accept:application/yaml"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ConfigMapマニフェストやVirtualMachineマニフェストなどのtype: allマニフェストを取得します。curl --cacert cacert.crt <all_manifest_url> -H \ "x-kubevirt-export-token:token_decode" -H \ "Accept:application/yaml"
$ curl --cacert cacert.crt <all_manifest_url> -H \1 "x-kubevirt-export-token:token_decode" -H \2 "Accept:application/yaml"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
curl --cacert cacert.crt https://vmexport-proxy.test.net/api/export.kubevirt.io/v1alpha1/namespaces/example/virtualmachineexports/example-export/external/manifests/all -H "x-kubevirt-export-token:token_decode" -H "Accept:application/yaml"
$ curl --cacert cacert.crt https://vmexport-proxy.test.net/api/export.kubevirt.io/v1alpha1/namespaces/example/virtualmachineexports/example-export/external/manifests/all -H "x-kubevirt-export-token:token_decode" -H "Accept:application/yaml"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
-
エクスポートしたマニフェストを使用して、ターゲットクラスター上に
ConfigMapオブジェクトとVirtualMachineオブジェクトを作成できます。
7.10. 仮想マシンインスタンスの管理 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization 環境の外部で独立して作成されたスタンドアロン仮想マシンインスタンス (VMI) がある場合、Web コンソールを使用するか、コマンドラインインターフェイス (CLI) から oc または virtctl コマンドを使用してそれらを管理できます。
virtctl コマンドは、oc コマンドよりも多くの仮想化オプションを提供します。たとえば、virtctl を使用して仮想マシンを一時停止したり、ポートを公開したりできます。
7.10.1. 仮想マシンインスタンスについて リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンインスタンス (VMI) は、実行中の仮想マシンを表します。VMI が仮想マシンまたは別のオブジェクトによって所有されている場合、Web コンソールで、または oc コマンドラインインターフェイス (CLI) を使用し、所有者を通してこれを管理します。
スタンドアロンの VMI は、自動化または CLI で他の方法により、スクリプトを使用して独立して作成され、起動します。お使いの環境では、OpenShift Virtualization 環境外で開発され、起動されたスタンドアロンの VMI が存在する可能性があります。CLI を使用すると、引き続きそれらのスタンドアロン VMI を管理できます。スタンドアロン VMI に関連付けられた特定のタスクに Web コンソールを使用することもできます。
- スタンドアロン VMI とそれらの詳細をリスト表示します。
- スタンドアロン VMI のラベルとアノテーションを編集します。
- スタンドアロン VMI を削除します。
仮想マシンを削除する際に、関連付けられた VMI は自動的に削除されます。仮想マシンまたは他のオブジェクトによって所有されていないため、スタンドアロン VMI を直接削除します。
OpenShift Virtualization をアンインストールする前に、CLI または Web コンソールを使用してスタンドアロンの VMI のリストを表示します。次に、未処理の VMI を削除します。
仮想マシンを編集すると、一部の設定が再起動なしで VMI に動的に適用される場合があります。VMI に動的に適用できない仮想マシンオブジェクトを変更すると、RestartRequired 仮想マシン条件がトリガーされます。変更は次回の再起動時に有効になり、条件は削除されます。
7.10.2. CLI を使用した仮想マシンインスタンスのリスト表示 リンクのコピーリンクがクリップボードにコピーされました!
oc コマンドラインインターフェイス (CLI) を使用して、スタンドアロンおよび仮想マシンによって所有されている VMI を含むすべての仮想マシンのリストを表示できます。
手順
以下のコマンドを実行して、すべての VMI のリストを表示します。
oc get vmis -A
$ oc get vmis -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.10.3. Web コンソールを使用したスタンドアロン仮想マシンインスタンスのリスト表示 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、仮想マシンによって所有されていないクラスター内のスタンドアロンの仮想マシンインスタンス (VMI) のリストを表示できます。
仮想マシンまたは他のオブジェクトが所有する VMI は、Web コンソールには表示されません。Web コンソールは、スタンドアロンの VMI のみを表示します。クラスター内のすべての VMI をリスト表示するには、CLI を使用する必要があります。
手順
サイドメニューから Virtualization → VirtualMachines をクリックします。
スタンドアロン VMI は、名前の横にある濃い色のバッジで識別できます。
7.10.4. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの編集 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、スタンドアロン仮想マシンインスタンスのアノテーションおよびラベルを編集できます。他のフィールドは編集できません。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- スタンドアロン VMI を選択して、VirtualMachineInstance details ページを開きます。
- Details タブで、Annotations または Labels の横にある鉛筆アイコンをクリックします。
- 関連する変更を加え、Save をクリックします。
7.10.5. CLI を使用したスタンドアロン仮想マシンインスタンスの削除 リンクのコピーリンクがクリップボードにコピーされました!
oc コマンドラインインターフェイス (CLI) を使用してスタンドアロン仮想マシンインスタンス (VMI) を削除できます。
前提条件
- 削除する必要のある VMI の名前を特定している。
手順
以下のコマンドを実行して VMI を削除します。
oc delete vmi <vmi_name>
$ oc delete vmi <vmi_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.10.6. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの削除 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールからスタンドアロン仮想マシンインスタンス (VMI) を削除します。
手順
- OpenShift Container Platform Web コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- Actions → Delete VirtualMachineInstance をクリックします。
- 確認のポップアップウィンドウで、Delete をクリックし、スタンドアロン VMI を永続的に削除します。
7.11. 仮想マシンの状態の制御 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールから仮想マシンを停止し、起動し、再起動し、一時停止を解除することができます。
virtctl を使用して仮想マシンの状態を管理し、CLI から他のアクションを実行できます。たとえば、virtctl を使用して仮想マシンを強制停止したり、ポートを公開したりできます。
7.11.1. 仮想マシンの起動 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールから仮想マシンを起動できます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 起動する仮想マシンが含まれる行を見つけます。
ユースケースに応じて適切なメニューに移動します。
このページに留まり、複数の仮想マシンに対して操作を実行するには、次の手順を実行します。
-
行の右端にある Options メニュー
をクリックして、Start VirtualMachine をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
- Actions → Start をクリックします。
URL ソースからプロビジョニングされる仮想マシンの初回起動時に、OpenShift Virtualization が URL エンドポイントからコンテナーをインポートする間、仮想マシンの状態は Importing になります。このプロセスは、イメージのサイズによって数分の時間がかかる可能性があります。
7.11.2. 仮想マシンの停止 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールから仮想マシンを停止できます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 停止する仮想マシンが含まれる行を見つけます。
ユースケースに応じて適切なメニューに移動します。
このページに留まり、複数の仮想マシンに対して操作を実行するには、次の手順を実行します。
-
行の右端にある Options メニュー
をクリックして、Stop VirtualMachine をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを停止する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
- Actions → Stop をクリックします。
7.11.3. 仮想マシンの再起動 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールから実行中の仮想マシンを再起動できます。
エラーを回避するには、ステータスが Importing の仮想マシンは再起動しないでください。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 再起動する仮想マシンが含まれる行を見つけます。
ユースケースに応じて適切なメニューに移動します。
このページに留まり、複数の仮想マシンに対して操作を実行するには、次の手順を実行します。
-
行の右端にある Options メニュー
をクリックして、Restart をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを再起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
- Actions → Restart をクリックします。
7.11.4. 仮想マシンの一時停止 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールから仮想マシンを一時停止できます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 一時停止する仮想マシンが含まれている行を見つけます。
ユースケースに応じて適切なメニューに移動します。
このページに留まり、複数の仮想マシンに対して操作を実行するには、次の手順を実行します。
-
行の右端にある Options メニュー
をクリックして、Pause VirtualMachine をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを一時停止する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
- Actions → Pause をクリックします。
7.11.5. 仮想マシンの一時停止の解除 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールから仮想マシンの一時停止を解除できます。
前提条件
- 1 つ以上の仮想マシンのステータスが Paused である必要がある。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 一時停止を解除する仮想マシンが含まれる行を見つけます。
ユースケースに応じて適切なメニューに移動します。
このページに留まり、複数の仮想マシンに対して操作を実行するには、次の手順を実行します。
-
行の右端にある Options メニュー
をクリックして、Unpause VirtualMachine をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンの一時停止を解除する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
- Actions → Unpause をクリックします。
7.12. 仮想 Trusted Platform Module デバイスの使用 リンクのコピーリンクがクリップボードにコピーされました!
VirtualMachine (VM) または VirtualMachineInstance (VMI) マニフェストを編集して、仮想 Trusted Platform Module (vTPM) デバイスを新規または既存の仮想マシンに追加します。
vTPM デバイスを持つ仮想マシン(VM)のクローン作成または作成はサポートされていません。vTPM デバイスを使用した VM のスナップショットの作成のサポートが OpenShift Virtualization 4.18 に追加されました。
7.12.1. vTPM デバイスについて リンクのコピーリンクがクリップボードにコピーされました!
仮想トラステッドプラットフォームモジュール (vTPM) デバイスは、物理トラステッドプラットフォームモジュール (TPM) ハードウェアチップのように機能します。
vTPM デバイスはどのオペレーティングシステムでも使用できますが、Windows 11 をインストールまたは起動するには TPM チップが必要です。vTPM デバイスを使用すると、Windows 11 イメージから作成された VM を物理 TPM チップなしで機能させることができます。
vTPM を有効にしないと、ノードに TPM デバイスがある場合でも、VM は TPM デバイスを認識しません。
また、vTPM デバイスは、物理ハードウェアを使用せずにシークレットを保存することで仮想マシンを保護します。OpenShift Virtualization は、仮想マシンの永続ボリューム要求 (PVC) を使用して、vTPM デバイス状態の永続化をサポートします。HyperConverged カスタムリソース (CR) で vmStateStorageClass 属性を設定することにより、PVC が使用するストレージクラスを指定する必要があります。
ストレージクラスは Filesystem タイプであり、ReadWriteMany (RWX) アクセスモードをサポートしている必要があります。
7.12.2. 仮想マシンへの vTPM デバイスの追加 リンクのコピーリンクがクリップボードにコピーされました!
仮想トラステッドプラットフォームモジュール (vTPM) デバイスを仮想マシン (VM) に追加すると、物理 TPM デバイスなしで Windows 11 イメージから作成された仮想マシンを実行できます。vTPM デバイスには、その仮想マシンのシークレットも保存されます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
ReadWriteMany(RWX) アクセスモードをサポートするFilesystemタイプのストレージクラスを使用するように永続ボリューム要求 (PVC) を設定しました。これは、仮想マシンの再起動後も vTPM デバイスデータを維持するために必要です。
手順
次のコマンドを実行して、仮想マシン設定を更新します。
oc edit vm <vm_name> -n <namespace>
$ oc edit vm <vm_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシン仕様を編集して vTPM デバイスを追加します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するには、エディターを保存し、終了します。
- オプション: 実行中の仮想マシンを編集している場合は、変更を有効にするためにこれを再起動する必要があります。
7.13. OpenShift Pipelines を使用した仮想マシンの管理 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Pipelines は、開発者が独自のコンテナーで CI/CD パイプラインの各ステップを設計および実行できるようにする、Kubernetes ネイティブの CI/CD フレームワークです。
OpenShift Pipelines タスクとサンプルパイプラインを使用すると、以下を実行できます。
- 仮想マシン (VM)、永続ボリューム要求 (PVC)、データボリューム、およびデータソースを作成および管理する。
- 仮想マシンでコマンドを実行する。
-
libguestfsツールを使用してディスクイメージを操作する。
タスクは タスクカタログ (ArtifactHub) にあります。
サンプルの Windows パイプラインは、パイプラインカタログ (ArtifactHub) にあります。
7.13.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
-
cluster-admin権限を使用して OpenShift Container Platform クラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。 - OpenShift Pipelines がインストールされている。
7.13.2. サポートされている仮想マシンタスク リンクのコピーリンクがクリップボードにコピーされました!
次の表に、サポートされているタスクを示します。
| タスク | 説明 |
|---|---|
|
|
提供されたマニフェストから、または |
|
| テンプレートからの仮想マシンの作成 |
|
| 仮想マシンテンプレートをコピーします。 |
|
| 仮想マシンテンプレートを変更します。 |
|
| データボリュームまたはデータソースを作成または削除します。 |
|
| 仮想マシンでスクリプトまたはコマンドを実行し、後で仮想マシンを停止または削除します。 |
|
|
|
|
|
|
|
| 仮想マシンインスタンスの特定のステータスを待機し、ステータスに基づいて失敗または成功します。 |
パイプラインでの仮想マシンの作成では、非推奨になったテンプレートベースのタスクではなく、ClusterInstanceType と ClusterPreference が使用されるようになりました。create-vm-from-template、copy-template、および modify-vm-template コマンドは引き続き使用できますが、デフォルトのパイプラインタスクでは使用されません。
7.13.3. Windows EFI インストーラーパイプライン リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールまたは CLI を使用して、Windows EFI installer pipeline を実行できます。
Windows EFI インストーラーパイプラインは、Windows インストールイメージ (ISO ファイル) から Windows 10、Windows 11、または Windows Server 2022 を新しいデータボリュームにインストールします。インストールプロセスの実行には、カスタムアンサーファイルが使用されます。
Windows EFI インストーラーパイプラインは、OpenShift Container Platform により事前定義された、Microsoft ISO ファイルに適した sysprep を含む config map ファイルを使用します。さまざまな Windows エディションに関連する ISO ファイルの場合は、システム固有の sysprep 定義を使用して新しい config map ファイルを作成することが必要になる場合があります。
7.13.3.1. Web コンソールを使用してサンプルパイプラインを実行する リンクのコピーリンクがクリップボードにコピーされました!
サンプルパイプラインは、Web コンソールの Pipelines メニューから実行できます。
手順
- サイドメニューの Pipelines → Pipelines をクリックします。
- パイプラインを選択して、Pipeline details ページを開きます。
- Actions リストから、Start を選択します。Start Pipeline ダイアログが表示されます。
- パラメーターのデフォルト値を保持し、Start をクリックしてパイプラインを実行します。Details タブでは、各タスクの進行状況が追跡され、パイプラインのステータスが表示されます。
7.13.3.2. CLI を使用してサンプルパイプラインを実行する リンクのコピーリンクがクリップボードにコピーされました!
PipelineRun リソースを使用して、サンプルパイプラインを実行します。PipelineRun オブジェクトは、パイプラインの実行中のインスタンスです。これは、クラスター上の特定の入力、出力、および実行パラメーターで実行されるパイプラインをインスタンス化します。また、パイプライン内のタスクごとに TaskRun オブジェクトを作成します。
手順
Microsoft Windows 11 インストーラーパイプラインを実行するには、次の
PipelineRunマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow PipelineRunマニフェストを適用します。oc apply -f windows11-customize-run.yaml
$ oc apply -f windows11-customize-run.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14. 高度な仮想マシン管理 リンクのコピーリンクがクリップボードにコピーされました!
7.14.1. 仮想マシンのリソースクォータの使用 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンのリソースクォータの作成および管理
7.14.1.1. 仮想マシンの自動リソースクォータ制限を有効にする リンクのコピーリンクがクリップボードにコピーされました!
AutoResourceLimits フィーチャーゲートを有効にすると、OpenShift Virtualization は仮想マシンの CPU とメモリーの制限を自動的に管理します。
デフォルトでは、OpenShift Virtualization は仮想マシンのリソース要求を計算します。AutoResourceLimits フィーチャーゲートを有効にすると、OpenShift Virtualization は namespace のクォータ要件を満たすためにリソース制限も計算します。
namespace で CPU とメモリーの両方のクォータが適用され、制限を設定する必要がある場合は、AutoResourceLimits フィーチャーゲートを有効にすることが推奨されます。この機能を有効にすると、メモリー制限は自動的に基本のメモリー割り当ての 2 倍に設定され、CPU 制限は仮想 CPU ごとに 1 つに設定されます。
alpha.kubevirt.io/auto-memory-limits-ratio ラベルを追加することで、特定の namespace のメモリー制限比率をカスタマイズできます。
たとえば、次のコマンドは、my-virtualization-project namespace の比率を 1.2 に設定します。
oc label ns/my-virtualization-project alpha.kubevirt.io/auto-memory-limits-ratio=1.2
$ oc label ns/my-virtualization-project alpha.kubevirt.io/auto-memory-limits-ratio=1.2
手順
仮想マシンの自動リソースクォータ制限を有効にするには、次の手順を実行します。
次のコマンドを実行して、
HyperConvergedカスタムリソース (CR) を編集します。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.featureGatesセクションで、autoResourceLimitsパラメーターを追加するか、trueに設定します。spec: featureGates: autoResourceLimits: truespec: featureGates: autoResourceLimits: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存し、エディターを終了します。
7.14.1.1.1. 仮想マシンのリソースクォータ制限を手動で設定する リンクのコピーリンクがクリップボードにコピーされました!
リクエストのみを使用するリソースクォータは、仮想マシン (VM) で自動的に機能します。リソースクォータで制限を使用する場合は、VM に手動でリソース制限を設定する必要があります。リソース limits は、リソース requests より少なくとも 100 MiB 大きくする必要があります。
リソースクォータ制限を手動で管理することは推奨されません。代わりに、前のセクションで説明したように、自動リソースクォータ制限の計算を有効にすることが推奨されます。制限を手動で設定すると、クォータの誤設定やスケジュールの問題が発生する可能性があります。
手順
VirtualMachineマニフェストを編集して、VM の制限を設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この設定がサポートされるのは、
limits.memory値がrequests.memory値より少なくとも100Mi大きいためです。
-
VirtualMachineマニフェストを保存します。
7.14.2. 仮想マシンのノードの指定 リンクのコピーリンクがクリップボードにコピーされました!
ノードの配置ルールを使用して、仮想マシン (VM) を特定のノードに配置することができます。
7.14.2.1. 仮想マシンのノード配置について リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) が適切なノードで実行されるようにするには、ノードの配置ルールを設定できます。以下の場合にこれを行うことができます。
- 仮想マシンが複数ある。フォールトトレランスを確保するために、これらを異なるノードで実行する必要がある。
- 2 つの相互間のネットワークトラフィックの多い chatty VM がある。冗長なノード間のルーティングを回避するには、仮想マシンを同じノードで実行します。
- 仮想マシンには、利用可能なすべてのノードにない特定のハードウェア機能が必要です。
- 機能をノードに追加する Pod があり、それらの機能を使用できるように仮想マシンをそのノードに配置する必要があります。
仮想マシンの配置は、ワークロードの既存のノードの配置ルールに基づきます。ワークロードがコンポーネントレベルの特定のノードから除外される場合、仮想マシンはそれらのノードに配置できません。
以下のルールタイプは、VirtualMachine マニフェストの spec フィールドで使用できます。
nodeSelector- このフィールドで指定したキーと値のペアでラベル付けされたノード上で仮想マシンをスケジュールできるようにします。ノードには、リスト表示されたすべてのペアに一致するラベルがなければなりません。
affinity-
より表現的な構文を使用して、ノードと仮想マシンに一致するルールを設定できます。たとえば、ルールがハード要件ではなく基本設定になるように指定し、ルールの条件が満たされない場合も仮想マシンがスケジュールされるようにすることができます。Pod のアフィニティー、Pod の非アフィニティー、およびノードのアフィニティーは仮想マシンの配置でサポートされます。Pod のアフィニティーは仮想マシンに対して動作します。
VirtualMachineワークロードタイプはPodオブジェクトに基づくためです。 tolerations一致する taint を持つノードに仮想マシンをスケジュールすることを許容します。ノードに taint が適用されると、そのノードはその taint を許容する仮想マシンのみを受け入れます。
注記アフィニティールールは、スケジューリング時にのみ適用されます。OpenShift Container Platform は、制約を満たさなくなった場合に実行中のワークロードを再スケジューリングしません。
7.14.2.2. ノード配置の例 リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML スニペットの例では、nodePlacement、affinity、および tolerations フィールドを使用して仮想マシンのノード配置をカスタマイズします。
7.14.2.2.1. 例: nodeSelector を使用した仮想マシンノードの配置 リンクのコピーリンクがクリップボードにコピーされました!
この例では、仮想マシンに example-key-1 = example-value-1 および example-key-2 = example-value-2 ラベルの両方が含まれるメタデータのあるノードが必要です。
この説明に該当するノードがない場合、仮想マシンはスケジュールされません。
仮想マシンマニフェストの例
7.14.2.2.2. 例: Pod のアフィニティーおよび Pod の非アフィニティーによる仮想マシンノードの配置 リンクのコピーリンクがクリップボードにコピーされました!
この例では、仮想マシンはラベル example-key-1 = example-value-1 を持つ実行中の Pod のあるノードでスケジュールされる必要があります。このようなノードで実行中の Pod がない場合、仮想マシンはスケジュールされません。
可能な場合に限り、仮想マシンはラベル example-key-2 = example-value-2 を持つ Pod のあるノードではスケジュールされません。ただし、すべての候補となるノードにこのラベルを持つ Pod がある場合、スケジューラーはこの制約を無視します。
仮想マシンマニフェストの例
7.14.2.2.3. 例: ノードのアフィニティーによる仮想マシンノードの配置 リンクのコピーリンクがクリップボードにコピーされました!
この例では、仮想マシンはラベル example.io/example-key = example-value-1 またはラベル example.io/example-key = example-value-2 を持つノードでスケジュールされる必要があります。この制約は、ラベルのいずれかがノードに存在する場合に満たされます。いずれのラベルも存在しない場合、仮想マシンはスケジュールされません。
可能な場合、スケジューラーはラベル example-node-label-key = example-node-label-value を持つノードを回避します。ただし、すべての候補となるノードにこのラベルがある場合、スケジューラーはこの制約を無視します。
仮想マシンマニフェストの例
7.14.2.2.4. 例: toleration を使用した仮想マシンノードの配置 リンクのコピーリンクがクリップボードにコピーされました!
この例では、仮想マシン用に予約されているノードに、すでに key=virtualization:NoSchedule taint のラベルが付けられています。この仮想マシンには一致する tolerations があるため、この仮想マシンを taint を持つノードにスケジュールできます。
taint を許容する仮想マシンを、その taint を持つノードにスケジュールする必要はありません。
仮想マシンマニフェストの例
7.14.3. kernel samepage merging (KSM) のアクティブ化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization は、ノードが過負荷になると kernel samepage merging (KSM) をアクティブ化できます。KSM は、仮想マシンのメモリーページにある同一データの重複を排除します。非常によく似た仮想マシンがある場合に KSM を使用すると、シングルノード上で多くの仮想マシンをスケジュールできるようになります。
KSM は、必ず信頼できるワークロードでのみ使用してください。
7.14.3.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Virtualization が KSM をアクティブ化するノード上で、管理者が KSM サポートを設定していることを確認する。
7.14.3.2. OpenShift Virtualization を使用して KSM をアクティブ化する リンクのコピーリンクがクリップボードにコピーされました!
ノードでメモリーの過負荷が発生した場合に kernel samepage merging (KSM) をアクティブ化するように、OpenShift Virtualization を設定できます。
7.14.3.2.1. 設定方法 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用するか、HyperConverged カスタムリソース (CR) を編集することで、すべてのノードの KSM アクティブ化機能を有効または無効にできます。HyperConverged CR は、より詳細な設定をサポートしています。
CR 設定
HyperConverged CR の spec.configuration.ksmConfiguration スタンザを編集することで、KSM アクティブ化機能を設定できます。
-
この機能を有効にして設定するには、
ksmConfigurationスタンザを編集します。 -
この機能を無効にするには、
ksmConfigurationスタンザを削除します。 -
ノード選択構文を
ksmConfiguration.nodeLabelSelectorフィールドに追加すると、OpenShift Virtualization はノードのサブセットのみで KSM を有効化できます。
管理者は、OpenShift Virtualization で KSM アクティブ化機能が無効になっている場合でも、それをサポートするノードでは KSM を有効化できます。
7.14.3.2.2. KSM ノードのラベル リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization は、KSM をサポートするように設定されたノードを識別し、次のノードラベルを適用します。
kubevirt.io/ksm-handler-managed: "false"-
メモリーの過負荷が発生しているノード上で OpenShift Virtualization が KSM をアクティブ化すると、このラベルが
"true"に設定されます。管理者が KSM をアクティブ化した場合、このラベルは"true"に設定されません。 kubevirt.io/ksm-enabled: "false"-
OpenShift Virtualization が KSM をアクティブ化しなかった場合でも、KSM がノード上でアクティブ化されると、このラベルは
"true"に設定されます。
このラベルは、KSM をサポートしていないノードには適用されません。
7.14.3.3. Web コンソールを使用して KSM のアクティブ化を設定する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、OpenShift Virtualization がクラスター内のすべてのノードで kernel samepage merging (KSM) をアクティブ化できるように設定できます。
手順
- サイドメニューから、Virtualization → Overview をクリックします。
- Settings タブを選択します。
- Cluster タブを選択します。
- Resource management を展開します。
すべてのノードの機能を有効または無効にします。
- Kernel Samepage Merging (KSM) をオンに設定します。
- Kernel Samepage Merging (KSM) をオフに設定します。
7.14.3.4. CLI を使用して KSM のアクティブ化を設定する リンクのコピーリンクがクリップボードにコピーされました!
HyperConverged カスタムリソース (CR) を編集することで、OpenShift Virtualization の kernel samepage merging (KSM) アクティブ化機能を有効または無効にできます。OpenShift Virtualization がノードのサブセットのみで KSM をアクティブ化するように設定する場合は、この方法を使用します。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow ksmConfigurationスタンザを編集します。すべてのノードで KSM アクティブ化機能を有効にするには、
nodeLabelSelectorの値を{}に設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードのサブセットで KSM アクティブ化機能を有効にするには、
nodeLabelSelectorフィールドを編集します。OpenShift Virtualization が KSM を有効にするノードに一致する構文を追加します。たとえば次の設定では、OpenShift Virtualization は<first_example_key>と<second_example_key>の両方が"true"に設定されているノードで KSM を有効にできます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow KSM アクティブ化機能を無効にするには、
ksmConfigurationスタンザを削除します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- ファイルを保存します。
7.14.4. 証明書ローテーションの設定 リンクのコピーリンクがクリップボードにコピーされました!
証明書ローテーションパラメーターを設定して、既存の証明書を置き換えます。
7.14.4.1. 証明書ローテーションの設定 リンクのコピーリンクがクリップボードにコピーされました!
これは、Web コンソールでの OpenShift Virtualization のインストール時に、または HyperConverged カスタムリソース (CR) でインストール後に実行することができます。
手順
以下のコマンドを実行して
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように
spec.certConfigフィールドを編集します。システムのオーバーロードを避けるには、すべての値が 10 分以上であることを確認します。golangParseDuration形式 に準拠する文字列として、すべての値を表現します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - YAML ファイルをクラスターに適用します。
7.14.4.2. 証明書ローテーションパラメーターのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
1 つ以上の certConfig 値を削除すると、デフォルト値が以下のいずれかの条件と競合する場合を除き、デフォルト値に戻ります。
-
ca.renewBeforeの値はca.durationの値以下である必要があります。 -
server.durationの値はca.durationの値以下である必要があります。 -
server.renewBeforeの値はserver.durationの値以下である必要があります。
デフォルト値がこれらの条件と競合すると、エラーが発生します。
以下の例で server.duration 値を削除すると、デフォルト値の 24h0m0s は ca.duration の値よりも大きくなり、指定された条件と競合します。
例
これにより、以下のエラーメッセージが表示されます。
error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission webhook "validate-hco.kubevirt.io" denied the request: spec.certConfig: ca.duration is smaller than server.duration
error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission webhook "validate-hco.kubevirt.io" denied the request: spec.certConfig: ca.duration is smaller than server.duration
エラーメッセージには、最初の競合のみが記載されます。続行する前に、すべての certConfig の値を確認します。
7.14.5. デフォルトの CPU モデルの設定 リンクのコピーリンクがクリップボードにコピーされました!
HyperConverged カスタムリソース (CR) の defaultCPUModel 設定を使用して、クラスター全体のデフォルト CPU モデルを定義します。
仮想マシン (VM) の CPU モデルは、仮想マシンおよびクラスター内の CPU モデルの可用性によって異なります。
仮想マシンに定義された CPU モデルがない場合:
-
defaultCPUModelは、クラスター全体のレベルで定義された CPU モデルを使用して自動的に設定されます。
-
仮想マシンとクラスターの両方に CPU モデルが定義されている場合:
- 仮想マシンの CPU モデルが優先されます。
仮想マシンにもクラスターにも CPU モデルが定義されていない場合:
- ホストモデルは、ホストレベルで定義された CPU モデルを使用して自動的に設定されます。
7.14.5.1. デフォルトの CPU モデルの設定 リンクのコピーリンクがクリップボードにコピーされました!
HyperConverged カスタムリソース (CR) を更新して、defaultCPUModel を設定します。OpenShift Virtualization の実行中に、defaultCPUModel を変更できます。
defaultCPUModel では、大文字と小文字が区別されます。
前提条件
- OpenShift CLI (oc) のインストール。
手順
以下のコマンドを実行して
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow CR に
defaultCPUModelフィールドを追加し、値をクラスター内に存在する CPU モデルの名前に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - YAML ファイルをクラスターに適用します。
7.14.6. 仮想マシンに UEFI モードを使用する リンクのコピーリンクがクリップボードにコピーされました!
Unified Extensible Firmware Interface (UEFI) モードで仮想マシン (VM) を起動できます。
7.14.6.1. 仮想マシンの UEFI モードについて リンクのコピーリンクがクリップボードにコピーされました!
レガシー BIOS などの Unified Extensible Firmware Interface (UEFI) は、コンピューターの起動時にハードウェアコンポーネントやオペレーティングシステムのイメージファイルを初期化します。UEFI は BIOS よりも最新の機能とカスタマイズオプションをサポートするため、起動時間を短縮できます。
これは、.efi 拡張子を持つファイルに初期化と起動に関する情報をすべて保存します。このファイルは、EFI System Partition (ESP) と呼ばれる特別なパーティションに保管されます。ESP には、コンピューターにインストールされるオペレーティングシステムのブートローダープログラムも含まれます。
7.14.6.2. UEFI モードでの仮想マシンの起動 リンクのコピーリンクがクリップボードにコピーされました!
VirtualMachine マニフェストを編集して、UEFI モードで起動するように仮想マシンを設定できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
VirtualMachineマニフェストファイルを編集または作成します。spec.firmware.bootloaderスタンザを使用して、UEFI モードを設定します。セキュアブートがアクティブな状態の UEFI モードでのブート
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、マニフェストをクラスターに適用します。
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.6.3. 永続的な EFI の有効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスターレベルで RWX ストレージクラスを設定し、仮想マシンの EFI セクションで設定を調整することで、仮想マシンで EFI 永続性を有効にできます。
前提条件
- クラスター管理者の権限がある。
- RWX アクセスモードと FS ボリュームモードをサポートするストレージクラスが必要です。
手順
次のコマンドを実行して、
VMPersistentStateフィーチャーゲートを有効にします。oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/featureGates/VMPersistentState", "value": true}]'$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/featureGates/VMPersistentState", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.6.4. 永続的な EFI を使用した仮想マシンの設定 リンクのコピーリンクがクリップボードにコピーされました!
マニフェストファイルを編集して、EFI の永続性を有効にするように仮想マシンを設定できます。
前提条件
-
VMPersistentStateフィーチャーゲートが有効になっている。
手順
仮想マシンマニフェストファイルを編集して保存し、設定を適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.7. 仮想マシンの PXE ブートの設定 リンクのコピーリンクがクリップボードにコピーされました!
PXE ブートまたはネットワークブートは OpenShift Virtualization で利用できます。ネットワークブートにより、ローカルに割り当てられたストレージデバイスなしにコンピューターを起動し、オペレーティングシステムまたは他のプログラムを起動し、ロードすることができます。たとえば、これにより、新規ホストのデプロイ時に PXE サーバーから必要な OS イメージを選択できます。
7.14.7.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- Linux ブリッジが 接続されている。
- PXE サーバーがブリッジとして同じ VLAN に接続されている。
7.14.7.2. MAC アドレスを指定した PXE ブート リンクのコピーリンクがクリップボードにコピーされました!
まず、管理者は PXE ネットワークの NetworkAttachmentDefinition オブジェクトを作成し、ネットワーク経由でクライアントを起動できます。次に、仮想マシンインスタンスの設定ファイルで Network Attachment Definition を参照して仮想マシンインスタンスを起動します。また PXE サーバーで必要な場合には、仮想マシンインスタンスの設定ファイルで MAC アドレスを指定することもできます。
前提条件
- Linux ブリッジが接続されている。
- PXE サーバーがブリッジとして同じ VLAN に接続されている。
手順
クラスターに PXE ネットワークを設定します。
PXE ネットワーク
pxe-net-confの Network Attachment Definition ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
NetworkAttachmentDefinitionオブジェクトの名前。- 2
- 設定の名前。設定名を Network Attachment Definition の
name値に一致させることが推奨されます。 - 3
- この Network Attachment Definition のネットワークを提供する Container Network Interface (CNI) プラグインの実際の名前。この例では、Linux bridge CNI プラグインを使用します。OVN-Kubernetes localnet または SR-IOV CNI プラグインを使用することもできます。
- 4
- ノードに設定される Linux ブリッジの名前。
- 5
- オプション: MAC スプーフィングチェックを有効にするフラグ。
trueに設定すると、Pod またはゲストインターフェイスの MAC アドレスを変更できません。この属性により、Pod から出ることができる MAC アドレスは 1 つだけになり、MAC スプーフィング攻撃に対するセキュリティーが確保されます。 - 6
- オプション: VLAN タグ。Node Network Configuration Policy では、追加の VLAN 設定は必要ありません。
- 7
- オプション: 仮想マシンがデフォルト VLAN 経由でブリッジに接続するかどうかを示します。デフォルト値は
trueです。
直前の手順で作成したファイルを使用して Network Attachment Definition を作成します。
oc create -f pxe-net-conf.yaml
$ oc create -f pxe-net-conf.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンインスタンス設定ファイルを、インターフェイスおよびネットワークの詳細を含めるように編集します。
PXE サーバーで必要な場合には、ネットワークおよび MAC アドレスを指定します。MAC アドレスが指定されていない場合、値は自動的に割り当てられます。
bootOrderが1に設定されており、インターフェイスが最初に起動することを確認します。この例では、インターフェイスは<pxe-net>というネットワークに接続されています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記複数のインターフェイスおよびディスクのブートの順序はグローバル順序になります。
オペレーティングシステムのプロビジョニング後に起動が適切に実行されるよう、ブートデバイス番号をディスクに割り当てます。
ディスク
bootOrderの値を2に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 直前に作成された Network Attachment Definition に接続されるネットワークを指定します。このシナリオでは、
<pxe-net>は<pxe-net-conf>という Network Attachment Definition に接続されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
仮想マシンインスタンスを作成します。
oc create -f vmi-pxe-boot.yaml
$ oc create -f vmi-pxe-boot.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created
virtualmachineinstance.kubevirt.io "vmi-pxe-boot" createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンインスタンスの実行を待機します。
oc get vmi vmi-pxe-boot -o yaml | grep -i phase phase: Running
$ oc get vmi vmi-pxe-boot -o yaml | grep -i phase phase: RunningCopy to Clipboard Copied! Toggle word wrap Toggle overflow VNC を使用して仮想マシンインスタンスを表示します。
virtctl vnc vmi-pxe-boot
$ virtctl vnc vmi-pxe-bootCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ブート画面で、PXE ブートが正常に実行されていることを確認します。
仮想マシンインスタンスにログインします。
virtctl console vmi-pxe-boot
$ virtctl console vmi-pxe-bootCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
仮想マシンのインターフェイスおよび MAC アドレスを確認し、ブリッジに接続されたインターフェイスに MAC アドレスが指定されていることを確認します。この場合、PXE ブートには IP アドレスなしに
eth1を使用しています。他のインターフェイスeth0は OpenShift Container Platform から IP アドレスを取得しています。ip addr
$ ip addrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
... 3. eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether de:00:00:00:00:de brd ff:ff:ff:ff:ff:ff
... 3. eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether de:00:00:00:00:de brd ff:ff:ff:ff:ff:ffCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.7.3. OpenShift Virtualization ネットワークの用語集 リンクのコピーリンクがクリップボードにコピーされました!
以下の用語は、OpenShift Virtualization ドキュメント全体で使用されています。
- Container Network Interface (CNI)
- コンテナーのネットワーク接続に重点を置く Cloud Native Computing Foundation プロジェクト。OpenShift Virtualization は CNI プラグインを使用して基本的な Kubernetes ネットワーク機能を強化します。
- Multus
- 複数の CNI の存在を可能にし、Pod または仮想マシンが必要なインターフェイスを使用できるようにする "メタ" CNI プラグイン。
- カスタムリソース定義 (CRD)
- カスタムリソースの定義を可能にする Kubernetes API リソース、または CRD API リソースを使用して定義されるオブジェクト。
- Network Attachment Definition (NAD)
- Multus プロジェクトによって導入された CRD。Pod、仮想マシン、および仮想マシンインスタンスを 1 つ以上のネットワークに接続できるようにします。
- ノードネットワーク設定ポリシー (NNCP)
-
nmstate プロジェクトによって導入された CRD。ノード上で要求されるネットワーク設定を表します。
NodeNetworkConfigurationPolicyマニフェストをクラスターに適用して、インターフェイスの追加および削除など、ノードネットワーク設定を更新します。
7.14.8. 仮想マシンでの Huge Page の使用 リンクのコピーリンクがクリップボードにコピーされました!
Huge Page は、クラスター内の仮想マシンのバッキングメモリーとして使用できます。
7.14.8.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
7.14.8.2. Huge Page の機能 リンクのコピーリンクがクリップボードにコピーされました!
メモリーは Page と呼ばれるブロックで管理されます。多くのシステムでは、1 ページは 4Ki です。メモリー 1Mi は 256 ページに、メモリー 1Gi は 256,000 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) は、仮想から物理へのページマッピングの小規模なハードウェアキャッシュのことです。ハードウェアの指示で渡された仮想アドレスが TLB にあれば、マッピングをすばやく決定できます。そうでない場合には、TLB ミスが発生し、システムは速度が遅く、ソフトウェアベースのアドレス変換にフォールバックされ、パフォーマンスの問題が発生します。TLB のサイズは固定されているので、TLB ミスの発生率を減らすには Page サイズを大きくする必要があります。
Huge Page とは、4Ki より大きいメモリーページのことです。x86_64 アーキテクチャーでは、2Mi と 1Gi の 2 つが一般的な Huge Page サイズです。別のアーキテクチャーではサイズは異なります。Huge Page を使用するには、アプリケーションが認識できるようにコードを書き込む必要があります。Transparent Huge Page (THP) は、アプリケーションによる認識なしに、Huge Page の管理を自動化しようとしますが、制約があります。特に、ページサイズは 2Mi に制限されます。THP では、THP のデフラグが原因で、メモリー使用率が高くなり、断片化が起こり、パフォーマンスの低下につながり、メモリーページがロックされてしまう可能性があります。このような理由から、アプリケーションは THP ではなく、事前割り当て済みの Huge Page を使用するように設計 (また推奨) される場合があります。
OpenShift Virtualization では、事前に割り当てられた Huge Page を使用できるように仮想マシンを設定できます。
7.14.8.3. 仮想マシンの Huge Page の設定 リンクのコピーリンクがクリップボードにコピーされました!
memory.hugepages.pageSize および resources.requests.memory パラメーターを仮想マシン設定に組み込み、仮想マシンを事前に割り当てられた Huge Page を使用するように設定できます。
メモリー要求はページサイズ別に分ける必要があります。たとえば、ページサイズ 1Gi の場合に 500Mi メモリーを要求することはできません。
ホストおよびゲスト OS のメモリーレイアウトには関連性がありません。仮想マシンマニフェストで要求される Huge Page が QEMU に適用されます。ゲスト内の Huge Page は、仮想マシンインスタンスの利用可能なメモリー量に基づいてのみ設定できます。
実行中の仮想マシンを編集する場合は、変更を有効にするために仮想マシンを再起動する必要があります。
前提条件
- ノードには、事前に割り当てられた Huge Page が設定されている必要がある。手順については、起動時の huge page の設定 を参照してください。
手順
仮想マシン設定で、
resources.requests.memoryおよびmemory.hugepages.pageSizeパラメーターをspec.domainに追加します。以下の設定スニペットは、ページサイズが1Giの合計4Giメモリーを要求する仮想マシンに関するものです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシン設定を適用します。
oc apply -f <virtual_machine>.yaml
$ oc apply -f <virtual_machine>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.9. 仮想マシン用の専用リソースの有効化 リンクのコピーリンクがクリップボードにコピーされました!
パフォーマンスを向上させるために、CPU などのノードリソースを仮想マシン専用に確保できます。
7.14.9.1. 専用リソースについて リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンの専用リソースを有効にする場合、仮想マシンのワークロードは他のプロセスで使用されない CPU でスケジュールされます。専用リソースを使用することで、仮想マシンのパフォーマンスとレイテンシーの予測の精度を向上させることができます。
7.14.9.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
-
CPU マネージャー がノードに設定されている。仮想マシンのワークロードをスケジュールする前に、ノードに
cpumanager = trueラベルが設定されていることを確認する。 - 仮想マシンの電源がオフになっている。
7.14.9.3. 仮想マシンの専用リソースの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Details タブで、仮想マシンの専用リソースを有効にすることができます。Red Hat テンプレートから作成された仮想マシンは、専用のリソースで設定できます。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Configuration → Scheduling タブで、Dedicated Resources の横にある編集アイコンをクリックします。
- Schedule this workload with dedicated resources (guaranteed policy) を選択します。
- Save をクリックします。
7.14.10. 仮想マシンのスケジュール リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンの CPU モデルとポリシー属性が、ノードがサポートする CPU モデルおよびポリシー属性との互換性に対して一致することを確認して、ノードで仮想マシン (VM) をスケジュールできます。
7.14.10.1. ポリシー属性 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) をスケジュールするには、ポリシー属性と、仮想マシンがノードでスケジュールされる際の互換性について一致する CPU 機能を指定します。仮想マシンに指定されるポリシー属性は、その仮想マシンをノードにスケジュールする方法を決定します。
| ポリシー属性 | 説明 |
|---|---|
| force | 仮想マシンは強制的にノードでスケジュールされます。これは、ホストの CPU が仮想マシンの CPU に対応していない場合でも該当します。 |
| require | 仮想マシンが特定の CPU モデルおよび機能仕様で設定されていない場合に仮想マシンに適用されるデフォルトのポリシー。このデフォルトポリシー属性または他のポリシー属性のいずれかを持つ CPU ノードの検出をサポートするようにノードが設定されていない場合、仮想マシンはそのノードでスケジュールされません。ホストの CPU が仮想マシンの CPU をサポートしているか、ハイパーバイザーが対応している CPU モデルをエミュレートできる必要があります。 |
| optional | 仮想マシンがホストの物理マシンの CPU でサポートされている場合は、仮想マシンがノードに追加されます。 |
| disable | 仮想マシンは CPU ノードの検出機能と共にスケジュールすることはできません。 |
| forbid | この機能がホストの CPU でサポートされ、CPU ノード検出が有効になっている場合でも、仮想マシンはスケジュールされません。 |
7.14.10.2. ポリシー属性および CPU 機能の設定 リンクのコピーリンクがクリップボードにコピーされました!
それぞれの仮想マシン (VM) にポリシー属性および CPU 機能を設定して、これがポリシーおよび機能に従ってノードでスケジュールされるようにすることができます。設定する CPU 機能は、ホストの CPU によってサポートされ、またはハイパーバイザーがエミュレートされることを確認するために検証されます。
7.14.10.3. サポートされている CPU モデルでの仮想マシンのスケジューリング リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) の CPU モデルを設定して、CPU モデルがサポートされるノードにこれをスケジュールできます。
手順
仮想マシン設定ファイルの
domainspec を編集します。以下の例は、VM 向けに定義された特定の CPU モデルを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- VM の CPU モデル。
7.14.10.4. ホストモデルでの仮想マシンのスケジューリング リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) の CPU モデルが host-model に設定されている場合、仮想マシンはスケジュールされているノードの CPU モデルを継承します。
手順
仮想マシン設定ファイルの
domainspec を編集します。以下の例は、仮想マシンに指定されるhost-modelを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- スケジュールされるノードの CPU モデルを継承する仮想マシン。
7.14.10.5. カスタムスケジューラーを使用した仮想マシンのスケジュール設定 リンクのコピーリンクがクリップボードにコピーされました!
カスタムスケジューラーを使用して、ノード上の仮想マシンをスケジュールできます。
前提条件
- セカンダリースケジューラーがクラスター用に設定されています。
手順
VirtualMachineマニフェストを編集して、カスタムスケジューラーを仮想マシン設定に追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- カスタムスケジューラーの名前。
schedulerName値が既存のスケジューラーと一致しない場合、virt-launcherPod は、指定されたスケジューラーが見つかるまでPending状態のままになります。
検証
virt-launcherPod イベントをチェックして、仮想マシンがVirtualMachineマニフェストで指定されたカスタムスケジューラーを使用していることを確認します。次のコマンドを入力して、クラスター内の Pod のリストを表示します。
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE virt-launcher-vm-fedora-dpc87 2/2 Running 0 24m
NAME READY STATUS RESTARTS AGE virt-launcher-vm-fedora-dpc87 2/2 Running 0 24mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して Pod イベントを表示します。
oc describe pod virt-launcher-vm-fedora-dpc87
$ oc describe pod virt-launcher-vm-fedora-dpc87Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力の
Fromフィールドの値により、スケジューラー名がVirtualMachineマニフェストで指定されたカスタムスケジューラーと一致することが検証されます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.11. PCI パススルーの設定 リンクのコピーリンクがクリップボードにコピーされました!
PCI (Peripheral Component Interconnect) パススルー機能を使用すると、仮想マシンからハードウェアデバイスにアクセスし、管理できます。PCI パススルーが設定されると、PCI デバイスはゲストオペレーティングシステムに物理的に接続されているかのように機能します。
クラスター管理者は、oc コマンドラインインターフェイス (CLI) を使用して、クラスターでの使用が許可されているホストデバイスを公開および管理できます。
7.14.11.1. GPU パススルー用のノードの準備 リンクのコピーリンクがクリップボードにコピーされました!
GPU パススルー用に指定したワーカーノードに GPU オペランドがデプロイされないようにすることができます。
7.14.11.1.1. NVIDIA GPU オペランドがノードにデプロイメントされないようにする リンクのコピーリンクがクリップボードにコピーされました!
クラスター内で NVIDIA GPU Operator を使用する場合は、GPU または vGPU オペランド用に設定したくないノードに nvidia.com/gpu.deploy.operands=false ラベルを適用できます。このラベルは、GPU または vGPU オペランドを設定する Pod の作成を防止し、Pod がすでに存在する場合は終了します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを実行して、ノードのラベルを付けます。
oc label node <node_name> nvidia.com/gpu.deploy.operands=false
$ oc label node <node_name> nvidia.com/gpu.deploy.operands=false1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<node_name>を、NVIDIA GPU オペランドをインストールしないノードの名前に置き換えます。
検証
次のコマンドを実行して、ラベルがノードに追加されたことを確認します。
oc describe node <node_name>
$ oc describe node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: GPU オペランドが以前にノードにデプロイされていた場合は、それらの削除を確認します。
次のコマンドを実行して、
nvidia-gpu-operatornamespace 内の Pod のステータスを確認します。oc get pods -n nvidia-gpu-operator
$ oc get pods -n nvidia-gpu-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Terminatingステータスの Pod が削除されるまで、Pod のステータスを監視します。oc get pods -n nvidia-gpu-operator
$ oc get pods -n nvidia-gpu-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.11.2. PCI パススルー用のホストデバイスの準備 リンクのコピーリンクがクリップボードにコピーされました!
7.14.11.2.1. PCI パススルー用ホストデバイスの準備について リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して PCI パススルー用にホストデバイスを準備するには、MachineConfig オブジェクトを作成し、カーネル引数を追加して、Input-Output Memory Management Unit (IOMMU) を有効にします。PCI デバイスを Virtual Function I/O (VFIO) ドライバーにバインドしてから、HyperConverged カスタムリソース (CR) の permittedHostDevices フィールドを編集してクラスター内で公開します。OpenShift Virtualization Operator を最初にインストールする場合、permittedHostDevices のリストは空になります。
CLI を使用してクラスターから PCI ホストデバイスを削除するには、HyperConverged CR から PCI デバイス情報を削除します。
7.14.11.2.2. IOMMU ドライバーを有効にするためのカーネル引数の追加 リンクのコピーリンクがクリップボードにコピーされました!
カーネルで IOMMU ドライバーを有効にするには、MachineConfig オブジェクトを作成し、カーネル引数を追加します。
前提条件
- クラスター管理者パーミッションがある。
- CPU ハードウェアは Intel または AMD です。
- BIOS で Directed I/O 拡張機能または AMD IOMMU 用の Intel Virtualization Technology を有効にしました。
手順
カーネル引数を識別する
MachineConfigオブジェクトを作成します。以下の例は、Intel CPU のカーネル引数を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規
MachineConfigオブジェクトを作成します。oc create -f 100-worker-kernel-arg-iommu.yaml
$ oc create -f 100-worker-kernel-arg-iommu.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
新規
MachineConfigオブジェクトが追加されていることを確認します。oc get MachineConfig
$ oc get MachineConfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.11.2.3. PCI デバイスの VFIO ドライバーへのバインディング リンクのコピーリンクがクリップボードにコピーされました!
PCI デバイスを VFIO (Virtual Function I/O) ドライバーにバインドするには、各デバイスから vendor-ID および device-ID の値を取得し、これらの値でリストを作成します。リストを MachineConfig オブジェクトに追加します。MachineConfig Operator は、PCI デバイスを持つノードで /etc/modprobe.d/vfio.conf を生成し、PCI デバイスを VFIO ドライバーにバインドします。
前提条件
- カーネル引数を CPU の IOMMU を有効にするために追加している。
手順
lspciコマンドを実行して、PCI デバイスのvendor-IDおよびdevice-IDを取得します。lspci -nnv | grep -i nvidia
$ lspci -nnv | grep -i nvidiaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)
02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Butane 設定ファイル
100-worker-vfiopci.buを作成し、PCI デバイスを VFIO ドライバーにバインドします。注記設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に
0です。たとえば、4.16.0です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Butane を使用して、ワーカーノードに配信される設定を含む
MachineConfigオブジェクトファイル (100-worker-vfiopci.yaml) を生成します。butane 100-worker-vfiopci.bu -o 100-worker-vfiopci.yaml
$ butane 100-worker-vfiopci.bu -o 100-worker-vfiopci.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfigオブジェクトをワーカーノードに適用します。oc apply -f 100-worker-vfiopci.yaml
$ oc apply -f 100-worker-vfiopci.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfigオブジェクトが追加されていることを確認します。oc get MachineConfig
$ oc get MachineConfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
VFIO ドライバーがロードされていることを確認します。
lspci -nnk -d 10de:
$ lspci -nnk -d 10de:Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力では、VFIO ドライバーが使用されていることを確認します。
出力例
04:00.0 3D controller [0302]: NVIDIA Corporation GP102GL [Tesla P40] [10de:1eb8] (rev a1) Subsystem: NVIDIA Corporation Device [10de:1eb8] Kernel driver in use: vfio-pci Kernel modules: nouveau04:00.0 3D controller [0302]: NVIDIA Corporation GP102GL [Tesla P40] [10de:1eb8] (rev a1) Subsystem: NVIDIA Corporation Device [10de:1eb8] Kernel driver in use: vfio-pci Kernel modules: nouveauCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.11.2.4. CLI を使用したクラスターでの PCI ホストデバイスの公開 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで PCI ホストデバイスを公開するには、PCI デバイスの詳細を HyperConverged カスタムリソース (CR) の spec.permittedHostDevices.pciHostDevices 配列に追加します。
手順
以下のコマンドを実行して、デフォルトエディターで
HyperConvergedCR を編集します。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow PCI デバイス情報を
spec.permittedHostDevices.pciHostDevices配列に追加します。以下に例を示します。設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記上記のスニペットの例は、
nvidia.com/GV100GL_Tesla_V100およびnvidia.com/TU104GL_Tesla_T4という名前の 2 つの PCI ホストデバイスが、HyperConvergedCR の許可されたホストデバイスの一覧に追加されたことを示しています。これらのデバイスは、OpenShift Virtualization と動作することがテストおよび検証されています。- 変更を保存し、エディターを終了します。
検証
以下のコマンドを実行して、PCI ホストデバイスがノードに追加されたことを確認します。この出力例は、各デバイスが
nvidia.com/GV100GL_Tesla_V100、nvidia.com/TU104GL_Tesla_T4、およびintel.com/qatのリソース名にそれぞれ関連付けられたデバイスが 1 つあることを示しています。oc describe node <node_name>
$ oc describe node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.11.2.5. CLI を使用したクラスターからの PCI ホストデバイスの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスターから PCI ホストデバイスを削除するには、HyperConverged カスタムリソース (CR) からそのデバイスの情報を削除します。
手順
以下のコマンドを実行して、デフォルトエディターで
HyperConvergedCR を編集します。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 適切なデバイスの
pciDeviceSelector、resourceName、およびexternalResourceProvider(該当する場合) のフィールドを削除して、spec.permittedHostDevices.pciHostDevices配列から PCI デバイス情報を削除します。この例では、intel.com/qatリソースが削除されました。設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存し、エディターを終了します。
検証
以下のコマンドを実行して、PCI ホストデバイスがノードから削除されたことを確認します。この出力例は、
intel.com/qatリソース名に関連付けられているデバイスがゼロであることを示しています。oc describe node <node_name>
$ oc describe node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.11.3. PCI パススルー用の仮想マシンの設定 リンクのコピーリンクがクリップボードにコピーされました!
PCI デバイスがクラスターに追加された後に、それらを仮想マシンに割り当てることができます。PCI デバイスが仮想マシンに物理的に接続されているかのような状態で利用できるようになりました。
7.14.11.3.1. PCI デバイスの仮想マシンへの割り当て リンクのコピーリンクがクリップボードにコピーされました!
PCI デバイスがクラスターで利用可能な場合、これを仮想マシンに割り当て、PCI パススルーを有効にすることができます。
手順
PCI デバイスをホストデバイスとして仮想マシンに割り当てます。
例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスターでホストデバイスとして許可される PCI デバイスの名前。仮想マシンがこのホストデバイスにアクセスできます。
検証
以下のコマンドを使用して、ホストデバイスが仮想マシンから利用可能であることを確認します。
lspci -nnk | grep NVIDIA
$ lspci -nnk | grep NVIDIACopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)
$ 02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.12. 仮想 GPU の設定 リンクのコピーリンクがクリップボードにコピーされました!
グラフィックスプロセッシングユニット (GPU) カードがある場合、OpenShift Virtualization は仮想マシンに割り当てることができる仮想 GPU (vGPU) を自動的に作成できます。
7.14.12.1. OpenShift Virtualization での仮想 GPU の使用について リンクのコピーリンクがクリップボードにコピーされました!
一部のグラフィックス処理ユニット (GPU) カードは、仮想 GPU (vGPU) の作成をサポートしています。管理者が HyperConverged カスタムリソース (CR) で設定の詳細を提供すると、OpenShift Virtualization は仮想 GPU およびその他の仲介デバイスを自動的に作成できます。この自動化は、大規模なクラスターで特に役立ちます。
機能とサポートの詳細は、ハードウェアベンダーのドキュメントを参照してください。
- 仲介デバイス
- 1 つまたは複数の仮想デバイスに分割された物理デバイス。仮想 GPU は、仲介デバイス (mdev) の一種です。物理 GPU のパフォーマンスが、仮想デバイス間で分割されます。仲介デバイスを 1 つまたは複数の仮想マシン (VM) に割り当てることができますが、ゲストの数は GPU と互換性がある必要があります。一部の GPU は複数のゲストをサポートしていません。
7.14.12.2. 仲介デバイス用のホストの準備 リンクのコピーリンクがクリップボードにコピーされました!
仲介デバイスを設定する前に、入出力メモリー管理ユニット (IOMMU) ドライバーを有効にする必要があります。
7.14.12.2.1. IOMMU ドライバーを有効にするためのカーネル引数の追加 リンクのコピーリンクがクリップボードにコピーされました!
カーネルで IOMMU ドライバーを有効にするには、MachineConfig オブジェクトを作成し、カーネル引数を追加します。
前提条件
- クラスター管理者パーミッションがある。
- CPU ハードウェアは Intel または AMD です。
- BIOS で Directed I/O 拡張機能または AMD IOMMU 用の Intel Virtualization Technology を有効にしました。
手順
カーネル引数を識別する
MachineConfigオブジェクトを作成します。以下の例は、Intel CPU のカーネル引数を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規
MachineConfigオブジェクトを作成します。oc create -f 100-worker-kernel-arg-iommu.yaml
$ oc create -f 100-worker-kernel-arg-iommu.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
新規
MachineConfigオブジェクトが追加されていることを確認します。oc get MachineConfig
$ oc get MachineConfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.12.3. NVIDIA GPU Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
NVIDIA GPU Operator を使用して、OpenShift Virtualization で GPU 高速化仮想マシンを実行するためのワーカーノードをプロビジョニングできます。
NVIDIA GPU Operator は、NVIDIA によってのみサポートされています。詳細は、Red Hat ナレッジベースの Obtaining Support from NVIDIA を参照してください。
7.14.12.3.1. NVIDIA GPU Operator の使用について リンクのコピーリンクがクリップボードにコピーされました!
NVIDIA GPU Operator と OpenShift Virtualization を使用すると、GPU 対応の仮想マシンを実行するためのワーカーノードを迅速にプロビジョニングできます。NVIDIA GPU Operator は、OpenShift Container Platform クラスター内の NVIDIA GPU リソースを管理し、GPU ワークロード用にノードを準備するときに必要なタスクを自動化します。
アプリケーションワークロードを GPU リソースにデプロイする前に、コンピューティングユニファイドデバイスアーキテクチャー (CUDA)、Kubernetes デバイスプラグイン、コンテナーランタイム、および自動ノードラベル付けや監視などのその他の機能を有効にする NVIDIA ドライバーなどのコンポーネントをインストールする必要があります。これらのタスクを自動化することで、インフラストラクチャーの GPU 容量を迅速に拡張できます。NVIDIA GPU Operator は、複雑な人工知能および機械学習 (AI/ML) ワークロードのプロビジョニングを特に容易にします。
7.14.12.3.2. 仲介デバイスを設定するためのオプション リンクのコピーリンクがクリップボードにコピーされました!
NVIDIA GPU Operator を使用すると、仲介デバイスを設定するには 2 つの方法があります。Red Hat がテストする方法では、OpenShift Virtualization 機能を使用して仲介デバイスをスケジュールしますが、NVIDIA の方法では GPU Operator のみを使用します。
- NVIDIA GPU Operator を使用した仲介デバイスの設定
- この方法では、NVIDIA GPU Operator のみを使用して仲介デバイスを設定します。この方法を使用するには、NVIDIA ドキュメントの NVIDIA GPU Operator with OpenShift Virtualization を参照してください。
- OpenShift Virtualization を使用した仲介デバイスの設定
この方法は Red Hat によってテストされており、OpenShift Virtualization の機能を使用して仲介デバイスを設定します。この場合、NVIDIA GPU Operator は、NVIDIA vGPU Manager でドライバーをインストールするためにのみ使用されます。GPU Operator は仲介デバイスを設定しません。
OpenShift 仮想化方式を使用する場合でも、NVIDIA ドキュメント に従って GPU Operator を設定します。ただし、この方法は次の点で NVIDIA ドキュメントとは異なります。
HyperConvergedカスタムリソース (CR) のデフォルトのdisableMDEVConfiguration: false設定を上書きしないでください。重要NVIDIA ドキュメント の説明に従ってこの機能ゲートを設定すると、OpenShift Virtualization が仲介デバイスを設定できなくなります。
次の例と一致するように
ClusterPolicyマニフェストを設定する必要があります。マニフェストの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この値を
falseに設定します。仮想マシンには必要ありません。 - 2
- この値を
trueに設定します。仮想マシンで vGPU を使用する場合に必要です。 - 3
<vgpu_container_registry>をレジストリー値に置き換えます。- 4
- この値を
falseに設定すると、OpenShift Virtualization が NVIDIA GPU Operator の代わりに仲介デバイスを設定できるようになります。 - 5
- vGPU デバイスの検出と kubelet へのアドバタイズを防止するには、この値を
falseに設定します。 - 6
vfio-pciドライバーがロードされないようにするには、この値をfalseに設定します。代わりに、OpenShift Virtualization のドキュメントに従って PCI パススルーを設定します。
7.14.12.4. 仮想 GPU がノードに割り当てられる方法 リンクのコピーリンクがクリップボードにコピーされました!
物理デバイスごとに、OpenShift Virtualization は以下の値を設定します。
- 1 つの mdev タイプ。
-
選択した
mdevタイプのインスタンスの最大数。
クラスターのアーキテクチャーは、デバイスの作成およびノードへの割り当て方法に影響します。
- ノードごとに複数のカードを持つ大規模なクラスター
同様の仮想 GPU タイプに対応する複数のカードを持つノードでは、関連するデバイス種別がラウンドロビン方式で作成されます。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このシナリオでは、各ノードに以下の仮想 GPU 種別に対応するカードが 2 つあります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードで、OpenShift Virtualization は以下の vGPU を作成します。
- 最初のカード上に nvidia-105 タイプの 16 の仮想 GPU
- 2 番目のカード上に nvidia-108 タイプの 2 つの仮想 GPU
- 1 つのノードに、要求された複数の仮想 GPU タイプをサポートするカードが 1 つある
OpenShift Virtualization は、
mediatedDeviceTypes一覧の最初のサポートされるタイプを使用します。たとえば、ノードカードのカードは
nvidia-223とnvidia-224をサポートします。次のmediatedDeviceTypesリストが設定されています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、OpenShift Virtualization は
nvidia-223タイプを使用します。
7.14.12.5. 仲介されたデバイスの管理 リンクのコピーリンクがクリップボードにコピーされました!
仲介されたデバイスを仮想マシンに割り当てる前に、デバイスを作成してクラスターに公開する必要があります。仲介されたデバイスを再設定および削除することもできます。
7.14.12.5.1. 仲介デバイスの作成および公開 リンクのコピーリンクがクリップボードにコピーされました!
管理者は、HyperConverged カスタムリソース (CR) を編集することで、仲介デバイスを作成し、クラスターに公開できます。
前提条件
- 入出力メモリー管理ユニット (IOMMU) ドライバーを有効にしました。
ハードウェアベンダーがドライバーを提供している場合は、仲介デバイスを作成するノードにドライバーをインストールしている。
- NVIDIA カードを使用する場合は、NVIDIA GRID ドライバーをインストールしている。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例7.1 仲介デバイスが設定された設定ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仲介デバイスを
spec.mediatedDevicesConfigurationスタンザに追加して作成します。YAML スニペットの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要OpenShift Virtualization 4.14 より前では、
mediatedDeviceTypesフィールドの名前はmediatedDevicesTypesでした。仲介デバイスを設定するときは、必ず正しいフィールド名を使用してください。クラスターに公開するデバイスの名前セレクターとリソース名の値を特定します。次のステップで、これらの値を
HyperConvergedCR に追加します。次のコマンドを実行して、
resourceName値を見つけます。oc get $NODE -o json \ | jq '.status.allocatable \ | with_entries(select(.key | startswith("nvidia.com/"))) \ | with_entries(select(.value != "0"))'$ oc get $NODE -o json \ | jq '.status.allocatable \ | with_entries(select(.key | startswith("nvidia.com/"))) \ | with_entries(select(.value != "0"))'Copy to Clipboard Copied! Toggle word wrap Toggle overflow /sys/bus/pci/devices/<slot>:<bus>:<domain>.<function>/mdev_supported_types/<type>/nameの内容を表示してmdevNameSelector値を見つけ、システムの正しい値に置き換えます。たとえば、
nvidia-231タイプの name ファイルには、セレクター文字列GRID T4-2Qが含まれます。GRID T4-2QをmdevNameSelector値として使用することで、ノードはnvidia-231タイプを使用できます。
mdevNameSelectorとresourceNameの値をHyperConvergedCR のspec.permittedHostDevices.mediatedDevicesスタンザに追加することで、仲介されたデバイスをクラスターに公開します。YAML スニペットの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存し、エディターを終了します。
検証
オプション: 次のコマンドを実行して、デバイスが特定のノードに追加されたことを確認します。
oc describe node <node_name>
$ oc describe node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.12.5.2. 仲介デバイスの変更および削除について リンクのコピーリンクがクリップボードにコピーされました!
仲介されたデバイスは、いくつかの方法で再設定または削除できます。
-
HyperConvergedCR を編集し、mediatedDeviceTypesスタンザの内容を変更します。 -
nodeMediatedDeviceTypesノードセレクターに一致するノードラベルを変更します。 HyperConvergedCR のspec.mediatedDevicesConfigurationおよびspec.permittedHostDevicesスタンザからデバイス情報を削除します。注記spec.permittedHostDevicesスタンザからデバイス情報を削除したが、spec.mediatedDevicesConfigurationスタンザからは削除しなかった場合、同じノードで新規の仲介デバイスタイプを作成することはできません。仲介デバイスを適切に削除するには、両方のスタンザからデバイス情報を削除します。
7.14.12.5.3. 仲介されたデバイスをクラスターから削除する リンクのコピーリンクがクリップボードにコピーされました!
クラスターから仲介デバイスを削除するには、HyperConverged カスタムリソース (CR) からそのデバイスの情報を削除します。
手順
以下のコマンドを実行して、デフォルトエディターで
HyperConvergedCR を編集します。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow HyperConvergedCR のspec.mediatedDevicesConfigurationおよびspec.permittedHostDevicesスタンザからデバイス情報を削除します。両方のエントリーを削除すると、後で同じノードで新しい仲介デバイスタイプを作成できます。以下に例を示します。設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存し、エディターを終了します。
7.14.12.6. 仲介デバイスの使用 リンクのコピーリンクがクリップボードにコピーされました!
仲介デバイスを 1 つ以上の仮想マシンに割り当てることができます。
7.14.12.6.1. CLI を使用した仮想マシンへの vGPU の割り当て リンクのコピーリンクがクリップボードにコピーされました!
仮想 GPU (vGPU) などの仲介デバイスを仮想マシンに割り当てます。
前提条件
-
仲介デバイスが
HyperConvergedカスタムリソースで設定されている。 - 仮想マシンが停止しています。
手順
VirtualMachineマニフェストのspec.domain.devices.gpusスタンザを編集して、仲介デバイスを仮想マシン (VM) に割り当てます。仮想マシンマニフェストの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
デバイスが仮想マシンで利用できることを確認するには、
<device_name>をVirtualMachineマニフェストのdeviceNameの値に置き換えて以下のコマンドを実行します。lspci -nnk | grep <device_name>
$ lspci -nnk | grep <device_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.12.6.2. Web コンソールを使用した仮想マシンへの vGPU の割り当て リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想 GPU を仮想マシンに割り当てることができます。
カスタマイズされたテンプレートまたは YAML ファイルから作成された仮想マシンに、ハードウェアデバイスを追加できます。特定のオペレーティングシステム用に事前に提供されているブートソーステンプレートにデバイスを追加することはできません。
前提条件
vGPU は、クラスター内の仲介デバイスとして設定されます。
- クラスターに接続されているデバイスを表示するには、サイドメニューから Compute → Hardware Devices をクリックします。
- 仮想マシンが停止しています。
手順
- OpenShift Container Platform Web コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- デバイスを割り当てる仮想マシンを選択します。
- Details タブで、GPU devices をクリックします。
- Add GPU device をクリックします。
- Name フィールドに識別値を入力します。
- Device name リストから、仮想マシンに追加するデバイスを選択します。
- Save をクリックします。
検証
-
デバイスが仮想マシンに追加されたことを確認するには、YAML タブをクリックし、
VirtualMachine設定を確認します。仲介されたデバイスはspec.domain.devicesスタンザに追加されます。
7.14.13. 仮想マシンでの Descheduler エビクションの有効化 リンクのコピーリンクがクリップボードにコピーされました!
descheduler を使用して Pod を削除し、Pod をより適切なノードに再スケジュールできます。Pod が仮想マシンの場合、Pod の削除により、仮想マシンが別のノードにライブマイグレーションされます。
仮想マシンの Descheduler エビクションはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
7.14.13.1. Descheduler プロファイル リンクのコピーリンクがクリップボードにコピーされました!
テクノロジープレビューの DevPreviewLongLifecycle プロファイルを使用して、仮想マシンで Descheduler を有効にします。これは、現在 OpenShift Virtualization で利用可能な唯一の Descheduler プロファイルです。適切なスケジューリングを確保するには、予想される負荷に応じた CPU およびメモリー要求で仮想マシンを作成します。
DevPreviewLongLifecycleこのプロファイルは、ノード間のリソース使用率のバランスを取り、以下のストラテジーを有効にします。
-
RemovePodsHavingTooManyRestarts: コンテナーが何度も再起動された Pod、およびすべてのコンテナー (Init コンテナーを含む) の再起動の合計が 100 を超える Pod を削除します。仮想マシンのゲストオペレーティングシステムを再起動しても、この数は増えません。 LowNodeUtilization: 使用率の低いノードがある場合に、使用率の高いノードから Pod を退避します。退避された Pod の宛先ノードはスケジューラーによって決定されます。- ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) で 20% 未満の場合に使用率が低いと見なされます。
- ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) について 50% を超える場合に過剰に使用されていると見なされます。
-
7.14.13.2. descheduler のインストール リンクのコピーリンクがクリップボードにコピーされました!
descheduler はデフォルトで利用できません。descheduler を有効にするには、Kube Descheduler Operator を OperatorHub からインストールし、1 つ以上の descheduler プロファイルを有効にする必要があります。
デフォルトで、descheduler は予測モードで実行されます。つまり、これは Pod エビクションのみをシミュレートします。Pod エビクションを実行するには、descheduler のモードを automatic に変更する必要があります。
クラスターでホストされたコントロールプレーンを有効にしている場合は、カスタム優先度のしきい値を設定して、ホストされたコントロールプレーンの namespace の Pod が削除される可能性を下げます。ホストされたコントロールプレーンの優先度クラスの中で優先度値が最も低い (100000000) ため、優先度しきい値クラス名を hypershift-control-plane に設定します。
前提条件
-
cluster-adminロールを持つユーザーとして OpenShift Container Platform にログインしている。 - OpenShift Container Platform Web コンソールにアクセスできる。
手順
- OpenShift Container Platform Web コンソールにログインします。
Kube Descheduler Operator に必要な namespace を作成します。
- Administration → Namespaces に移動し、Create Namespace をクリックします。
-
Name フィールドに
openshift-kube-descheduler-operatorを入力し、Labels フィールドにopenshift.io/cluster-monitoring=trueを入力して descheduler メトリクスを有効にし、Create をクリックします。
Kube Descheduler Operator をインストールします。
- Operators → OperatorHub に移動します。
- Kube Descheduler Operator をフィルターボックスに入力します。
- Kube Descheduler Operator を選択し、Install をクリックします。
- Install Operator ページで、A specific namespace on the cluster を選択します。ドロップダウンメニューから openshift-kube-descheduler-operator を選択します。
- Update Channel および Approval Strategy の値を必要な値に調整します。
- Install をクリックします。
descheduler インスタンスを作成します。
- Operators → Installed Operators ページから、Kube Descheduler Operator をクリックします。
- Kube Descheduler タブを選択し、Create KubeDescheduler をクリックします。
必要に応じて設定を編集します。
- エビクションをシミュレーションせずに Pod をエビクトするには、Mode フィールドを Automatic に変更します。
Profiles セクションを展開し、
DevPreviewLongLifecycleを選択します。AffinityAndTaintsプロファイルがデフォルトで有効になっています。重要OpenShift Virtualization で現在利用できるプロファイルは
DevPreviewLongLifecycleのみです。
また、後で OpenShift CLI (oc) を使用して、Descheduler のプロファイルおよび設定を設定することもできます。
7.14.13.3. 仮想マシン (VM) での descheduler エビクションの有効化 リンクのコピーリンクがクリップボードにコピーされました!
descheduler のインストール後に、アノテーションを VirtualMachine カスタムリソース (CR) に追加して descheduler エビクションを仮想マシンで有効にできます。
前提条件
-
descheduler を OpenShift Container Platform Web コンソールまたは OpenShift CLI (
oc) にインストールしている。 - 仮想マシンが実行されていないことを確認します。
手順
仮想マシンを起動する前に、
descheduler.alpha.kubernetes.io/evictアノテーションをVirtualMachineCR に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストール時に Web コンソールで
DevPreviewLongLifecycleプロファイルをまだ設定していない場合は、KubeDeschedulerオブジェクトのspec.profileセクションにDevPreviewLongLifecycleを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- デフォルトでは、Descheduler は Pod をエビクトしません。Pod をエビクトするには、
modeをAutomaticに設定します。
Descheduler が仮想マシンで有効になりました。
7.14.14. 仮想マシンの高可用性について リンクのコピーリンクがクリップボードにコピーされました!
障害が発生したノードを手動で削除して仮想マシンフェイルオーバーをトリガーするか、修復ノードを設定することによって、仮想マシンの高可用性を有効にすることができます。
障害が発生したノードを手動で削除する
ノードに障害が発生し、マシンヘルスチェックがクラスターにデプロイされていない場合、runStrategy: Always が設定された仮想マシンは正常なノードに自動的に移動しません。仮想マシンのフェイルオーバーをトリガーするには、Node オブジェクトを手動で削除する必要があります。
障害が発生したノードを削除して仮想マシンのフェイルオーバーをトリガーする を参照してください。
修復ノードの設定
OperatorHub から Self Node Remediation Operator または Fence Agents Remediation Operator をインストールし、マシンのヘルスチェックまたはノードの修復チェックを有効にすることで、修復ノードを設定できます。
ノードの修復、フェンシング、メンテナンスの詳細は、Red Hat OpenShift のワークロードの可用性 を参照してください。
7.14.15. 仮想マシンのコントロールプレーンのチューニング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization は、コントロールプレーンレベルで次のチューニングオプションを提供します。
-
highBurstプロファイルは、固定QPSとburstレートを使用して、1 つのバッチで数百の仮想マシンを作成します。 - ワークロードの種類に基づいた移行設定の調整
7.14.15.1. highBurst プロファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
highBurst プロファイルを使用して、1 つのクラスター内に多数の仮想マシンを作成および維持します。
手順
次のパッチを適用して、
highBurstチューニングポリシープロファイルを有効にします。oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type=json -p='[{"op": "add", "path": "/spec/tuningPolicy", \ "value": "highBurst"}]'$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type=json -p='[{"op": "add", "path": "/spec/tuningPolicy", \ "value": "highBurst"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、
highBurstチューニングポリシープロファイルが有効になっていることを確認します。oc get kubevirt.kubevirt.io/kubevirt-kubevirt-hyperconverged \ -n openshift-cnv -o go-template --template='{{range $config, \ $value := .spec.configuration}} {{if eq $config "apiConfiguration" \ "webhookConfiguration" "controllerConfiguration" "handlerConfiguration"}} \ {{"\n"}} {{$config}} = {{$value}} {{end}} {{end}} {{"\n"}}$ oc get kubevirt.kubevirt.io/kubevirt-kubevirt-hyperconverged \ -n openshift-cnv -o go-template --template='{{range $config, \ $value := .spec.configuration}} {{if eq $config "apiConfiguration" \ "webhookConfiguration" "controllerConfiguration" "handlerConfiguration"}} \ {{"\n"}} {{$config}} = {{$value}} {{end}} {{end}} {{"\n"}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.14.16. コンピュートリソースの割り当て リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization では、仮想マシン (VM) に割り当てられたコンピュートリソースは、Guaranteed CPU またはタイムスライスされた CPU シェアのいずれかによってサポートされます。
Guaranteed CPU (CPU 予約とも呼ばれる) は、CPU コアまたはスレッドを特定のワークロード専用にし、他のワークロードでは使用できなくなります。Guaranteed CPU を仮想マシンに割り当てると、仮想マシンは予約された物理 CPU に単独でアクセスできるようになります。仮想マシンの専用リソースを有効化 し、Guaranteed CPU を使用します。
タイムスライス CPU は、共有物理 CPU 上の時間のスライスを各ワークロード専用にします。スライスのサイズは、仮想マシンの作成中、または仮想マシンがオフラインのときに指定できます。デフォルトでは、各仮想 CPU は 100 ミリ秒、つまり 1/10 秒の物理 CPU 時間を受け取ります。
CPU 予約のタイプは、インスタンスのタイプまたは仮想マシン設定によって異なります。
7.14.16.1. CPU リソースのオーバーコミット リンクのコピーリンクがクリップボードにコピーされました!
タイムスライシングにより、複数の仮想 CPU (vCPU) が 1 つの物理 CPU を共有できます。これは CPU オーバーコミットメント として知られています。Guaranteed 仮想マシンをオーバーコミットすることはできません。
CPU を仮想マシンに割り当てるときに、パフォーマンスよりも仮想マシン密度を優先するように CPU オーバーコミットメントを設定します。仮想 CPU の CPU オーバーコミットメントが高くなると、より多くの仮想マシンが特定のノードに適合します。
7.14.16.2. CPU 割り当て率の設定 リンクのコピーリンクがクリップボードにコピーされました!
CPU 割り当て率は、仮想 CPU を物理 CPU のタイムスライスにマッピングすることにより、オーバーコミットメントの程度を指定します。
たとえば、10:1 のマッピングまたは比率は、タイムスライスを使用して、10 個の仮想 CPU を 1 個の物理 CPU にマッピングします。
各物理 CPU にマップされる仮想 CPU のデフォルトの数を変更するには、HyperConverged CR で vmiCPUAllocationRatio 値を設定します。Pod CPU リクエストは、仮想 CPU の数に CPU 割り当て率の逆数を乗算して計算されます。たとえば、vmiCPUAllocationRatio が 10 に設定されている場合、OpenShift Virtualization はその仮想マシンの Pod 上で 10 分の 1 少ない CPU を要求します。
手順
HyperConverged CR で vmiCPUAllocationRatio 値を設定して、ノードの CPU 割り当て率を定義します。
以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow vmiCPUAllocationRatioを設定します。... spec: resourceRequirements: vmiCPUAllocationRatio: 1 # ...... spec: resourceRequirements: vmiCPUAllocationRatio: 11 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
vmiCPUAllocationRatioが1に設定されている場合、Pod に対して最大量の仮想 CPU が要求されます。
7.14.17. マルチキュー機能について リンクのコピーリンクがクリップボードにコピーされました!
マルチキュー機能を使用して、複数の仮想 CPU を備えた仮想マシン (VM) のネットワークスループットとパフォーマンスを拡張します。
デフォルトでは、ドメイン XML から派生した queueCount 値は、仮想マシンに割り当てられた仮想 CPU の数によって決まります。仮想 CPU の数が増えても、ネットワークパフォーマンスは向上しません。さらに、virtio-net には Tx キューと Rx キューが 1 つしかないため、ゲストはパケットを並行して送信または取得できません。
ゲストインスタンス内の vNIC の数が仮想 CPU の数に比例する場合、virtio-net マルチキューを有効にしても大きな改善は得られません。
7.14.17.1. 既知の制限 リンクのコピーリンクがクリップボードにコピーされました!
- virtio-net マルチキューがホストで有効になっているが、管理者によってゲストオペレーティングシステムで有効になっていない場合でも、MSI ベクトルは消費されます。
- 各 virtio-net キューは、vhost ドライバー用に 64 KiB のカーネルメモリーを消費します。
-
networkInterfaceMultiqueueが 'true' に設定されている場合、CPU が 16 個を超えて搭載されている仮想マシンを起動すると接続できなくなります (CNV-16107)。
7.14.17.2. マルチキュー機能の有効化 リンクのコピーリンクがクリップボードにコピーされました!
VirtIO モデルで設定されたインターフェイスのマルチキュー機能を有効にします。
手順
マルチキュー機能を有効にするには、仮想マシンの
VirtualMachineマニフェストファイルでnetworkInterfaceMultiqueue値をtrueに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
VirtualMachineマニフェストファイルを保存して変更を適用します。
7.15. 仮想マシンディスク リンクのコピーリンクがクリップボードにコピーされました!
7.15.1. 仮想マシンディスクのホットプラグ リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) または仮想マシンインスタンス (VMI) を停止することなく、仮想ディスクを追加または削除できます。
データボリュームおよび永続ボリューム要求 (PVC) のみをホットプラグおよびホットアンプラグできます。コンテナーディスクのホットプラグおよびホットアンプラグはできません。
ホットプラグされたディスクは、再起動後も仮想マシンに接続されたままになります。仮想マシンからディスクを削除するには、ディスクを切断する必要があります。
ホットプラグされたディスクを永続的に作成して、仮想マシンに永続的にマウントできます。
各仮想マシンは、ホットプラグされたディスクが scsi バスを使用できるように、virtio-scsi コントローラーを備えています。virtio-scsi コントローラーは、パフォーマンス上の利点を維持しながら、virtio の制限を克服します。スケーラビリティーが高く、400 万台を超えるディスクのホットプラグをサポートします。
通常の virtio はスケーラブルではないため、ホットプラグされたディスクには使用できません。各 virtio ディスクは、仮想マシン内の限られた PCI Express (PCIe) スロットの 1 つを使用します。PCIe スロットは他のデバイスでも使用されるため、事前に予約する必要があります。したがって、スロットはオンデマンドで利用できない場合があります。
7.15.1.1. Web コンソールを使用したディスクのホットプラグとホットアンプラグ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシンの実行中にディスクを仮想マシンに接続することで、ディスクをホットプラグできます。
ホットプラグされたディスクは、プラグを抜くまで仮想マシンに接続されたままになります。
ホットプラグされたディスクを永続的に作成して、仮想マシンに永続的にマウントできます。
前提条件
- ホットプラグに使用できるデータボリュームまたは永続ボリュームクレーム (PVC) が必要です。
手順
- Web コンソールで Virtualization → VirtualMachines に移動します。
- 実行中の仮想マシンを選択して、その詳細を表示します。
- VirtualMachine details ページで、Configuration → Disks をクリックします。
ホットプラグされたディスクを追加します。
- Add disk をクリックします。
- Add disk (hot plugged) ウィンドウで、Source リストからディスクを選択し、Save をクリックします。
オプション: ホットプラグされたディスクを取り外します。
-
ディスクの横にあるオプションメニュー
をクリックし、Detach を選択します。
- Detach をクリックします。
-
ディスクの横にあるオプションメニュー
オプション: ホットプラグされたディスクを永続的にします。
-
ディスクの横にあるオプションメニュー
をクリックし、Make persistent を選択します。
- 仮想マシンを再起動して変更を適用します。
-
ディスクの横にあるオプションメニュー
7.15.1.2. コマンドラインを使用したディスクのホットプラグとホットアンプラグ リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して、仮想マシンの実行中にディスクのホットプラグおよびホットアンプラグを行うことができます。
ホットプラグされたディスクを永続的に作成して、仮想マシンに永続的にマウントできます。
前提条件
- ホットプラグ用に 1 つ以上のデータボリュームまたは永続ボリューム要求 (PVC) が利用可能である必要があります。
手順
次のコマンドを実行して、ディスクをホットプラグします。
virtctl addvolume <virtual-machine|virtual-machine-instance> \ --volume-name=<datavolume|PVC> \ [--persist] [--serial=<label-name>]
$ virtctl addvolume <virtual-machine|virtual-machine-instance> \ --volume-name=<datavolume|PVC> \ [--persist] [--serial=<label-name>]Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプションの
--persistフラグを使用して、ホットプラグされたディスクを、永続的にマウントされた仮想ディスクとして仮想マシン仕様に追加します。仮想ディスクを永続的にマウントするために、仮想マシンを停止、再開または再起動します。--persistフラグを指定しても、仮想ディスクをホットプラグしたり、ホットアンプラグしたりできなくなります。--persistフラグは仮想マシンに適用され、仮想マシンインスタンスには適用されません。 -
オプションの
--serialフラグを使用すると、選択した英数字の文字列ラベルを追加できます。これは、ゲスト仮想マシンでホットプラグされたディスクを特定するのに役立ちます。このオプションを指定しない場合、ラベルはデフォルトでホットプラグされたデータボリュームまたは PVC の名前に設定されます。
-
オプションの
次のコマンドを実行して、ディスクをホットアンプラグします。
virtctl removevolume <virtual-machine|virtual-machine-instance> \ --volume-name=<datavolume|PVC>
$ virtctl removevolume <virtual-machine|virtual-machine-instance> \ --volume-name=<datavolume|PVC>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.15.2. 仮想マシンディスクの拡張 リンクのコピーリンクがクリップボードにコピーされました!
ディスクの永続ボリューム要求 (PVC) を拡張することで、仮想マシンディスクのサイズを増やすことができます。
ストレージプロバイダーがボリューム拡張をサポートしていない場合は、空のデータボリュームを追加することで、仮想マシンの利用可能な仮想ストレージを拡張できます。
仮想マシンディスクのサイズを減らすことはできません。
7.15.2.1. 仮想マシンディスク PVC の拡張 リンクのコピーリンクがクリップボードにコピーされました!
ディスクの永続ボリューム要求 (PVC) を拡張することで、仮想マシンディスクのサイズを増やすことができます。
PVC がファイルシステムボリュームモードを使用する場合、ディスクイメージファイルは、ファイルシステムのオーバーヘッド用にスペースを確保しながら、利用可能なサイズまで拡張されます。
手順
拡張する必要のある仮想マシンディスクの
PersistentVolumeClaimマニフェストを編集します。oc edit pvc <pvc_name>
$ oc edit pvc <pvc_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ディスクサイズを更新します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しいディスクサイズを指定します。
7.15.2.2. 空のデータボリュームを追加して利用可能な仮想ストレージを拡張する リンクのコピーリンクがクリップボードにコピーされました!
空のデータボリュームを追加することで、仮想マシンの利用可能なストレージを拡張できます。
前提条件
- 少なくとも 1 つの永続ボリュームが必要です。
手順
次の例に示すように、
DataVolumeマニフェストを作成します。DataVolumeマニフェストの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してデータボリュームを作成します。
oc create -f <blank-image-datavolume>.yaml
$ oc create -f <blank-image-datavolume>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第8章 ネットワーク リンクのコピーリンクがクリップボードにコピーされました!
8.1. ネットワークの概要 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization は、カスタムリソースおよびプラグインを使用して高度なネットワーク機能を提供します。仮想マシン (VM) は、OpenShift Container Platform のネットワークおよびエコシステムと統合されています。
シングルスタックの IPv6 クラスターで OpenShift Virtualization は実行できません。
次の図は、OpenShift Virtualization の一般的なネットワーク設定を示しています。他の設定も可能です。
図8.1 OpenShift Virtualization ネットワークの概要
Pod と仮想マシンは同じネットワークインフラストラクチャー上で実行するため、コンテナー化されたワークロードと仮想化されたワークロードを簡単に接続できます。
仮想マシンをデフォルトの Pod ネットワークおよび任意の数のセカンダリーネットワークに接続できます。
デフォルトの Pod ネットワークは、すべてのメンバー間の接続、サービス抽象化、IP 管理、マイクロセグメンテーション、およびその他の機能を提供します。
Multus は、互換性のある他の CNI プラグインを使用して、Pod または仮想マシンが追加のネットワークインターフェイスに接続できるようにする "メタ" CNI プラグインです。
デフォルトの Pod ネットワークはオーバーレイベースであり、基盤となるマシンネットワークを介してトンネリングされます。
マシンネットワークは、選択したネットワークインターフェイスコントローラー (NIC) のセットを介して定義できます。
セカンダリー仮想マシンネットワークは通常、VLAN カプセル化の有無にかかわらず、物理ネットワークに直接ブリッジされます。セカンダリーネットワーク用の仮想オーバーレイネットワークを作成することも可能です。
仮想マシンをアンダーレイネットワークに直接接続することは、Red Hat OpenShift Service on AWS ではサポートされていません。
セカンダリー仮想マシンネットワークは、図 1 に示すように専用の NIC セットで定義することも、マシンネットワークを使用することもできます。
8.1.1. OpenShift Virtualization ネットワークの用語集 リンクのコピーリンクがクリップボードにコピーされました!
以下の用語は、OpenShift Virtualization ドキュメント全体で使用されています。
- Container Network Interface (CNI)
- コンテナーのネットワーク接続に重点を置く Cloud Native Computing Foundation プロジェクト。OpenShift Virtualization は CNI プラグインを使用して基本的な Kubernetes ネットワーク機能を強化します。
- Multus
- 複数の CNI の存在を可能にし、Pod または仮想マシンが必要なインターフェイスを使用できるようにする "メタ" CNI プラグイン。
- カスタムリソース定義 (CRD)
- カスタムリソースの定義を可能にする Kubernetes API リソース、または CRD API リソースを使用して定義されるオブジェクト。
- Network Attachment Definition (NAD)
- Multus プロジェクトによって導入された CRD。Pod、仮想マシン、および仮想マシンインスタンスを 1 つ以上のネットワークに接続できるようにします。
- ノードネットワーク設定ポリシー (NNCP)
-
nmstate プロジェクトによって導入された CRD。ノード上で要求されるネットワーク設定を表します。
NodeNetworkConfigurationPolicyマニフェストをクラスターに適用して、インターフェイスの追加および削除など、ノードネットワーク設定を更新します。
8.1.2. デフォルトの Pod ネットワークの使用 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンをデフォルトの Pod ネットワークに接続する
- 各仮想マシンは、デフォルトの内部 Pod ネットワークにデフォルトで接続されます。仮想マシン仕様を編集することで、ネットワークインターフェイスを追加または削除できます。
- 仮想マシンをサービスとして公開する
-
Serviceオブジェクトを作成することで、クラスター内またはクラスター外に仮想マシンを公開できます。オンプレミスクラスターの場合、MetalLB Operator を使用して負荷分散サービスを設定できます。OpenShift Container Platform Web コンソールまたは CLI を使用して、MetalLB Operator をインストール できます。
8.1.3. 仮想マシンのセカンダリーネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
Linux ブリッジ、SR-IOV、OVN-Kubernetes CNI プラグインを使用して、仮想マシンをセカンダリーネットワークに接続できます。仮想マシン仕様では、複数のセカンダリーネットワークとインターフェイスをリストできます。セカンダリーネットワークインターフェイスに接続する場合、仮想マシン仕様でプライマリー Pod ネットワークを指定する必要はありません。
- OVN-Kubernetes セカンダリーネットワークへの仮想マシンの接続
仮想マシンを OVN-Kubernetes セカンダリーネットワークに接続できます。OpenShift Virtualization は、OVN-Kubernetes の
layer2およびlocalnetトポロジーをサポートしています。localnetトポロジーは、VLAN カプセル化の有無にかかわらず、基盤となる物理ネットワークに仮想マシンを公開する方法として推奨されます。-
layer2トポロジーは、クラスター全体の論理スイッチによってワークロードを接続します。OVN-Kubernetes CNI プラグインは、Geneve (Generic Network Virtualization Encapsulation) プロトコルを使用して、ノード間にオーバーレイネットワークを作成します。このオーバーレイネットワークを使用すると、追加の物理ネットワークインフラストラクチャーを設定することなく、さまざまなノード上の仮想マシンを接続できます。 -
localnetトポロジーは、セカンダリーネットワークを物理アンダーレイに接続します。これにより、east-west クラスタートラフィックとクラスター外で実行されているサービスへのアクセスの両方が可能になります。ただし、クラスターノード上の基盤となる Open vSwitch (OVS) システムの追加設定が必要です。
-
OVN-Kubernetes セカンダリーネットワークを設定し、そのネットワークに仮想マシンを接続するには、次の手順を実行します。
ネットワークアタッチメント定義 (NAD) を作成して、OVN-Kubernetes セカンダリーネットワークの設定 を行います。
注記localnetトポロジーの場合は、NAD を作成 する前にNodeNetworkConfigurationPolicyオブジェクトを作成し、OVS ブリッジを設定する 必要があります。- ネットワークの詳細を仮想マシン仕様に追加して、仮想マシンを OVN-Kubernetes セカンダリーネットワークに接続 します。
- 仮想マシンの SR-IOV ネットワークへの接続
高帯域幅または低レイテンシーを必要とするアプリケーション向けに、ベアメタルまたは Red Hat OpenStack Platform (RHOSP) インフラストラクチャーにインストールされた OpenShift Container Platform クラスター上の追加ネットワークで、Single Root I/O Virtualization (SR-IOV) ネットワークデバイスを使用できます。
SR-IOV ネットワークデバイスとネットワーク接続を管理するには、クラスターに SR-IOV Network Operator をインストール する必要があります。
次の手順を実行すると、仮想マシンを SR-IOV ネットワークに接続できます。
-
SriovNetworkNodePolicyCRD を作成して、SR-IOV ネットワークデバイスを設定 します。 -
SriovNetworkオブジェクトを作成して、SR-IOV ネットワークを設定 します。 - 仮想マシン設定にネットワークの詳細を追加して、仮想マシンを SR-IOV ブリッジネットワークに接続 します。
-
- Linux ブリッジネットワークへの仮想マシンの接続
Kubernetes NMState Operator をインストールし て、セカンダリーネットワークの Linux ブリッジ、VLAN、およびボンディングを設定します。基盤となる物理ネットワークに仮想マシンを接続する方法としては、OVN-Kubernetes の
localnetトポロジーが推奨されます。ただし、OpenShift Virtualization は Linux ブリッジネットワークもサポートしています。注記Linux ブリッジネットワークを使用する場合、デフォルトのマシンネットワークに直接接続することはできません。
次の手順を実行すると、Linux ブリッジネットワークを作成し、そのネットワークに仮想マシンを接続できます。
-
NodeNetworkConfigurationPolicyカスタムリソース定義 (CRD) を作成して、Linux ブリッジネットワークデバイスを設定 します。 -
NetworkAttachmentDefinitionCRD を作成して、Linux ブリッジネットワークを設定 します。 - 仮想マシン設定にネットワークの詳細を追加して、仮想マシンを Linux ブリッジネットワークに接続 します。
-
- ホットプラグ対応のセカンダリーネットワークインターフェイス
- 仮想マシンを停止せずに、セカンダリーネットワークインターフェイスを追加または削除できます。OpenShift Virtualization は、ブリッジバインディングおよび VirtIO デバイスドライバーを使用するセカンダリーインターフェイスのホットプラグとホットアンプラグをサポートしています。OpenShift Virtualization は、SR-IOV バインディングを使用するセカンダリーインターフェイスのホットプラグもサポートしています。
- SR-IOV での DPDK の使用
- Data Plane Development Kit (DPDK) は、高速パケット処理用のライブラリーとドライバーのセットを提供するものです。SR-IOV ネットワーク上で DPDK ワークロードを実行するようにクラスターと仮想マシンを設定できます。
- ライブマイグレーション用の専用ネットワークの設定
- ライブマイグレーション専用の Multus ネットワーク を設定できます。専用ネットワークは、ライブマイグレーション中のテナントワークロードに対するネットワークの飽和状態の影響を最小限に抑えます。
- クラスター FQDN を使用した仮想マシンへのアクセス
- 完全修飾ドメイン名 (FQDN) を使用して、クラスターの外部からセカンダリーネットワークインターフェイスに接続されている仮想マシンにアクセスできます。
- IP アドレスの設定と表示
- 仮想マシンを作成するときに、セカンダリーネットワークインターフェイスの IP アドレスを設定できます。IP アドレスは、cloud-init でプロビジョニングされます。仮想マシンの IP アドレスは、OpenShift Container Platform Web コンソールまたはコマンドラインを使用して表示できます。ネットワーク情報は QEMU ゲストエージェントによって収集されます。
8.1.3.1. Linux ブリッジ CNI と OVN-Kubernetes localnet トポロジーの比較 リンクのコピーリンクがクリップボードにコピーされました!
次の表は、Linux ブリッジ CNI を使用する場合と OVN-Kubernetes プラグインの localnet トポロジーを使用する場合に利用できる機能の比較を示しています。
| 機能 | Linux ブリッジ CNI で利用可能 | OVN-Kubernetes localnet で利用可能 |
|---|---|---|
| アンダーレイネイティブネットワークへのレイヤー 2 アクセス | セカンダリーネットワークインターフェイスコントローラー (NIC) のみ | はい |
| アンダーレイ VLAN へのレイヤー 2 アクセス | はい | はい |
| ネットワークポリシー | いいえ | はい |
| 管理された IP プール | いいえ | いいえ |
| MAC スプーフィングフィルタリング | はい | はい |
8.1.4. OpenShift Service Mesh との統合 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンのサービスメッシュへの接続
- OpenShift Virtualization は OpenShift Service Mesh と統合されています。Pod と仮想マシン間のトラフィックを監視、視覚化、制御できます。
8.1.5. MAC アドレスプールの管理 リンクのコピーリンクがクリップボードにコピーされました!
- ネットワークインターフェイスの MAC アドレスプールの管理
- KubeMacPool コンポーネントは、共有 MAC アドレスプールから仮想マシンネットワークインターフェイスの MAC アドレスを割り当てます。これにより、各ネットワークインターフェイスに一意の MAC アドレスが確実に割り当てられます。その仮想マシンから作成された仮想マシンインスタンスは、再起動後も割り当てられた MAC アドレスを保持します。
8.1.6. SSH アクセスの設定 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンへの SSH アクセスの設定
次の方法を使用して、仮想マシンへの SSH アクセスを設定できます。
SSH 鍵ペアを作成し、公開鍵を仮想マシンに追加し、秘密鍵を使用して
virtctl sshコマンドを実行して仮想マシンに接続します。cloud-init データソースを使用して設定できるゲストオペレーティングシステムを使用して、実行時または最初の起動時に Red Hat Enterprise Linux (RHEL) 9 仮想マシンに SSH 公開鍵を追加できます。
virtctl port-fowardコマンドを.ssh/configファイルに追加し、OpenSSH を使用して仮想マシンに接続します。サービスを作成し、そのサービスを仮想マシンに関連付け、サービスによって公開されている IP アドレスとポートに接続します。
セカンダリーネットワークを設定し、仮想マシンをセカンダリーネットワークインターフェイスに接続し、割り当てられた IP アドレスに接続します。
8.2. 仮想マシンをデフォルトの Pod ネットワークに接続する リンクのコピーリンクがクリップボードにコピーされました!
masquerade バインディングモードを使用するようにネットワークインターフェイスを設定することで、仮想マシンをデフォルトの内部 Pod ネットワークに接続できます。
ネットワークインターフェイスを通過してデフォルトの Pod ネットワークに到達するトラフィックは、ライブマイグレーション中に中断されます。
8.2.1. コマンドラインでのマスカレードモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
マスカレードモードを使用し、仮想マシンの送信トラフィックを Pod IP アドレスの背後で非表示にすることができます。マスカレードモードは、ネットワークアドレス変換 (NAT) を使用して仮想マシンを Linux ブリッジ経由で Pod ネットワークバックエンドに接続します。
仮想マシンの設定ファイルを編集して、マスカレードモードを有効にし、トラフィックが仮想マシンに到達できるようにします。
前提条件
- 仮想マシンは、IPv4 アドレスを取得するために DHCP を使用できるように設定される必要がある。
手順
仮想マシン設定ファイルの
interfacesspec を編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ポート 49152 および 49153 は libvirt プラットフォームで使用するために予約され、これらのポートへの他のすべての受信トラフィックは破棄されます。
仮想マシンを作成します。
oc create -f <vm-name>.yaml
$ oc create -f <vm-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2.2. デュアルスタック (IPv4 および IPv6) でのマスカレードモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
cloud-init を使用して、新規仮想マシン (VM) を、デフォルトの Pod ネットワークで IPv6 と IPv4 の両方を使用するように設定できます。
仮想マシンインスタンス設定の Network.pod.vmIPv6NetworkCIDR フィールドは、VM の静的 IPv6 アドレスとゲートウェイ IP アドレスを決定します。これらは IPv6 トラフィックを仮想マシンにルーティングするために virt-launcher Pod で使用され、外部では使用されません。Network.pod.vmIPv6NetworkCIDR フィールドは、Classless Inter-Domain Routing (CIDR) 表記で IPv6 アドレスブロックを指定します。デフォルト値は fd10:0:2::2/120 です。この値は、ネットワーク要件に基づいて編集できます。
仮想マシンが実行されている場合、仮想マシンの送受信トラフィックは、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 アドレスとデフォルトゲートウェイを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace で仮想マシンインスタンスを作成します。
oc create -f example-vm-ipv6.yaml
$ oc create -f example-vm-ipv6.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
- IPv6 が設定されていることを確認するには、仮想マシンを起動し、仮想マシンインスタンスのインターフェイスステータスを表示して、これに IPv6 アドレスがあることを確認します。
oc get vmi <vmi-name> -o jsonpath="{.status.interfaces[*].ipAddresses}"
$ oc get vmi <vmi-name> -o jsonpath="{.status.interfaces[*].ipAddresses}"
8.2.3. ジャンボフレームのサポートについて リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes CNI プラグインを使用すると、デフォルトの Pod ネットワークに接続されている 2 つの仮想マシン (VM) 間でフラグメント化されていないジャンボフレームパケットを送信できます。ジャンボフレームの最大伝送単位 (MTU) 値は 1500 バイトを超えています。
VM は、クラスター管理者が設定したクラスターネットワークの MTU 値を、次のいずれかの方法で自動的に取得します。
-
libvirt: ゲスト OS に VirtIO ドライバーの最新バージョンがあり、エミュレーションされたデバイスの Peripheral Component Interconnect (PCI) 設定レジスターを介して着信データを解釈できる場合。 - DHCP: ゲスト DHCP クライアントが DHCP サーバーの応答から MTU 値を読み取ることができる場合。
VirtIO ドライバーを持たない Windows VM の場合、netsh または同様のツールを使用して MTU を手動で設定する必要があります。これは、Windows DHCP クライアントが MTU 値を読み取らないためです。
8.3. サービスを使用して仮想マシンを公開する リンクのコピーリンクがクリップボードにコピーされました!
Service オブジェクトを作成して、クラスター内またはクラスターの外部に仮想マシンを公開することができます。
8.3.1. サービスについて リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes サービスは一連の Pod で実行されているアプリケーションへのクライアントのネットワークアクセスを公開します。サービスは抽象化、負荷分散を提供し、タイプ NodePort と LoadBalancer の場合は外部世界への露出を提供します。
- ClusterIP
-
内部 IP アドレスでサービスを公開し、クラスター内の他のアプリケーションに DNS 名として公開します。1 つのサービスを複数の仮想マシンにマッピングできます。クライアントがサービスに接続しようとすると、クライアントのリクエストは使用可能なバックエンド間で負荷分散されます。
ClusterIPはデフォルトのサービスタイプです。 - NodePort
-
クラスター内の選択した各ノードの同じポートでサービスを公開します。
NodePortは、ノード自体がクライアントから外部にアクセスできる限り、クラスターの外部からポートにアクセスできるようにします。 - LoadBalancer
- 現在のクラウドに外部ロードバランサーを作成し (サポートされている場合)、固定の外部 IP アドレスをサービスに割り当てます。
オンプレミスクラスターの場合、MetalLB Operator をデプロイすることで負荷分散サービスを設定できます。
8.3.2. デュアルスタックサポート リンクのコピーリンクがクリップボードにコピーされました!
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.3.3. コマンドラインを使用したサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して、サービスを作成し、それを仮想マシンに関連付けることができます。
前提条件
- サービスをサポートするようにクラスターネットワークを設定しました。
手順
VirtualMachineマニフェストを編集して、サービス作成のラベルを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
special: keyをspec.template.metadata.labelsスタンザに追加します。
注記仮想マシンのラベルは Pod に渡されます。
special: keyラベルは、Serviceマニフェストのspec.selector属性のラベルと一致する必要があります。-
VirtualMachineマニフェストファイルを保存して変更を適用します。 仮想マシンを公開するための
Serviceマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Serviceマニフェストファイルを保存します。 以下のコマンドを実行してサービスを作成します。
oc create -f example-service.yaml
$ oc create -f example-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 仮想マシンを再起動して変更を適用します。
検証
Serviceオブジェクトをクエリーし、これが利用可能であることを確認します。oc get service -n example-namespace
$ oc get service -n example-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. 内部 FQDN を使用した仮想マシンへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
ヘッドレスサービスを使用すると、安定した完全修飾ドメイン名 (FQDN) 上のデフォルトの内部 Pod ネットワークに接続されている仮想マシン (VM) にアクセスできます。
Kubernetes ヘッドレスサービス は、Pod のセットの表現にクラスター IP アドレスを割り当てないサービス形式です。ヘッドレスサービスは、サービスに単一の仮想 IP アドレスを提供する代わりに、サービスに関連付けられた Pod ごとに DNS レコードを作成します。特定の TCP ポートまたは UDP ポートを公開しなくても、FQDN を通じて仮想マシンを公開できます。
OpenShift Container Platform Web コンソールを使用して VM を作成した場合、VirtualMachine details ページの Overview タブの Network タイルにその内部 FQDN が表示されます。VM への接続の詳細は、内部 FQDN を使用した仮想マシンへの接続 を参照してください。
8.4.1. CLI を使用したプロジェクトでのヘッドレスサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
namespace にヘッドレスサービスを作成するには、サービス YAML 定義に clusterIP: None パラメーターを追加します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
次の例のように、仮想マシンを公開するための
Serviceマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Serviceマニフェストファイルを保存します。 以下のコマンドを実行してサービスを作成します。
oc create -f headless_service.yaml
$ oc create -f headless_service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.2. CLI を使用した仮想マシンのヘッドレスサービスへのマッピング リンクのコピーリンクがクリップボードにコピーされました!
内部の完全修飾ドメイン名 (FQDN) を使用してクラスター内から仮想マシン (VM) に接続するには、まず仮想マシンをヘッドレスサービスにマップする必要があります。仮想マシン設定ファイルに spec.hostname および spec.subdomain パラメーターを設定します。
サブドメインと名前が一致するヘッドレスサービスが存在する場合、<vm.spec.hostname>.<vm.spec.subdomain>.<vm.metadata.namespace>.svc.cluster.local の形式で仮想マシンに対して一意の DNS A レコードが作成されます。
手順
次のコマンドを実行して、
VirtualMachineマニフェストを編集し、サービスセレクターラベルとサブドメインを追加します。oc edit vm <vm_name>
$ oc edit vm <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow VirtualMachineマニフェストファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存し、エディターを終了します。
- 仮想マシンを再起動して変更を適用します。
8.4.3. 内部 FQDN を使用した仮想マシンへの接続 リンクのコピーリンクがクリップボードにコピーされました!
内部の完全修飾ドメイン名 (FQDN) を使用して仮想マシン (VM) に接続できます。
前提条件
-
virtctlツールがインストールされている。 -
Web コンソールから仮想マシンの内部 FQDN を特定するか、仮想マシンをヘッドレスサービスにマッピングしている。内部 FQDN の形式は
<vm.spec.hostname>.<vm.spec.subdomain>.<vm.metadata.namespace>.svc.cluster.localです。
手順
次のコマンドを入力して仮想マシンコンソールに接続します。
virtctl console vm-fedora
$ virtctl console vm-fedoraCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要求された FQDN を使用して仮想マシンに接続するには、次のコマンドを実行します。
ping myvm.mysubdomain.<namespace>.svc.cluster.local
$ ping myvm.mysubdomain.<namespace>.svc.cluster.localCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
PING myvm.mysubdomain.default.svc.cluster.local (10.244.0.57) 56(84) bytes of data. 64 bytes from myvm.mysubdomain.default.svc.cluster.local (10.244.0.57): icmp_seq=1 ttl=64 time=0.029 ms
PING myvm.mysubdomain.default.svc.cluster.local (10.244.0.57) 56(84) bytes of data. 64 bytes from myvm.mysubdomain.default.svc.cluster.local (10.244.0.57): icmp_seq=1 ttl=64 time=0.029 msCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例では、
myvm.mysubdomain.default.svc.cluster.localの DNS エントリーは10.244.0.57を指しています。これは、現在仮想マシンに割り当てられているクラスター IP アドレスです。
8.5. Linux ブリッジネットワークへの仮想マシンの接続 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、OpenShift Virtualization は単一の内部 Pod ネットワークとともにインストールされます。
次の手順を実行すると、Linux ブリッジネットワークを作成し、そのネットワークに仮想マシンを接続できます。
- Linux ブリッジ Node Network Configuration Policy (NNCP) を作成 します。
- Web コンソール または コマンドライン を使用して、Linux ブリッジネットワークアタッチメント定義 (NAD) を作成します。
- Web コンソール または コマンドライン を使用して、NAD を認識するように仮想マシンを設定します。
OpenShift Virtualization は、Linux ブリッジボンディングモード 0、5、および 6 をサポートしていません。詳細は、Which bonding modes work when used with a bridge that virtual machine guests or containers connect to? を参照してください。
8.5.1. Linux ブリッジ NNCP の作成 リンクのコピーリンクがクリップボードにコピーされました!
Linux ブリッジネットワークの NodeNetworkConfigurationPolicy (NNCP) マニフェストを作成できます。
前提条件
- Kubernetes NMState Operator がインストールされている。
手順
NodeNetworkConfigurationPolicyマニフェストを作成します。この例には、独自の情報で置き換える必要のあるサンプルの値が含まれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5.2. Linux ブリッジ NAD の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールまたはコマンドラインを使用して、Linux ブリッジ Network Attachment Definition (NAD) を作成できます。
8.5.2.1. Web コンソールを使用した Linux ブリッジ NAD の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、Network Attachment Definition (NAD) を作成して、Pod および仮想マシンに layer-2 ネットワークを提供できます。
Linux ブリッジ Network Attachment Definition は、仮想マシンを VLAN に接続するための最も効率的な方法です。
仮想マシンのネットワークアタッチメント定義での IP アドレス管理 (IPAM) の設定はサポートされていません。
手順
- Web コンソールで、Networking → NetworkAttachmentDefinitions をクリックします。
Create Network Attachment Definition をクリックします。
注記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 をクリックします。
8.5.2.2. コマンドラインを使用した Linux ブリッジ NAD の作成 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用してネットワークアタッチメント定義 (NAD) を作成し、Pod および仮想マシンに layer-2 ネットワークを提供できます。
NAD と仮想マシンは同じ namespace に存在する必要があります。
仮想マシンのネットワークアタッチメント定義での IP アドレス管理 (IPAM) の設定はサポートされていません。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
次の例のように、仮想マシンを
NetworkAttachmentDefinition設定に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
NetworkAttachmentDefinitionオブジェクトの名前。- 2
- オプション: 一部のノードに設定されたブリッジのノード選択に使用するアノテーションのキーと値のペア。このアノテーションをネットワークアタッチメント定義に追加すると、仮想マシンインスタンスが、定義されたブリッジが接続されているノード上でのみ実行されます。
- 3
- 設定の名前。設定名を Network Attachment Definition の
name値に一致させることが推奨されます。 - 4
- この Network Attachment Definition のネットワークを提供する Container Network Interface (CNI) プラグインの実際の名前。異なる CNI を使用するのでない限り、このフィールドは変更しないでください。
- 5
- ノードに設定される Linux ブリッジの名前。この名前は、
NodeNetworkConfigurationPolicyマニフェストで定義されているインターフェイスブリッジ名と一致する必要があります。 - 6
- オプション: MAC スプーフィングチェックを有効にするフラグ。
trueに設定すると、Pod またはゲストインターフェイスの MAC アドレスを変更できません。この属性により、Pod から出ることができる MAC アドレスは 1 つだけになり、MAC スプーフィング攻撃に対するセキュリティーが確保されます。 - 7
- オプション: VLAN タグ。Node Network Configuration Policy では、追加の VLAN 設定は必要ありません。
- 8
- オプション: 仮想マシンがデフォルト VLAN 経由でブリッジに接続するかどうかを示します。デフォルト値は
trueです。
注記Linux ブリッジ Network Attachment Definition は、仮想マシンを VLAN に接続するための最も効率的な方法です。
Network Attachment Definition を作成します。
oc create -f network-attachment-definition.yaml
$ oc create -f network-attachment-definition.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ここで、
network-attachment-definition.yamlは Network Attachment Definition マニフェストのファイル名です。
検証
次のコマンドを実行して、ネットワーク接続定義が作成されたことを確認します。
oc get network-attachment-definition bridge-network
$ oc get network-attachment-definition bridge-networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5.3. 仮想マシンネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールまたはコマンドラインを使用して、仮想マシンネットワークインターフェイスを設定できます。
8.5.3.1. Web コンソールを使用した仮想マシンネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、仮想マシンのネットワークインターフェイスを設定できます。
前提条件
- ネットワークの Network Attachment Definition を作成している。
手順
- Virtualization → VirtualMachines に移動します。
- 仮想マシンをクリックして、VirtualMachine details ページを表示します。
- Configuration タブで、Network interfaces タブをクリックします。
- Add network interface をクリックします。
- インターフェイス名を入力し、Network リストから Network Attachment Definition を選択します。
- Save をクリックします。
- 仮想マシンを再起動またはライブマイグレーションして、変更を適用します。
ネットワークフィールド
| Name | 説明 |
|---|---|
| Name | ネットワークインターフェイスコントローラーの名前。 |
| モデル | ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
| ネットワーク | 利用可能な Network Attachment Definition のリスト。 |
| 型 | 利用可能なバインディングメソッドの一覧。ネットワークインターフェイスに適したバインド方法を選択します。
|
| MAC Address | ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
8.5.3.2. コマンドラインを使用した仮想マシンネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインを使用して、ブリッジネットワークの仮想マシンネットワークインターフェイスを設定できます。
前提条件
- 設定を編集する前に仮想マシンをシャットダウンします。実行中の仮想マシンを編集する場合は、変更を有効にするために仮想マシンを再起動する必要があります。
手順
次の例のように、ブリッジインターフェイスとネットワークアタッチメント定義を仮想マシン設定に追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用します。
oc apply -f example-vm.yaml
$ oc apply -f example-vm.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - オプション: 実行中の仮想マシンを編集している場合は、変更を有効にするためにこれを再起動する必要があります。
8.6. 仮想マシンの SR-IOV ネットワークへの接続 リンクのコピーリンクがクリップボードにコピーされました!
次の手順を実行して、仮想マシン (VM) を Single Root I/O Virtualization (SR-IOV) ネットワークに接続できます。
8.6.1. SR-IOV ネットワークデバイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。
SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。再起動は次の場合にのみ行われます。
-
Mellanox NIC (
mlx5ドライバー) の場合、Physical Function (PF) 上の Virtual Function (VF) の数が増加するたびにノードの再起動が行われます。 -
Intel NIC の場合、カーネルパラメーターに
intel_iommu=onとiommu=ptが含まれていない場合にのみ再起動が行われます。
設定の変更が適用されるまでに数分かかる場合があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされている。
- ドレイン (解放) されたノードからエビクトされたワークロードを処理するために、クラスター内に利用可能な十分なノードがある。
- SR-IOV ネットワークデバイス設定にコントロールプレーンノードを選択していない。
手順
SriovNetworkNodePolicyオブジェクトを作成してから、YAML を<name>-sriov-node-network.yamlファイルに保存します。<name>をこの設定の名前に置き換えます。Copy to Clipboard Copied! Toggle word