Red Hat SummitVirtualization
OpenShift Virtualization のインストール、使用方法、およびリリースノート
概要
第1章 OpenShift Virtualization について
OpenShift Virtualization の機能およびサポート範囲について確認します。
1.1. OpenShift Virtualization の機能
OpenShift Virtualization は OpenShift Container Platform のアドオンであり、仮想マシンのワークロードを実行し、このワークロードをコンテナーのワークロードと共に管理することを可能にします。
OpenShift Virtualization は、Kubernetes カスタムリソースにより新規オブジェクトを OpenShift Container Platform クラスターに追加し、仮想化タスクを有効にします。これらのタスクには、以下が含まれます。
- Linux および Windows 仮想マシンの作成と管理
- 各種コンソールおよび CLI ツールの使用による仮想マシンへの接続
- 既存の仮想マシンのインポートおよびクローン作成
- ネットワークインターフェイスコントローラーおよび仮想マシンに割り当てられたストレージディスクの管理
- 仮想マシンのノード間でのライブマイグレーション
機能強化された Web コンソールは、これらの仮想化されたリソースを OpenShift Container Platform クラスターコンテナーおよびインフラストラクチャーと共に管理するためのグラフィカルポータルを提供します。
OpenShift Virtualization は、Red Hat OpenShift Data Foundation の機能とうまく連携するように設計およびテストされています。
OpenShift Data Foundation を使用して OpenShift Virtualization をデプロイする場合は、Windows 仮想マシンディスク用の専用ストレージクラスを作成する必要があります。詳細は 、Windows VM の ODF PersistentVolumes の最適化 を参照してください。
OpenShift Virtualization は、OVN-Kubernetes、OpenShift SDN、または 認定 OpenShift CNI プラグイン にリストされているその他の認定ネットワークプラグインのいずれかで使用できます。
1.1.1. OpenShift Virtualization サポートのクラスターバージョン
OpenShift Virtualization 4.12 は OpenShift Container Platform 4.12 クラスターで使用するためにサポートされます。OpenShift Virtualization の最新の z-stream リリースを使用するには、最初に OpenShift Container Platform の最新バージョンにアップグレードする必要があります。
1.2. シングルノード OpenShift の違い
単一ノードのクラスターに OpenShift Virtualization をインストールできます。
支援付きのインストーラーを使用して単一ノードの OpenShift クラスターをプロビジョニングすると、事前設定された永続ストレージが自動的にデプロイされます。
- OpenShift Virtualization 4.10 および 4.11 では、HostPath Provisioner (HPP) が自動的にインストールされます。
- OpenShift Virtualization 4.12 では、OpenShift Data Foundation Logical Volume Manager Operator は提供される追加設定なしのストレージソリューションです。HPP を使用して手動でデプロイすることもできます。
シングルノード OpenShift は高可用性をサポートしていません。複数ノードクラスターの機能については、以下の違いに注意してください。
- Pod の 停止状態の予算はサポートされていません。
- ライブマイグレーションはサポートされていません。
- ストレージの動作の違いにより、一部の仮想マシンテンプレートは単一ノードの Openshift と互換性がありません。互換性を確保するために、データボリュームまたはストレージプロファイルを使用するテンプレートまたは仮想マシンにエビクションストラテジーを設定しないでください。
第2章 OpenShift Virtualization アーキテクチャー
OpenShift Virtualization アーキテクチャーについて学習します。
2.1. OpenShift Virtualization アーキテクチャーの仕組み
OpenShift Virtualization をインストールすると、Operator Lifecycle Manager (OLM) は、OpenShift Virtualization の各コンポーネントのオペレーター Pod をデプロイします。
-
コンピューティング:
virt-operator -
ストレージ:
cdi-operator -
ネットワーク:
cluster-network-addons-operator -
スケーリング:
ssp-operator -
テンプレート作成:
tekton-tasks-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 コントロールプレーン用の追加コンポーネントなどのリソースを作成します。たとえば、hco-operator が KubeVirt CR を作成すると、virt-operator はそれを調整し、virt-controller、virt-handler、virt-api などの追加リソースを作成します。
OLM は hostpath-provisioner-operator をデプロイしますが、hostpath provisioner (HPP) CR を作成するまで機能しません。
2.2. hco-operator について
hco- operator (HCO) は、OpenShift Virtualization をデプロイおよび管理するための単一のエントリーポイントと、独自のデフォルトを持ついくつかのヘルパー Operator を提供します。また、これらの Operator のカスタム リソース (CR) も作成します。
| コンポーネント | 説明 |
|---|---|
|
|
|
|
|
クラスターから直接ダウンロードできるように、 |
|
| OpenShift Virtualization に必要なすべての Operator、CR、およびオブジェクトが含まれています。 |
|
| SSP CR。これは、HCO によって自動的に作成されます。 |
|
| A CDI CR。これは、HCO によって自動的に作成されます。 |
|
|
|
2.3. cdi-operator について
cdi-operator は、Containerized Data Importer (CDI) とその関連リソースを管理します。これは、データ ボリュームを使用して仮想マシン (VM) イメージを永続ボリューム要求 (PVC) にインポートします。
| コンポーネント | 説明 |
|---|---|
|
| 安全なアップロードトークンを発行して、VM ディスクを PVC にアップロードするための承認を管理します。 |
|
| 外部ディスクのアップロードトラフィックを適切なアップロードサーバー Pod に転送して、正しい PVC に書き込むことができるようにします。有効なアップロードトークンが必要です。 |
|
| データ ボリュームの作成時に仮想マシンイメージを PVC にインポートするヘルパー Pod。 |
2.4. cluster-network-addons-operator について
cluster-network-addons-operator は、ネットワーク コンポーネントをクラスターにデプロイし、ネットワーク機能を拡張するための関連リソースを管理します。
| コンポーネント | 説明 |
|---|---|
|
| Kubemacpool の Webhook の TLS 証明書を管理します。 |
|
| 仮想マシン (VM) ネットワークインターフェイスカード (NIC) の MAC アドレスプールサービスを提供します。 |
|
| ノードで使用可能なネットワークブリッジをノードリソースとしてマークします。 |
|
| クラスターノードに CNI プラグインをインストールし、ネットワーク接続定義を介して Linux ブリッジに VM を接続できるようにします。 |
2.5. hostpath-provisioner-operator について
hostpath-provisioner-operator は、マルチノードホストパスプロビジョナー (HPP) および関連リソースをデプロイおよび管理します。
| コンポーネント | 説明 |
|---|---|
|
| ホストパスプロビジョナー (HPP) の実行が指定されている各ノードにワーカーを提供します。Pod は、指定されたバッキングストレージをノードにマウントします。 |
|
| HPP の Container Storage Interface (CSI) ドライバーインターフェイスを実装します。 |
|
| HPP のレガシードライバーインターフェイスを実装します。 |
2.6. ssp-operator について
ssp-operator は、共通テンプレート、関連するデフォルトのブートソース、およびテンプレートバリデーターをデプロイします。
| コンポーネント | 説明 |
|---|---|
|
|
テンプレートから作成された仮想マシンの |
2.7. tekton-tasks-operator について
tekton-tasks-operator は、VM 用の OpenShift パイプラインの使用法を示すサンプルパイプラインをデプロイします。また、ユーザーがテンプレートから VM を作成し、テンプレートをコピーおよび変更し、データボリュームを作成できるようにする追加の OpenShift Pipeline タスクをデプロイします。
| コンポーネント | 説明 |
|---|---|
|
| テンプレートから仮想マシンを作成します。 |
|
| 仮想マシンテンプレートをコピーします。 |
|
| 仮想マシンテンプレートを作成または削除します。 |
|
| データボリュームまたはデータソースを作成または削除します。 |
|
| 仮想マシンでスクリプトまたはコマンドを実行し、後で仮想マシンを停止または削除します。 |
|
|
|
|
|
|
|
| 特定の VMI ステータスを待機し、そのステータスに従って失敗または成功します。 |
2.8. 仮想 Operator について
virt-operator は、現在の仮想マシン (VM) のワークロードを中断することなく、OpenShift Virtualization をデプロイ、アップグレード、および管理します。
| コンポーネント | 説明 |
|---|---|
|
| すべての仮想化関連フローのエントリーポイントとして機能する HTTP API サーバー。 |
|
|
新しい VM インスタンスオブジェクトの作成を監視し、対応する Pod を作成します。Pod がノードでスケジュールされると、 |
|
|
VM への変更を監視し、必要な操作を実行するように |
|
|
|
第3章 OpenShift Virtualization の開始
基本的な環境をインストールして設定することにより、OpenShift Virtualization の特徴と機能を調べることができます。
クラスター設定手順には、cluster-admin 権限が必要です。
3.1. OpenShift Virtualization の計画とインストール
OpenShift Container Platform クラスターで OpenShift Virtualization を計画およびインストールします。
計画およびインストールのリソース
3.2. 仮想マシンの作成と管理
Web コンソールを使用して仮想マシン (VM) を作成します。
仮想マシンに接続します。
- Web コンソールを使用して、仮想マシンの Serial コンソール または VNC コンソール に接続します。
- SSH を使用して仮想マシンに接続します。
- RDP を使用して Windows 仮想マシンに接続します。
VM を管理します。
3.3. 次のステップ
VM をセカンダリーネットワークに接続します。
- 仮想マシンを Linux ブリッジネットワークに接続します。
- 注記
VM はデフォルトで Pod ネットワークに接続されます。Linux ブリッジや SR-IOV などのセカンダリーネットワークを設定してから、そのネットワークを仮想マシン設定に追加する必要があります。
- Web コンソールを使用して、リソース、詳細、ステータス、およびトップコンシューマーをモニターします。
- Web コンソールを使用して、仮想マシンワークロードに関する概要情報を表示します。
- CLI を使用して OpenShift Virtualization ログを表示します。
-
sysprepを使用して Windows 仮想マシンのデプロイメントを自動化します。 - 仮想マシンをライブマイグレーションします。
- 仮想マシンをバックアップおよび復元します。
第4章 Web コンソールの概要
OpenShift Container Platform Web コンソールの Virtualization セクションには、OpenShift Virtualization 環境を管理および監視するための以下のページが含まれています。
| Page | 説明 |
|---|---|
| OpenShift Virtualization 環境を管理および監視します。 | |
| テンプレートのカタログから VirtualMachine を作成します。 | |
| VirtualMachine を設定および監視します。 | |
| テンプレートを作成および管理します。 | |
| VirtualMachine ブートソースの DataSource を作成および管理します。 | |
| ワークロードの MigrationPolicy を作成および管理します。 |
| アイコン | 説明 |
|---|---|
|
| Edit アイコン |
|
| Link アイコン |
4.1. Overview ページ
Overview ページには、リソース、メトリック、移行の進行状況、およびクラスターレベルの設定が表示されます。
例4.1 Overview ページ
| 要素 | 説明 |
|---|---|
|
virtctl のダウンロード |
リソースを管理するには、 |
| Overview タブ | リソース、使用率、アラート、およびステータス。 |
| CPU、メモリー、およびストレージリソースのトップコンシューマー。 | |
| ライブマイグレーションのステータス。 | |
| Settings タブ | ライブマイグレーションの制限やパーミッションなど、クラスター全体の設定。 |
4.1.1. Overview タブ
Overview タブには、リソース、使用率、アラート、およびステータスが表示されます。
例4.2 Overview タブ
| 要素 | 説明 |
|---|---|
| Getting started resources カード |
|
| VirtualMachines タイル | 過去 7 日間の傾向を示すグラフを含む VirtualMachine の数。 |
| vCPU usage タイル | 過去 7 日間の傾向を示すグラフを含む vCPU 使用率。 |
| Memory タイル | 過去 7 日間の傾向を示すグラフを含むメモリー使用率。 |
| Storage タイル | 過去 7 日間の傾向を示すグラフを含むストレージ使用率。 |
| Alerts タイル | 重大度別にグループ化された OpenShift Virtualization アラート。 |
| VirtualMachine statuses タイル | ステータス別にグループ化された VirtualMachine の数。 |
| VirtualMachines per template グラフ | テンプレート名でグループ化された、テンプレートから作成された VirtualMachine の数。 |
4.1.2. Top consumers タブ
Top consumers タブには、CPU、メモリー、およびストレージのトップコンシューマーが表示されます。
例4.3 Top consumers タブ
| 要素 | 説明 |
|---|---|
|
仮想化ダッシュボードを表示 | OpenShift Virtualization のトップコンシューマーを表示する Observe → Dashboards へのリンク。 |
| Time period リスト | 結果をフィルタリングする期間を選択します。 |
| Top consumers リスト | 結果をフィルタリングするトップコンシューマーの数を選択します。 |
| CPU グラフ | CPU 使用率が最も高い VirtualMachine。 |
| Memory グラフ | メモリー使用率が最も多い VirtualMachine。 |
| Memory swap traffic グラフ | メモリースワップトラフィックが最も多い VirtualMachine。 |
| vCPU wait グラフ | vCPU 待機時間が最も長い VirtualMachine。 |
| Storage throughput グラフ | ストレージスループットの使用率が最も高い VirtualMachines。 |
| Storage IOPS グラフ | 1 秒あたりのストレージ入出力操作の使用率が最も高い VirtualMachines。 |
4.1.3. Migrations タブ
Migrations タブには、VirtualMachineInstance の移行のステータスが表示されます。
例4.4 Migrations タブ
| 要素 | 説明 |
|---|---|
| Time period リスト | VirtualMachineInstanceMigration をフィルタリングする期間を選択します。 |
| VirtualMachineInstanceMigrations テーブル | VirtualMachineInstance 移行のリスト。 |
4.1.4. Settings タブ
Settings タブには、次のタブにクラスター全体の設定が表示されます。
| タブ | 説明 |
|---|---|
| General タブ | OpenShift Virtualization のバージョンと更新ステータス。 |
| Live migration タブ | ライブマイグレーションの制限とネットワーク設定。 |
| Red Hat テンプレートのプロジェクト。 | |
| クラスター全体のパーミッション。 |
4.1.4.1. General タブ
General タブには、OpenShift Virtualization のバージョンと更新ステータスが表示されます。
例4.5 General タブ
| Label | 説明 |
|---|---|
| サービス名 | OpenShift Virtualization |
| Provider | Red Hat |
| インストール済みバージョン | 4.12.16 |
| 更新ステータス |
例: |
| Channel | 更新用に選択されたチャネル。 |
4.1.4.2. Live migration タブ
Live migration タブでライブマイグレーションを設定できます。
例4.6 Live migration タブ
| 要素 | 説明 |
|---|---|
| Max. migrations per cluster フィールド | クラスターごとのライブマイグレーションの最大数を選択します。 |
| Max. migrations per node フィールド | ノードごとのライブマイグレーションの最大数を選択します。 |
| Live migration network リスト | ライブマイグレーション専用のセカンダリーネットワークを選択します。 |
4.1.4.3. Templates project タブ
Templates project タブで、テンプレートのプロジェクトを選択できます。
例4.7 Templates project タブ
| 要素 | 説明 |
|---|---|
| Project リスト |
Red Hat テンプレートを保存するプロジェクトを選択します。デフォルトのテンプレートプロジェクトは 複数のテンプレートプロジェクトを定義する場合は、各プロジェクトの Templates ページ でテンプレートを複製する必要があります。 |
4.1.4.4. User permissions タブ
User permissions タブには、タスクに対するクラスター全体のパーミッションが表示されます。
例4.8 User permissions タブ
| 要素 | 説明 |
|---|---|
| User Permissions テーブル | テンプレートの共有 やパーミッションなどのタスクのリスト。 |
4.2. Catalog ページ
Catalog ページでテンプレートを選択して、VirtualMachine を作成できます。
例4.9 Catalog ページ
| 要素 | 説明 |
|---|---|
| Templates project リスト | テンプレートが配置されているプロジェクトを選択します。
デフォルトでは、Red Hat テンプレートは |
| All items|Default templates | Default templates をクリックして、デフォルトのテンプレートのみを表示します。 |
| Boot source available チェックボックス | チェックボックスをオンにして、使用可能なブートソースを含むテンプレートを表示します。 |
| Operating system チェックボックス | チェックボックスをオンにして、選択したオペレーティングシステムのテンプレートを表示します。 |
| Workload チェックボックス | チェックボックスをオンにして、選択したワークロードを含むテンプレートを表示します。 |
| Search フィールド | テンプレートをキーワードで検索します。 |
| テンプレートタイル | テンプレートタイルをクリックして、テンプレートの詳細を表示し、VirtualMachine を作成します。 |
4.3. VirtualMachines ページ
VirtualMachines ページで VirtualMachine を作成および管理できます。
例4.10 VirtualMachines ページ
| 要素 | 説明 |
|---|---|
| Create → From catalog | Catalog ページで VirtualMachine を作成します。 |
| Create → With YAML | YAML 設定ファイルを編集して VirtualMachine を作成します。 |
| Filter フィールド | ステータス、テンプレート、オペレーティングシステム、またはノードで VirtualMachine をフィルタリングします。 |
| Search フィールド | 名前またはラベルで VirtualMachine を検索します。 |
| VirtualMachines テーブル | VirtualMachine のリスト。
VirtualMachine の横の Options メニュー
VirtualMachine をクリックして、VirtualMachine details ページに移動します。 |
4.3.1. VirtualMachine details ページ
VirtualMachine details ページで VirtualMachine を設定できます。
例4.11 VirtualMachine details ページ
| 要素 | 説明 |
|---|---|
| Actions メニュー | Actions メニューをクリックして、Stop、Restart、Pause、Clone、Migrate、Copy SSH command、Edit labels、Edit annotations、または Delete を選択します。 |
| Overview タブ | リソースの使用率、アラート、ディスク、およびデバイス。 |
| VirtualMachine 設定。 | |
| Metrics タブ | メモリー、CPU、ストレージ、ネットワーク、移行のメトリクス。 |
| VirtualMachine YAML 設定ファイル。 | |
| スケジューリング設定。 | |
| Environment タブ | 設定マップ、シークレット、およびサービスアカウントの管理。 |
| Events タブ | VirtualMachine イベントストリーム。 |
| コンソールセッション管理。 | |
| ネットワークインターフェイス管理。 | |
| ディスク管理。 | |
| Cloud-init と SSH キーの管理。 | |
| Snapshots タブ | スナップショット管理 |
4.3.1.1. Overview タブ
Overview タブには、リソースの使用率、アラート、および設定情報が表示されます。
例4.12 Overview タブ
| 要素 | 説明 |
|---|---|
| Details タイル | VirtualMachine の一般情報。 |
| Utilization タイル | CPU、Memory、Storage、および Network transfer グラフ。 |
| Hardware devices タイル | GPU とホストデバイス。 |
| Alerts タイル | 重大度別にグループ化された OpenShift Virtualization アラート。 |
| Snapshots タイル |
Take snapshot |
| Network interfaces タイル | Network interfaces テーブル。 |
| Disks タイル | Disks テーブル。 |
4.3.1.2. Details タブ
Details タブで VirtualMachine を設定できます。
例4.13 Details タブ
| 要素 | 説明 |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| 名前 | VirtualMachine 名。 |
| namespace | VirtualMachine の namespace。 |
| ラベル | 編集アイコンをクリックして、ラベルを編集します。 |
| Annotations | 編集アイコンをクリックして、注釈を編集します。 |
| 説明 | 編集アイコンをクリックして、説明を入力します。 |
| Operating system | オペレーティングシステム名。 |
| CPU|Memory | 編集アイコンをクリックして、CPU|Memory 要求を編集します。
CPU の数は、 |
| マシンタイプ | VirtualMachine マシンタイプ。 |
| 起動モード | 編集アイコンをクリックして、起動モードを編集します。 |
| 一時停止モードで開始 | 編集アイコンをクリックして、この設定を有効にします。 |
| Template | VirtualMachine の作成に使用されるテンプレートの名前。 |
| 作成日時 | VirtualMachine の作成日。 |
| Owner | VirtualMachine の所有者。 |
| ステータス | VirtualMachine の状態。 |
| Pod |
|
| VirtualMachineInstance | VirtualMachine インスタンス名。 |
| ブート順序 | 編集アイコンをクリックして、起動ソースを選択します。 |
| IP アドレス | VirtualMachine の IP アドレス。 |
| ホスト名 | VirtualMachine のホスト名。 |
| タイムゾーン | VirtualMachine のタイムゾーン。 |
| ノード | VirtualMachine が実行されているノード。 |
| Workload profile | 編集アイコンをクリックして、ワークロードプロファイルを編集します。 |
| virtctl を使用している SSH |
コピーアイコンをクリックして、 |
| SSH over NodePort |
Create a Service to expose your VirtualMachine for SSH access を選択すると、 |
| GPU デバイス | 編集アイコンをクリックして、GPU デバイスを追加します。 |
| Host devices | 編集アイコンをクリックして、ホストデバイスを追加します。 |
| Services セクション | サービスを表示します。 |
| Active users セクション | アクティブなユーザーを表示します。 |
4.3.1.3. Metrics タブ
Metrics タブには、メモリー、CPU、ストレージ、ネットワーク、および移行の使用率グラフが表示されます。
例4.14 Metrics タブ
| 要素 | 説明 |
|---|---|
| Time range リスト | 結果をフィルタリングする期間を選択します。 |
|
Virtualization ダッシュボード | 現在のプロジェクトの Workloads タブにリンクします。 |
| Utilization セクション | Memory、CPU、および Network interface グラフ。 |
| Storage セクション | Storage total read/write および Storage iops total read/write グラフ。 |
| Network セクション | Network in、Network out、および Network bandwidth グラフ。 |
| Migration セクション | Migration および KV data transfer rate グラフ。 |
4.3.1.4. YAML タブ
YAML タブで YAML ファイルを編集して、VirtualMachine を設定できます。
例4.15 YAML タブ
| 要素 | 説明 |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Save ボタン | 変更を YAML ファイルに保存します。 |
| Reload ボタン | 変更を破棄し、YAML ファイルをリロードします。 |
| Cancel ボタン | YAML タブを終了します。 |
| Download ボタン | YAML ファイルをローカルマシンにダウンロードします。 |
4.3.1.5. Scheduling タブ
Scheduling タブでスケジュールを設定できます。
例4.16 Scheduling タブ
| 設定 | Description |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Node selector | 編集アイコンをクリックして、ラベルを追加し、適格なノードを指定します。 |
| 容認 | 編集アイコンをクリックして、許容範囲を追加し、適格なノードを指定します。 |
| アフィニティールール | 編集アイコンをクリックして、アフィニティールールを追加します。 |
| Descheduler スイッチ | Descheduler を有効または無効にします。Descheduler は、実行中の Pod をエビクトして、Pod をより適切なノードに再スケジュールできるようにします。 |
| 専用リソース | 編集アイコンをクリックして、Schedule this workload with dedicated resources (guaranteed policy) を選択します。 |
| エビクションストラテジー | 編集アイコンをクリックして、VirtualMachineInstance エビクション戦略として LiveMigrate を選択します。 |
4.3.1.6. Environment タブ
Environment タブで設定マップ、シークレット、およびサービスアカウントを管理できます。
例4.17 Environment タブ
| 要素 | 説明 |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
|
Add Config Map, Secret or Service Account | リンクをクリックして、リソースリストから設定マップ、シークレット、またはサービスアカウントを選択します。 |
4.3.1.7. Events タブ
Events タブには、VirtualMachine イベントのリストが表示されます。
4.3.1.8. Console タブ
Console タブで、VirtualMachine へのコンソールセッションを開くことができます。
例4.18 Console タブ
| 要素 | 説明 |
|---|---|
| Guest login credentials セクション |
Guest login credentials を展開して、 |
| Console リスト | VNC コンソール または Serial コンソール を選択します。 デスクトップビューアー を選択して、リモートデスクトッププロトコル (RDP) を使用して Windows Virtual Machines に接続できます。同じネットワーク上のマシンに RDP クライアントをインストールする必要があります。 |
| Send key リスト | コンソールに送信するキーストロークの組み合わせを選択します。 |
| Disconnect ボタン | コンソール接続を切断します。 新しいコンソールセッションを開く場合は、コンソール接続を手動で切断する必要があります。それ以外の場合、最初のコンソールセッションは引き続きバックグラウンドで実行されます。 |
4.3.1.9. Network interfaces タブ
Network interfaces タブでネットワークインターフェイスを管理できます。
例4.19 Network interfaces タブ
| 設定 | Description |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Add network interface ボタン | VirtualMachine にネットワークインターフェイスを追加します。 |
| Filter フィールド | インターフェイスタイプでフィルタリングします。 |
| Search フィールド | 名前またはラベルでネットワークインターフェイスを検索します。 |
| Network interface テーブル | ネットワークインターフェイスのリスト。
ネットワークインターフェースの横にある Options メニュー
|
4.3.1.10. Disks タブ
Disks タブでディスクを管理できます。
例4.20 Disks タブ
| 設定 | Description |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Add disk ボタン | VirtualMachine にディスクを追加します。 |
| Filter フィールド | ディスクの種類でフィルタリングします。 |
| Search フィールド | ディスクを名前で検索します。 |
| Disks テーブル | VirtualMachine ディスクのリスト。
ディスクの横にある Options メニュー
|
| File systems テーブル | VirtualMachine ファイルシステムのリスト。 |
4.3.1.11. Scripts タブ
Scripts タブで、VirtualMachine の cloud-init および SSH キーを管理できます。
例4.21 Scripts タブ
| 要素 | 説明 |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Cloud-init | 編集アイコンをクリックして、cloud-init 設定を編集します。 |
| 認可された SSH キー | 編集アイコンをクリックして、新しいシークレットを作成するか、既存のシークレットを添付します。 |
4.3.1.12. Snapshots タブ
Snapshots タブで、スナップショットを作成し、スナップショットから VirtualMachine を復元できます。
例4.22 Snapshots タブ
| 要素 | 説明 |
|---|---|
| Take snapshot ボタン | スナップショットを作成します。 |
| Filter フィールド | スナップショットをステータスでフィルタリングします。 |
| Search フィールド | 名前またはラベルでスナップショットを検索します。 |
| Snapshot テーブル | スナップショットのリスト。
スナップショットの横にある Options メニュー
|
4.4. Templates ページ
Templates ページで VirtualMachine テンプレートを作成、編集、および複製できます。
Red Hat テンプレートは編集できません。Red Hat テンプレートを複製して編集し、カスタムテンプレートを作成できます。
例4.23 Templates ページ
| 要素 | 説明 |
|---|---|
| Create Template ボタン | YAML 設定ファイルを編集してテンプレートを作成します。 |
| Filter フィールド | テンプレートをタイプ、ブートソース、テンプレートプロバイダー、またはオペレーティングシステムでフィルタリングします。 |
| Search フィールド | 名前またはラベルでテンプレートを検索します。 |
| Templates テーブル | テンプレートのリスト。
テンプレートの横にある Options メニュー
|
4.4.1. テンプレートの詳細ページ
テンプレートの詳細 ページで、テンプレートの設定を表示し、カスタムテンプレートを編集できます。
例4.24 テンプレートの詳細ページ
| 要素 | 説明 |
|---|---|
| Actions メニュー | Actions メニューをクリックして、Edit、Clone、Edit boot source、Edit boot source reference の Edit labels の Edit annotations、または Delete を選択します。 |
| テンプレートの設定と設定。 | |
| YAML 設定ファイル。 | |
| スケジューリング設定。 | |
| ネットワークインターフェイス管理。 | |
| ディスク管理。 | |
| Cloud-init、SSH キー、および Sysprep の管理。 | |
| Parameters タブ | パラメーター |
4.4.1.1. Details タブ
Details タブでカスタムテンプレートを設定できます。
例4.25 Details タブ
| 要素 | 説明 |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| 名前 | テンプレート名 |
| namespace | テンプレートの namespace。 |
| Labels | 編集アイコンをクリックして、ラベルを編集します。 |
| Annotations | 編集アイコンをクリックして、注釈を編集します。 |
| Display name | 編集アイコンをクリックして、表示名を編集します。 |
| Description | 編集アイコンをクリックして、説明を入力します。 |
| Operating system | オペレーティングシステム名。 |
| CPU|Memory | 編集アイコンをクリックして、CPU|Memory 要求を編集します。
CPU の数は、 |
| Machine type | テンプレートマシンタイプ。 |
| Boot mode | 編集アイコンをクリックして、起動モードを編集します。 |
| Base template | このテンプレートの作成に使用されたベーステンプレートの名前。 |
| Created at | テンプレートの作成日。 |
| Owner | テンプレート所有者。 |
| Boot order | テンプレートの起動順序。 |
| Boot source | ブートソースの可用性。 |
| プロバイダー | テンプレートプロバイダー |
| Support | テンプレートのサポートレベル。 |
| GPU devices | 編集アイコンをクリックして、GPU デバイスを追加します。 |
| Host devices | 編集アイコンをクリックして、ホストデバイスを追加します。 |
4.4.1.2. YAML タブ
YAML タブで YAML ファイルを編集して、カスタムテンプレートを設定できます。
例4.26 YAML タブ
| 要素 | 説明 |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Save ボタン | 変更を YAML ファイルに保存します。 |
| Reload ボタン | 変更を破棄し、YAML ファイルをリロードします。 |
| Cancel ボタン | YAML タブを終了します。 |
| Download ボタン | YAML ファイルをローカルマシンにダウンロードします。 |
4.4.1.3. Scheduling タブ
Scheduling タブでスケジュールを設定できます。
例4.27 Scheduling タブ
| 設定 | Description |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Node selector | 編集アイコンをクリックして、ラベルを追加し、適格なノードを指定します。 |
| 容認 | 編集アイコンをクリックして、許容範囲を追加し、適格なノードを指定します。 |
| アフィニティールール | 編集アイコンをクリックして、アフィニティールールを追加します。 |
| Descheduler スイッチ | Descheduler を有効または無効にします。Descheduler は、実行中の Pod をエビクトして、Pod をより適切なノードに再スケジュールできるようにします。 |
| 専用リソース | 編集アイコンをクリックして、Schedule this workload with dedicated resources (guaranteed policy) を選択します。 |
| エビクションストラテジー | 編集アイコンをクリックして、VirtualMachineInstance エビクション戦略として LiveMigrate を選択します。 |
4.4.1.4. Network interfaces タブ
Network interfaces タブでネットワークインターフェイスを管理できます。
例4.28 Network interfaces タブ
| 設定 | Description |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Add network interface ボタン | テンプレートにネットワークインターフェイスを追加します。 |
| Filter フィールド | インターフェイスタイプでフィルタリングします。 |
| Search フィールド | 名前またはラベルでネットワークインターフェイスを検索します。 |
| Network interface テーブル | ネットワークインターフェイスのリスト。
ネットワークインターフェースの横にある Options メニュー
|
4.4.1.5. Disks タブ
Disks タブでディスクを管理できます。
例4.29 Disks タブ
| 設定 | Description |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Add disk ボタン | テンプレートにディスクを追加します。 |
| Filter フィールド | ディスクの種類でフィルタリングします。 |
| Search フィールド | ディスクを名前で検索します。 |
| Disks テーブル | テンプレートディスクのリスト。
ディスクの横にある Options メニュー
|
4.4.1.6. Scripts タブ
Scripts タブで、cloud-init 設定、SSH キー、および Sysprep 応答ファイルを管理できます。
例4.30 Scripts タブ
| 要素 | 説明 |
|---|---|
| YAML スイッチ | ON を設定して、YAML 設定ファイルでライブの変更を表示します。 |
| Cloud-init | 編集アイコンをクリックして、cloud-init 設定を編集します。 |
| 認可された SSH キー | 編集アイコンをクリックして、新しいシークレットを作成するか、既存のシークレットを添付します。 |
| Sysprep |
編集アイコンをクリックして |
4.4.1.7. パラメータータブ
パラメーター タブで、選択したテンプレート設定を編集できます。
例4.31 パラメータータブ
| 要素 | Description |
|---|---|
| VM name | 生成された値には Generated (expression)、デフォルト値を設定するには Value、または Default value type リストから None を選択します。 |
| データソースの namespace | 生成された値には Generated (expression)、デフォルト値を設定するには Value、または Default value type リストから None を選択します。 |
| cloud-user パスワード | 生成された値には Generated (expression)、デフォルト値を設定するには Value、または Default value type リストから None を選択します。 |
4.5. DataSources ページ
DataSources ページで、VirtualMachine ブートソースの DataSource を作成および設定できます。
DataSource を作成すると、DataImportCron リソースは、ブートソースの自動更新を無効にしないかぎり、ディスクイメージをポーリングしてインポートする cron ジョブを定義します。
例4.32 DataSources ページ
| 要素 | Description |
|---|---|
| Create DataSource → With form | レジストリー URL、ディスクサイズ、リビジョン数、および cron 式をフォームに入力して、DataSource を作成します。 |
| Create DataSources → With YAML | YAML 設定ファイルを編集して DataSource を作成します。 |
| Filter フィールド | 利用可能な DataImportCron などの属性で DataSource をフィルタリングします。 |
| Search フィールド | 名前またはラベルで DataSource を検索します。 |
| DataSources テーブル | データソースのリスト。
DataSource の横にある Options メニュー
|
DataSource をクリックして、DataSource details ページを表示します。
4.5.1. DataSource details ページ
DataSource details ページで DataSource を設定できます。
例4.33 DataSource details ページ
| 要素 | 説明 |
|---|---|
| Details タブ | フォームを編集して DataSource を設定します。 |
| YAML タブ | YAML 設定ファイルを編集して DataSource を設定します。 |
| Actions メニュー | Edit labels、Edit annotations、または Delete を選択します。 |
| 名前 | データソース名。 |
| namespace | データソースの namespace。 |
| Labels | 編集アイコンをクリックして、ラベルを編集します。 |
| Annotations | 編集アイコンをクリックして、注釈を編集します。 |
| Conditions | DataSource のステータス条件を表示します。 |
4.6. MigrationPolicies ページ
MigrationPolicies ページでワークロードの MigrationPolicy を管理できます。
例4.34 MigrationPolicies ページ
| 要素 | Description |
|---|---|
| Create MigrationPolicy → With form | フォームに設定とラベルを入力して、MigrationPolicy を作成します。 |
| Create MigrationPolicy → With YAML | YAML 設定ファイルを編集して MigrationPolicy を作成します。 |
| Name | Label 検索フィールド | 名前またはラベルで MigrationPolicy を検索します。 |
| MigrationPolicies テーブル | MigrationPolicy のリスト。
MigrationPolicy の横にある Options メニューをクリックして、
|
MigrationPolicy をクリックして、MigrationPolicy details ページを表示します。
4.6.1. MigrationPolicy details ページ
MigrationPolicy details ページで MigrationPolicy を設定できます。
例4.35 MigrationPolicy details ページ
| 要素 | 説明 |
|---|---|
| Details タブ | フォームを編集して MigrationPolicy を設定します。 |
| YAML タブ | YAML 設定ファイルを編集して MigrationPolicy を設定します。 |
| Actions メニュー | Edit または Delete を選択します。 |
| 名前 | MigrationPolicy 名。 |
| Description | MigrationPolicy の説明。 |
| 設定 | 編集アイコンをクリックして、MigrationPolicy 設定を更新します。 |
| 移行ごとの帯域幅 |
移行ごとの帯域幅要求。帯域幅を無制限にするには、値を |
| 自動収束 | 自動収束ポリシー。 |
| ポストコピー | ポストコピーポリシー。 |
| 完了タイムアウト | 秒単位の完了タイムアウト値。 |
| プロジェクトラベル | Edit をクリックして、プロジェクトラベルを編集します。 |
| VirtualMachine のラベル | Edit をクリックして、VirtualMachine のラベルを編集します。 |
第5章 OpenShift Virtualization リリースノート
5.1. 多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、用語の置き換えは、今後の複数のリリースにわたって段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
5.2. Red Hat OpenShift Virtualization について
Red Hat OpenShift Virtualization は、従来の仮想マシン (VM) をコンテナーと共に実行される OpenShift Container Platform に組み込み、それらをネイティブ Kubernetes オブジェクトとして管理することを可能にします。
OpenShift Virtualization は、
アイコンで表されます。
OVN-Kubernetes または OpenShiftSDN のデフォルトの Container Network Interface (CNI) ネットワークプロバイダーで、OpenShift Virtualization を使用できます。
OpenShift Virtualization の機能 を参照してください。
OpenShift Virtualization のアーキテクチャーとデプロイメント の詳細を参照してください。
OpenShift Virtualization 用に クラスターを準備します。
5.2.1. OpenShift Virtualization サポートのクラスターバージョン
OpenShift Virtualization 4.12 は OpenShift Container Platform 4.12 クラスターで使用するためにサポートされます。OpenShift Virtualization の最新の z-stream リリースを使用するには、最初に OpenShift Container Platform の最新バージョンにアップグレードする必要があります。
5.2.2. サポート対象のゲストオペレーティングシステム
OpenShift Virtualization でサポートされているゲストオペレーティングシステムを確認するにはCertified Guest Operating Systems in Red Hat OpenStack Platform, Red Hat Virtualization and OpenShift Virtualization参照してください。
5.3. 新機能および変更された機能
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 8 という名前が付けられます。
- Intel および AMD CPU。
-
OpenShift Virtualization は、
ロゴを使用しません。OpenShift Virtualization は現在、バージョン 4.9 以降の
ロゴで表されます。
-
virtctl memory-dumpコマンド を使用して、フォレンジック分析用の仮想マシンメモリーダンプを作成できます。
-
virtctl vmexportコマンドを使用するかVirtualMachineExportカスタムリソースを作成することにより、仮想マシン (VM) や VM スナップショット、または永続ボリューム請求 (PVC) から ボリュームをエクスポートおよびダウンロード して、異なるクラスタまたは同じクラスタの異なる namespace で再作成することが可能です。フォレンジック分析のためにメモリーダンプをエクスポートすることもできます。
- OpenShift Virtualization Web コンソールの機能と設定については、Web コンソールの概要ドキュメント を参照してください。
-
virtctl sshコマンドを 使用して、ローカル SSH クライアントを使用する か、OpenShift Container Platform Web コンソールから SSH コマンドをコピー することにより、SSH トラフィックを仮想マシンに転送できます。
-
スタンドアロンのデータボリューム、および
dataVolumeTemplateを使用して VM 用のディスクを準備するときに作成されたデータボリュームは、システムに保存されなくなりました。PVC の作成後、データボリュームは自動的にガベージコレクションおよび削除されるようになりました。
- OpenShift Virtualization は、OpenShift Container Platform モニタリングダッシュボードを使用してアクセスできる ライブマイグレーションメトリック を提供するようになりました。
-
OpenShift Virtualization Operator は、
APIServerカスタムリソースからクラスター全体の TLS セキュリティープロファイル を読み取り、それを仮想化、ストレージ、ネットワーキング、およびインフラストラクチャーを含む OpenShift Virtualization コンポーネントに伝播するようになりました。
- OpenShift Virtualization には、アラートをトリガーする問題のトラブルシューティングに役立つ ランブック があります。アラートは、Web コンソールの Virtualization → Overview ページに表示されます。各 Runbook はアラートを定義し、問題を診断して解決するための手順を提供します。この機能は、以前はテクノロジープレビューとして導入されていましたが、現在一般提供されています。
5.3.1. クイックスタート
-
クイックスタートツアーは、複数の OpenShift Virtualization 機能で利用できます。ツアーを表示するには、OpenShift Virtualization コンソールのヘッダーのメニューバーにある Help アイコン ? をクリックし、Quick Starts を選択します。Filter フィールドに
virtualizationキーワードを入力して、利用可能なツアーをフィルターできます。
5.3.2. ネットワーク
- OpenShift Container Platform クラスターのチェックアップを実行する namespace を指定 できるようになりました。
- レイヤー 2 モードで MetalLB Operator を使用して、負荷分散サービスを設定 できるようになりました。
5.3.3. Web コンソール
Virtualization → Overview ページには、次の使いやすさの拡張機能があります。
- Download virtctl リンクが利用可能です。
- リソース情報は、管理ユーザーおよび非管理ユーザー向けにカスタマイズされています。たとえば、管理者以外のユーザーには自分の仮想マシンのみが表示されます。
- Overview タブには、仮想マシンの数と vCPU、メモリー、およびストレージの使用率が、過去 7 日間の傾向を示すグラフと共に表示されます。
- Overview タブの Alerts カードには、重大度別にグループ化されたアラートが表示されます。
- Top Consumers タブには、設定可能な期間における CPU、メモリー、およびストレージの使用率のトップコンシューマーが表示されます。
- Migrations タブには、VM 移行の進行状況が表示されます。
- Settings タブには、ライブマイグレーションの制限、ライブマイグレーションネットワーク、テンプレートプロジェクトなど、クラスター全体の設定が表示されます。
- Virtualization → MigrationPolicies ページで、ライブマイグレーションポリシーを 1 カ所で作成および管理できます。
- VirtualMachine details ページの Metrics タブには、設定可能な期間における VM のメモリー、CPU、ストレージ、ネットワーク、および移行のメトリックが表示されます。
- テンプレートをカスタマイズして VM を作成する場合、各仮想マシン設定タブで YAML スイッチを ON に設定して、YAML 設定ファイルのライブ変更をフォームと一緒に表示できます。
- Virtualization → Overview ページの Migrations タブには、設定可能な期間における仮想マシンインスタンスの移行の進行状況が表示されます。
- ライブマイグレーション専用のネットワークを定義して、テナントワークロードの中断を最小限に抑えることができるようになりました。ネットワークを選択するには、Virtualization → Overview → Settings → Live migration に移動します。
5.3.4. 非推奨の機能
非推奨の機能は現在のリリースに含まれており、サポートされています。ただし、これらは今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
5.3.5. 削除された機能
削除された機能は、現在のリリースではサポートされません。
- 従来の HPP カスタムリソースと関連するストレージクラスのサポートは、すべての新しいデプロイメントで削除されました。OpenShift Virtualization 4.12 では、HPP Operator は Kubernetes Container Storage Interface (CSI) ドライバーを使用してローカルストレージを設定します。レガシー HPP カスタムリソースは、以前のバージョンの OpenShift Virtualization にインストールされていた場合にのみサポートされます。
OpenShift Virtualization 4.11 は、以下のオブジェクトを含む nmstate のサポートを削除します。
-
NodeNetworkState -
NodeNetworkConfigurationPolicy -
NodeNetworkConfigurationEnactment
既存の nmstate 設定を維持およびサポートするには、OpenShift Virtualization 4.11 に更新する前に Kubernetes NMState Operator をインストールします。Extended Update Support (EUS) バージョンの 4.12 の場合、4.12 に更新した後に Kubernetes NMState Operator をインストールします。Operator は、OpenShift Container Platform Web コンソールの OperatorHub から、または OpenShift CLI (
oc) を使用してインストールできます。-
Node Maintenance Operator (NMO) は OpenShift Virtualization に同梱されなくなりました。これは、OpenShift Container Platform Web コンソールの OperatorHub から NMO をインストール、または OpenShift CLI (
oc) を使用してインストールできます。OpenShift Virtualization 4.10.2 以降の 4.10 リリースから OpenShift Virtualization 4.11 に更新する前に、以下のいずれかのタスクを実行する必要があります。Extended Update Support (EUS) バージョンの場合、4.10.2 以降の 4.10 リリースから OpenShift Virtualization 4.12 に更新する前に、以下のタスクを実行する必要があります。
- すべてのノードをメンテナンスモードから移動します。
-
スタンドアロン NMO をインストールし、
nodemaintenances.nodemaintenance.kubevirt.ioカスタムリソース (CR) をnodemaintenances.nodemaintenance.medik8s.ioCR に置き換えます。
5.4. テクノロジープレビュー機能
現在、今回のリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。これらの機能に関しては、Red Hat カスタマーポータルの以下のサポート範囲を参照してください。
- OpenShift Container Platform クラスターチェックアップ を実行して、VM 間のネットワークレイテンシーを測定できるようになりました。
Tekton Tasks Operator (TTO) は、OpenShift Virtualization を Red Hat OpenShift Pipelines と統合 するようになりました。TTO には、次のことを可能にするクラスタータスクとサンプルパイプラインが含まれています。
- 仮想マシン (VM)、永続ボリューム要求 (PVC)、およびデータボリュームを作成および管理します。
- 仮想マシンでコマンドを実行します。
-
libguestfsツールを使用してディスクイメージを操作します。 - Windows インストールイメージ (ISO ファイル) から新しいデータボリュームに Windows 10 をインストールします。
- 基本的な Windows 10 インストールをカスタマイズしてから、新しいイメージとテンプレートを作成します。
- ゲストエージェントの ping プローブ を使用して、QEMU ゲストエージェントが仮想マシンで実行されているかどうかを判断できるようになりました。
- Microsoft Windows 11 をゲスト OS として使用できるようになりました。ただし、OpenShift Virtualization 4.12 は、BitLocker リカバリーの重要な機能に必要な USB ディスクをサポートしていません。回復キーを保護するには、BitLocker recovery guide で説明されている他の方法を使用します。
- 帯域幅の使用率、並列移行の最大数、タイムアウトなどの特定のパラメーターを使用してライブマイグレーションポリシーを作成し、仮想マシンと namespace のラベルを使用して、仮想マシンのグループにポリシーを適用できます。
5.5. バグ修正
-
ドライバーのインストール後に新しいデバイス設定を失うことなく、ドライバーをインストールする前に仲介デバイスを有効にするように
HyperConvergedCR を設定できるようになりました。(BZ#2046298) -
OVN-Kubernetes クラスターネットワークプロバイダーは、大量の
NodePortサービスを作成して、RAM と CPU の使用率がピークに達してもクラッシュしなくなりました。(OCPBUGS-1940) - Red Hat Ceph Storage または Red Hat OpenShift Data Foundation Storage を使用している場合、一度に 100 を超える仮想マシンのクローン作成が断続的に失敗することはなくなりました。(BZ#1989527)
5.6. 既知の問題
- シングルスタックの IPv6 クラスターで OpenShift Virtualization は実行できません。(BZ#2193267)
- コンピュートノードがさまざま含まれる、異種クラスターでは、HyperV Reenlightenment が有効になっている仮想マシンは、タイムスタンプカウンタースケーリング (TSC) をサポートしていないノード、TSC 頻度が非季節なノードでスケジュールできません。(BZ#2151169)
異なる SELinux コンテキストで 2 つの Pod を使用すると、
ocs-storagecluster-cephfsストレージクラスの VM が移行に失敗し、VM のステータスがPausedに変わります。これは、両方の Pod がReadWriteManyCephFS の共有ボリュームに同時にアクセスしようとするためです。(BZ#2092271)-
回避策として、
ocs-storagecluster-ceph-rbdストレージクラスを使用して、Red Hat Ceph Storage を使用するクラスターで VM をライブマイグレーションします。
-
回避策として、
OpenShift Virtualization 4.12 では、
TopoLVMプロビジョナー名の文字列が変更されました。その結果、オペレーティングシステムイメージの自動インポートが失敗し、次のエラーメッセージが表示される場合があります (BZ#2158521)。DataVolume.storage spec is missing accessMode and volumeMode, cannot get access mode from StorageProfile.
DataVolume.storage spec is missing accessMode and volumeMode, cannot get access mode from StorageProfile.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 回避策として、以下を実施します。
ストレージプロファイルの
claimPropertySets配列を更新します。oc patch storageprofile <storage_profile> --type=merge -p '{"spec": {"claimPropertySets": [{"accessModes": ["ReadWriteOnce"], "volumeMode": "Block"}, \ {"accessModes": ["ReadWriteOnce"], "volumeMode": "Filesystem"}]}}'$ oc patch storageprofile <storage_profile> --type=merge -p '{"spec": {"claimPropertySets": [{"accessModes": ["ReadWriteOnce"], "volumeMode": "Block"}, \ {"accessModes": ["ReadWriteOnce"], "volumeMode": "Filesystem"}]}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
openshift-virtualization-os-imagesnamespace で影響を受けるデータボリュームを削除します。これらは、更新されたストレージプロファイルのアクセスモードとボリュームモードで再作成されます。
バインディングモードが
WaitForFirstConsumerであるストレージの VM スナップショットを復元すると、復元された PVC がPending状態のままになり、復元操作が進行しません。-
回避策として、復元された仮想マシンを起動し、停止してから、再度起動します。仮想マシンがスケジュールされ、PVC が
Bound状態になり、復元操作が完了します。(BZ#2149654)
-
回避策として、復元された仮想マシンを起動し、停止してから、再度起動します。仮想マシンがスケジュールされ、PVC が
-
テンプレートのデフォルトのエビクションストラテジーが
LiveMigrateであるため、Single Node OpenShift (SNO) クラスター上の共通テンプレートから作成された仮想マシンはVMCannotBeEvictedアラートを表示します。仮想マシンのエビクションストラテジーを更新することで、このアラートを無視するか、アラートを削除できます。(BZ#2092412) -
OpenShift Virtualization をアンインストールしても、OpenShift Virtualization によって作成された
feature.node.kubevirt.ioノードラベルは削除されません。ラベルは手動で削除する必要があります。(CNV-22036) Containerized Data Importer (CDI) によって作成された一部の永続ボリューム要求 (PVC) アノテーションにより、仮想マシンのスナップショット復元操作が無期限に停止する可能性があります。(BZ#2070366)
回避策として、アノテーションを手動で削除できます。
-
VirtualMachineSnapshotCR のstatus.virtualMachineSnapshotContentName値から、VirtualMachineSnapshotContent カスタムリソース (CR) 名を取得します。 -
VirtualMachineSnapshotContentCR を編集し、k8s.io/cloneRequestを含むすべての行を削除します。 VirtualMachineオブジェクトでspec.dataVolumeTemplatesの値を指定しなかった場合は、次の両方の条件に該当するこの namespace のDataVolumeおよびPersistentVolumeClaimオブジェクトを削除します。-
オブジェクトの名前は
restore-で始まります。 オブジェクトは仮想マシンによって参照されません。
spec.dataVolumeTemplatesの値を指定した場合、この手順はオプションとなります。
-
オブジェクトの名前は
-
更新された
VirtualMachineSnapshotCR で 復元操作 を繰り返します。
-
-
Windows 11 仮想マシンは、FIPS モード で実行されているクラスターで起動しません。Windows 11 には、デフォルトで Trusted Platform Module (TPM) デバイスが必要です。ただし、
swtpm(ソフトウェア TPM エミュレーター) パッケージは FIPS と互換性がありません。(BZ#2089301)
OpenShift Container Platform クラスターが OVN-Kubernetes をデフォルトの Container Network Interface (CNI) プロバイダーとして使用する場合、OVN-Kubernetes のホストネットワークトポロジーの変更により、Linux ブリッジまたはボンディングデバイスをホストのデフォルトインターフェイスに割り当てることはできません。(BZ#1885605)
- 回避策として、ホストに接続されたセカンダリーネットワークインターフェイスを使用するか、OpenShift SDN デフォルト CNI プロバイダーに切り替えることができます。
場合によっては、複数の仮想マシンが読み取り/書き込みモードで同じ PVC をマウントできるため、データが破損する可能性があります。(BZ#1992753)
- 回避策として、複数の仮想マシンで読み取り/書き込みモードで単一の PVC を使用しないでください。
Pod Disruption Budget (PDB) は、移行可能な仮想マシンイメージについての Pod の中断を防ぎます。PDB が Pod の中断を検出する場合、
openshift-monitoringはLiveMigrateエビクションストラテジーを使用する仮想マシンイメージに対して 60 分ごとにPodDisruptionBudgetAtLimitアラートを送信します。(BZ#2026733)- 回避策として、アラートをサイレント にします。
OpenShift Virtualization は、Pod によって使用されるサービスアカウントトークンをその特定の Pod にリンクします。OpenShift Virtualization は、トークンが含まれるディスクイメージを作成してサービスアカウントボリュームを実装します。仮想マシンを移行すると、サービスアカウントボリュームが無効になります。(BZ#2037611)
- 回避策として、サービスアカウントではなくユーザーアカウントを使用してください。ユーザーアカウントトークンは特定の Pod にバインドされていないためです。
csi-cloneクローンストラテジーを使用して 100 台以上の仮想マシンのクローンを作成する場合、Ceph CSI はクローンをパージしない可能性があります。クローンの手動削除も失敗する可能性があります。(BZ#2055595)-
回避策として、
ceph-mgrを再起動して仮想マシンのクローンをパージすることができます。
-
回避策として、
ブロックストレージデバイスで論理ボリューム管理(LVM)を使用する VM では、Red Hat Enterprise Linux CoreOS (RHCOS)ホストと競合しないように追加の設定が必要になります。
-
回避策として、仮想マシンの作成、LVM のプロビジョニング、および仮想マシンの再起動を行うことができます。これにより、空の
system.lvmdevicesファイルが作成されます。(OCPBUGS-5223)
-
回避策として、仮想マシンの作成、LVM のプロビジョニング、および仮想マシンの再起動を行うことができます。これにより、空の
第6章 インストール
6.1. OpenShift Virtualization のクラスターの準備
OpenShift Virtualization をインストールする前にこのセクションを確認して、クラスターが要件を満たしていることを確認してください。
ユーザープロビジョニング、インストーラープロビジョニング、またはアシステッドインストーラーなど、任意のインストール方法を使用して、OpenShift Container Platform をデプロイできます。ただし、インストール方法とクラスタートポロジーは、スナップショットやライブマイグレーションなどの OpenShift Virtualization 機能に影響を与える可能性があります。
FIPS モード
クラスターを FIPS モード でインストールする場合、OpenShift Virtualization に追加の設定は必要ありません。
IPv6
シングルスタックの IPv6 クラスターで OpenShift Virtualization は実行できません。(BZ#2193267)
6.1.1. ハードウェアとオペレーティングシステムの要件
OpenShift Virtualization の次のハードウェアおよびオペレーティングシステム要件を確認してください。
サポート対象プラットフォーム
- オンプレミスのベアメタルサーバー
- Amazon Web Services ベアメタルインスタンス。詳細は、AWS ベアメタルノードへの OpenShift Virtualization のデプロイ を参照してください。
- IBM Cloud Bare Metal Servers。詳細は IBM Cloud Bare Metal Nodes への OpenShift Virtualization のデプロイ を参照してください。
AWS ベアメタルインスタンスまたは IBM Cloud Bare Metal Servers への OpenShift Virtualization のインストールは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
- 他のクラウドプロバイダーが提供するベアメタルインスタンスまたはサーバーはサポートされていません。
CPU の要件
- Red Hat Enterprise Linux (RHEL) 8 でサポート
- Intel 64 または AMD64 CPU 拡張機能のサポート
- Intel VT または AMD-V ハードウェア仮想化拡張機能が有効
- NX (実行なし) フラグが有効
ストレージ要件
- OpenShift Container Platform によるサポート
Red Hat OpenShift Data Foundation を使用して OpenShift Virtualization をデプロイする場合は、Windows 仮想マシンディスク用の専用ストレージクラスを作成する必要があります。詳細は 、Windows VM の ODF PersistentVolumes の最適化 を参照してください。
オペレーティングシステム要件
ワーカーノードにインストールされた Red Hat Enterprise Linux CoreOS (RHCOS)
注記RHEL ワーカー ノードはサポートされていません。
- クラスターが CPU の異なるワーカーノードを使用している場合、CPU ごとに能力が異なるため、ライブマイグレーションの失敗が発生する可能性があります。このような失敗を回避するには、各ノードに適切な能力の CPU を使用し、仮想マシンにノードアフィニティーを設定して、移行が成功するようにします。詳細は、必須のノードのアフィニティールールの設定 を参照してください。
6.1.2. 物理リソースのオーバーヘッド要件
OpenShift Virtualization は OpenShift Container Platform のアドオンであり、クラスターの計画時に考慮する必要のある追加のオーバーヘッドを強要します。各クラスターマシンは、OpenShift Container Platform の要件に加えて、以下のオーバーヘッドの要件を満たす必要があります。クラスター内の物理リソースを過剰にサブスクライブすると、パフォーマンスに影響する可能性があります。
このドキュメントに記載されている数は、Red Hat のテスト方法およびセットアップに基づいています。これらの数は、独自のセットアップおよび環境に応じて異なります。
6.1.2.1. メモリーのオーバーヘッド
以下の式を使用して、OpenShift Virtualization のメモリーオーバーヘッドの値を計算します。
クラスターメモリーのオーバーヘッド
Memory overhead per infrastructure node ≈ 150 MiB
Memory overhead per infrastructure node ≈ 150 MiBMemory overhead per worker node ≈ 360 MiB
Memory overhead per worker node ≈ 360 MiBさらに、OpenShift Virtualization 環境リソースには、すべてのインフラストラクチャーノードに分散される合計 2179 MiB の RAM が必要です。
仮想マシンのメモリーオーバーヘッド
Memory overhead per virtual machine ≈ (1.002 × requested memory) \
+ 218 MiB \
+ 8 MiB × (number of vCPUs) \
+ 16 MiB × (number of graphics devices) \
+ (additional memory overhead)
Memory overhead per virtual machine ≈ (1.002 × requested memory) \
+ 218 MiB \
+ 8 MiB × (number of vCPUs) \
+ 16 MiB × (number of graphics devices) \
+ (additional memory overhead) 6.1.2.2. CPU オーバーヘッド
以下の式を使用して、OpenShift Virtualization のクラスタープロセッサーのオーバーヘッド要件を計算します。仮想マシンごとの CPU オーバーヘッドは、個々の設定によって異なります。
クラスターの CPU オーバーヘッド
CPU overhead for infrastructure nodes ≈ 4 cores
CPU overhead for infrastructure nodes ≈ 4 coresOpenShift 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 の数に関する特別なルールはありません。
6.1.2.3. ストレージのオーバーヘッド
以下のガイドラインを使用して、OpenShift Virtualization 環境のストレージオーバーヘッド要件を見積もります。
クラスターストレージオーバーヘッド
Aggregated storage overhead per node ≈ 10 GiB
Aggregated storage overhead per node ≈ 10 GiB10 GiB は、OpenShift Virtualization のインストール時にクラスター内の各ノードに関するディスク上のストレージの予想される影響に相当します。
仮想マシンのストレージオーバーヘッド
仮想マシンごとのストレージオーバーヘッドは、仮想マシン内のリソース割り当ての特定の要求により異なります。この要求は、クラスター内の別の場所でホストされるノードまたはストレージリソースの一時ストレージに対するものである可能性があります。OpenShift Virtualization は現在、実行中のコンテナー自体に追加の一時ストレージを割り当てていません。
6.1.2.4. 例
クラスター管理者が、クラスター内の 10 台の (それぞれ 1 GiB の RAM と 2 つの vCPU の) 仮想マシンをホストする予定の場合、クラスター全体で影響を受けるメモリーは 11.68 GiB になります。クラスターの各ノードについて予想されるディスク上のストレージの影響は 10 GiB で示され、仮想マシンのワークロードをホストするワーカーノードについての CPU の影響は最小 2 コアで示されます。
6.1.3. オブジェクトの最大値
クラスターを計画するときは、次のテスト済みオブジェクトの最大数を考慮する必要があります。
6.1.4. 制限されたネットワーク環境
インターネット接続のない制限された環境に OpenShift Virtualization をインストールする場合は、制限されたネットワーク用に Operator Lifecycle Manager を設定 する必要があります。
インターネット接続が制限されている場合、Operator Lifecycle Manager でプロキシーサポートを設定 して、Red Hat が提供する OperatorHub にアクセスすることができます。
6.1.5. ライブマイグレーション
ライブマイグレーションには次の要件があります。
-
ReadWriteMany(RWX) アクセスモードの共有ストレージ - 十分な RAM およびネットワーク帯域幅
- 仮想マシンがホストモデルの CPU を使用する場合、ノードは仮想マシンのホストモデルの CPU をサポートする必要があります。
ライブマイグレーションを引き起こすノードドレインをサポートするために、クラスター内に十分なメモリーリクエスト容量があることを確認する必要があります。以下の計算を使用して、必要な予備のメモリーを把握できます。
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)クラスターで 並行して実行できるデフォルトの移行数 は 5 です。
6.1.6. スナップショットとクローン作成
スナップショットとクローン作成の要件は、OpenShift Virtualization ストレージ機能 を参照してください。
6.1.7. クラスターの高可用性オプション
クラスターには、次の高可用性 (HA) オプションのいずれかを設定できます。
installer-provisioned infrastructure (IPI) の自動高可用性は、マシンヘルスチェック をデプロイすることで利用できます。
注記インストーラーでプロビジョニングされるインフラストラクチャーを使用してインストールされ、MachineHealthCheck が適切に設定された OpenShift Container Platform クラスターで、ノードで MachineHealthCheck が失敗し、クラスターで利用できなくなると、そのノードは再利用されます。障害が発生したノードで実行された仮想マシンでは、一連の条件によって次に起こる動作が変わります。潜在的な結果と RunStrategy がそれらの結果にどのように影響するかについての詳細情報は、仮想マシンの RunStrategy について を参照してください。
-
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>を実行します。注記外部モニタリングシステムまたは資格のある人材によるノードの正常性の監視が行われない場合、仮想マシンは高可用性を失います。
6.2. OpenShift Virtualization コンポーネントのノードの指定
ノードの配置ルールを設定して、OpenShift Virtualization Operator、ワークロード、およびコントローラーをデプロイするノードを指定します。
OpenShift Virtualization のインストール後に一部のコンポーネントのノードの配置を設定できますが、ワークロード用にノードの配置を設定する場合には仮想マシンを含めることはできません。
6.2.1. 仮想化コンポーネントのノード配置について
OpenShift Virtualization がそのコンポーネントをデプロイする場所をカスタマイズして、以下を確認する必要がある場合があります。
- 仮想マシンは、仮想化ワークロード用のノードにのみデプロイされる。
- Operator はインフラストラクチャーノードにのみデプロイされる。
- 特定のノードは OpenShift Virtualization の影響を受けない。たとえば、クラスターで実行される仮想化に関連しないワークロードがあり、それらのワークロードを OpenShift Virtualization から分離する必要があるとします。
6.2.1.1. ノードの配置ルールを仮想化コンポーネントに適用する方法
対応するオブジェクトを直接編集するか、Web コンソールを使用して、コンポーネントのノードの配置ルールを指定できます。
-
Operator Lifecycle Manager (OLM) がデプロイする OpenShift Virtualization Operator の場合は、OLM
Subscriptionオブジェクトを直接編集します。現時点では、Web コンソールを使用してSubscriptionオブジェクトのノードの配置ルールを設定することはできません。 -
OpenShift Virtualization Operator がデプロイするコンポーネントの場合は、
HyperConvergedオブジェクトを直接編集するか、OpenShift Virtualization のインストール時に Web コンソールを使用してこれを設定します。 ホストパスプロビジョナーの場合、
HostPathProvisionerオブジェクトを直接編集するか、Web コンソールを使用してこれを設定します。警告ホストパスプロビジョナーと仮想化コンポーネントを同じノードでスケジュールする必要があります。スケジュールしない場合は、ホストパスプロビジョナーを使用する仮想化 Pod を実行できません。
オブジェクトに応じて、以下のルールタイプを 1 つ以上使用できます。
nodeSelector- Pod は、キーと値のペアまたはこのフィールドで指定したペアを使用してラベルが付けられたノードに Pod をスケジュールできます。ノードには、リスト表示されたすべてのペアに一致するラベルがなければなりません。
affinity- より表現的な構文を使用して、ノードと Pod に一致するルールを設定できます。アフィニティーを使用すると、ルールの適用方法に追加のニュアンスを持たせることができます。たとえば、ルールがハード要件ではなく基本設定になるように指定し、ルールの条件が満たされない場合も Pod がスケジュールされるようにすることができます。
tolerations- 一致するテイントを持つノードで Pod をスケジュールできます。テイントがノードに適用される場合、そのノードはテイントを容認する Pod のみを受け入れます。
6.2.1.2. OLM Subscription オブジェクトのノード配置
OLM が OpenShift Virtualization Operator をデプロイするノードを指定するには、OpenShift Virtualization のインストール時に Subscription オブジェクトを編集します。以下の例に示されるように、spec.config フィールドにノードの配置ルールを追加できます。
- 1
configフィールドはnodeSelectorおよびtolerationsをサポートしますが、affinityはサポートしません。
6.2.1.3. HyperConverged オブジェクトのノード配置
OpenShift Virtualization がそのコンポーネントをデプロイするノードを指定するには、OpenShift Virtualization のインストール時に作成する HyperConverged Cluster カスタムリソース (CR) ファイルに nodePlacement オブジェクトを含めることができます。以下の例のように、spec.infra および spec.workloads フィールドに nodePlacement を含めることができます。
- 1
nodePlacementフィールドは、nodeSelector、affinity、およびtolerationsフィールドをサポートします。
6.2.1.4. HostPathProvisioner オブジェクトのノード配置
ノードの配置ルールは、ホストパスプロビジョナーのインストール時に作成する HostPathProvisioner オブジェクトの spec.workload フィールドで設定できます。
- 1
workloadフィールドは、nodeSelector、affinity、およびtolerationsフィールドをサポートします。
6.2.2. マニフェストの例
以下の YAML ファイルの例では、nodePlacement、affinity、および tolerations オブジェクトを使用して OpenShift Virtualization コンポーネントのノード配置をカスタマイズします。
6.2.2.1. Operator Lifecycle Manager サブスクリプションオブジェクト
6.2.2.1.1. 例: OLM Subscription オブジェクトの nodeSelector を使用したノード配置
この例では、OLM が example.io/example-infra-key = example-infra-value のラベルが付けられたノードに OpenShift Virtualization Operator を配置するように、nodeSelector を設定します。
6.2.2.1.2. 例: OLM Subscription オブジェクトの容認を使用したノード配置
この例では、OLM が OpenShift Virtualization Operator をデプロイするために予約されるノードには key=virtualization:NoSchedule テイントのラベルが付けられます。一致する容認のある Pod のみがこれらのノードにスケジュールされます。
6.2.2.2. HyperConverged オブジェクト
6.2.2.2.1. 例: HyperConverged Cluster CR の nodeSelector を使用したノード配置
この例では、nodeSelector は、インフラストラクチャーリソースが example.io/example-infra-key = example-infra-value のラベルが付けられたノードに配置されるように設定され、ワークロードは example.io/example-workloads-key = example-workloads-value のラベルが付けられたノードに配置されるように設定されます。
6.2.2.2.2. 例: HyperConverged Cluster CR のアフィニティーを使用したノード配置
この例では、affinity は、インフラストラクチャーリソースが example.io/example-infra-key = example-infra-value のラベルが付けられたノードに配置されるように設定され、ワークロードが example.io/example-workloads-key = example-workloads-value のラベルが付けられたノードに配置されるように設定されます。ワークロード用には 9 つ以上の CPU を持つノードが優先されますが、それらが利用可能ではない場合も、Pod は依然としてスケジュールされます。
6.2.2.2.3. 例: HyperConverged Cluster CR の容認を使用したノード配置
この例では、OpenShift Virtualization コンポーネント用に予約されるノードには key=virtualization:NoSchedule テイントのラベルが付けられます。一致する容認のある Pod のみがこれらのノードにスケジュールされます。
6.2.2.3. HostPathProvisioner オブジェクト
6.2.2.3.1. 例: HostPathProvisioner オブジェクトの nodeSelector を使用したノード配置
この例では、example.io/example-workloads-key = example-workloads-value のラベルが付けられたノードにワークロードが配置されるように nodeSelector を設定します。
6.3. Web コンソールを使用した OpenShift Virtualization のインストール
OpenShift Virtualization をインストールし、仮想化機能を OpenShift Container Platform クラスターに追加します。
OpenShift Container Platform 4.13 Web コンソール を使用して、OpenShift Virtualization Operator にサブスクライブし、これをデプロイすることができます。
6.3.1. OpenShift Virtualization Operator のインストール
OpenShift Container Platform Web コンソールから OpenShift Virtualization Operator をインストールできます。
前提条件
- OpenShift Container Platform 4.12 をクラスターにインストールしていること。
-
cluster-adminパーミッションを持つユーザーとして OpenShift Container Platform Web コンソールにログインすること。
手順
- Administrator パースペクティブから、Operators → OperatorHub をクリックします。
- Filter by keyword に Virtualization と入力します。
- Red Hat ソースラベルをがある {CNVOperatorDisplayName} タイルを選択します。
- 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 を使用できます。
6.3.2. 次のステップ
以下のコンポーネントを追加で設定する必要がある場合があります。
- ホストパスプロビジョナー は、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。
6.4. CLI を使用した OpenShift Virtualization のインストール
OpenShift Virtualization をインストールし、仮想化機能を OpenShift Container Platform クラスターに追加します。コマンドラインを使用してマニフェストをクラスターに適用し、OpenShift Virtualization Operator にサブスクライブし、デプロイできます。
OpenShift Virtualization がそのコンポーネントをインストールするノードを指定するには、ノードの配置ルールを設定 します。
6.4.1. 前提条件
- OpenShift Container Platform 4.12 をクラスターにインストールしていること。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
6.4.2. CLI を使用した OpenShift Virtualization カタログのサブスクライブ
OpenShift Virtualization をインストールする前に、OpenShift Virtualization カタログにサブスクライブする必要があります。サブスクライブにより、openshift-cnv namespace に OpenShift Virtualization Operator へのアクセスが付与されます。
単一マニフェストをクラスターに適用して Namespace、OperatorGroup、および Subscription オブジェクトをサブスクライブし、設定します。
手順
以下のマニフェストを含む 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 ファイルで、証明書のローテーションパラメーターを設定 できます。
6.4.3. CLI を使用した OpenShift Virtualization Operator のデプロイ
oc CLI を使用して OpenShift Virtualization Operator をデプロイすることができます。
前提条件
-
openshift-cnvnamespace の OpenShift Virtualization カタログへのアクティブなサブスクリプション。
手順
以下のマニフェストを含む 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.12.16 OpenShift Virtualization 4.12.16 Succeeded
NAME DISPLAY VERSION REPLACES PHASE kubevirt-hyperconverged-operator.v4.12.16 OpenShift Virtualization 4.12.16 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.4. 次のステップ
以下のコンポーネントを追加で設定する必要がある場合があります。
- ホストパスプロビジョナー は、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。
6.5. virtctl クライアントのインストール
virtctl クライアントは、OpenShift Virtualization リソースを管理するためのコマンドラインユーティリティーです。Linux、Windows、および macOS で使用できます。
6.5.1. Linux、Windows、および macOS への virtctl クライアントのインストール
お使いのオペレーティングシステム用の virtctl クライアントをダウンロードしてインストールします。
手順
- OpenShift Container Platform Web コンソールで Virtualization > Overview に移動します。
-
ページの右上隅にある Download virtctl リンクをクリックして、お使いのオペレーティングシステム用の
virtctlクライアントをダウンロードします。 virtctlをインストールします。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
6.5.2. virtctl を RPM としてインストールする
OpenShift Virtualization リポジトリーを有効にした後、Red Hat Enterprise Linux (RHEL) に virtctl クライアントを RPM としてインストールできます。
6.5.2.1. OpenShift Virtualization リポジトリーの有効化
Red Hat Enterprise Linux (RHEL) のバージョンの OpenShift Virtualization リポジトリーを有効にします。
前提条件
- システムは、Red Hat Container Native Virtualization エンタイトルメントへの有効なサブスクリプションを持つ Red Hat アカウントに登録されています。
手順
subscription-managerCLI ツールを使用して、オペレーティングシステムに適切な OpenShift Virtualization リポジトリーを有効にします。RHEL 8 のリポジトリーを有効にするには、次を実行します。
subscription-manager repos --enable cnv-4.12-for-rhel-8-x86_64-rpms
# subscription-manager repos --enable cnv-4.12-for-rhel-8-x86_64-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow RHEL 7 のリポジトリーを有効にするには、次を実行します。
subscription-manager repos --enable rhel-7-server-cnv-4.12-rpms
# subscription-manager repos --enable rhel-7-server-cnv-4.12-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.2.2. yum ユーティリティーを使用した virtctl クライアントのインストール
kubevirt-virtctl パッケージから virtctl クライアントをインストールします。
前提条件
- Red Hat Enterprise Linux (RHEL) システムで OpenShift Virtualization リポジトリーを有効にしました。
手順
kubevirt-virtctlパッケージをインストールします。yum install kubevirt-virtctl
# yum install kubevirt-virtctlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6. OpenShift Virtualization のアンインストール
Web コンソールまたはコマンドラインインターフェイス (CLI) を使用して OpenShift Virtualization をアンインストールし、OpenShift Virtualization ワークロード、Operator、およびそのリソースを削除します。
6.6.1. Web コンソールを使用した OpenShift Virtualization のアンインストール
OpenShift Virtualization をアンインストールするには、Web コンソール を使用して次のタスクを実行します。
まず、すべての 仮想マシン と 仮想マシンインスタンス を削除する必要があります。
ワークロードがクラスターに残っている間は、OpenShift Virtualization をアンインストールできません。
6.6.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 をクリックします。
6.6.1.2. Web コンソールの使用によるクラスターからの Operator の削除
クラスター管理者は Web コンソールを使用して、選択した namespace からインストールされた Operator を削除できます。
前提条件
-
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 を手動で削除する必要があります。
6.6.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 をクリックします。
6.6.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 の削除を選択します。
6.6.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
第7章 OpenShift Virtualization の更新
Operator Lifecycle Manager(OLM) が OpenShift Virtualization の z-stream およびマイナーバージョンの更新を提供する方法を確認します。
Node Maintenance Operator (NMO) は OpenShift Virtualization に同梱されなくなりました。NMO は、OpenShift Container Platform Web コンソールの OperatorHub から、または OpenShift CLI (
oc) を使用して インストール できます。ノードの修復、フェンシング、メンテナンスの詳細は、Red Hat OpenShift のワークロードの可用性 を参照してください。OpenShift Virtualization 4.10.2 以降のリリースから OpenShift Virtualization 4.11 に更新する前に、以下のいずれかのタスクを実行する必要があります。
- すべてのノードをメンテナンスモードから移動します。
-
スタンドアロン NMO をインストールし、
nodemaintenances.nodemaintenance.kubevirt.ioカスタムリソース (CR) をnodemaintenances.nodemaintenance.medik8s.ioCR に置き換えます。
7.1. OpenShift Virtualization の更新について
- 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 を次のマイナーバージョンに更新できません。
- OpenShift Virtualization サブスクリプションは、stable という名前の単一の更新チャネルを使用します。stable チャネルでは、OpenShift Virtualization および OpenShift Container Platform バージョンとの互換性が確保されます。
サブスクリプションの承認ストラテジーが Automatic に設定されている場合に、更新プロセスは、Operator の新規バージョンが stable チャネルで利用可能になるとすぐに開始します。サポート可能な環境を確保するために、自動 承認ストラテジーを使用することを強く推奨します。OpenShift Virtualization の各マイナーバージョンは、対応する OpenShift Container Platform バージョンを実行する場合にのみサポートされます。たとえば、OpenShift Virtualization 4.12 は OpenShift Container Platform 4.12 で実行する必要があります。
- クラスターのサポート容易性および機能が損なわれるリスクがあるので、Manual 承認ストラテジーを選択することは可能ですが、推奨していません。Manual 承認ストラテジーでは、保留中のすべての更新を手動で承認する必要があります。OpenShift Container Platform および OpenShift Virtualization の更新の同期が取れていない場合には、クラスターはサポートされなくなります。
- 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。
- OpenShift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
- データボリュームおよびその関連付けられた永続ボリューム要求は更新時に保持されます。
ホストパスプロビジョナーストレージを使用する仮想マシンを実行している場合、それらをライブマイグレーションすることはできず、OpenShift Container Platform クラスターの更新をブロックする可能性があります。
回避策として、仮想マシンを再設定し、クラスターの更新時にそれらの電源を自動的にオフになるようにできます。evictionStrategy: LiveMigrate フィールドを削除し、runStrategy フィールドを Always に設定します。
7.1.1. ワークロードの更新について
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 回の試行のみがバッファーに保持されます。これにより、デバッグ用の情報を保持しながら、移行オブジェクトがシステムに蓄積されるのを防ぎます。
7.1.2. EUS から EUS への更新について
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 バージョンに更新できるようになりました。
7.1.2.1. 更新の準備中
EUS から EUS への更新を開始する前に、次のことを行う必要があります。
- EUS から EUS への更新を開始する前に、ワーカーノードのマシン設定プールを一時停止して、ワーカーが 2 回再起動されないようにします。
- 更新プロセスを開始する前に、ワークロードの自動更新を無効にします。これは、ターゲットの EUS バージョンに更新するまで、OpenShift Virtualization が仮想マシン (VM) を移行または削除しないようにするためです。
デフォルトでは、OpenShift Virtualization Operator を更新すると、OpenShift Virtualization は virt-launcher Pod などのワークロードを自動的に更新します。この動作は、HyperConverged カスタムリソースの spec.workloadUpdateStrategy スタンザで設定できます。
EUS から EUS への更新を実行するための準備 の詳細を参照してください。
7.2. EUS から EUS への更新中のワークロード更新の防止
ある Extended Update Support (EUS) バージョンから次のバージョンに更新する場合、自動ワークロード更新を手動で無効にして、更新プロセス中に OpenShift Virtualization がワークロードを移行または削除しないようにする必要があります。
前提条件
- OpenShift Container Platform の EUS バージョンを実行中で、次の EUS バージョンに更新する予定である。その間、奇数番号のバージョンにまだ更新していません。
- 「EUS から EUS への更新を実行するための準備」を読み、OpenShift Container Platform クラスターに関連する警告と要件を学習しました。
- OpenShift Container Platform ドキュメントの指示に従って、ワーカーノードのマシン設定プールを一時停止しました。
- デフォルトの Automatic 承認ストラテジーを使用することを推奨します。Manual 承認ストラテジーを使用する場合は、Web コンソールで保留中のすべての更新を承認する必要があります。詳細は、「保留中の Operator の更新を手動で承認する」セクションを参照してください。
手順
次のコマンドを実行して、現在の
workloadUpdateMethods設定をバックアップします。WORKLOAD_UPDATE_METHODS=$(oc get kv kubevirt-kubevirt-hyperconverged -n openshift-cnv -o jsonpath='{.spec.workloadUpdateStrategy.workloadUpdateMethods}')$ WORKLOAD_UPDATE_METHODS=$(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 hco kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op":"replace","path":"/spec/workloadUpdateStrategy/workloadUpdateMethods", "value":[]}]'$ oc patch hco 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 hco kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
$ oc get hco kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例7.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 hco kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"
$ oc get hco 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 hco kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
$ oc get hco 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になると、更新が完了します。バックアップしたワークロードの更新方法の設定を復元します。
oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":$WORKLOAD_UPDATE_METHODS}]"$ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":$WORKLOAD_UPDATE_METHODS}]"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
次のステップ
- ワーカーノードのマシン設定プールの一時停止を解除できるようになりました。
7.3. ワークロードの更新方法の設定
HyperConverged カスタムリソース (CR) を編集することにより、ワークロードの更新方法を設定できます。
前提条件
ライブマイグレーションを更新方法として使用するには、まずクラスターでライブマイグレーションを有効にする必要があります。
注記VirtualMachineInstanceCR にevictionStrategy: LiveMigrateが含まれており、仮想マシンインスタンス (VMI) がライブマイグレーションをサポートしない場合には、VMI は更新されません。
手順
デフォルトエディターで
HyperConvergedCR を作成するには、以下のコマンドを実行します。oc edit hco -n openshift-cnv kubevirt-hyperconverged
$ oc edit hco -n openshift-cnv kubevirt-hyperconvergedCopy 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スタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。- 変更を適用するには、エディターを保存し、終了します。
7.4. 保留中の Operator 更新の承認
7.4.1. 保留中の Operator 更新の手動による承認
インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。
前提条件
- Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- 更新が保留中の Operator は Upgrade available のステータスを表示します。更新する Operator の名前をクリックします。
- Subscription タブをクリックします。承認が必要な更新は、アップグレードステータス の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
- 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
- 更新に利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
- Operators → Installed Operators ページに戻り、更新の進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。
7.5. 更新ステータスの監視
7.5.1. OpenShift Virtualization アップグレードステータスのモニタリング
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 hco -n openshift-cnv kubevirt-hyperconverged \ -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'$ oc get hco -n openshift-cnv kubevirt-hyperconverged \ -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
7.5.2. 以前の OpenShift Virtualization ワークロードの表示
CLI を使用して、以前のワークロードのリストを表示できます。
クラスターに以前の仮想化 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 が自動的に更新されるようにします。
第8章 セキュリティーポリシー
仮想マシン (VM) のワークロードは、特権のない Pod として実行されます。仮想マシンが OpenShift Virtualization 機能を使用できるように、一部の Pod には、他の Pod 所有者が使用できないカスタムセキュリティーポリシーが付与されます。
-
拡張された
container_tSELinux ポリシーがvirt-launcherPod に適用されます。 -
Security Context Constraints (SCC) は、
kubevirt-controllerサービスアカウントに対して定義されます。
8.1. ワークロードのセキュリティーについて
デフォルトでは、仮想マシン (VM) のワークロードは OpenShift Virtualization の root 権限では実行されません。
仮想マシンごとに、virt-launcher Pod が libvirt のインスタンスを セッションモード で実行し、仮想マシンプロセスを管理します。セッションモードでは、libvirt デーモンは root 以外のユーザーアカウントとして実行され、同じユーザー識別子 (UID) で実行されているクライアントからの接続のみを許可します。したがって、仮想マシンは権限のない Pod として実行し、最小権限のセキュリティー原則に従います。
root 権限を必要とするサポート対象の OpenShift Virtualization 機能はありません。機能に root が必要な場合は、OpenShift Virtualization での使用がサポートされていない可能性があります。
8.2. virt-launcher Pod の拡張 SELinux ポリシー
virt-launcher Pod の container_t SELinux ポリシーが拡張され、OpenShift 仮想化の重要な機能が有効になります。
ネットワークマルチキューには次のポリシーが必要です。これにより、使用可能な vCPU の数が増加するにつれてネットワークパフォーマンスを拡張できます。
-
allow process self (tun_socket (relabelfrom relabelto attach_queue))
-
次のポリシーによって、
virt-launcherが/proc/cpuinfoおよび/proc/uptimeを含む/procディレクトリーの下のファイルを読み取ることができます。-
allow process proc_type (file (getattr open read))
-
次のポリシーによって、
libvirtdがネットワーク関連のデバッグメッセージをリレーできます。allow process self (netlink_audit_socket (nlmsg_relay))注記このポリシーがない場合、ネットワークデバッグメッセージをリレーしようとする試みはブロックされます。これにより、ノードの監査ログが SELinux 拒否でいっぱいになる可能性があります。
次のポリシーによって、
libvirtdがhugetblfsにアクセスできます。これは、巨大なページをサポートするために必要です。-
allow process hugetlbfs_t (dir (add_name create write remove_name rmdir setattr)) -
allow process hugetlbfs_t (file (create unlink))
-
次のポリシーによって、
virtiofsがファイルシステムをマウントし、NFS にアクセスできます。-
allow process nfs_t (dir (mounton)) -
allow process proc_t (dir (mounton)) -
allow process proc_t (filesystem (mount unmount))
-
次のポリシーは、
passtネットワーキングを有効にする上流の Kubevirt から継承されます。-
プロセス tmpfs_t を許可 (ファイルシステム (マウント))
-
OpenShift Virtualization は現時点で passt をサポートしていません。
SCC (Security Context Constraints) は Pod のパーミッションを制御します。これらのパーミッションには、コンテナーのコレクションである Pod が実行できるアクションおよびそれがアクセスできるリソース情報が含まれます。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行に関する条件の一覧を定義できます。
virt-controller は、クラスター内の仮想マシンの virt-launcher Pod を作成するクラスターコントローラーです。これらの Pod には、kubevirt-controller サービスアカウントによってパーミッションが付与されます。
kubevirt-controller サービスアカウントには追加の SCC および Linux 機能が付与され、これにより適切なパーミッションを持つ virt-launcher Pod を作成できます。これらの拡張パーミッションにより、仮想マシンは通常の Pod の範囲外の OpenShift Virtualization 機能を利用できます。
kubevirt-controller サービスアカウントには以下の SCC が付与されます。
-
scc.AllowHostDirVolumePlugin = true
これは、仮想マシンが hostpath ボリュームプラグインを使用することを可能にします。 -
scc.AllowPrivilegedContainer = false
これは、virt-launcher Pod が権限付きコンテナーとして実行されないようにします。 scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE", "SYS_PTRACE"}
-
SYS_NICEを使用すると、CPU アフィニティーを設定できます。 -
NET_BIND_SERVICEは、DHCP および Slirp 操作を許可します。 -
SYS_PTRACEを使用すると、特定バージョンのlibvirtで、ソフトウェア Trusted Platform Module (TPM) エミュレーターであるswtpmのプロセス ID (PID) を見つけることができます。
-
8.3.1. 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第9章 CLI ツールの使用
クラスターでリソースを管理するために使用される 2 つの主な CLI ツールは以下の通りです。
-
OpenShift virtualization
virtctlクライアント -
OpenShift Container Platform
ocクライアント
9.1. 前提条件
-
virtctlクライアントをインストール する必要があります。
9.2. OpenShift Container Platform クライアントコマンド
OpenShift Container Platform oc クライアントは、VirtualMachine (vm) および VirtualMachineInstance (vmi) オブジェクトタイプを含む、OpenShift Container Platform リソースを管理するためのコマンドラインユーティリティーです。
-n <namespace> フラグを使用して、別のプロジェクトを指定できます。
| コマンド | Description |
|---|---|
|
|
OpenShift Container Platform クラスターに |
|
| 現在のプロジェクトの指定されたオブジェクトタイプのオブジェクトのリストを表示します。 |
|
| 現在のプロジェクトで特定のリソースの詳細を表示します。 |
|
| 現在のプロジェクトで、ファイル名または標準入力 (stdin) からリソースを作成します。 |
|
| 現在のプロジェクトのリソースを編集します。 |
|
| 現在のプロジェクトのリソースを削除します。 |
oc クライアントコマンドについてのより総合的な情報については、OpenShift Container Platform CLI ツール のドキュメントを参照してください。
9.3. Virtctl コマンド
virtctl クライアントは、OpenShift Virtualization リソースを管理するためのコマンドラインユーティリティーです。
| コマンド | 説明 |
|---|---|
|
|
|
|
|
|
|
| 特定のコマンドのオプションのリストを表示します。 |
|
|
任意の |
9.3.1. 仮想マシンおよび VMI 管理コマンド
virtctl を使用して、仮想マシン (VM) または仮想マシンインスタンス (VMI) の状態を管理し、仮想マシンを移行できます。
| コマンド | 説明 |
|---|---|
|
| 仮想マシンを開始します。 |
|
| 仮想マシンを一時停止状態で起動します。このオプションを使用すると、VNC コンソールからブートプロセスを中断できます。 |
|
| 仮想マシンを停止します。 |
|
| 仮想マシンを強制停止します。このオプションは、データの不整合またはデータ損失を引き起こす可能性があります。 |
|
| 仮想マシンまたは VMI を一時停止します。マシンの状態がメモリーに保持されます。 |
|
| 仮想マシンまたは VMI の一時停止を解除します。 |
|
| 仮想マシンを移行します。 |
|
| 仮想マシンを再起動します。 |
9.3.2. 仮想マシンおよび VMI 接続コマンド
virtctl を使用して、シリアルコンソールに接続し、ポートを公開し、プロキシー接続を設定し、ポートを指定し、仮想マシンへの VNC 接続を開くことができます。
| コマンド | Description |
|---|---|
|
| VMI のシリアルコンソールに接続します。 |
|
| 仮想マシンまたは VMI の指定されたポートを転送するサービスを作成し、ノードの指定されたポートでサービスを公開します。 |
|
| VMI への仮想ネットワーククライアント (VNC) 接続を開きます。 VNC を介して VMI のグラフィカルコンソールにアクセスするには、ローカルマシンにリモートビューアーが必要です。 |
|
| ポート番号を表示し、VNC 接続を介してビューアーを使用して手動で VMI に接続します。 |
|
| ポートが利用可能な場合、その指定されたポートでプロキシーを実行するためにポート番号を指定します。 ポート番号が指定されていない場合、プロキシーはランダムポートで実行されます。 |
9.3.3. 仮想マシンボリュームエクスポートコマンド
virtctl vmexport コマンドを使用して、仮想マシン、仮想マシンスナップショット、または永続ボリューム要求 (PVC) からエクスポートされたボリュームを作成、ダウンロード、または削除できます。
| コマンド | 説明 |
|---|---|
|
|
仮想マシン、仮想マシンスナップショット、または PVC からボリュームをエクスポートするには、
|
|
|
|
|
|
オプション:
|
|
|
|
9.3.4. 仮想マシンメモリーダンプコマンド
virtctl memory-dump コマンドを使用して、PVC に仮想マシン (VM) のメモリーダンプを出力できます。既存の PVC を指定するか、--create-claim フラグを使用して新しい PVC を作成できます。
前提条件
-
PVC ボリュームモードは
FileSystemである必要があります。 PVC は、メモリーダンプを格納するのに十分な大きさである必要があります。
PVC サイズを計算する式は
(VMMemorySize + 100Mi) * FileSystemOverheadです。ここで、100Miはメモリーダンプのオーバーヘッドです。次のコマンドを実行して、
HyperConvergedカスタムリソースでホットプラグフィーチャーゲートを有効にする必要があります。oc patch hco kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "add", "path": "/spec/featureGates", \ "value": "HotplugVolumes"}]'$ oc patch hco 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 を変更する場合は、メモリーダンプを手動で削除する必要があります。
このコマンドは、 |
9.3.5. イメージアップロードコマンド
virtctl image-upload コマンドを使用して、VM イメージをデータボリュームにアップロードできます。
| コマンド | 説明 |
|---|---|
|
| VM イメージを既存のデータボリュームにアップロードします。 |
|
| 指定された要求されたサイズの新しいデータボリュームに VM イメージをアップロードします。 |
9.3.6. 環境情報コマンド
virtctl を使用して、バージョン、ファイルシステム、ゲストオペレーティングシステム、およびログインユーザーに関する情報を表示できます。
| コマンド | Description |
|---|---|
|
| ゲストマシンで使用可能なファイルシステムを表示します。 |
|
| ゲストマシンのオペレーティングシステムに関する情報を表示します。 |
|
| ゲストマシンにログインしているユーザーを表示します。 |
9.4. virtctl guestfs を使用したコンテナーの作成
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 名は必須の引数です。この引数を追加しないと、エラーメッセージが表示されます。
9.5. 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 つだけを受け入れます。
第10章 仮想マシン
10.1. 仮想マシンの作成
以下のいずれかの手順を使用して、仮想マシンを作成します。
- クイックスタートのガイド付きツアー
- カタログからクイック作成
- 仮想マシンウィザードによる事前に設定された YAML ファイルの貼り付け
- CLI の使用
openshift-* namespace に仮想マシンを作成しないでください。代わりに、openshift 接頭辞なしの新規 namespace を作成するか、既存 namespace を使用します。
Web コンソールから仮想マシンを作成する場合、ブートソースで設定される仮想マシンテンプレートを選択します。ブートソースを含む仮想マシンテンプレートには Available boot source というラベルが付けられるか、それらはカスタマイズされたラベルテキストを表示します。選択可能なブートソースでテンプレートを使用すると、仮想マシンの作成プロセスをスピードアップできます。
ブートソースのないテンプレートには、Boot source required というラベルが付けられます。ブートソースを仮想マシンに追加する 手順を実行する場合、これらのテンプレートを使用できます。
ストレージの動作の違いにより、一部の仮想マシンテンプレートは単一ノードの Openshift と互換性がありません。互換性を確保するためには、テンプレートまたはデータボリュームまたはストレージプロファイルを使用する仮想マシンにevictionStrategyフィールドを設定しないでください。
10.1.1. クイックスタートの使用による仮想マシンの作成
Web コンソールは、仮想マシンを作成するためのガイド付きツアーを含むクイックスタートを提供します。Administrator パースペクティブの Help メニューを選択して Quick Starts カタログにアクセスし、Quick Starts カタログを表示できます。Quick Starts タイルをクリックし、ツアーを開始すると、システムによるプロセスのガイドが開始します。
Quick Starts のタスクは、Red Hat テンプレートの選択から開始します。次に、ブートソースを追加して、オペレーティングシステムイメージをインポートできます。最後に、カスタムテンプレートを保存し、これを使用して仮想マシンを作成できます。
前提条件
- オペレーティングシステムイメージの URL リンクをダウンロードできる Web サイトにアクセスすること。
手順
- Web コンソールで、Help メニューから Quick Starts を選択します。
- Quick Starts カタログのタイルをクリックします。例: Red Hat Linux Enterprise Linux 仮想マシンの作成
- ガイド付きツアーの手順に従い、オペレーティングシステムイメージのインポートと仮想マシンの作成タスクを実行します。Virtualization → VirtualMachines ページに仮想マシンが表示されます。
10.1.2. 仮想マシンのクイック作成
使用可能なブートソースを含むテンプレートを使用して、仮想マシン (VM) をすばやく作成できます。
手順
- サイドメニューの Virtualization → Catalog をクリックします。
利用可能なブートソース をクリックして、テンプレートをブートソースでフィルタリングします。
注記デフォルトでは、テンプレートリストには Default Templates のみが表示されます。選択したフィルターで使用可能なすべてのテンプレートを表示するには、フィルタリング時に すべてのアイテムをクリックします。
- テンプレートをクリックして詳細を表示します。
仮想マシンのクイック作成をクリックして、テンプレートから VM を作成します。
仮想マシンの詳細ページに、プロビジョニングステータスが表示されます。
検証
- Events をクリックして、仮想マシンがプロビジョニングされたときにイベントのストリームを表示します。
- Console をクリックして、仮想マシンが正常に起動したことを確認します。
10.1.3. カスタマイズされたテンプレートからの仮想マシンの作成
一部のテンプレートでは、追加のパラメーターが必要です。たとえば、ブート ソースを持つ PVC などです。テンプレートの選択パラメーターをカスタマイズして、仮想マシン (VM) を作成できます。
手順
Web コンソールで、テンプレートを選択します。
- サイドメニューの Virtualization → Catalog をクリックします。
- オプション: プロジェクト、キーワード、オペレーティングシステム、またはワークロードプロファイルでテンプレートをフィルター処理します。
- カスタマイズするテンプレートをクリックします。
- Customize VirtualMachineを クリックします。
- Name や Disk source など、仮想マシンのパラメーターを指定します。オプションで、複製するデータソースを指定できます。
検証
- Events をクリックして、仮想マシンがプロビジョニングされたときにイベントのストリームを表示します。
- Console をクリックして、仮想マシンが正常に起動したことを確認します。
Web コンソールから仮想マシンを作成する場合は、仮想マシンのフィールドセクションを参照してください。
10.1.3.1. ネットワークフィールド
| Name | 説明 |
|---|---|
| Name | ネットワークインターフェイスコントローラーの名前。 |
| モデル | ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
| Network | 利用可能なネットワーク接続定義のリスト。 |
| 型 | 利用可能なバインディングメソッドの一覧。ネットワークインターフェイスに適したバインド方法を選択します。
|
| MAC Address | ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
10.1.3.2. ストレージフィールド
| Name | 選択 | Description |
|---|---|---|
| Source | 空白 (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 URLURL、および Clone existing PVC ディスクで利用できます。OpenShift Virtualization 4.11 より前では、これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。OpenShift Virtualization 4.11 以降では、システムは ストレージプロファイル のデフォルト値を使用します。
ストレージプロファイルを使用して、OpenShift Virtualization のストレージをプロビジョニングするときに一貫した高度なストレージ設定を確保します。
Volume Mode と Access Mode を手動で指定するには、デフォルトで選択されている Apply optimized StorageProfile settings チェックボックスをオフにする必要があります。
| Name | モードの説明 | パラメーター | パラメーターの説明 |
|---|---|---|---|
| ボリュームモード | 永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。 | Filesystem | ファイルシステムベースのボリュームで仮想ディスクを保存します。 |
| Block |
ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 | ||
| アクセスモード | 永続ボリュームのアクセスモード。 | ReadWriteOnce (RWO) | ボリュームはシングルノードで読み取り/書き込みとしてマウントできます。 |
| ReadWriteMany (RWX) | ボリュームは、一度に多くのノードで読み取り/書き込みとしてマウントできます。 注記 これは、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。 | ||
| ReadOnlyMany (ROX) | ボリュームは数多くのノードで読み取り専用としてマウントできます。 |
10.1.3.3. Cloud-init フィールド
| Name | Description |
|---|---|
| 認可された SSH キー | 仮想マシンの ~/.ssh/authorized_keys にコピーされるユーザーの公開鍵。 |
| カスタムスクリプト | 他のオプションを、カスタム cloud-init スクリプトを貼り付けるフィールドに置き換えます。 |
ストレージクラスのデフォルトを設定するには、ストレージプロファイルを使用します。詳細については、ストレージプロファイルのカスタマイズを参照してください。
10.1.3.4. 仮想マシンウィザードの作成用の事前に設定された YAML ファイルの貼り付け
YAML 設定ファイルを作成し、解析して仮想マシンを作成します。YAML 編集画面を開くと、常に有効な example 仮想マシン設定がデフォルトで提供されます。
Create をクリックする際に YAML 設定が無効な場合、エラーメッセージでエラーが発生したパラメーターが示唆されます。エラーは一度に 1 つのみ表示されます。
編集中に YAML 画面から離れると、設定に対して加えた変更が取り消されます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- Create をクリックし、With YAML を選択します。
編集可能なウィンドウで仮想マシンの設定を作成するか、これを貼り付けます。
-
または、YAML 画面にデフォルトで提供される
example仮想マシンを使用します。
-
または、YAML 画面にデフォルトで提供される
- オプション: Download をクリックして YAML 設定ファイルをその現在の状態でダウンロードします。
- Create をクリックして仮想マシンを作成します。
仮想マシンが VirtualMachines ページにリスト表示されます。
10.1.4. CLI の使用による仮想マシンの作成
virtualMachine マニフェストから仮想マシンを作成できます。
手順
仮想マシンの
VirtualMachineマニフェストを編集します。たとえば、次のマニフェストは Red Hat Enterprise Linux (RHEL) 仮想マシンを設定します。マニフェストファイルを使用して仮想マシンを作成します。
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
10.1.5. 仮想マシンのストレージボリュームタイプ
| ストレージボリュームタイプ | Description |
|---|---|
| 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 コンソールから停止または再起動する場合には破棄されます。空のディスクは、アプリケーションの依存関係および一時ディスクの一時ファイルシステムの制限を上回るデータを保存するために使用されます。 ディスク 容量 サイズも指定する必要があります。 |
10.1.6. 仮想マシンの RunStrategy について
仮想マシンの RunStrategy は、一連の条件に応じて仮想マシンインスタンス (VMI) の動作を判別します。spec.runStrategy 設定は、spec.running 設定の代わりに仮想マシン設定プロセスに存在します。spec.runStrategy 設定を使用すると、true または false の応答のみを伴う spec.running 設定とは対照的に、VMI の作成および管理をより柔軟に行えます。ただし、2 つの設定は相互排他的です。spec.running または spec.runStrategy のいずれかを使用できます。両方を使用する場合は、エラーが発生します。
4 つ RunStrategy が定義されています。
Always-
VMI は仮想マシンの作成時に常に表示されます。元の VMI が何らかの理由で停止する場合に、新規の VMI が作成されます。これは
spec.running: trueと同じ動作です。 RerunOnFailure- 前のインスタンスがエラーが原因で失敗する場合は、VMI が再作成されます。インスタンスは、仮想マシンが正常に停止する場合 (シャットダウン時など) には再作成されません。
Manual(手動)-
start、stop、およびrestartvirtctl クライアントコマンドは、 VMI の状態および存在を制御するために使用できます。 Halted-
仮想マシンが作成される際に VMI は存在しません。これは
spec.running: falseと同じ動作です。
start、stop、および restart の virtctl コマンドの各種の組み合わせは、どの RunStrategy が使用されるかに影響を与えます。
以下の表は、仮想マシンの各種の状態からの移行について示しています。最初の列には、仮想マシンの初期の RunStrategy が表示されます。それぞれの追加の列には、virtctl コマンドと、このコマンド実行後の新規 RunStrategy が表示されます。
| 初期 RunStrategy | start | stop | restart |
|---|---|---|---|
| Always | - | Halted | Always |
| RerunOnFailure | - | Halted | RerunOnFailure |
| Manual | Manual | Manual | Manual |
| Halted | Always | - | - |
インストーラーでプロビジョニングされるインフラストラクチャーを使用してインストールされた OpenShift Virtualization クラスターでは、ノードで MachineHealthCheck に失敗し、クラスターで利用できなくなると、RunStrategy が Always または RerunOnFailure の仮想マシンが新規ノードで再スケジュールされます。
- 1
- VMI の現在の
RunStrategy設定。
10.2. 仮想マシンの編集
Web コンソールの YAML エディターまたはコマンドラインの OpenShift CLI のいずれかを使用して、仮想マシン設定を更新できます。Virtual Machine Details 画面でパラメーターのサブセットを更新することもできます。
10.2.1. Web コンソールでの仮想マシンの編集
OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイスを使用して、仮想マシンを編集できます。
手順
- Web コンソールで Virtualization → VirtualMachines に移動します。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- フィールドが編集可能であることを示す鉛筆アイコンが付いているフィールドをクリックします。たとえば、BIOS や UEFI などの現在の ブートモード 設定をクリックして、Boot mode ウィンドウを開き、リストからオプションを選択します。
- Save をクリックします。
仮想マシンが実行されている場合、Boot Order または Flavor への変更は仮想マシンを再起動するまで反映されません。
関連するフィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更のリストが表示されます。
10.2.2. Web コンソールを使用した仮想マシンの YAML 設定の編集
Web コンソールで、仮想マシンの YAML 設定を編集できます。一部のパラメーターは変更できません。無効な設定で Save をクリックすると、エラーメッセージで変更できないパラメーターが示唆されます。
編集中に YAML 画面から離れると、設定に対して加えた変更が取り消されます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択します。
- YAML タブをクリックして編集可能な設定を表示します。
- オプション: Download をクリックして YAML ファイルをその現在の状態でローカルにダウンロードできます。
- ファイルを編集し、Save をクリックします。
オブジェクトの更新されたバージョン番号を含む、変更が正常に行われたことを示す確認メッセージが表示されます。
10.2.3. CLI を使用した仮想マシン YAML 設定の編集
以下の手順を使用し、CLI を使用して仮想マシン YAML 設定を編集します。
前提条件
- YAML オブジェクト設定ファイルを使用して仮想マシンを設定していること。
-
ocCLI をインストールしていること。
手順
以下のコマンドを実行して、仮想マシン設定を更新します。
oc edit <object_type> <object_ID>
$ oc edit <object_type> <object_ID>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - オブジェクト設定を開きます。
- YAML を編集します。
実行中の仮想マシンを編集する場合は、以下のいずれかを実行する必要があります。
- 仮想マシンを再起動します。
新規の設定を有効にするために、以下のコマンドを実行します。
oc apply <object_type> <object_ID>
$ oc apply <object_type> <object_ID>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2.4. 仮想マシンへの仮想ディスクの追加
以下の手順を使用して仮想ディスクを仮想マシンに追加します。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details 画面を開きます。
- Disks タブをクリックし、Add disk をクリックします。
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 をクリックします。
仮想マシンが実行中の場合、新規ディスクは pending restart 状態にあり、仮想マシンを再起動するまで割り当てられません。
ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。
ストレージクラスのデフォルトを設定するには、ストレージプロファイルを使用します。詳細については、ストレージプロファイルのカスタマイズを参照してください。
10.2.4.1. VirtualMachine の CD-ROM の編集
以下の手順を使用して、仮想マシンの CD-ROM を編集します。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details 画面を開きます。
- Disks タブをクリックします。
-
編集する CD-ROM の Options メニュー
をクリックし、Edit を選択します。
- Edit CD-ROM ウィンドウで、Source、Persistent Volume Claim、Name、Type、および Interface フィールドを編集します。
- Save をクリックします。
10.2.4.2. ストレージフィールド
| Name | 選択 | Description |
|---|---|---|
| Source | 空白 (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 URLURL、および Clone existing PVC ディスクで利用できます。OpenShift Virtualization 4.11 より前では、これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。OpenShift Virtualization 4.11 以降では、システムは ストレージプロファイル のデフォルト値を使用します。
ストレージプロファイルを使用して、OpenShift Virtualization のストレージをプロビジョニングするときに一貫した高度なストレージ設定を確保します。
Volume Mode と Access Mode を手動で指定するには、デフォルトで選択されている Apply optimized StorageProfile settings チェックボックスをオフにする必要があります。
| Name | モードの説明 | パラメーター | パラメーターの説明 |
|---|---|---|---|
| ボリュームモード | 永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。 | Filesystem | ファイルシステムベースのボリュームで仮想ディスクを保存します。 |
| Block |
ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 | ||
| アクセスモード | 永続ボリュームのアクセスモード。 | ReadWriteOnce (RWO) | ボリュームはシングルノードで読み取り/書き込みとしてマウントできます。 |
| ReadWriteMany (RWX) | ボリュームは、一度に多くのノードで読み取り/書き込みとしてマウントできます。 注記 これは、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。 | ||
| ReadOnlyMany (ROX) | ボリュームは数多くのノードで読み取り専用としてマウントできます。 |
10.2.5. 仮想マシンへのネットワークインターフェイスの追加
以下の手順を使用してネットワークインターフェイスを仮想マシンに追加します。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details 画面を開きます。
- Network Interfaces タブをクリックします。
- Add Network Interface をクリックします。
- Add Network Interface ウィンドウで、ネットワークインターフェイスの Name、Model、Network、 Type、および MAC Address を指定します。
- Add をクリックします。
仮想マシンが実行中の場合、新規ネットワークインターフェイスは pending restart 状態にあり、仮想マシンを再起動するまで変更は反映されません。
ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更のリストが表示されます。
10.2.5.1. ネットワークフィールド
| Name | 説明 |
|---|---|
| Name | ネットワークインターフェイスコントローラーの名前。 |
| モデル | ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
| Network | 利用可能なネットワーク接続定義のリスト。 |
| 型 | 利用可能なバインディングメソッドの一覧。ネットワークインターフェイスに適したバインド方法を選択します。
|
| MAC Address | ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
10.3. ブート順序の編集
Web コンソールまたは CLI を使用して、ブート順序リストの値を更新できます。
Virtual Machine Overview ページの Boot Order で、以下を実行できます。
- ディスクまたはネットワークインターフェイスコントローラー (NIC) を選択し、これをブート順序のリストに追加します。
- ブート順序の一覧でディスクまたは NIC の順序を編集します。
- ブート順序のリストからディスクまたは NIC を削除して、起動可能なソースのインベントリーに戻します。
10.3.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 バナーには、仮想マシンの再起動時に適用されるすべての変更のリストが表示されます。
10.3.2. Web コンソールでのブート順序リストの編集
Web コンソールで起動順序リストを編集します。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Details タブをクリックします。
- Boot Order の右側にある鉛筆アイコンをクリックします。
ブート順序リストで項目を移動するのに適した方法を選択します。
- スクリーンリーダーを使用しない場合、移動する項目の横にある矢印アイコンにカーソルを合わせ、項目を上下にドラッグし、選択した場所にドロップします。
- スクリーンリーダーを使用する場合は、上矢印キーまたは下矢印を押して、ブート順序リストで項目を移動します。次に Tab キーを押して、選択した場所に項目をドロップします。
- Save をクリックします。
仮想マシンが実行されている場合、ブート順序の変更は仮想マシンが再起動されるまで反映されません。
Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更のリストが表示されます。
10.3.3. YAML 設定ファイルでのブート順序リストの編集
CLI を使用して、YAML 設定ファイルのブート順序のリストを編集します。
手順
以下のコマンドを実行して、仮想マシンの YAML 設定ファイルを開きます。
oc edit vm example
$ oc edit vm exampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルを編集し、ディスクまたはネットワークインターフェイスコントローラー (NIC) に関連付けられたブート順序の値を変更します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - YAML ファイルを保存します。
- reload the content をクリックして、Web コンソールで YAML ファイルの更新されたブート順序の値をブート順序リストに適用します。
10.3.4. Web コンソールでのブート順序リストからの項目の削除
Web コンソールを使用して、ブート順序のリストから項目を削除します。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Details タブをクリックします。
- Boot Order の右側にある鉛筆アイコンをクリックします。
-
項目の横にある Remove アイコン
をクリックします。この項目はブート順序のリストから削除され、利用可能なブートソースのリストに保存されます。ブート順序リストからすべての項目を削除する場合、以下のメッセージが表示されます。No resource selected.仮想マシンは、YAML ファイルでの出現順にディスクからの起動を試行します。
仮想マシンが実行されている場合、Boot Order への変更は仮想マシンを再起動するまで反映されません。
Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更のリストが表示されます。
10.4. 仮想マシンの削除
Web コンソールまたは oc コマンドラインインターフェイスを使用して、仮想マシンを削除できます。
10.4.1. Web コンソールの使用による仮想マシンの削除
仮想マシンを削除すると、仮想マシンはクラスターから永続的に削除されます。
仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
削除する仮想マシンの Options メニュー
をクリックし、Delete を選択します。
- または、仮想マシン名をクリックして VirtualMachine details ページを開き、Actions → Delete をクリックします。
- 確認のポップアップウィンドウで、Delete をクリックし、仮想マシンを永続的に削除します。
10.4.2. CLI の使用による仮想マシンの削除
oc コマンドラインインターフェイス (CLI) を使用して仮想マシンを削除できます。oc クライアントを使用すると、複数の仮想マシンで各種のアクションを実行できます。
仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。
前提条件
- 削除する仮想マシンの名前を特定している。
手順
以下のコマンドを実行し、仮想マシンを削除します。
oc delete vm <vm_name>
$ oc delete vm <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記このコマンドは、現在のプロジェクトに存在するオブジェクトのみを削除します。削除する必要のあるオブジェクトが別のプロジェクトまたは namespace にある場合、
-n <project_name>オプションを指定します。
10.5. 仮想マシンのエクスポート
仮想マシンを別のクラスターにインポートしたり、フォレンジック目的でボリュームを分析したりするために、仮想マシン (VM) とそれに関連付けられたディスクをエクスポートできます。
コマンドラインインターフェイスを使用して、VirtualMachineExport カスタムリソース (CR) を作成します。
または、virtctl vmexport コマンド を使用して VirtualMachineExport CR を作成し、エクスポートされたボリュームをダウンロードすることもできます。
10.5.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
10.6. 仮想マシンインスタンスの管理
OpenShift Virtualization 環境の外部で独立して作成されたスタンドアロン仮想マシンインスタンス (VMI) がある場合、Web コンソールを使用するか、コマンドラインインターフェイス (CLI) から oc または virtctl コマンドを使用してそれらを管理できます。
virtctl コマンドは、oc コマンドよりも多くの仮想化オプションを提供します。たとえば、virtctl を使用して仮想マシンを一時停止したり、ポートを公開したりできます。
10.6.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 を削除します。
10.6.2. CLI を使用した仮想マシンインスタンスのリスト表示
oc コマンドラインインターフェイス (CLI) を使用して、スタンドアロンおよび仮想マシンによって所有されている VMI を含むすべての仮想マシンのリストを表示できます。
手順
以下のコマンドを実行して、すべての VMI のリストを表示します。
oc get vmis -A
$ oc get vmis -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.6.3. Web コンソールを使用したスタンドアロン仮想マシンインスタンスのリスト表示
Web コンソールを使用して、仮想マシンによって所有されていないクラスター内のスタンドアロンの仮想マシンインスタンス (VMI) のリストを表示できます。
仮想マシンまたは他のオブジェクトが所有する VMI は、Web コンソールには表示されません。Web コンソールは、スタンドアロンの VMI のみを表示します。クラスター内のすべての VMI をリスト表示するには、CLI を使用する必要があります。
手順
サイドメニューから Virtualization → VirtualMachines をクリックします。
スタンドアロン VMI は、名前の横にある濃い色のバッジで識別できます。
10.6.4. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの編集
Web コンソールを使用して、スタンドアロン仮想マシンインスタンスのアノテーションおよびラベルを編集できます。他のフィールドは編集できません。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- スタンドアロン VMI を選択して、VirtualMachineInstance details ページを開きます。
- Details タブで、Annotations または Labels の横にある鉛筆アイコンをクリックします。
- 関連する変更を加え、Save をクリックします。
10.6.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
10.6.6. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの削除
Web コンソールからスタンドアロン仮想マシンインスタンス (VMI) を削除します。
手順
- OpenShift Container Platform Web コンソールで、サイドメニューからVirtualization → VirtualMachinesをクリックします。
- Actions → Delete VirtualMachineInstance をクリックします。
- 確認のポップアップウィンドウで、Delete をクリックし、スタンドアロン VMI を永続的に削除します。
10.7. 仮想マシンの状態の制御
Web コンソールから仮想マシンを停止し、起動し、再起動し、一時停止を解除することができます。
virtctl を使用して仮想マシンの状態を管理し、CLI から他のアクションを実行できます。たとえば、virtctl を使用して仮想マシンを強制停止したり、ポートを公開したりできます。
10.7.1. 仮想マシンの起動
Web コンソールから仮想マシンを起動できます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 起動する仮想マシンが含まれる行を見つけます。
ユースケースに応じて適切なメニューに移動します。
複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。
-
行の右端にある Options メニュー
をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
- Actions をクリックします。
- 再起動を選択します。
- 確認ウィンドウで Start をクリックし、仮想マシンを起動します。
URL ソースからプロビジョニングされる仮想マシンの初回起動時に、OpenShift Virtualization が URL エンドポイントからコンテナーをインポートする間、仮想マシンの状態は Importing になります。このプロセスは、イメージのサイズによって数分の時間がかかる可能性があります。
10.7.2. 仮想マシンの再起動
Web コンソールから実行中の仮想マシンを再起動できます。
エラーを回避するには、ステータスが Importing の仮想マシンは再起動しないでください。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 再起動する仮想マシンが含まれる行を見つけます。
ユースケースに応じて適切なメニューに移動します。
複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。
-
行の右端にある Options メニュー
をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを再起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
- Actions → Restart をクリックします。
- 確認ウィンドウで Restart をクリックし、仮想マシンを再起動します。
10.7.3. 仮想マシンの停止
Web コンソールから仮想マシンを停止できます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 停止する仮想マシンが含まれる行を見つけます。
ユースケースに応じて適切なメニューに移動します。
複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。
-
行の右端にある Options メニュー
をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを停止する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
- Actions → Stop をクリックします。
- 確認ウィンドウで Stop をクリックし、仮想マシンを停止します。
10.7.4. 仮想マシンの一時停止の解除
Web コンソールから仮想マシンの一時停止を解除できます。
前提条件
1 つ以上の仮想マシンのステータスが Paused である必要がある。
注記virtctlクライアントを使用して仮想マシンを一時停止することができます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 一時停止を解除する仮想マシンが含まれる行を見つけます。
ユースケースに応じて適切なメニューに移動します。
複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。
- Status 列で、Paused をクリックします。
選択した仮想マシンの一時停止を解除する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
- Status の右側にある鉛筆アイコンをクリックします。
- 確認ウィンドウで Stop をクリックし、仮想マシンの一時停止を解除します。
10.8. 仮想マシンコンソールへのアクセス
OpenShift Virtualization は、異なる製品タスクを実現するために使用できる異なる仮想マシンコンソールを提供します。これらのコンソールには、OpenShift Container Platform Web コンソールから、また CLI コマンドを使用してアクセスできます。
単一の仮想マシンに対する同時 VNC 接続の実行は、現在サポートされていません。
10.8.1. OpenShift Container Platform Web コンソールでの仮想マシンコンソールへのアクセス
OpenShift Container Platform Web コンソールでシリアルコンソールまたは VNC コンソールを使用して、仮想マシンに接続できます。
OpenShift Container Platform Web コンソールで、RDP (リモートデスクトッププロトコル) を使用するデスクトップビューアーコンソールを使用して、Windows 仮想マシンに接続できます。
10.8.1.1. シリアルコンソールへの接続
Web コンソールの VirtualMachine details ページにある Console タブから、実行中の仮想マシンのシリアルコンソールに接続します。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Console タブをクリックします。VNC コンソールがデフォルトで開きます。
- 一度に 1 つのコンソール セッションのみが開かれるようにするには、Disconnect をクリックします。それ以外の場合、VNC コンソール セッションはバックグラウンドでアクティブなままになります。
- VNC Console ドロップダウンリストをクリックし、Serial Console を選択します。
- Disconnect をクリックして、コンソールセッションを終了します。
- オプション: Open Console in New Window をクリックして、別のウィンドウでシリアルコンソールを開きます。
10.8.1.2. VNC コンソールへの接続
Web コンソールの VirtualMachine details ページにある Console タブから、実行中の仮想マシンの VNC コンソールに接続します。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Console タブをクリックします。VNC コンソールがデフォルトで開きます。
- オプション: Open Console in New Window をクリックして、別のウィンドウで VNC コンソールを開きます。
- オプション: Send Key をクリックして、キーの組み合わせを仮想マシンに送信します。
- コンソールウィンドウの外側をクリックし、Disconnect をクリックしてセッションを終了します。
10.8.1.3. RDP を使用した Windows 仮想マシンへの接続
Remote Desktop Protocol (RDP) を使用する Desktop viewer コンソールは、Windows 仮想マシンに接続するためのより使いやすいコンソールを提供します。
RDP を使用して Windows 仮想マシンに接続するには、Web コンソールの VirtualMachine 詳細 ページの Console タブから仮想マシンの console.rdp ファイルをダウンロードし、優先する RDP クライアントに提供します。
前提条件
-
QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。
qemu-guest-agentは VirtIO ドライバーに含まれています。 - Windows 仮想マシンと同じネットワーク上のマシンにインストールされた RDP クライアント。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- Windows 仮想マシンをクリックして、VirtualMachine details ページを開きます。
- Console タブをクリックします。
- コンソールのリストから、Desktop viewer を選択します。
-
Launch Remote Desktop をクリックし、
console.rdpファイルをダウンロードします。 -
優先する RDP クライアントで
console.rdpファイルを参照して、Windows 仮想マシンに接続します。
10.8.1.4. 仮想マシンの表示の切り替え
Windows 仮想マシン (VM) に vGPU が接続されている場合、Web コンソールを使用してデフォルトのディスプレイと vGPU ディスプレイを切り替えることができます。
前提条件
-
仲介されたデバイスは、
HyperConvergedカスタムリソースで設定され、仮想マシンに割り当てられます。 - 仮想マシンは実行中です。
手順
- OpenShift Container Platform コンソールで、Virtualization → VirtualMachines をクリックします。
- Windows 仮想マシンを選択して Overview 画面を開きます。
- Console タブをクリックします。
- コンソールのリストから、VNC console を選択します。
Send Key リストから適切なキーの組み合わせを選択します。
-
デフォルトの仮想マシン表示にアクセスするには、
Ctl + Alt+ 1を選択します。 -
vGPU ディスプレイにアクセスするには、
Ctl + Alt + 2を選択します。
-
デフォルトの仮想マシン表示にアクセスするには、
10.8.1.5. Web コンソールを使用した SSH コマンドのコピー
コマンドをコピーして、SSH 経由で仮想マシン (VM) ターミナルに接続します。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
-
オプション メニューをクリック
仮想マシンの SSH コマンドのコピー を選択します。
- ターミナルに貼り付け、仮想マシンにアクセスします。
10.8.2. CLI コマンドの使用による仮想マシンコンソールへのアクセス
10.8.2.1. virtctl を使用して SSH 経由で仮想マシンにアクセスする
virtctl ssh コマンドを使用して、ローカル SSH クライアントを使用して SSH トラフィックを仮想マシン (VM) に転送できます。仮想マシンで SSH キー認証を設定している場合は、手順 1 は必要ないため、手順 2 に進んでください。
コントロールプレーンの SSH トラフィックが多いと、API サーバーの速度が低下する可能性があります。定期的に多数の接続が必要な場合は、専用の Kubernetes Service オブジェクトを使用して仮想マシンにアクセスします。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
virtctlクライアントをインストールしました。 - アクセスする仮想マシンが実行されています。
- 仮想マシンと同じプロジェクトにいます。
手順
SSH キー認証を設定します。
ssh-keygenコマンドを使用して、SSH 公開鍵ペアを生成します。ssh-keygen -f <key_file>
$ ssh-keygen -f <key_file>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- キーを格納するファイルを指定します。
仮想マシンにアクセスするための SSH 公開鍵を含む SSH 認証シークレットを作成します。
oc create secret generic my-pub-key --from-file=key1=<key_file>.pub
$ oc create secret generic my-pub-key --from-file=key1=<key_file>.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow VirtualMachineマニフェストにシークレットへの参照を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 仮想マシンを再起動して変更を適用します。
SSH 経由で仮想マシンに接続します。
次のコマンドを実行して、SSH 経由で仮想マシンにアクセスします。
virtctl ssh -i <key_file> <vm_username>@<vm_name>
$ virtctl ssh -i <key_file> <vm_username>@<vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 仮想マシンとの間でファイルを安全に転送するには、次のコマンドを使用します。
マシンから仮想マシンにファイルをコピーする
virtctl scp -i <key_file> <filename> <vm_username>@<vm_name>:
$ virtctl scp -i <key_file> <filename> <vm_username>@<vm_name>:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンからマシンにファイルをコピーする
virtctl scp -i <key_file> <vm_username@<vm_name>:<filename> .
$ virtctl scp -i <key_file> <vm_username@<vm_name>:<filename> .Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.8.2.2. OpenSSH および 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
10.8.2.3. 仮想マシンインスタンスのシリアルコンソールへのアクセス
virtctl console コマンドは、指定された仮想マシンインスタンスへのシリアルコンソールを開きます。
前提条件
-
virt-viewerパッケージがインストールされていること。 - アクセスする仮想マシンインスタンスが実行中であること。
手順
virtctlでシリアルコンソールに接続します。virtctl console <VMI>
$ virtctl console <VMI>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.8.2.4. VNC を使用した仮想マシンインスタンスのグラフィカルコンソールへのアクセス
virtctl クライアントユーティリティーは remote-viewer 機能を使用し、実行中の仮想マシンインスタンスに対してグラフィカルコンソールを開くことができます。この機能は virt-viewer パッケージに組み込まれています。
前提条件
-
virt-viewerパッケージがインストールされていること。 - アクセスする仮想マシンインスタンスが実行中であること。
リモートマシンで SSH 経由で virtctl を使用する場合、X セッションをマシンに転送する必要があります。
手順
virtctlユーティリティーを使用してグラフィカルインターフェイスに接続します。virtctl vnc <VMI>
$ virtctl vnc <VMI>Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドが失敗した場合には、トラブルシューティング情報を収集するために
-vフラグの使用を試行します。virtctl vnc <VMI> -v 4
$ virtctl vnc <VMI> -v 4Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.8.2.5. RDP コンソールの使用による Windows 仮想マシンへの接続
ローカルのリモートデスクトッププロトコル (RDP) クライアントを使用して、Windows 仮想マシン (VM) に接続するための Kubernetes Service オブジェクトを作成します。
前提条件
-
QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。
qemu-guest-agentオブジェクトは VirtIO ドライバーに含まれています。 - ローカルマシンにインストールされた RDP クライアント。
手順
VirtualMachineマニフェストを編集して、サービス作成のラベルを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ラベル
special: keyをspec.template.metadata.labelsセクションに追加します。
注記仮想マシンのラベルは Pod に渡されます。
special: キーラベルは、Serviceマニフェストのspec.selector属性のラベルと一致する必要があります。-
VirtualMachineマニフェストファイルを保存して変更を適用します。 仮想マシンを公開するための
Serviceマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
サービスマニフェストファイルを保存します。 以下のコマンドを実行してサービスを作成します。
oc create -f <service_name>.yaml
$ oc create -f <service_name>.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 NodePortサービスの出力例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE rdpservice NodePort 172.30.232.73 <none> 3389:30000/TCP 5m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE rdpservice NodePort 172.30.232.73 <none> 3389:30000/TCP 5mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、ノードの IP アドレスを取得します。
oc get node <node_name> -o wide
$ oc get node <node_name> -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP node01 Ready worker 6d22h v1.24.0 192.168.55.101 <none>
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP node01 Ready worker 6d22h v1.24.0 192.168.55.101 <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 優先する RDP クライアントでノード IP アドレスと割り当てられたポートを指定します。
- Windows 仮想マシンに接続するためのユーザー名とパスワードを入力します。
10.9. sysprep を使用した Windows のインストールの自動化
Microsoft DVD イメージとsysprepを使用して、Windows 仮想マシンのインストール、セットアップ、およびソフトウェアプロビジョニングを自動化できます。
10.9.1. Windows DVD を使用した VM ディスクイメージの作成
Microsoft はダウンロード用のディスクイメージを提供していませんが、Windows DVD を使用してディスクイメージを作成できます。このディスクイメージを使用して、仮想マシンを作成できます。
手順
- Open Shift Virtualization Web コンソールで、Storage → PersistentVolumeClaims → Create PersistentVolumeClaim With Data upload formをクリックします。
- 目的のプロジェクトを選択します。
- 永続ボリューム要求の名前を設定します。
- Windows DVD から仮想マシンディスクイメージをアップロードします。これで、イメージをブートソースとして使用して、新しい Windows 仮想マシンを作成できます。
10.9.2. ディスクイメージを使用した Windows のインストール
ディスクイメージを使用して、仮想マシンに Windows をインストールできます。
前提条件
- Windows DVD を使用してディスクイメージを作成する必要があります。
-
autounattend.xml応答ファイルを作成する必要があります。詳細は、Microsoft のドキュメント を参照してください。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → Catalog をクリックします。
- Windows テンプレートを選択し、Customize VirtualMachine をクリックします。
- Disk source リストから Upload (Upload a new file to a PVC) を選択し、DVD イメージを参照します。
- Review and create VirtualMachine をクリックします。
- Clone available operating system source to this Virtual Machine のチェックを外します。
- Start this VirtualMachine after creation のチェックを外します。
- Scripts タブの Sysprep セクションで、Edit をクリックします。
-
autounattend.xml応答ファイルを参照し、Save をクリックします。 - Create VirtualMachine をクリックします。
-
YAML タブで、
running:falseをrunStrategy: RerunOnFailureに置き換え、Save をクリックします。
VM は、autounattend.xml 応答ファイルを含む sysprep ディスクで開始されます。
10.9.3. sysprep を使用した Windows 仮想マシンの一般化
イメージを一般化すると、イメージが仮想マシン (VM) にデプロイされる際に、システム固有の設定データがすべて削除されます。
仮想マシンを一般化する前に、Windows の無人インストール後にsysprepツールが応答ファイルを検出できないことを確認する必要があります。
手順
- OpenShift Container Platform コンソールで、Virtualization → VirtualMachines をクリックします。
- Windows 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Disks タブをクリックします。
-
sysprepディスクの Options メニュー
をクリックし、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 仮想マシンのインストールイメージとして使用できるようになりました。
これで、仮想マシンを特殊化できます。
10.9.4. Windows 仮想マシンの特殊化
仮想マシン (VM) を特殊化すると、一般化された Windows イメージから VM にコンピューター固有の情報が設定されます。
前提条件
- 一般化された Windows ディスクイメージが必要です。
-
unattend.xml応答ファイルを作成する必要があります。詳細は、Microsoft のドキュメント を参照してください。
手順
- OpenShift Container Platform コンソールで、Virtualization → Catalog をクリックします。
- Windows テンプレートを選択し、Customize VirtualMachine をクリックします。
- Disk source リストから PVC (clone PVC) を選択します。
- 一般化された Windows イメージの Persistent Volume Claim project および Persistent Volume Claim name を指定します。
- Review and create VirtualMachine をクリックします。
- Scripts タブをクリックします。
-
Sysprep セクションで、Edit をクリックし、
unattend.xml応答ファイルを参照して、Save をクリックします。 - Create VirtualMachine をクリックします。
Windows は初回起動時に、unattend.xml 応答ファイルを使用して VM を特殊化します。これで、仮想マシンを使用する準備が整いました。
10.10. 障害が発生したノードの解決による仮想マシンのフェイルオーバーのトリガー
ノードに障害が発生し、マシンヘルスチェック がクラスターにデプロイされていない場合、runStrategy: Always が設定された仮想マシンは正常なノードに自動的に再配置されません。仮想マシンのフェイルオーバーをトリガーするには、Node オブジェクトを手動で削除する必要があります。
インストーラーでプロビジョニングされるインフラストラクチャー を使用してクラスターをインストールし、マシンヘルスチェックを適切に設定している場合は、以下のようになります。
- 障害が発生したノードは自動的に再利用されます。
-
runStrategyがAlwaysまたはRerunOnFailureに設定された仮想マシンは正常なノードで自動的にスケジュールされます。
10.10.1. 前提条件
-
仮想マシンが実行されていたノードに
NotReady状態 が設定されている。 -
障害のあるノードで実行されていた仮想マシンでは、
RunStrategyがAlwaysに設定されている。 -
OpenShift CLI (
oc) がインストールされている。
10.10.2. ベアメタルクラスターからのノードの削除
CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーで管理されないベア Pod は、OpenShift Container Platform からはアクセスできなくなります。レプリケーションコントローラーで管理されるベア Pod は、他の利用可能なノードに再スケジュールされます。ローカルのマニフェスト Pod は削除する必要があります。
手順
以下の手順を実行して、ベアメタルで実行されている OpenShift Container Platform クラスターからノードを削除します。
ノードにスケジュール対象外 (unschedulable) のマークを付けます。
oc adm cordon <node_name>
$ oc adm cordon <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノード上のすべての Pod をドレイン (解放) します。
oc adm drain <node_name> --force=true
$ oc adm drain <node_name> --force=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow このステップは、ノードがオフラインまたは応答しない場合に失敗する可能性があります。ノードが応答しない場合でも、共有ストレージに書き込むワークロードを実行している可能性があります。データの破損を防ぐには、続行する前に物理ハードウェアの電源を切ります。
クラスターからノードを削除します。
oc delete node <node_name>
$ oc delete node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードオブジェクトはクラスターから削除されていますが、これは再起動後や kubelet サービスが再起動される場合にクラスターに再び参加することができます。ノードとそのすべてのデータを永続的に削除するには、ノードの使用を停止 する必要があります。
- 物理ハードウェアを電源を切っている場合は、ノードがクラスターに再度加わるように、そのハードウェアを再びオンに切り替えます。
10.10.3. 仮想マシンのフェイルオーバーの確認
すべてのリソースが正常でないノードで終了すると、移行した仮想マシンのそれぞれについて、新しい仮想マシンインスタンス (VMI) が正常なノードに自動的に作成されます。VMI が作成されていることを確認するには、oc CLI を使用してすべての VMI を表示します。
10.10.3.1. CLI を使用した仮想マシンインスタンスのリスト表示
oc コマンドラインインターフェイス (CLI) を使用して、スタンドアロンおよび仮想マシンによって所有されている VMI を含むすべての仮想マシンのリストを表示できます。
手順
以下のコマンドを実行して、すべての VMI のリストを表示します。
oc get vmis -A
$ oc get vmis -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.11. QEMU ゲストエージェントの仮想マシンへのインストール
QEMU ゲストエージェント は、仮想マシンで実行され、仮想マシン、ユーザー、ファイルシステム、およびセカンダリーネットワークに関する情報をホストに渡すデーモンです。
10.11.1. QEMU ゲストエージェントの Linux 仮想マシンへのインストール
qemu-guest-agent は広く利用されており、Red Hat 仮想マシンでデフォルトで利用できます。このエージェントをインストールし、サービスを起動します。
仮想マシン (VM) に QEMU ゲストエージェントがインストールされ、実行されているかどうかを確認するには、AgentConnected が 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
10.11.2. QEMU ゲストエージェントの Windows 仮想マシンへのインストール
Windows 仮想マシンの場合には、QEMU ゲストエージェントは VirtIO ドライバーに含まれます。既存または新規の Windows インストールにドライバーをインストールします。
仮想マシン (VM) に QEMU ゲストエージェントがインストールされ、実行されているかどうかを確認するには、AgentConnected が VM 仕様に表示されていることを確認します。
整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。
QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。
10.11.2.1. VirtIO ドライバーの既存 Windows 仮想マシンへのインストール
VirtIO ドライバーを、割り当てられた SATA CD ドライブから既存の Windows 仮想マシンにインストールします。
この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。このプロセスは Windows のバージョンごとに若干異なる可能性があります。特定のインストール手順については、お使いの Windows バージョンについてのインストールドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- 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 をクリックしてウィンドウを閉じます。
- 仮想マシンを再起動してドライバーのインストールを完了します。
10.11.2.2. Windows インストール時の VirtIO ドライバーのインストール
Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。
この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- Windows インストールプロセスを開始します。
- Advanced インストールを選択します。
-
ストレージの宛先は、ドライバーがロードされるまで認識されません。
Load driverをクリックします。 - ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
- 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
- Windows インストールを完了します。
10.12. 仮想マシンの QEMU ゲストエージェント情報の表示
QEMU ゲストエージェントが仮想マシンで実行されている場合は、Web コンソールを使用して、仮想マシン、ユーザー、ファイルシステム、およびセカンダリーネットワークに関する情報を表示できます。
10.12.1. 前提条件
- QEMU ゲストエージェントを仮想マシンにインストールしている。
10.12.2. Web コンソールでの QEMU ゲストエージェント情報について
QEMU ゲストエージェントがインストールされると、VirtualMachine details ページの Overview タブおよび Details タブに、ホスト名、オペレーティングシステム、タイムゾーン、およびログインユーザーに関する情報が表示されます。
VirtualMachine details ページには、仮想マシンにインストールされているゲストオペレーティングシステムに関する情報が表示されます。Details タブには、ログインユーザーの情報が含まれる表が表示されます。Disks タブには、ファイルシステムの情報が含まれる表が表示されます。
QEMU ゲストエージェントがインストールされていないと、Overview タブおよび Details タブには、仮想マシンの作成時に指定したオペレーティングシステムについての情報が表示されます。
10.12.3. Web コンソールでの QEMU ゲストエージェント情報の表示
Web コンソールを使用して、QEMU ゲストエージェントによってホストに渡される仮想マシンの情報を表示できます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシン名を選択して、VirtualMachine details ページを開きます。
- Details タブをクリックして、アクティブなユーザーを表示します。
- Disks タブをクリックして、ファイルシステムについての情報を表示します。
10.13. 仮想マシンでの config map、シークレット、およびサービスアカウントの管理
シークレット、config map、およびサービスアカウントを使用して設定データを仮想マシンに渡すことができます。たとえば、以下を実行できます。
- シークレットを仮想マシンに追加して認証情報を必要とするサービスに仮想マシンのアクセスを付与します。
- Pod または別のオブジェクトがデータを使用できるように、機密データではない設定データを config map に保存します。
- サービスアカウントをそのコンポーネントに関連付けることにより、コンポーネントが API サーバーにアクセスできるようにします。
OpenShift Virtualization はシークレット、設定マップ、およびサービスアカウントを仮想マシンディスクとして公開し、追加のオーバーヘッドなしにプラットフォーム全体でそれらを使用できるようにします。
10.13.1. シークレット、設定マップ、またはサービスアカウントの仮想マシンへの追加
OpenShift Container Platform Web コンソールを使用して、シークレット、設定マップ、またはサービスアカウントを仮想マシンに追加します。
これらのリソースは、ディスクとして仮想マシンに追加されます。他のディスクをマウントするように、シークレット、設定マップ、またはサービスアカウントをマウントします。
仮想マシンが実行中の場合、変更内容は仮想マシンが再起動されるまで反映されません。新規に追加されたリソースは、ページ上部の Pending Changes バナーの Environment および Disks タブの両方に保留中のリソースとしてマークされます。
前提条件
- 追加するシークレット、設定マップ、またはサービスアカウントは、ターゲット仮想マシンと同じ namespace に存在する必要がある。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Environment タブで、Add Config Map, Secret or Service Account をクリックします。
- Select a resource をクリックし、リストから resource を選択します。6 文字のシリアル番号が、選択したリソースについて自動的に生成されます。
- オプション: Reload をクリックして、環境を最後に保存した状態に戻します。
- Save をクリックします。
検証
- VirtualMachine details ページで、Disks タブをクリックし、シークレット、config map、またはサービスアカウントがディスクのリストに含まれていることを確認します。
- Actions → Restart をクリックして、仮想マシンを再起動します。
他のディスクをマウントするように、シークレット、設定マップ、またはサービスアカウントをマウントできるようになりました。
10.13.2. 仮想マシンからのシークレット、設定マップ、またはサービスアカウントの削除
OpenShift Container Platform Web コンソールを使用して、シークレット、設定マップ、またはサービスアカウントを仮想マシンから削除します。
前提条件
- 仮想マシンに割り当てられるシークレット、設定マップ、またはサービスアカウントが少なくとも 1 つ必要である。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Environment タブをクリックします。
-
リストで削除する項目を見つけ、項目の右上にある Remove
をクリックします。
- Save をクリックします。
Reload をクリックし、最後に保存された状態にフォームをリセットできます。
検証
- VirtualMachine details ページで、Disks タブをクリックします。
- 削除したシークレット、設定マップ、またはサービスアカウントがディスクの一覧に含まれていないことを確認します。
10.14. VirtIO ドライバーの既存の Windows 仮想マシンへのインストール
10.14.1. VirtIO ドライバーについて
VirtIO ドライバーは、Microsoft Windows 仮想マシンが OpenShift Virtualization で実行されるために必要な準仮想化デバイスドライバーです。サポートされるドライバーは、Red Hat Ecosystem Catalog の container-native-virtualization/virtio-win コンテナーディスクで利用できます。
container-native-virtualization/virtio-win コンテナーディスクは、ドライバーのインストールを有効にするために SATA CD ドライブとして仮想マシンに割り当てられる必要があります。仮想マシン上での Windows のインストール時に VirtIO ドライバーをインストールすることも、既存の Windows インストールに追加することもできます。
ドライバーのインストール後に、container-native-virtualization/virtio-win コンテナーディスクは仮想マシンから削除できます。
新しい Windows 仮想マシンに Virtio ドライバーをインストールする も参照してください。
10.14.2. Microsoft Windows 仮想マシンのサポートされる VirtIO ドライバー
| ドライバー名 | ハードウェア 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 が設定されている場合にのみ利用できます。 |
10.14.3. VirtIO ドライバーコンテナーディスクの仮想マシンへの追加
OpenShift Virtualization は、Red Hat Ecosystem Catalog で利用できる Microsoft Windows の VirtIO ドライバーをコンテナーディスクとして配布します。これらのドライバーを Windows 仮想マシンにインストールするには、仮想マシン設定ファイルで container-native-virtualization/virtio-win コンテナーディスクを SATA CD ドライブとして仮想マシンに割り当てます。
前提条件
-
container-native-virtualization/virtio-winコンテナーディスクを Red Hat Ecosystem Catalog からダウンロードすること。コンテナーディスクがクラスターにない場合は Red Hat レジストリーからダウンロードされるため、これは必須ではありません。
手順
container-native-virtualization/virtio-winコンテナーディスクをcdromディスクとして Windows 仮想マシン設定ファイルに追加します。コンテナーディスクは、クラスターにない場合はレジストリーからダウンロードされます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenShift Virtualization は、
VirtualMachine設定ファイルに定義される順序で仮想マシンディスクを起動します。container-native-virtualization/virtio-winコンテナーディスクの前に仮想マシンの他のディスクを定義するか、オプションのbootOrderパラメーターを使用して仮想マシンが正しいディスクから起動するようにできます。ディスクにbootOrderを指定する場合、これは設定のすべてのディスクに指定される必要があります。
ディスクは、仮想マシンが起動すると利用可能になります。
-
コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で
oc apply -f <vm.yaml>を使用するか、仮想マシンを再起動します。 -
仮想マシンが実行されていない場合、
virtctl start <vm>を使用します。
-
コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で
仮想マシンが起動したら、VirtIO ドライバーを割り当てられた SATA CD ドライブからインストールできます。
10.14.4. VirtIO ドライバーの既存 Windows 仮想マシンへのインストール
VirtIO ドライバーを、割り当てられた SATA CD ドライブから既存の Windows 仮想マシンにインストールします。
この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。このプロセスは Windows のバージョンごとに若干異なる可能性があります。特定のインストール手順については、お使いの Windows バージョンについてのインストールドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- 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 をクリックしてウィンドウを閉じます。
- 仮想マシンを再起動してドライバーのインストールを完了します。
10.14.5. 仮想マシンからの VirtIO コンテナーディスクの削除
必要なすべての VirtIO ドライバーを仮想マシンにインストールした後は、container-native-virtualization/virtio-win コンテナーディスクを仮想マシンに割り当てる必要はなくなります。container-native-virtualization/virtio-win コンテナーディスクを仮想マシン設定ファイルから削除します。
手順
設定ファイルを編集し、
diskおよびvolumeを削除します。oc edit vm <vm-name>
$ oc edit vm <vm-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を有効にするために仮想マシンを再起動します。
10.15. VirtIO ドライバーの新規 Windows 仮想マシンへのインストール
10.15.1. 前提条件
- 仮想マシンからアクセスできる Windows インストールメディア (ISO のデータボリュームへのインポート および仮想マシンへの割り当てを実行)。
10.15.2. VirtIO ドライバーについて
VirtIO ドライバーは、Microsoft Windows 仮想マシンが OpenShift Virtualization で実行されるために必要な準仮想化デバイスドライバーです。サポートされるドライバーは、Red Hat Ecosystem Catalog の container-native-virtualization/virtio-win コンテナーディスクで利用できます。
container-native-virtualization/virtio-win コンテナーディスクは、ドライバーのインストールを有効にするために SATA CD ドライブとして仮想マシンに割り当てられる必要があります。仮想マシン上での Windows のインストール時に VirtIO ドライバーをインストールすることも、既存の Windows インストールに追加することもできます。
ドライバーのインストール後に、container-native-virtualization/virtio-win コンテナーディスクは仮想マシンから削除できます。
VirtIO ドライバーの既存の Windows 仮想マシンへのインストール も参照してください。
10.15.3. Microsoft Windows 仮想マシンのサポートされる VirtIO ドライバー
| ドライバー名 | ハードウェア 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 が設定されている場合にのみ利用できます。 |
10.15.4. VirtIO ドライバーコンテナーディスクの仮想マシンへの追加
OpenShift Virtualization は、Red Hat Ecosystem Catalog で利用できる Microsoft Windows の VirtIO ドライバーをコンテナーディスクとして配布します。これらのドライバーを Windows 仮想マシンにインストールするには、仮想マシン設定ファイルで container-native-virtualization/virtio-win コンテナーディスクを SATA CD ドライブとして仮想マシンに割り当てます。
前提条件
-
container-native-virtualization/virtio-winコンテナーディスクを Red Hat Ecosystem Catalog からダウンロードすること。コンテナーディスクがクラスターにない場合は Red Hat レジストリーからダウンロードされるため、これは必須ではありません。
手順
container-native-virtualization/virtio-winコンテナーディスクをcdromディスクとして Windows 仮想マシン設定ファイルに追加します。コンテナーディスクは、クラスターにない場合はレジストリーからダウンロードされます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenShift Virtualization は、
VirtualMachine設定ファイルに定義される順序で仮想マシンディスクを起動します。container-native-virtualization/virtio-winコンテナーディスクの前に仮想マシンの他のディスクを定義するか、オプションのbootOrderパラメーターを使用して仮想マシンが正しいディスクから起動するようにできます。ディスクにbootOrderを指定する場合、これは設定のすべてのディスクに指定される必要があります。
ディスクは、仮想マシンが起動すると利用可能になります。
-
コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で
oc apply -f <vm.yaml>を使用するか、仮想マシンを再起動します。 -
仮想マシンが実行されていない場合、
virtctl start <vm>を使用します。
-
コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で
仮想マシンが起動したら、VirtIO ドライバーを割り当てられた SATA CD ドライブからインストールできます。
10.15.5. Windows インストール時の VirtIO ドライバーのインストール
Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。
この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- Windows インストールプロセスを開始します。
- Advanced インストールを選択します。
-
ストレージの宛先は、ドライバーがロードされるまで認識されません。
Load driverをクリックします。 - ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
- 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
- Windows インストールを完了します。
10.15.6. 仮想マシンからの VirtIO コンテナーディスクの削除
必要なすべての VirtIO ドライバーを仮想マシンにインストールした後は、container-native-virtualization/virtio-win コンテナーディスクを仮想マシンに割り当てる必要はなくなります。container-native-virtualization/virtio-win コンテナーディスクを仮想マシン設定ファイルから削除します。
手順
設定ファイルを編集し、
diskおよびvolumeを削除します。oc edit vm <vm-name>
$ oc edit vm <vm-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を有効にするために仮想マシンを再起動します。
10.16. 仮想 Trusted Platform Module デバイスの使用
VirtualMachine (VM) または VirtualMachineInstance (VMI) マニフェストを編集して、仮想 Trusted Platform Module (vTPM) デバイスを新規または既存の仮想マシンに追加します。
10.16.1. vTPM デバイスについて
仮想トラステッドプラットフォームモジュール (vTPM) デバイスは、物理トラステッドプラットフォームモジュール (TPM) ハードウェアチップのように機能します。
vTPM デバイスはどのオペレーティングシステムでも使用できますが、Windows 11 をインストールまたは起動するには TPM チップが必要です。vTPM デバイスを使用すると、Windows 11 イメージから作成された VM を物理 TPM チップなしで機能させることができます。
vTPM を有効にしないと、ノードに TPM デバイスがある場合でも、VM は TPM デバイスを認識しません。
また、vTPM デバイスは、物理ハードウェアなしでシークレットを一時的に保存することで、仮想マシンを保護します。ただし、永続的なシークレット ストレージに vTPM を使用することは現在サポートされていません。vTPM は、VM のシャットダウン後に保存されたシークレットを破棄します。
10.16.2. 仮想マシンへの vTPM デバイスの追加
仮想トラステッドプラットフォームモジュール (vTPM) デバイスを仮想マシン (VM) に追加すると、物理 TPM デバイスなしで Windows 11 イメージから作成された仮想マシンを実行できます。vTPM デバイスは、その仮想マシンのシークレットも一時的に保存します。
手順
次のコマンドを実行して、仮想マシン設定を更新します。
oc edit vm <vm_name>
$ oc edit vm <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow tpm: {}行が含まれるように仮想マシンspecを編集します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- TPM デバイスを仮想マシンに追加します。
- 変更を適用するには、エディターを保存し、終了します。
- オプション: 実行中の仮想マシンを編集している場合は、変更を有効にするためにこれを再起動する必要があります。
10.17. OpenShift Pipelines を使用した仮想マシンの管理
Red Hat OpenShift Pipelines は、開発者が独自のコンテナーで CI/CD パイプラインの各ステップを設計および実行できるようにする、Kubernetes ネイティブの CI/CD フレームワークです。
Tekton Tasks Operator (TTO) は、OpenShift Virtualization と OpenShift Pipelines を統合します。TTO には、次のことを可能にするクラスタータスクとサンプルパイプラインが含まれています。
- 仮想マシン (VM)、永続ボリューム要求 (PVC)、およびデータボリュームの作成と管理
- 仮想マシンでコマンドを実行する
-
libguestfsツールを使用してディスクイメージを操作する
Red Hat OpenShift Pipelines を使用した仮想マシンの管理は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
10.17.1. 前提条件
-
cluster-admin権限を使用して OpenShift Container Platform クラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。 - OpenShift Pipelines CLI がインストールされている。
10.17.2. Tekton Tasks Operator リソースのデプロイ
Tekton Tasks Operator (TTO) クラスタータスクとサンプルパイプラインは、OpenShift Virtualization のインストール時にデフォルトではデプロイされません。TTO リソースをデプロイするには、HyperConverged カスタムリソース (CR) で deployTektonTaskResources フィーチャーゲートを有効にします。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hco -n openshift-cnv kubevirt-hyperconverged
$ oc edit hco -n openshift-cnv kubevirt-hyperconvergedCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.featureGates.deployTektonTaskResourcesフィールドをtrueに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記後でフィーチャーゲートを無効にしても、クラスタータスクとサンプルパイプラインは引き続き使用できます。
- 変更を保存し、エディターを終了します。
10.17.3. Tekton Tasks Operator によってサポートされる仮想マシンタスク
次の表は、Tekton Tasks Operator の一部として含まれているクラスタータスクを示しています。
| タスク | Description |
|---|---|
|
| テンプレートからの仮想マシンの作成 |
|
| 仮想マシンテンプレートをコピーします。 |
|
| 仮想マシンテンプレートを変更します。 |
|
| データボリュームまたはデータソースを作成または削除します。 |
|
| 仮想マシンでスクリプトまたはコマンドを実行し、後で仮想マシンを停止または削除します。 |
|
|
|
|
|
|
|
| 仮想マシンインスタンスの特定のステータスを待機し、ステータスに基づいて失敗または成功します。 |
10.17.4. パイプラインの例
Tekton Tasks Operator には、次の Pipeline マニフェストの例が含まれています。サンプルパイプラインは、Web コンソールまたは CLI を使用して実行できます。
- Windows 10 インストーラーパイプライン
- このパイプラインは、Windows インストールイメージ (ISO ファイル) から Windows 10 を新しいデータボリュームにインストールします。インストールプロセスの実行には、カスタムアンサーファイルが使用されます。
- Windows 10 カスタマイズパイプライン
- このパイプラインは、基本的な Windows 10 インストールのデータボリュームを複製し、Microsoft SQL Server Express をインストールしてカスタマイズし、新しいイメージとテンプレートを作成します。
10.17.4.1. Web コンソールを使用してサンプルパイプラインを実行する
サンプルパイプラインは、Web コンソールの Pipelines メニューから実行できます。
手順
- サイドメニューの Pipelines → Pipelines をクリックします。
- パイプラインを選択して、Pipeline details ページを開きます。
- Actions リストから、Start を選択します。Start Pipeline ダイアログが表示されます。
- パラメーターのデフォルト値を保持し、Start をクリックしてパイプラインを実行します。Details タブでは、各タスクの進行状況が追跡され、パイプラインのステータスが表示されます。
10.17.4.2. CLI を使用してサンプルパイプラインを実行する
PipelineRun リソースを使用して、サンプルパイプラインを実行します。PipelineRun オブジェクトは、パイプラインの実行中のインスタンスです。これは、クラスター上の特定の入力、出力、および実行パラメーターで実行されるパイプラインをインスタンス化します。また、パイプライン内のタスクごとに TaskRun オブジェクトを作成します。
手順
Windows 10 インストーラーパイプラインを実行するには、次の
PipelineRunマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Windows 10 64 ビット ISO ファイルの URL を指定します。製品の言語は英語 (米国) でなければなりません。
PipelineRunマニフェストを適用します。oc apply -f windows10-installer-run.yaml
$ oc apply -f windows10-installer-run.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows 10 カスタマイズパイプラインを実行するには、次の
PipelineRunマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow PipelineRunマニフェストを適用します。oc apply -f windows10-customize-run.yaml
$ oc apply -f windows10-customize-run.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.18. 高度な仮想マシン管理
10.18.1. 仮想マシンのリソースクォータの使用
仮想マシンのリソースクォータの作成および管理
10.18.1.1. 仮想マシンのリソースクォータ制限の設定
リクエストのみを使用するリソースクォータは、仮想マシン (VM) で自動的に機能します。リソースクォータで制限を使用する場合は、VM に手動でリソース制限を設定する必要があります。リソース制限は、リソース要求より少なくとも 100 MiB 大きくする必要があります。
手順
VirtualMachineマニフェストを編集して、VM の制限を設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この設定がサポートされるのは、
limits.memory値がrequests.memory値より少なくとも100Mi大きいためです。
-
VirtualMachineマニフェストを保存します。
10.18.2. 仮想マシンのノードの指定
ノードの配置ルールを使用して、仮想マシン (VM) を特定のノードに配置することができます。
10.18.2.1. 仮想マシンのノード配置について
仮想マシン (VM) が適切なノードで実行されるようにするには、ノードの配置ルールを設定できます。以下の場合にこれを行うことができます。
- 仮想マシンが複数ある。フォールトトレランスを確保するために、これらを異なるノードで実行する必要がある。
- 2 つの相互間のネットワークトラフィックの多い chatty VM がある。冗長なノード間のルーティングを回避するには、仮想マシンを同じノードで実行します。
- 仮想マシンには、利用可能なすべてのノードにない特定のハードウェア機能が必要です。
- 機能をノードに追加する Pod があり、それらの機能を使用できるように仮想マシンをそのノードに配置する必要があります。
仮想マシンの配置は、ワークロードの既存のノードの配置ルールに基づきます。ワークロードがコンポーネントレベルの特定のノードから除外される場合、仮想マシンはそれらのノードに配置できません。
以下のルールタイプは、VirtualMachine マニフェストの spec フィールドで使用できます。
nodeSelector- 仮想マシンは、キーと値のペアまたはこのフィールドで指定したペアを使用してラベルが付けられたノードに Pod をスケジュールできます。ノードには、リスト表示されたすべてのペアに一致するラベルがなければなりません。
affinityより表現的な構文を使用して、ノードと仮想マシンに一致するルールを設定できます。たとえば、ルールがハード要件ではなく基本設定になるように指定し、ルールの条件が満たされない場合も仮想マシンがスケジュールされるようにすることができます。Pod のアフィニティー、Pod の非アフィニティー、およびノードのアフィニティーは仮想マシンの配置でサポートされます。Pod のアフィニティーは仮想マシンに対して動作します。
VirtualMachineワークロードタイプはPodオブジェクトに基づくためです。注記アフィニティールールは、スケジューリング時にのみ適用されます。OpenShift Container Platform は、制約を満たさなくなった場合に実行中のワークロードを再スケジューリングしません。
tolerations- 一致するテイントを持つノードで仮想マシンをスケジュールできます。テイントがノードに適用される場合、そのノードはテイントを容認する仮想マシンのみを受け入れます。
10.18.2.2. ノード配置の例
以下の YAML スニペットの例では、nodePlacement、affinity、および tolerations フィールドを使用して仮想マシンのノード配置をカスタマイズします。
10.18.2.2.1. 例: nodeSelector を使用した仮想マシンノードの配置
この例では、仮想マシンに example-key-1 = example-value-1 および example-key-2 = example-value-2 ラベルの両方が含まれるメタデータのあるノードが必要です。
この説明に該当するノードがない場合、仮想マシンはスケジュールされません。
仮想マシンマニフェストの例
10.18.2.2.2. 例: Pod のアフィニティーおよび Pod の非アフィニティーによる仮想マシンノードの配置
この例では、仮想マシンはラベル example-key-1 = example-value-1 を持つ実行中の Pod のあるノードでスケジュールされる必要があります。このようなノードで実行中の Pod がない場合、仮想マシンはスケジュールされません。
可能な場合に限り、仮想マシンはラベル example-key-2 = example-value-2 を持つ Pod のあるノードではスケジュールされません。ただし、すべての候補となるノードにこのラベルを持つ Pod がある場合、スケジューラーはこの制約を無視します。
仮想マシンマニフェストの例
10.18.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 を持つノードを回避します。ただし、すべての候補となるノードにこのラベルがある場合、スケジューラーはこの制約を無視します。
仮想マシンマニフェストの例
10.18.2.2.4. 例: 容認 (toleration) を使用した仮想マシンノードの配置
この例では、仮想マシン用に予約されるノードには、すでに key=virtualization:NoSchedule テイントのラベルが付けられています。この仮想マシンには一致する tolerations があるため、これをテイントが付けられたノードにスケジュールできます。
テイントを容認する仮想マシンは、そのテイントを持つノードにスケジュールする必要はありません。
仮想マシンマニフェストの例
10.18.3. 証明書ローテーションの設定
証明書ローテーションパラメーターを設定して、既存の証明書を置き換えます。
10.18.3.1. 証明書ローテーションの設定
これは、Web コンソールでの OpenShift Virtualization のインストール時に、または HyperConverged カスタムリソース (CR) でインストール後に実行することができます。
手順
以下のコマンドを実行して
HyperConvergedCR を開きます。oc edit hco -n openshift-cnv kubevirt-hyperconverged
$ oc edit hco -n openshift-cnv kubevirt-hyperconvergedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように
spec.certConfigフィールドを編集します。システムのオーバーロードを避けるには、すべての値が 10 分以上であることを確認します。golangParseDuration形式 に準拠する文字列として、すべての値を表現します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - YAML ファイルをクラスターに適用します。
10.18.3.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 の値を確認します。
10.18.4. 仮想マシンに UEFI モードを使用する
Unified Extensible Firmware Interface (UEFI) モードで仮想マシン (VM) を起動できます。
10.18.4.1. 仮想マシンの UEFI モードについて
レガシー BIOS などの Unified Extensible Firmware Interface (UEFI) は、コンピューターの起動時にハードウェアコンポーネントやオペレーティングシステムのイメージファイルを初期化します。UEFI は BIOS よりも最新の機能とカスタマイズオプションをサポートするため、起動時間を短縮できます。
これは、.efi 拡張子を持つファイルに初期化と起動に関する情報をすべて保存します。このファイルは、EFI System Partition (ESP) と呼ばれる特別なパーティションに保管されます。ESP には、コンピューターにインストールされるオペレーティングシステムのブートローダープログラムも含まれます。
10.18.4.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
10.18.5. 仮想マシンの PXE ブートの設定
PXE ブートまたはネットワークブートは OpenShift Virtualization で利用できます。ネットワークブートにより、ローカルに割り当てられたストレージデバイスなしにコンピューターを起動し、オペレーティングシステムまたは他のプログラムを起動し、ロードすることができます。たとえば、これにより、新規ホストのデプロイ時に PXE サーバーから必要な OS イメージを選択できます。
10.18.5.1. 前提条件
- Linux ブリッジが接続されている。
- PXE サーバーがブリッジとして同じ VLAN に接続されている。
10.18.5.2. MAC アドレスを指定した PXE ブート
まず、管理者は PXE ネットワークの NetworkAttachmentDefinition オブジェクトを作成し、ネットワーク経由でクライアントを起動できます。次に、仮想マシンインスタンスの設定ファイルでネットワーク接続定義を参照して仮想マシンインスタンスを起動します。また PXE サーバーで必要な場合には、仮想マシンインスタンスの設定ファイルで MAC アドレスを指定することもできます。
前提条件
- Linux ブリッジが接続されている。
- PXE サーバーがブリッジとして同じ VLAN に接続されている。
手順
クラスターに PXE ネットワークを設定します。
直前の手順で作成したファイルを使用してネットワーク接続定義を作成します。
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 直前に作成されたネットワーク接続定義に接続されるネットワークを指定します。このシナリオでは、
<pxe-net>は<pxe-net-conf>というネットワーク接続定義に接続されます。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" created仮想マシンインスタンスの実行を待機します。
oc get vmi vmi-pxe-boot -o yaml | grep -i phase
$ 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:ff10.18.5.3. OpenShift Virtualization ネットワークの用語集
OpenShift Virtualization は、カスタムリソースおよびプラグインを使用して高度なネットワーク機能を提供します。
以下の用語は、OpenShift Virtualization ドキュメント全体で使用されています。
- Container Network Interface (CNI)
- コンテナーのネットワーク接続に重点を置く Cloud Native Computing Foundation プロジェクト。OpenShift Virtualization は CNI プラグインを使用して基本的な Kubernetes ネットワーク機能を強化します。
- Multus
- 複数の CNI の存在を可能にし、Pod または仮想マシンが必要なインターフェイスを使用できるようにするメタ CNI プラグイン。
- カスタムリソース定義 (CRD、Custom Resource Definition)
- カスタムリソースの定義を可能にする Kubernetes API リソース、または CRD API リソースを使用して定義されるオブジェクト。
- ネットワーク接続定義 (NAD)
- Pod、仮想マシン、および仮想マシンインスタンスを 1 つ以上のネットワークに割り当てることを可能にする Multus プロジェクトによって導入される CRD。
- ノードネットワーク設定ポリシー (NNCP)
-
ノードで要求されるネットワーク設定の説明。
NodeNetworkConfigurationPolicyマニフェストをクラスターに適用して、インターフェイスの追加および削除など、ノードネットワーク設定を更新します。 - PXE (Preboot eXecution Environment)
- 管理者がネットワーク経由でサーバーからクライアントマシンを起動できるようにするインターフェイス。ネットワークのブートにより、オペレーティングシステムおよび他のソフトウェアをクライアントにリモートでロードできます。
10.18.6. 仮想マシンでの Huge Page の使用
Huge Page は、クラスター内の仮想マシンのバッキングメモリーとして使用できます。
10.18.6.1. 前提条件
10.18.6.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 を使用できるように仮想マシンを設定できます。
10.18.6.3. 仮想マシンの Huge Page の設定
memory.hugepages.pageSize および resources.requests.memory パラメーターを仮想マシン設定に組み込み、仮想マシンを事前に割り当てられた Huge Page を使用するように設定できます。
メモリー要求はページサイズ別に分ける必要があります。たとえば、ページサイズ 1Gi の場合に 500Mi メモリーを要求することはできません。
ホストおよびゲスト OS のメモリーレイアウトには関連性がありません。仮想マシンマニフェストで要求される Huge Page が QEMU に適用されます。ゲスト内の 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
10.18.7. 仮想マシン用の専用リソースの有効化
パフォーマンスを向上させるために、CPU などのノードリソースを仮想マシン専用に確保できます。
10.18.7.1. 専用リソースについて
仮想マシンの専用リソースを有効にする場合、仮想マシンのワークロードは他のプロセスで使用されない CPU でスケジュールされます。専用リソースを使用することで、仮想マシンのパフォーマンスとレイテンシーの予測の精度を向上させることができます。
10.18.7.2. 前提条件
-
CPU マネージャー がノードに設定されている。仮想マシンのワークロードをスケジュールする前に、ノードに
cpumanager = trueラベルが設定されていることを確認する。 - 仮想マシンの電源がオフになっている。
10.18.7.3. 仮想マシンの専用リソースの有効化
Details タブで、仮想マシンの専用リソースを有効にすることができます。Red Hat テンプレートから作成された仮想マシンは、専用のリソースで設定できます。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Scheduling タブで、Dedicated Resources の横にある鉛筆アイコンをクリックします。
- Schedule this workload with dedicated resources (guaranteed policy) を選択します。
- Save をクリックします。
10.18.8. 仮想マシンのスケジュール
仮想マシンの CPU モデルとポリシー属性が、ノードがサポートする CPU モデルおよびポリシー属性との互換性について一致することを確認して、ノードで仮想マシン (VM) をスケジュールできます。
10.18.8.1. ポリシー属性
仮想マシン (VM) をスケジュールするには、ポリシー属性と、仮想マシンがノードでスケジュールされる際の互換性について一致する CPU 機能を指定します。仮想マシンに指定されるポリシー属性は、その仮想マシンをノードにスケジュールする方法を決定します。
| ポリシー属性 | 説明 |
|---|---|
| force | 仮想マシンは強制的にノードでスケジュールされます。これは、ホストの CPU が仮想マシンの CPU に対応していない場合でも該当します。 |
| require | 仮想マシンが特定の CPU モデルおよび機能仕様で設定されていない場合に仮想マシンに適用されるデフォルトのポリシー。このデフォルトポリシー属性または他のポリシー属性のいずれかを持つ CPU ノードの検出をサポートするようにノードが設定されていない場合、仮想マシンはそのノードでスケジュールされません。ホストの CPU が仮想マシンの CPU をサポートしているか、ハイパーバイザーが対応している CPU モデルをエミュレートできる必要があります。 |
| optional | 仮想マシンがホストの物理マシンの CPU でサポートされている場合は、仮想マシンがノードに追加されます。 |
| disable | 仮想マシンは CPU ノードの検出機能と共にスケジュールすることはできません。 |
| forbid | この機能がホストの CPU でサポートされ、CPU ノード検出が有効になっている場合でも、仮想マシンはスケジュールされません。 |
10.18.8.2. ポリシー属性および CPU 機能の設定
それぞれの仮想マシン (VM) にポリシー属性および CPU 機能を設定して、これがポリシーおよび機能に従ってノードでスケジュールされるようにすることができます。設定する CPU 機能は、ホストの CPU によってサポートされ、またはハイパーバイザーがエミュレートされることを確認するために検証されます。
10.18.8.3. サポートされている CPU モデルでの仮想マシンのスケジューリング
仮想マシン (VM) の CPU モデルを設定して、CPU モデルがサポートされるノードにこれをスケジュールできます。
手順
仮想マシン設定ファイルの
domain仕様を編集します。以下の例は、VM 向けに定義された特定の CPU モデルを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- VM の CPU モデル。
10.18.8.4. ホストモデルでの仮想マシンのスケジューリング
仮想マシン (VM) の CPU モデルが host-model に設定されている場合、仮想マシンはスケジュールされているノードの CPU モデルを継承します。
手順
仮想マシン設定ファイルの
domain仕様を編集します。以下の例は、仮想マシンに指定されるhost-modelを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- スケジュールされるノードの CPU モデルを継承する仮想マシン。
10.18.9. PCI パススルーの設定
PCI (Peripheral Component Interconnect) パススルー機能を使用すると、仮想マシンからハードウェアデバイスにアクセスし、管理できます。PCI パススルーが設定されると、PCI デバイスはゲストオペレーティングシステムに物理的に接続されているかのように機能します。
クラスター管理者は、oc コマンドラインインターフェイス (CLI) を使用して、クラスターでの使用が許可されているホストデバイスを公開および管理できます。
10.18.9.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 デバイス情報を削除します。
10.18.9.1.1. IOMMU ドライバーを有効にするためのカーネル引数の追加
カーネルの IOMMU (Input-Output Memory Management Unit) ドライバーを有効にするには、MachineConfig オブジェクトを作成し、カーネル引数を追加します。
前提条件
- 作業用の OpenShift Container Platform クラスターに対する管理者権限が必要です。
- Intel または AMD CPU ハードウェア。
- Intel Virtualization Technology for Directed I/O 拡張または BIOS (Basic Input/Output System) の AMD IOMMU が有効にされている。
手順
カーネル引数を識別する
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
10.18.9.1.2. 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 の詳細は、「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
10.18.9.1.3. 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
10.18.9.1.4. 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
10.18.9.2. PCI パススルー用の仮想マシンの設定
PCI デバイスがクラスターに追加された後に、それらを仮想マシンに割り当てることができます。PCI デバイスが仮想マシンに物理的に接続されているかのような状態で利用できるようになりました。
10.18.9.2.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
10.18.10. 仮想 GPU パススルーの設定
仮想マシンは仮想 GPU (vGPU) ハードウェアにアクセスできます。仮想マシンに仮想 GPU を割り当てると、次のことが可能になります。
- 基盤となるハードウェアの GPU の一部にアクセスして、仮想マシンで高いパフォーマンスのメリットを実現する。
- リソースを大量に消費する I/O 操作を合理化する。
仮想 GPU パススルーは、ベアメタル環境で実行されているクラスターに接続されているデバイスにのみ割り当てることができます。
10.18.10.1. 仮想マシンへの vGPU パススルーデバイスの割り当て
Open Shift Container Platform Web コンソールを使用して、vGPU パススルーデバイスを仮想マシンに割り当てます。
前提条件
- 仮想マシンを停止する必要があります。
手順
- Open Shift Container Platform Web コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- デバイスを割り当てる仮想マシンを選択します。
Details タブで、GPU devices をクリックします。
vGPU デバイスをホストデバイスとして追加すると、VNC コンソールでデバイスにアクセスすることはできません。
- Add GPU device をクリックし、Name を入力して、Device name リストからデバイスを選択します。
- Save をクリックします。
-
YAMLタブをクリックして、クラスター設定の
hostDevicesセクションに新しいデバイスが追加されていることを確認します。
カスタマイズされたテンプレートまたは YAML ファイルから作成された仮想マシンに、ハードウェアデバイスを追加できます。Windows 10 や RHEL 7 などの特定のオペレーティングシステム用に事前に提供されているブートソーステンプレートにデバイスを追加することはできません。
クラスターに接続されているリソースを表示するには、サイドメニューから Compute → Hardware Devices をクリックします。
10.18.11. 仲介デバイスの設定
HyperConvergedカスタムリソース (CR) でデバイスのリストを提供すると、Open Shift Virtualization は仮想 GPU (vGPU) などの仲介デバイスを自動的に作成します。
仲介デバイスの宣言型設定は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
10.18.11.1. NVIDIA GPU Operator の使用について
NVIDIA GPU Operator は、OpenShift Container Platform クラスターで NVIDIA GPU リソースを管理し、GPU ノードのブートストラップに関連するタスクを自動化します。GPU はクラスター内の特別なリソースであるため、アプリケーションワークロードを GPU にデプロイする前に、いくつかのコンポーネントをインストールする必要があります。これらのコンポーネントには、コンピューティングユニファイドデバイスアーキテクチャー (CUDA)、Kubernetes デバイスプラグイン、コンテナーランタイム、および自動ノードラベル付け、監視などを可能にする NVIDIA ドライバーが含まれます。
NVIDIA GPU Operator は、NVIDIA によってのみサポートされています。NVIDIA からサポートを受ける方法は、Obtaining Support from NVIDIA を参照してください。
OpenShift Container Platform OpenShift Virtualization で GPU を有効にする方法は、OpenShift Container Platform ネイティブの方法と、NVIDIA GPU Operator を使用する方法の 2 つあります。ここでは、OpenShift Container Platform ネイティブの方法を説明します。
NVIDIA GPU Operator は、OpenShift Container Platform OpenShift Virtualization が GPU を OpenShift Container Platform で実行されている仮想化されたワークロードに公開できるようにする Kubernetes Operator です。これにより、ユーザーは GPU 対応の仮想マシンを簡単にプロビジョニングおよび管理できるようになり、他のワークロードと同じプラットフォームで複雑な人工知能/機械学習 (AI/ML) ワークロードを実行できるようになります。また、インフラストラクチャーの GPU 容量を簡単にスケーリングできるようになり、GPU ベースのワークロードが急激に増加しても対応できます。
NVIDIA GPU Operator を使用して、GPU で高速化された VM を実行するためのワーカーノードをプロビジョニングする方法の詳細は、NVIDIA GPU Operator with OpenShift Virtualization を参照してください。
10.18.11.2. OpenShift Virtualization での仮想 GPU の使用について
一部のグラフィックス処理ユニット (GPU) カードは、仮想 GPU (vGPU) の作成をサポートしています。管理者が HyperConverged カスタムリソース (CR) で設定の詳細を提供すると、OpenShift Virtualization は仮想 GPU およびその他の仲介デバイスを自動的に作成できます。この自動化は、大規模なクラスターで特に役立ちます。
機能とサポートの詳細は、ハードウェアベンダーのドキュメントを参照してください。
- 仲介デバイス
- 1 つまたは複数の仮想デバイスに分割された物理デバイス。仮想 GPU は、仲介デバイス (mdev) の一種です。物理 GPU のパフォーマンスが、仮想デバイス間で分割されます。仲介デバイスを 1 つまたは複数の仮想マシン (VM) に割り当てることができますが、ゲストの数は GPU と互換性がある必要があります。一部の GPU は複数のゲストをサポートしていません。
10.18.11.2.1. 前提条件
ハードウェアベンダーがドライバーを提供している場合は、仲介デバイスを作成するノードにドライバーをインストールしている。
- NVIDIA カードを使用する場合は、NVIDIAGRID ドライバーをインストールしている。
10.18.11.2.2. 設定の概要
仲介デバイスを設定する場合、管理者は次のタスクを完了する必要があります。
- 仲介デバイスを作成する。
- 仲介デバイスをクラスターに公開する。
HyperConverged CR には、両方のタスクを実行する API が含まれています。
仲介デバイスの作成
仲介デバイスのクラスターへの公開
- 1
- この値にマッピングする仲介デバイスをホスト上に公開します。注記
実際のシステムの正しい値に置き換えて、
/sys/bus/pci/devices/<slot>:<bus>:<domain>.<function>/mdev_supported_types/<type>/nameの内容を表示し、デバイスがサポートする仲介デバイスのタイプを確認できます。たとえば、
nvidia-231タイプの name ファイルには、セレクター文字列GRID T4-2Qが含まれます。GRID T4-2QをmdevNameSelector値として使用することで、ノードはnvidia-231タイプを使用できます。 - 2
resourceNameは、ノードに割り当てられたものと一致する必要があります。次のコマンドを使用して、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
10.18.11.2.3. 仮想 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 は、
mediatedDevicesTypes一覧の最初のサポートされるタイプを使用します。たとえば、ノードカードのカードは
nvidia-223とnvidia-224をサポートします。以下のmediatedDevicesTypes一覧が設定されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、OpenShift Virtualization は
nvidia-223タイプを使用します。
10.18.11.2.4. 仲介デバイスの変更および削除について
クラスターの仲介デバイス設定は、次の方法を使用して OpenShift Virtualization で更新できます。
-
HyperConvergedCR を編集し、mediadDevicesTypesスタンザの内容を変更します。 -
nodeMediatedDeviceTypesノードセレクターに一致するノードラベルを変更します。 HyperConvergedCR のspec.mediaDevicesConfigurationおよびspec.permittedHostDevicesスタンザからデバイス情報を削除します。注記spec.permittedHostDevicesスタンザからデバイス情報を削除したが、spec.mediatedDevicesConfigurationスタンザからは削除しなかった場合、同じノードで新規の仲介デバイスタイプを作成することはできません。仲介デバイスを適切に削除するには、両方のスタンザからデバイス情報を削除します。
具体的な変更に応じて、これらのアクションにより、OpenShift Virtualization は仲介デバイスを再設定するか、クラスターノードからそれらを削除します。
10.18.11.2.5. 仲介デバイス用のホストの準備
仲介デバイスを設定する前に、入出力メモリー管理ユニット (IOMMU) ドライバーを有効にする必要があります。
10.18.11.2.5.1. IOMMU ドライバーを有効にするためのカーネル引数の追加
カーネルの IOMMU (Input-Output Memory Management Unit) ドライバーを有効にするには、MachineConfig オブジェクトを作成し、カーネル引数を追加します。
前提条件
- 作業用の OpenShift Container Platform クラスターに対する管理者権限が必要です。
- Intel または AMD CPU ハードウェア。
- Intel Virtualization Technology for Directed I/O 拡張または BIOS (Basic Input/Output System) の AMD IOMMU が有効にされている。
手順
カーネル引数を識別する
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
10.18.11.2.6. 仲介デバイスの追加および削除
仲介デバイスを追加または削除できます。
10.18.11.2.6.1. 仲介デバイスの作成および公開
HyperConverged カスタムリソース (CR) を編集して、仮想 GPU (vGPU) などの仲介デバイスを公開し、作成できます。
前提条件
- IOMMU (Input-Output Memory Management Unit) ドライバーを有効にしている。
手順
以下のコマンドを実行して、デフォルトエディターで
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およびpermittedHostDevicesスタンザが含まれるようにします。以下に例を示します。設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <.> 仲介デバイスを作成します。<.> 必須: グローバル
MediedDevicesTypes設定。<.> 任意: 特定のノードのグローバル設定をオーバーライドします。<.>nodeMediatedDeviceTypesを使用する場合は必須。<.> 仲介デバイスをクラスターに公開します。- 変更を保存し、エディターを終了します。
検証
以下のコマンドを実行して、デバイスが特定のノードに追加されたことを確認できます。
oc describe node <node_name>
$ oc describe node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.18.11.2.6.2. CLI を使用したクラスターからの仲介デバイスの削除
クラスターから仲介デバイスを削除するには、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 - 変更を保存し、エディターを終了します。
10.18.11.3. 仲介デバイスの使用
vGPU は仲介デバイスの一種です。物理 GPU のパフォーマンスは仮想デバイス間で分割されます。仲介デバイスを 1 つ以上の仮想マシンに割り当てることができます。
10.18.11.3.1. 仮想マシンへの仲介デバイスの割り当て
仮想 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
10.18.12. ウォッチドッグの設定
ウォッチドッグデバイスに仮想マシン (VM) を設定し、ウォッチドッグをインストールして、ウォッチドッグサービスを開始することで、ウォッチドッグを公開します。
10.18.12.1. 前提条件
-
仮想マシンで
i6300esbウォッチドッグデバイスのカーネルサポートが含まれている。Red Hat Enterprise Linux(RHEL) イメージが、i6300esbをサポートしている。
10.18.12.2. ウォッチドッグデバイスの定義
オペレーティングシステム (OS) が応答しなくなるときにウォッチドッグがどのように進行するかを定義します。
表10.4 利用可能なアクション
|
|
仮想マシン (VM) の電源がすぐにオフになります。 |
|
| VM はその場で再起動し、ゲスト OS は反応できません。ゲスト OS の再起動に必要な時間の長さにより liveness プローブのタイムアウトが生じる可能性があるため、このオプションの使用は推奨されません。このタイムアウトにより、クラスターレベルの保護が liveness プローブの失敗に気づき、強制的に再スケジュールした場合に、VM の再起動にかかる時間が長くなる可能性があります。 |
|
| VM は、すべてのサービスを停止することにより、正常に電源を切ります。 |
手順
以下の内容を含む YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
watchdogアクション (poweroff、reset、またはshutdown) を指定します。
上記の例では、電源オフアクションを使用して、RHEL8 VM で
i6300esbウォッチドッグデバイスを設定し、デバイスを/dev/watchdogとして公開します。このデバイスは、ウォッチドッグバイナリーで使用できるようになりました。
以下のコマンドを実行して、YAML ファイルをクラスターに適用します。
$ oc apply -f <file_name>.yaml
$ oc apply -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
この手順は、ウォッチドッグ機能をテストするためにのみ提供されており、実稼働マシンでは実行しないでください。
以下のコマンドを実行して、VM がウォッチドッグデバイスに接続されていることを確認します。
lspci | grep watchdog -i
$ lspci | grep watchdog -iCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドのいずれかを実行して、ウォッチドッグがアクティブであることを確認します。
カーネルパニックをトリガーします。
echo c > /proc/sysrq-trigger
# echo c > /proc/sysrq-triggerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ウォッチドッグサービスを終了します。
pkill -9 watchdog
# pkill -9 watchdogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.18.12.3. ウォッチドッグデバイスのインストール
仮想マシンに watchdog パッケージをインストールして、ウォッチドッグサービスを起動します。
手順
root ユーザーとして、
watchdogパッケージおよび依存関係をインストールします。yum install watchdog
# yum install watchdogCopy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/watchdog.confファイルの以下の行のコメントを解除して、変更を保存します。#watchdog-device = /dev/watchdog
#watchdog-device = /dev/watchdogCopy to Clipboard Copied! Toggle word wrap Toggle overflow ウォッチドッグサービスが起動時に開始できるように有効化します。
systemctl enable --now watchdog.service
# systemctl enable --now watchdog.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.18.13. 事前定義済みのブートソースの自動インポートおよび更新
システム定義 で OpenShift Virtualization に含まれるブートソース、または作成した ユーザー定義 のブートソースを使用できます。システム定義のブートソースのインポートおよび更新は、製品の機能ゲートによって制御されます。機能ゲートを使用して、更新を有効、無効、または再度有効にすることができます。ユーザー定義のブートソースは、製品機能ゲートによって制御されないため、自動インポートおよび更新をオプトインまたはオプトアウトするには、個別に管理する必要があります。
バージョン 4.10 以降、OpenShift Virtualization は、手動でオプトアウトするか、デフォルトのストレージクラスを設定しない限り、ブートソースを自動的にインポートして更新します。
バージョン 4.10 にアップグレードする場合は、バージョン 4.9 以前からのブートソースの自動インポートおよび更新を手動で有効にする必要があります。
10.18.13.1. ブートソースの自動更新の有効化
OpenShift Virtualization 4.9 以前からのブートソースがある場合は、これらのブートソースの自動更新を手動で有効にする必要があります。OpenShift Virtualization 4.10 以降のすべてのブートソースは、デフォルトで自動的に更新されます。
自動ブートソースのインポートおよび更新を有効にするには、自動更新する各ブートソースの cdi.kubevirt.io/dataImportCron フィールドを true に設定します。
手順
ブートソースの自動更新を有効にするには、次のコマンドを使用して
dataImportCronラベルをデータソースに適用します。oc label --overwrite DataSource rhel8 -n openshift-virtualization-os-images cdi.kubevirt.io/dataImportCron=true
$ oc label --overwrite DataSource rhel8 -n openshift-virtualization-os-images cdi.kubevirt.io/dataImportCron=true1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
trueを指定すると、rhel8ブートソースの自動更新がオンになります。
10.18.13.2. ブートソースの自動更新の無効化
ブートソースの自動インポートおよび更新を無効にすると、切断された環境でログの数を減らしたり、リソースの使用率を減らしたりするのに役立ちます。
ブートソースの自動インポートおよび更新を無効にするには、HyperConverged カスタムリソース (CR) の spec.featureGates.enableCommonBootImageImport フィールドを false に設定します。
ユーザー定義のブートソースは、この設定の影響を受けません。
手順
次のコマンドを使用して、ブートソースの自動更新を無効にします。
oc patch hco kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", \ "value": false}]'$ oc patch hco kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", \ "value": false}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.18.13.3. ブートソースの自動更新の再有効化
以前にブートソースの自動更新を無効にしている場合は、この機能を手動で再度有効にする必要があります。HyperConverged カスタムリソース (CR) の spec.featureGates.enableCommonBootImageImport フィールドを true に設定します。
手順
以下のコマンドを使用して自動更新を再度有効にします。
oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", "value": true}]'$ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.18.13.4. ユーザー定義のブートソース更新用のストレージクラスの設定
ユーザー定義のブートソースの自動インポートおよび更新を可能にするストレージクラスを設定できます。
手順
HyperConvergedカスタムリソース (CR) を編集して、新しいstorageClassNameを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、新しいデフォルトのストレージクラスを設定します。
oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'$ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch storageclass <appropriate_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'$ oc patch storageclass <appropriate_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.18.13.5. ユーザー定義の起動ソースの自動更新を有効にする
OpenShift Virtualization は、デフォルトでシステム定義のブートソースを自動的に更新しますが、ユーザー定義のブートソースは自動的に更新しません。HyperConverged カスタムリソース (CR) を編集して、ユーザー定義のブートソースで自動インポートおよび更新を手動で有効にする必要があります。
手順
以下のコマンドを使用して、編集するために
HyperConvergedCR を開きます。oc edit -n openshift-cnv HyperConverged
$ oc edit -n openshift-cnv HyperConvergedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 適切なテンプレートおよびブートソースを
dataImportCronTemplatesセクションで追加して、HyperConvergedCR を編集します。以下に例を示します。CentOS 7 の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このアノテーションは、
volumeBindingModeがWaitForFirstConsumerに設定されたストレージクラスに必要です。 - 2
- cron 形式で指定されるジョブのスケジュール。
- 3
- レジストリーソースからデータボリュームを作成するのに使用します。
nodedocker キャッシュに基づくデフォルトのnodepullMethodではなく、デフォルトのpodpullMethodを使用します。nodedocker キャッシュはレジストリーイメージがContainer.Imageで利用可能な場合に便利ですが、CDI インポーターはこれにアクセスすることは許可されていません。 - 4
- 利用可能なブートソースとして検出するカスタムイメージの場合、イメージの
managedDataSourceの名前が、仮想マシンテンプレート YAML ファイルのspec.dataVolumeTemplates.spec.sourceRef.nameにあるテンプレートのDataSourceの名前に一致する必要があります。 - 5
- cron ジョブが削除されたときにデータボリュームおよびデータソースを保持するには、
Allを使用します。cron ジョブが削除されたときにデータボリュームおよびデータソースを削除するには、Noneを使用します。
10.18.13.6. システム定義またはユーザー定義のブートソースの自動更新の無効化
ユーザー定義のブートソースおよびシステム定義のブートソースの自動インポートおよび更新を無効にすることができます。
デフォルトでは、システム定義のブートソースは HyperConverged カスタムリソース (CR) の spec.dataImportCronTemplates にリストされていないため、ブートソースを追加し、自動インポートおよび更新を無効にする必要があります。
手順
-
ユーザー定義のブートソースの自動インポートおよび更新を無効にするには、カスタムリソースリストの
spec.dataImportCronTemplatesフィールドからブートソースを削除します。 システム定義の起動ソースの自動インポートおよび更新を無効にするには、以下を行います。
-
HyperConvergedCR を編集し、ブートソースをspec.dataImportCronTemplatesに追加します。 dataimportcrontemplate.kubevirt.io/enableアノテーションをfalseに設定して、自動インポートおよび更新を無効にします。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
10.18.13.7. ブートソースのステータスの確認
ブートソースがシステム定義かユーザー定義かを確認できます。
HyperConverged CR の status.dataImportChronTemplates フィールドにリストされている各ブートソースの status セクションは、ブートソースのタイプを示します。たとえば、commonTemplate: true はシステム定義 (commonTemplate) の起動ソースを示し、status: {} はユーザー定義の起動ソースを示します。
10.18.14. 仮想マシンでの Descheduler エビクションの有効化
Descheduler を使用して Pod を削除し、Pod をより適切なノードに再スケジュールできます。Pod が仮想マシンの場合、Pod の削除により、仮想マシンが別のノードにライブマイグレーションされます。
仮想マシンの Descheduler エビクションはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
10.18.14.1. Descheduler プロファイル
テクノロジープレビューの DevPreviewLongLifecycle プロファイルを使用して、仮想マシンで Descheduler を有効にします。これは、現在 OpenShift Virtualization で利用可能な唯一の Descheduler プロファイルです。適切なスケジューリングを確保するには、予想される負荷に応じた CPU およびメモリー要求で仮想マシンを作成します。
DevPreviewLongLifecycleこのプロファイルは、ノード間のリソース使用率のバランスを取り、以下のストラテジーを有効にします。
-
RemovePodsHavingTooManyRestarts: コンテナーが何度も再起動された Pod、およびすべてのコンテナー (Init コンテナーを含む) の再起動の合計が 100 を超える Pod を削除します。仮想マシンのゲストオペレーティングシステムを再起動しても、この数は増えません。 LowNodeUtilization: 使用率の低いノードがある場合に、使用率の高いノードから Pod をエビクトします。エビクトされた Pod の宛先ノードはスケジューラーによって決定されます。- ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) について 20% 未満の場合に使用率が低いと見なされます。
- ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) について 50% を超える場合に過剰に使用されていると見なされます。
-
10.18.14.2. Descheduler のインストール
Descheduler はデフォルトで利用できません。Descheduler を有効にするには、Kube Descheduler Operator を OperatorHub からインストールし、1 つ以上の Descheduler プロファイルを有効にする必要があります。
デフォルトで、Descheduler は予測モードで実行されます。つまり、これは Pod エビクションのみをシミュレートします。Pod エビクションを実行するには、Descheduler のモードを automatic に変更する必要があります。
クラスターでホストされたコントロールプレーンを有効にしている場合は、カスタム優先度のしきい値を設定して、ホストされたコントロールプレーンの namespace の Pod が削除される可能性を下げます。ホストされたコントロールプレーンの優先度クラスの中で優先度値が最も低い (100000000) ため、優先度しきい値クラス名を hypershift-control-plane に設定します。
前提条件
- クラスター管理者の権限。
- 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 のプロファイルおよび設定を設定することもできます。
10.18.14.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 が仮想マシンで有効になりました。
10.19. 仮想マシンのインポート
10.19.1. データボリュームインポートの TLS 証明書
10.19.1.1. データボリュームインポートの認証に使用する TLS 証明書の追加
ソースからデータをインポートするには、レジストリーまたは HTTPS エンドポイントの TLS 証明書を設定マップに追加する必要があります。この設定マップは、宛先データボリュームの namespace に存在する必要があります。
TLS 証明書の相対パスを参照して設定マップ を作成します。
手順
正しい namespace にあることを確認します。設定マップは、同じ namespace にある場合にデータボリュームによってのみ参照されます。
oc get ns
$ oc get nsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定マップを作成します。
oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>
$ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.19.1.2. 例: TLS 証明書から作成される設定マップ
以下は、ca.pem TLS 証明書で作成される設定マップの例です。
10.19.2. データボリュームの使用による仮想マシンイメージのインポート
Containerized Data Importer (CDI) を使用し、データボリュームを使用して仮想マシンイメージを永続ボリューム要求 (PVC) にインポートします。次に、データボリュームを永続ストレージの仮想マシンに割り当てることができます。
仮想マシンイメージは、HTTP または HTTPS エンドポイントでホストするか、コンテナーディスクに組み込み、コンテナーレジストリーで保存できます。
ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。
サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムによって異なります。詳細は、該当するオペレーティングシステムのドキュメントを参照してください。
10.19.2.1. 前提条件
- エンドポイントに TLS 証明書が必要な場合、TLS 証明書がデータボリュームと同じ namespace の config map に組み込まれていて、データボリューム設定で参照されている。
コンテナーディスクをインポートするには、以下を実行すること。
- 仮想マシンイメージからコンテナーディスクを準備 し、これをコンテナーレジストリーに保存してからインポートする必要がある場合があります。
-
コンテナーレジストリーに TLS がない場合、レジストリーを
HyperConvergedカスタムリソースのinsecureRegistriesフィールドに追加 し、ここからコンテナーディスクをインポートできます。
- この操作を正常に完了するためには、ストレージクラスを定義するか、CDI スクラッチ領域を用意 しなければならない場合があります。
10.19.2.2. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
| コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
|---|---|---|---|---|---|
| KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
| KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
CDI は OpenShift Container Platform の クラスター全体のプロキシー設定 を使用するようになりました。
10.19.2.3. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.19.2.4. データボリュームを使用して仮想マシンイメージをストレージにインポートする
データボリュームを使用して、仮想マシンイメージをストレージにインポートできます。
仮想マシンイメージは、HTTP または HTTPS エンドポイントでホストするか、イメージをコンテナーディスクに組み込み、コンテナーレジストリーで保存できます。
イメージのデータソースは、VirtualMachine 設定ファイルで指定します。仮想マシンが作成されると、仮想マシンイメージを含むデータボリュームがストレージにインポートされます。
前提条件
仮想マシンイメージをインポートするには、以下が必要である。
-
RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで
xzまたはgzを使用して圧縮される)。 - データソースにアクセスするために必要な認証情報と共にイメージがホストされる HTTP または HTTPS エンドポイント
-
RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで
- コンテナーディスクをインポートするには、仮想マシンイメージをコンテナーディスクに組み込み、データソースにアクセスするために必要な認証クレデンシャルとともにコンテナーレジストリーに保存する必要があります。
- 仮想マシンが自己署名証明書またはシステム CA バンドルによって署名されていない証明書を使用するサーバーと通信する必要がある場合は、データボリュームと同じ namespace に config map を作成する必要があります。
手順
データソースに認証が必要な場合は、データソースのクレデンシャルを指定して
Secretマニフェストを作成し、endpoint-secret.yamlとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Secretマニフェストを適用します。oc apply -f endpoint-secret.yaml
$ oc apply -f endpoint-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow VirtualMachineマニフェストを編集し、インポートする仮想マシンイメージのデータソースを指定して、vm-fedora-datavolume.yamlとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 仮想マシンの名前を指定します。
- 2
- データボリュームの名前を指定します。
- 3
- HTTP または HTTPS エンドポイントに
httpを指定します。レジストリーからインポートされたコンテナーディスクイメージのregistryを指定します。 - 4
- インポートする仮想マシンイメージの URL またはレジストリーエンドポイントを指定します。この例では、HTTPS エンドポイントで仮想マシンイメージを参照します。コンテナーレジストリーエンドポイントのサンプルは
url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest"です。 - 5
- データソースの
Secretを作成した場合は、Secret名を指定します。 - 6
- オプション: CA 証明書 config map を指定します。
仮想マシンを作成します。
oc create -f vm-fedora-datavolume.yaml
$ oc create -f vm-fedora-datavolume.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記oc createコマンドは、データボリュームおよび仮想マシンを作成します。CDI コントローラーは適切なアノテーションを使用して基礎となる PVC を作成し、インポートプロセスが開始されます。インポートが完了すると、データボリュームのステータスがSucceededに変わります。仮想マシンを起動できます。データボリュームのプロビジョニングはバックグランドで実行されるため、これをプロセスをモニターする必要はありません。
検証
インポーター Pod は指定された URL から仮想マシンイメージまたはコンテナーディスクをダウンロードし、これをプロビジョニングされた PV に保存します。以下のコマンドを実行してインポーター Pod のステータスを確認します。
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ステータスが
Succeededになるまでデータボリュームを監視します。oc describe dv fedora-dv
$ oc describe dv fedora-dv1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
VirtualMachineマニフェストで定義したデータボリューム名を指定します。
シリアルコンソールにアクセスして、プロビジョニングが完了し、仮想マシンが起動したことを確認します。
virtctl console vm-fedora-datavolume
$ virtctl console vm-fedora-datavolumeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.19.3. データボリュームの使用による仮想マシンイメージのブロックストレージへのインポート
既存の仮想マシンイメージは OpenShift Container Platform クラスターにインポートできます。OpenShift Virtualization はデータボリュームを使用してデータのインポートおよび基礎となる永続ボリューム要求 (PVC) の作成を自動化します。
ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。
サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムによって異なります。詳細は、該当するオペレーティングシステムのドキュメントを参照してください。
10.19.3.1. 前提条件
- CDI でサポートされる操作マトリックス に応じてスクラッチ領域が必要な場合は、この操作が正常に完了するように、まずは ストレージクラスを定義するフィルタリングCDI スクラッチ領域を用意 すること。
10.19.3.2. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.19.3.3. ブロック永続ボリュームについて
ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。
raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block を指定してプロビジョニングされます。
10.19.3.4. ローカルブロック永続ボリュームの作成
ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック永続ボリューム (PV) を作成します。次に、このループデバイスを PV マニフェストで Block ボリュームとして参照し、これを仮想マシンイメージのブロックデバイスとして使用できます。
手順
-
ローカル PV を作成するノードに
rootとしてログインします。この手順では、node01を例に使用します。 ファイルを作成して、これを null 文字で設定し、ブロックデバイスとして使用できるようにします。以下の例では、2Gb (20 100Mb ブロック) のサイズのファイル
loop10を作成します。dd if=/dev/zero of=<loop10> bs=100M count=20
$ dd if=/dev/zero of=<loop10> bs=100M count=20Copy to Clipboard Copied! Toggle word wrap Toggle overflow loop10ファイルをループデバイスとしてマウントします。losetup </dev/loop10>d3 <loop10>
$ losetup </dev/loop10>d3 <loop10>1 2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow マウントされたループデバイスを参照する
PersistentVolumeマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブロック PV を作成します。
oc create -f <local-block-pv10.yaml>
# oc create -f <local-block-pv10.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 直前の手順で作成された永続ボリュームのファイル名。
10.19.3.5. データボリュームを使用して仮想マシンイメージをブロックストレージにインポートする
データボリュームを使用して、仮想マシンイメージをブロックストレージにインポートできます。仮想マシンを作成する前に、VirtualMachine マニフェストでデータボリュームを参照します。
前提条件
-
RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで
xzまたはgzを使用して圧縮される)。 - データソースにアクセスするために必要な認証情報と共にイメージがホストされる HTTP または HTTPS エンドポイント
手順
データソースに認証が必要な場合は、データソースのクレデンシャルを指定して
Secretマニフェストを作成し、endpoint-secret.yamlとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Secretマニフェストを適用します。oc apply -f endpoint-secret.yaml
$ oc apply -f endpoint-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow データ
DataVolumeマニフェストを作成し、仮想マシンイメージのデータソースとstorage.volumeModeのBlockを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンイメージをインポートするために data volume を作成します。
oc create -f import-pv-datavolume.yaml
$ oc create -f import-pv-datavolume.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
仮想マシンを作成する前に、VirtualMachine マニフェストでこのデータボリュームを参照できます。
10.19.3.6. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
| コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
|---|---|---|---|---|---|
| KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
| KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
CDI は OpenShift Container Platform の クラスター全体のプロキシー設定 を使用するようになりました。
10.20. 仮想マシンのクローン作成
10.20.1. 複数の namespace 間でデータボリュームをクローン作成するためのユーザーパーミッションの有効化
namespace には相互に分離する性質があるため、ユーザーはデフォルトでは namespace をまたがってリソースのクローンを作成することができません。
ユーザーが仮想マシンのクローンを別の namespace に作成できるようにするには、cluster-admin ロールを持つユーザーが新規のクラスターロールを作成する必要があります。このクラスターロールをユーザーにバインドし、それらのユーザーが仮想マシンのクローンを宛先 namespace に対して作成できるようにします。
10.20.1.1. 前提条件
-
cluster-adminロールを持つユーザーのみがクラスターロールを作成できること。
10.20.1.2. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.20.1.3. データボリュームのクローン作成のための RBAC リソースの作成
datavolumes リソースのすべてのアクションのパーミッションを有効にする新規のくスターロールを作成します。
手順
ClusterRoleマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスターロールの一意の名前。
クラスターにクラスターロールを作成します。
oc create -f <datavolume-cloner.yaml>
$ oc create -f <datavolume-cloner.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 直前の手順で作成された
ClusterRoleマニフェストのファイル名です。
移行元および宛先 namespace の両方に適用される
RoleBindingマニフェストを作成し、直前の手順で作成したクラスターロールを参照します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターにロールバインディングを作成します。
oc create -f <datavolume-cloner.yaml>
$ oc create -f <datavolume-cloner.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 直前の手順で作成された
RoleBindingマニフェストのファイル名です。
10.20.2. 新規データボリュームへの仮想マシンディスクのクローン作成
データボリューム設定ファイルでソース PVC を参照し、新規データボリュームに仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを作成できます。
volumeMode: Block が指定された永続ボリューム (PV) から volumeMode: Filesystem が指定された PV へのクローンなど、異なるボリュームモード間でのクローン操作がサポートされます。
ただし、contentType: kubevirt を使用している場合にのみ異なるボリュームモード間のクローンが可能です。
事前割り当てをグローバルに有効にする場合や、単一データボリュームについて、Containerized Data Importer (CDI) はクローン時にディスク領域を事前に割り当てます。事前割り当てにより、書き込みパフォーマンスが向上します。詳細は、データボリュームについての事前割り当ての使用 を参照してください。
10.20.2.1. 前提条件
- ユーザーは、仮想マシンディスクの PVC のクローンを別の namespace に作成するために 追加のパーミッション が必要です。
10.20.2.2. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.20.2.3. 新規データボリュームへの仮想マシンディスクの永続ボリューム要求 (PVC) のクローン作成
既存の仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを新規データボリュームに作成できます。その後、新規データボリュームは新規の仮想マシンに使用できます。
データボリュームが仮想マシンとは別に作成される場合、データボリュームのライフサイクルは仮想マシンから切り離されます。仮想マシンが削除されても、データボリュームもその関連付けられた PVC も削除されません。
前提条件
- 使用する既存の仮想マシンディスクの PVC を判別すること。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
-
OpenShift CLI (
oc) がインストールされている。
手順
- 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンディスクを確認します。
新規データボリュームの名前、ソース PVC の名前および namespace、および新規データボリュームのサイズを指定するデータボリュームの YAML ファイルを作成します。
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow データボリュームを作成して PVC のクローン作成を開始します。
oc create -f <cloner-datavolume>.yaml
$ oc create -f <cloner-datavolume>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。
10.20.2.4. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
| コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
|---|---|---|---|---|---|
| KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
| KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
10.20.3. データボリュームテンプレートの使用による仮想マシンのクローン作成
既存の仮想マシンの永続ボリューム要求 (PVC) のクローン作成により、新規の仮想マシンを作成できます。dataVolumeTemplate を仮想マシン設定ファイルに含めることにより、元の PVC から新規のデータボリュームを作成します。
volumeMode: Block が指定された永続ボリューム (PV) から volumeMode: Filesystem が指定された PV へのクローンなど、異なるボリュームモード間でのクローン操作がサポートされます。
ただし、contentType: kubevirt を使用している場合にのみ異なるボリュームモード間のクローンが可能です。
事前割り当てをグローバルに有効にする場合や、単一データボリュームについて、Containerized Data Importer (CDI) はクローン時にディスク領域を事前に割り当てます。事前割り当てにより、書き込みパフォーマンスが向上します。詳細は、データボリュームについての事前割り当ての使用 を参照してください。
10.20.3.1. 前提条件
- ユーザーは、仮想マシンディスクの PVC のクローンを別の namespace に作成するために 追加のパーミッション が必要です。
10.20.3.2. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.20.3.3. データボリュームテンプレートの使用による、クローン作成された永続ボリューム要求 (PVC) からの仮想マシンの新規作成
既存の仮想マシンの永続ボリューム要求 (PVC) のクローンをデータボリュームに作成する仮想マシンを作成できます。仮想マシンマニフェストの dataVolumeTemplate を参照することにより、source PVC のクローンがデータボリュームに作成され、これは次に仮想マシンを作成するために自動的に使用されます。
データボリュームが仮想マシンのデータボリュームテンプレートの一部として作成されると、データボリュームのライフサイクルは仮想マシンに依存します。つまり、仮想マシンが削除されると、データボリュームおよび関連付けられた PVC も削除されます。
前提条件
- 使用する既存の仮想マシンディスクの PVC を判別すること。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
-
OpenShift CLI (
oc) がインストールされている。
手順
- 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンを確認します。
VirtualMachineオブジェクトの YAML ファイルを作成します。以下の仮想マシンのサンプルでは、source-namespacenamespace にあるmy-favorite-vm-diskのクローンを作成します。favorite-cloneという2Giデータはmy-favorite-vm-diskから作成されます。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 作成する仮想マシン。
PVC のクローンが作成されたデータボリュームで仮想マシンを作成します。
oc create -f <vm-clone-datavolumetemplate>.yaml
$ oc create -f <vm-clone-datavolumetemplate>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.20.3.4. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
| コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
|---|---|---|---|---|---|
| KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
| KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
10.20.4. 新規ブロックストレージデータボリュームへの仮想マシンディスクのクローン作成
データボリューム設定ファイルでソース PVC を参照し、新規ブロックデータボリュームに仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを作成できます。
volumeMode: Block が指定された永続ボリューム (PV) から volumeMode: Filesystem が指定された PV へのクローンなど、異なるボリュームモード間でのクローン操作がサポートされます。
ただし、contentType: kubevirt を使用している場合にのみ異なるボリュームモード間のクローンが可能です。
事前割り当てをグローバルに有効にする場合や、単一データボリュームについて、Containerized Data Importer (CDI) はクローン時にディスク領域を事前に割り当てます。事前割り当てにより、書き込みパフォーマンスが向上します。詳細は、データボリュームについての事前割り当ての使用 を参照してください。
10.20.4.1. 前提条件
- ユーザーは、仮想マシンディスクの PVC のクローンを別の namespace に作成するために 追加のパーミッション が必要です。
10.20.4.2. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.20.4.3. ブロック永続ボリュームについて
ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。
raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block を指定してプロビジョニングされます。
10.20.4.4. ローカルブロック永続ボリュームの作成
ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック永続ボリューム (PV) を作成します。次に、このループデバイスを PV マニフェストで Block ボリュームとして参照し、これを仮想マシンイメージのブロックデバイスとして使用できます。
手順
-
ローカル PV を作成するノードに
rootとしてログインします。この手順では、node01を例に使用します。 ファイルを作成して、これを null 文字で設定し、ブロックデバイスとして使用できるようにします。以下の例では、2Gb (20 100Mb ブロック) のサイズのファイル
loop10を作成します。dd if=/dev/zero of=<loop10> bs=100M count=20
$ dd if=/dev/zero of=<loop10> bs=100M count=20Copy to Clipboard Copied! Toggle word wrap Toggle overflow loop10ファイルをループデバイスとしてマウントします。losetup </dev/loop10>d3 <loop10>
$ losetup </dev/loop10>d3 <loop10>1 2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow マウントされたループデバイスを参照する
PersistentVolumeマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブロック PV を作成します。
oc create -f <local-block-pv10.yaml>
# oc create -f <local-block-pv10.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 直前の手順で作成された永続ボリュームのファイル名。
10.20.4.5. 新規データボリュームへの仮想マシンディスクの永続ボリューム要求 (PVC) のクローン作成
既存の仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを新規データボリュームに作成できます。その後、新規データボリュームは新規の仮想マシンに使用できます。
データボリュームが仮想マシンとは別に作成される場合、データボリュームのライフサイクルは仮想マシンから切り離されます。仮想マシンが削除されても、データボリュームもその関連付けられた PVC も削除されません。
前提条件
- 使用する既存の仮想マシンディスクの PVC を判別すること。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
-
OpenShift CLI (
oc) がインストールされている。 - ソース PVC と同じか、これよりも大きい 1 つ以上の利用可能なブロック永続ボリューム (PV)。
手順
- 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンディスクを確認します。
新規データボリュームの名前、ソース PVC の名前および namespace、利用可能なブロック PV を使用できるようにするために
volumeMode: Block、および新規データボリュームのサイズを指定するデータボリュームの YAML ファイルを作成します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow データボリュームを作成して PVC のクローン作成を開始します。
oc create -f <cloner-datavolume>.yaml
$ oc create -f <cloner-datavolume>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。
10.20.4.6. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
| コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
|---|---|---|---|---|---|
| KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
| KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
10.21. 仮想マシンのネットワーク
10.21.1. デフォルトの Pod ネットワーク用の仮想マシンの設定
masquerade バインディングモードを使用するようにネットワークインターフェイスを設定することで、仮想マシンをデフォルトの内部 Pod ネットワークに接続できます。
デフォルトの Pod ネットワークに接続している仮想ネットワークインターフェイスカード (vNIC) 上のトラフィックは、ライブマイグレーション時に中断します。
10.21.1.1. コマンドラインでのマスカレードモードの設定
マスカレードモードを使用し、仮想マシンの送信トラフィックを Pod IP アドレスの背後で非表示にすることができます。マスカレードモードは、ネットワークアドレス変換 (NAT) を使用して仮想マシンを Linux ブリッジ経由で Pod ネットワークバックエンドに接続します。
仮想マシンの設定ファイルを編集して、マスカレードモードを有効にし、トラフィックが仮想マシンに到達できるようにします。
前提条件
- 仮想マシンは、IPv4 アドレスを取得するために DHCP を使用できるように設定される必要がある。以下の例では、DHCP を使用するように設定されます。
手順
仮想マシン設定ファイルの
interfaces仕様を編集します。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
10.21.1.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}"10.21.2. 仮想マシンを公開するサービスの作成
Service オブジェクトを使用して、クラスター内またはクラスターの外部に仮想マシンを公開することができます。
10.21.2.1. サービスについて
Kubernetes サービス は、一連の Pod で実行されるアプリケーションをネットワークサービスとして公開するための抽象的な方法です。サービスを使用すると、アプリケーションがトラフィックを受信できます。サービスは、Service オブジェクトに spec.type を指定して複数の異なる方法で公開できます。
- ClusterIP
-
クラスター内の内部 IP アドレスでサービスを公開します。
ClusterIPはデフォルトのサービスタイプです。 - NodePort
-
クラスター内の選択した各ノードの同じポートでサービスを公開します。
NodePortは、クラスター外からサービスにアクセスできるようにします。 - LoadBalancer
現在のクラウド（サポートされている場合）に外部ロードバランサーを作成し、固定の外部 IP アドレスをサービスに割り当てます。
注記オンプレミスクラスターの場合、MetalLB Operator をデプロイすることで負荷分散サービスを設定できます。
10.21.2.1.1. デュアルスタックサポート
IPv4 および IPv6 のデュアルスタックネットワークがクラスターに対して有効にされている場合、Service オブジェクトに spec.ipFamilyPolicy および spec.ipFamilies フィールドを定義して、IPv4、IPv6、またはそれら両方を使用するサービスを作成できます。
spec.ipFamilyPolicy フィールドは以下の値のいずれかに設定できます。
- SingleStack
- コントロールプレーンは、最初に設定されたサービスクラスターの IP 範囲に基づいて、サービスのクラスター IP アドレスを割り当てます。
- PreferDualStack
- コントロールプレーンは、デュアルスタックが設定されたクラスターのサービス用に IPv4 および IPv6 クラスター IP アドレスの両方を割り当てます。
- RequireDualStack
-
このオプションは、デュアルスタックネットワークが有効にされていないクラスターの場合には失敗します。デュアルスタックが設定されたクラスターの場合、その値が
PreferDualStackに設定されている場合と同じになります。コントロールプレーンは、IPv4 アドレスと IPv6 アドレス範囲の両方からクラスター IP アドレスを割り当てます。
単一スタックに使用する IP ファミリーや、デュアルスタック用の IP ファミリーの順序は、spec.ipFamilies を以下のアレイ値のいずれかに設定して定義できます。
-
[IPv4] -
[IPv6] -
[IPv4, IPv6] -
[IPv6, IPv4]
10.21.2.2. 仮想マシンのサービスとしての公開
ClusterIP、NodePort、または LoadBalancer サービスを作成し、クラスター内外から実行中の仮想マシン (VM) に接続します。
手順
VirtualMachineマニフェストを編集して、サービス作成のラベルを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ラベル
special: keyをspec.template.metadata.labelsセクションに追加します。
注記仮想マシンのラベルは Pod に渡されます。
special: キーラベルは、Serviceマニフェストのspec.selector属性のラベルと一致する必要があります。-
VirtualMachineマニフェストファイルを保存して変更を適用します。 仮想マシンを公開するための
Serviceマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Serviceオブジェクトの名前。- 2
Serviceオブジェクトが存在する namespace。これはVirtualMachineマニフェストのmetadata.namespaceフィールドと同じである必要があります。- 3
- オプション: ノードが外部 IP アドレスで受信したサービストラフィックを分散する方法を指定します。これは
NodePortおよびLoadBalancerサービスタイプにのみ適用されます。デフォルト値はClusterで、トラフィックをすべてのクラスターエンドポイントに均等にルーティングします。 - 4
- オプション: 設定する場合、
nodePort値はすべてのサービスで固有でなければなりません。指定しない場合、30000を超える範囲内の値は動的に割り当てられます。 - 5
- オプション: サービスによって公開される VM ポート。ポートリストが仮想マシンマニフェストに定義されている場合は、オープンポートを参照する必要があります。
targetPortが指定されていない場合は、ポートと同じ値を取ります。 - 6
VirtualMachineマニフェストのspec.template.metadata.labelsスタンザに追加したラベルへの参照。- 7
- サービスのタイプ。使用できる値は
ClusterIP、NodePort、およびLoadBalancerです。
-
サービスマニフェストファイルを保存します。 以下のコマンドを実行してサービスを作成します。
oc create -f <service_name>.yaml
$ oc create -f <service_name>.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 ClusterIPサービスの出力例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice ClusterIP 172.30.3.149 <none> 27017/TCP 2m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice ClusterIP 172.30.3.149 <none> 27017/TCP 2mCopy to Clipboard Copied! Toggle word wrap Toggle overflow NodePortサービスの出力例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice NodePort 172.30.232.73 <none> 27017:30000/TCP 5m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice NodePort 172.30.232.73 <none> 27017:30000/TCP 5mCopy to Clipboard Copied! Toggle word wrap Toggle overflow LoadBalancerサービスの出力例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice LoadBalancer 172.30.27.5 172.29.10.235,172.29.10.235 27017:31829/TCP 5s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice LoadBalancer 172.30.27.5 172.29.10.235,172.29.10.235 27017:31829/TCP 5sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンに接続するための適切な方法を選択します。
ClusterIPサービスの場合は、サービス IP アドレスとサービスポートを使用して、クラスター内から仮想マシンに接続します。以下に例を示します。ssh fedora@172.30.3.149 -p 27017
$ ssh fedora@172.30.3.149 -p 27017Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodePortサービスの場合、ノード IP アドレスとクラスターネットワーク外のノードポートを指定して仮想マシンに接続します。以下に例を示します。ssh fedora@$NODE_IP -p 30000
$ ssh fedora@$NODE_IP -p 30000Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
LoadBalancerサービスの場合は、vinagreクライアントを使用し、パブリック IP アドレスおよびポートで仮想マシンに接続します。外部ポートは動的に割り当てられます。
10.21.3. Linux ブリッジネットワークへの仮想マシンの割り当て
デフォルトでは、OpenShift Virtualization は単一の内部 Pod ネットワークとともにインストールされます。
追加のネットワークに接続するには、Linux ブリッジ ネットワーク接続定義 (NAD) を作成する必要があります。
仮想マシンを追加のネットワークに割り当てるには、以下を実行します。
- Linux ブリッジ ノード ネットワーク設定ポリシーを作成します。
- Linux ブリッジ ネットワーク接続定義を作成します。
- 仮想マシンを設定して、仮想マシンがネットワーク接続定義を認識できるようにします。
スケジューリング、インターフェイスタイプ、およびその他のノードのネットワークアクティビティーについての詳細は、node networking セクションを参照してください。
10.21.3.1. ネットワーク接続定義によるネットワークへの接続
10.21.3.1.1. Linux ブリッジ ノード ネットワーク設定ポリシーの作成
NodeNetworkConfigurationPolicy マニフェスト YAML ファイルを使用して、Linux ブリッジを作成します。
前提条件
- Kubernetes NMState Operator がインストールされている。
手順
NodeNetworkConfigurationPolicyマニフェストを作成します。この例には、独自の情報で置き換える必要のあるサンプルの値が含まれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.21.3.2. Linux ブリッジネットワーク接続定義の作成
仮想マシンのネットワークアタッチメント定義での IP アドレス管理 (IPAM) の設定はサポートされていません。
10.21.3.2.1. Web コンソールでの Linux ブリッジネットワーク接続定義の作成
ネットワーク管理者は、ネットワーク接続定義を作成して layer-2 ネットワークを Pod および仮想マシンに提供できます。
手順
- Web コンソールで、Networking → Network Attachment Definitions をクリックします。
Create Network Attachment Definition をクリックします。
注記ネットワーク接続定義は Pod または仮想マシンと同じ namespace にある必要があります。
- 一意の Name およびオプションの Description を入力します。
- Network Type リストをクリックし、CNV Linux bridge を選択します。
- Bridge Name フィールドにブリッジの名前を入力します。
- オプション: リソースに VLAN ID が設定されている場合、VLAN Tag Number フィールドに ID 番号を入力します。
- オプション: MAC Spoof Check を選択して、MAC スプーフフィルタリングを有効にします。この機能により、Pod を終了するための MAC アドレスを 1 つだけ許可することで、MAC スプーフィング攻撃に対してセキュリティーを確保します。
Create をクリックします。
注記Linux ブリッジ ネットワーク接続定義は、仮想マシンを VLAN に接続するための最も効率的な方法です。
10.21.3.2.2. CLI での Linux ブリッジネットワーク接続定義の作成
ネットワーク管理者は、タイプ cnv-bridge のネットワーク接続定義を、レイヤー 2 ネットワークを Pod および仮想マシンに提供するように設定できます。
前提条件
-
MAC スプーフィングチェックを有効にするには、ノードが nftables をサポートして、
nftバイナリーがデプロイされている必要があります。
手順
- 仮想マシンと同じ namespace にネットワーク接続定義を作成します。
次の例のように、仮想マシンをネットワーク接続定義に追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
NetworkAttachmentDefinitionオブジェクトの名前。- 2
- オプション: ノード選択のアノテーションのキーと値のペア。
bridge-interfaceは一部のノードに設定されるブリッジの名前に一致する必要があります。このアノテーションをネットワーク接続定義に追加する場合、仮想マシンインスタンスはbridge-interfaceブリッジが接続されているノードでのみ実行されます。 - 3
- 設定の名前。設定名をネットワーク接続定義の
name値に一致させることが推奨されます。 - 4
- このネットワーク接続定義のネットワークを提供する Container Network Interface (CNI) プラグインの実際の名前。異なる CNI を使用するのでない限り、このフィールドは変更しないでください。
- 5
- ノードに設定される Linux ブリッジの名前。
- 6
- オプション:MAC スプーフィングチェックを有効にする。
trueに設定すると、Pod またはゲストインターフェイスの MAC アドレスを変更できません。この属性は、Pod からの MAC アドレスを 1 つだけ許可することで、MAC スプーフィング攻撃に対してセキュリティーを確保します。 - 7
- オプション: VLAN タグ。ノードのネットワーク設定ポリシーでは、追加の VLAN 設定は必要ありません。
- 8
- オプション: 仮想マシンがデフォルト VLAN 経由でブリッジに接続するかどうかを示します。デフォルト値は
trueです。
注記Linux ブリッジネットワーク接続定義は、仮想マシンを VLAN に接続するための最も効率的な方法です。
ネットワーク接続定義を作成します。
oc create -f <network-attachment-definition.yaml>
$ oc create -f <network-attachment-definition.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ここで、
<network-attachment-definition.yaml>はネットワーク接続定義マニフェストのファイル名です。
検証
次のコマンドを実行して、ネットワーク接続定義が作成されたことを確認します。
oc get network-attachment-definition <bridge-network>
$ oc get network-attachment-definition <bridge-network>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.21.3.3. Linux ブリッジネットワーク用の仮想マシンの設定
10.21.3.3.1. Web コンソールでの仮想マシンの NIC の作成
Web コンソールから追加の NIC を作成し、これを仮想マシンに割り当てます。
前提条件
- ネットワーク接続定義が使用可能である必要があります。
手順
- OpenShift Container Platform コンソールの正しいプロジェクトで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Network Interfaces タブをクリックして、仮想マシンにすでに接続されている NIC を表示します。
- Add Network Interface をクリックし、一覧に新規スロットを作成します。
- 追加ネットワークの Network リストからネットワーク接続定義を選択します。
- 新規 NIC の Name、Model、Type、および MAC Address に入力します。
- Save をクリックして NIC を保存し、これを仮想マシンに割り当てます。
10.21.3.3.2. ネットワークフィールド
| Name | 説明 |
|---|---|
| Name | ネットワークインターフェイスコントローラーの名前。 |
| モデル | ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
| Network | 利用可能なネットワーク接続定義のリスト。 |
| 型 | 利用可能なバインディングメソッドの一覧。ネットワークインターフェイスに適したバインド方法を選択します。
|
| MAC Address | ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
10.21.3.3.3. CLI で仮想マシンを追加のネットワークに接続する
ブリッジインターフェイスを追加し、仮想マシン設定でネットワーク接続定義を指定して、仮想マシンを追加のネットワークに割り当てます。
以下の手順では、YAML ファイルを使用して設定を編集し、更新されたファイルをクラスターに適用します。oc edit <object> <name> コマンドを使用して、既存の仮想マシンを編集することもできます。
前提条件
- 設定を編集する前に仮想マシンをシャットダウンします。実行中の仮想マシンを編集する場合は、変更を有効にするために仮想マシンを再起動する必要があります。
手順
- ブリッジネットワークに接続する仮想マシンの設定を作成または編集します。
ブリッジインターフェイスを
spec.template.spec.domain.devices.interfaces一覧に追加し、ネットワーク接続定義をspec.template.spec.networks一覧に追加します。この例では、a-bridge-networkネットワーク接続定義に接続されるbridge-netというブリッジインターフェイスを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ブリッジインターフェイスの名前。
- 2
- ネットワークの名前。この値は、対応する
spec.template.spec.domain.devices.interfacesエントリーのname値と一致する必要があります。 - 3
- ネットワーク接続定義の名前。接頭辞は、存在する namespace になります。namespace は、
defaultの namespace または仮想マシンが作成される namespace と同じでなければなりません。この場合、multusが使用されます。Multus は、Pod または仮想マシンが必要なインターフェイスを使用できるように、複数の CNI が存在できるようにするクラウドネットワークインターフェイス (CNI) プラグインです。
設定を適用します。
oc apply -f <example-vm.yaml>
$ oc apply -f <example-vm.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - オプション: 実行中の仮想マシンを編集している場合は、変更を有効にするためにこれを再起動する必要があります。
10.21.4. 仮想マシンの SR-IOV ネットワークへの接続
次の手順を実行して、仮想マシン (VM) を Single Root I/O Virtualization (SR-IOV) ネットワークに接続できます。
- SR-IOV ネットワーク デバイスを設定します。
- SR-IOV ネットワークを設定します。
- 仮想マシンを SR-IOV ネットワークに接続します。
10.21.4.1. 前提条件
- ホストのファームウェアでグローバル SR-IOV および VT-d 設定を有効 にしておく必要があります。
- SR-IOV Network Operator をインストール しておく必要があります。
10.21.4.2. SR-IOV ネットワークデバイスの設定
SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。
SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。
設定の変更が適用されるまでに数分かかる場合があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされている。
- ドレイン (解放) されたノードからエビクトされたワークロードを処理するために、クラスター内に利用可能な十分なノードがある。
- SR-IOV ネットワークデバイス設定についてコントロールプレーンノードを選択していない。
手順
SriovNetworkNodePolicyオブジェクトを作成してから、YAML を<name>-sriov-node-network.yamlファイルに保存します。<name>をこの設定の名前に置き換えます。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、またはpfNameの値も指定する必要があります。pfNamesとrootDevicesの両方を同時に指定する場合、それらが同一のデバイスをポイントすることを確認します。- 9
- オプション: SR-IOV ネットワークデバイスのベンダー 16 進コードを指定します。許可される値は
8086または15b3のいずれかのみになります。 - 10
- オプション: SR-IOV ネットワークデバイスのデバイス 16 進コードを指定します。許可される値は
158b、1015、1017のみになります。 - 11
- オプション: このパラメーターは、1 つ以上のイーサネットデバイスの物理機能 (PF) 名の配列を受け入れます。
- 12
- このパラメーターは、イーサネットデバイスの物理機能に関する 1 つ以上の PCI バスアドレスの配列を受け入れます。以下の形式でアドレスを指定します:
0000:02:00.1 - 13
- OpenShift Virtualization の仮想機能には、
vfio-pciドライバータイプが必要です。 - 14
- オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを指定します。Mellanox カードの場合、
isRdmaをfalseに設定します。デフォルト値はfalseです。
注記isRDMAフラグがtrueに設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。-
オプション: SR-IOV 対応のクラスターノードにまだラベルが付いていない場合は、
SriovNetworkNodePolicy.Spec.NodeSelectorでラベルを付けます。ノードのラベル付けの詳細は、「ノードのラベルを更新する方法について」を参照してください。 SriovNetworkNodePolicyオブジェクトを作成します。oc create -f <name>-sriov-node-network.yaml
$ 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
10.21.4.3. SR-IOV の追加ネットワークの設定
SriovNetwork オブジェクトを作成して、SR-IOV ハードウェアを使用する追加のネットワークを設定できます。
SriovNetwork オブジェクトの作成時に、SR-IOV Network Operator は NetworkAttachmentDefinition オブジェクトを自動的に作成します。
SriovNetwork オブジェクトが running 状態の Pod または仮想マシンに割り当てられている場合、これを変更したり、削除したりしないでください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
-
以下の
SriovNetworkオブジェクトを作成してから、YAML を<name>-sriov-network.yamlファイルに保存します。<name>を、この追加ネットワークの名前に置き換えます。
- 1
<name>をオブジェクトの名前に置き換えます。SR-IOV Network Operator は、同じ名前を持つNetworkAttachmentDefinitionオブジェクトを作成します。- 2
- SR-IOV ネットワーク Operator がインストールされている namespace を指定します。
- 3
<sriov_resource_name>を、この追加ネットワークの SR-IOV ハードウェアを定義するSriovNetworkNodePolicyオブジェクトの.spec.resourceNameパラメーターの値に置き換えます。- 4
<target_namespace>を SriovNetwork のターゲット namespace に置き換えます。ターゲット namespace の Pod または仮想マシンのみを SriovNetwork に割り当てることができます。- 5
- オプション:
<vlan>を、追加ネットワークの仮想 LAN (VLAN) ID に置き換えます。整数値は0から4095である必要があります。デフォルト値は0です。 - 6
- オプション:
<spoof_check>を VF の spoof check モードに置き換えます。許可される値は、文字列の"on"および"off"です。重要指定する値を引用符で囲む必要があります。そうしないと、CR は SR-IOV ネットワーク Operator によって拒否されます。
- 7
- オプション:
<link_state>を仮想機能 (VF) のリンクの状態に置き換えます。許可される値は、enable、disable、およびautoです。 - 8
- オプション:
<max_tx_rate>を VF の最大伝送レート (Mbps) に置き換えます。 - 9
- オプション:
<min_tx_rate>を VF の最小伝送レート (Mbps) に置き換えます。この値は、常に最大伝送レート以下である必要があります。注記Intel NIC は
minTxRateパラメーターをサポートしません。詳細は、BZ#1772847 を参照してください。 - 10
- オプション:
<vlan_qos>を VF の IEEE 802.1p 優先レベルに置き換えます。デフォルト値は0です。 - 11
- オプション:
<trust_vf>を VF の信頼モードに置き換えます。許可される値は、文字列の"on"および"off"です。重要指定する値を引用符で囲む必要があります。そうしないと、CR は SR-IOV ネットワーク Operator によって拒否されます。
- 12
- オプション:
<capabilities>を、このネットワークに設定する機能に置き換えます。
オブジェクトを作成するには、以下のコマンドを入力します。
<name>を、この追加ネットワークの名前に置き換えます。oc create -f <name>-sriov-network.yaml
$ oc create -f <name>-sriov-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 以下のコマンドを実行して、直前の手順で作成した
SriovNetworkオブジェクトに関連付けられたNetworkAttachmentDefinitionオブジェクトが存在することを確認するには、以下のコマンドを入力します。<namespace>を、SriovNetworkオブジェクト で指定した namespace に置き換えます。oc get net-attach-def -n <namespace>
$ oc get net-attach-def -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.21.4.4. 仮想マシンの SR-IOV ネットワークへの接続
仮想マシンの設定にネットワークの詳細を含めることで、仮想マシンを SR-IOV ネットワークに接続することができます。
手順
SR-IOV ネットワークの詳細を仮想マシン設定の
spec.domain.devices.interfacesおよびspec.networksに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシン設定を適用します。
oc apply -f <vm-sriov.yaml>
$ oc apply -f <vm-sriov.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 仮想マシン YAML ファイルの名前。
10.21.5. 仮想マシンのサービスメッシュへの接続
OpenShift Virtualization が OpenShift Service Mesh に統合されるようになりました。IPv4 を使用してデフォルトの Pod ネットワークで仮想マシンのワークロードを実行する Pod 間のトラフィックのモニター、可視化、制御が可能です。
10.21.5.1. 前提条件
- サービスメッシュ Operator を インストールし、サービスメッシュコントロールプレーン をデプロイしておく必要があります。
- 仮想マシンが作成される namespace を サービスメッシュメンバーロール に追加しておく必要があります。
-
デフォルトの Pod ネットワークには
masqueradeバインディングメソッドを使用する必要があります。
10.21.5.2. サービスメッシュの仮想マシンの設定
仮想マシン (VM) ワークロードをサービスメッシュに追加するには、sidecar.istio.io/inject アノテーションを true に設定して、仮想マシン設定ファイルでサイドカーコンテナーの自動挿入を有効にします。次に、仮想マシンをサービスとして公開し、メッシュでアプリケーションを表示します。
前提条件
- ポートの競合を回避するには、Istio サイドカープロキシーが使用するポートを使用しないでください。これには、ポート 15000、15001、15006、15008、15020、15021、および 15090 が含まれます。
手順
仮想マシン設定ファイルを編集し、
sidecar.istio.io/inject: "true"アノテーションを追加します。設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシン設定を適用します。
oc apply -f <vm_name>.yaml
$ oc apply -f <vm_name>.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 仮想マシン YAML ファイルの名前。
Serviceオブジェクトを作成し、仮想マシンをサービスメッシュに公開します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サービスの対象となる Pod セットを判別するサービスセレクターです。この属性は、仮想マシン設定ファイルの
spec.metadata.labelsフィールドに対応します。上記の例では、vm-istioという名前のServiceオブジェクトは、ラベルがapp=vm-istioの Pod の TCP ポート 8080 をターゲットにします。
サービスを作成します。
oc create -f <service_name>.yaml
$ oc create -f <service_name>.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サービス YAML ファイルの名前。
10.21.6. 仮想マシンの IP アドレスの設定
仮想マシンの静的および動的 IP アドレスを設定できます。
10.21.6.1. cloud-init を使用した新規仮想マシンの IP アドレスの設定
仮想マシン (VM) を作成するときに、cloud-init を使用してセカンダリー NIC の IP アドレスを設定できます。IP アドレスは、動的または静的にプロビジョニングできます。
VM が Pod ネットワークに接続されている場合、更新しない限り、Pod ネットワークインターフェイスがデフォルトルートになります。
前提条件
- 仮想マシンはセカンダリーネットワークに接続されている。
- 仮想マシンの動的 IP を設定するために、セカンダリーネットワーク上で使用できる DHCP サーバーがある。
手順
仮想マシン設定の
spec.template.spec.volumes.cloudInitNoCloud.networkDataスタンザを編集します。
10.21.7. NIC の IP アドレスの仮想マシンへの表示
Web コンソールまたは oc クライアントを使用して、ネットワークインターフェイスコントローラー (NIC) の IP アドレスを表示できます。QEMU ゲストエージェント は、仮想マシンのセカンダリーネットワークに関する追加情報を表示します。
10.21.7.1. 前提条件
- QEMU ゲストエージェントを仮想マシンにインストールしている。
10.21.7.2. CLI での仮想マシンインターフェイスの IP アドレスの表示
ネットワークインターフェイス設定は oc describe vmi <vmi_name> コマンドに含まれます。
IP アドレス情報は、仮想マシン上で ip addr を実行するか、oc get vmi <vmi_name> -o yaml を実行して表示することもできます。
手順
oc describeコマンドを使用して、仮想マシンインターフェイス設定を表示します。oc describe vmi <vmi_name>
$ oc describe vmi <vmi_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.21.7.3. Web コンソールでの仮想マシンインターフェイスの IP アドレスの表示
IP 情報は、仮想マシンの VirtualMachine details ページに表示されます。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシン名を選択して、VirtualMachine details ページを開きます。
接続されている各 NIC の情報は、Details タブの IP Address の下に表示されます。
10.21.8. 仮想マシンの MAC アドレスプールの使用
KubeMacPool コンポーネントは、指定の namespace の仮想マシン NIC に MAC アドレスプールサービスを提供します。
10.21.8.1. KubeMacPool について
KubeMacPool は namespace ごとに MAC アドレスプールを提供し、プールから仮想マシン NIC の MAC アドレスを割り当てます。これにより、NIC には別の仮想マシンの MAC アドレスと競合しない一意の MAC アドレスが割り当てられます。
仮想マシンから作成される仮想マシンインスタンスは、再起動時に割り当てられる MAC アドレスを保持します。
KubeMacPool は、仮想マシンから独立して作成される仮想マシンインスタンスを処理しません。
KubeMacPool は、OpenShift Virtualization のインストール時にデフォルトで有効化されます。namespace の MAC アドレスプールは、mutatevirtualmachines.kubemacpool.io=ignore ラベルを namespace に追加して無効にできます。ラベルを削除して、namespace の KubeMacPool を再度有効にします。
10.21.8.2. CLI での namespace の MAC アドレスプールの無効化
mutatevirtualmachines.kubemacpool.io=ignore ラベルを namespace に追加して、namespace の仮想マシンの MAC アドレスプールを無効にします。
手順
mutatevirtualmachines.kubemacpool.io=ignoreラベルを namespace に追加します。以下の例では、KubeMacPool を 2 つの namespace (<namespace1>および<namespace2>) について無効にします。oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io=ignore
$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io=ignoreCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.21.8.3. CLI での namespace の MAC アドレスプールを再度有効にする
namespace の KubeMacPool を無効にしている場合で、これを再度有効にする必要がある場合は、namespace から mutatevirtualmachines.kubemacpool.io=ignore ラベルを削除します。
以前のバージョンの OpenShift Virtualization では、mutatevirtualmachines.kubemacpool.io=allocate ラベルを使用して namespace の KubeMacPool を有効にしていました。これは引き続きサポートされますが、KubeMacPool がデフォルトで有効化されるようになったために不要になります。
手順
KubeMacPool ラベルを namespace から削除します。以下の例では、KubeMacPool を 2 つの namespace (
<namespace1>および<namespace2>) について再度有効にします。oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io-
$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.22. 仮想マシンディスク
10.22.1. ストレージ機能
以下の表を使用して、OpenShift Virtualization のローカルおよび共有の永続ストレージ機能の可用性を確認できます。
10.22.1.1. OpenShift Virtualization ストレージ機能マトリクス
| 仮想マシンのライブマイグレーション | ホスト支援型仮想マシンディスクのクローン作成 | ストレージ支援型仮想マシンディスクのクローン作成 | 仮想マシンのスナップショット | |
|---|---|---|---|---|
| OpenShift Data Foundation: RBD ブロックモードボリューム | はい | はい | はい | はい |
| OpenShift Virtualization ホストパスプロビジョナー | いいえ | はい | いいえ | いいえ |
| 他の複数ノードの書き込み可能なストレージ | はい [1] | はい | はい [2] | はい [2] |
| 他の単一ノードの書き込み可能なストレージ | いいえ | はい | はい [2] | はい [2] |
- PVC は ReadWriteMany アクセスモードを要求する必要があります。
- ストレージプロバイダーが Kubernetes および CSI スナップショット API の両方をサポートする必要があります。
以下を使用する仮想マシンのライブマイグレーションを行うことはできません。
- ReadWriteOnce (RWO) アクセスモードのストレージクラス
- GPU などのパススルー機能
それらの仮想マシンの evictionStrategy フィールドを LiveMigrate に設定しないでください。
10.22.2. 仮想マシンのローカルストレージの設定
ホストパスプロビジョナー (HPP) を使用して、仮想マシンのローカルストレージを設定できます。
OpenShift Virtualization Operator のインストール時に、Hostpath Provisioner (HPP) Operator は自動的にインストールされます。HPP は、Hostpath Provisioner Operator によって作成される OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。HPP を使用するには、HPP カスタムリソース (CR) を作成する必要があります。
10.22.2.1. 基本ストレージ プールを使用したホストパスプロビジョナーの作成
storagePools スタンザを使用して HPP カスタムリソース (CR) を作成することにより、基本ストレージプールを使用してホストパスプロビジョナー (HPP) を設定します。ストレージプールは、CSI ドライバーが使用する名前とパスを指定します。
前提条件
-
spec.storagePools.pathで指定されたディレクトリーには、読み取り/書き込みアクセス権が必要です。 - ストレージプールは、オペレーティングシステムと同じパーティションにあってはなりません。そうしないと、オペレーティングシステムのパーティションがいっぱいになり、パフォーマンスに影響を与えたり、ノードが不安定になったり、使用できなくなったりする可能性があります。
手順
次の例のように、
storagePoolsスタンザを含むhpp_cr.yamlファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存して終了します。
次のコマンドを実行して HPP を作成します。
oc create -f hpp_cr.yaml
$ oc create -f hpp_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.22.2.1.1. ストレージクラスの作成について
ストレージクラスの作成時に、ストレージクラスに属する永続ボリューム (PV) の動的プロビジョニングに影響するパラメーターを設定します。StorageClass オブジェクトの作成後には、このオブジェクトのパラメーターを更新できません。
ホストパスプロビジョナー (HPP) を使用するには、storagePools スタンザで CSI ドライバーの関連付けられたストレージクラスを作成する必要があります。
仮想マシンは、ローカル PV に基づくデータボリュームを使用します。ローカル PV は特定のノードにバインドされます。ディスクイメージは仮想マシンで使用するために準備されますが、ローカルストレージ PV がすでに固定されたノードに仮想マシンをスケジュールすることができない可能性があります。
この問題を解決するには、Kubernetes Pod スケジューラーを使用して、永続ボリューム要求 (PVC) を正しいノードの PV にバインドします。volumeBindingMode パラメーターが WaitForFirstConsumer に設定された StorageClass 値を使用することにより、PV のバインディングおよびプロビジョニングは、Pod が PVC を使用して作成されるまで遅延します。
10.22.2.1.2. storagePools スタンザを使用した CSI ドライバーのストレージクラスの作成
ホストパス プロビジョナー (HPP) CSI ドライバー用のストレージクラスカスタムリソース (CR) を作成します。
手順
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
10.22.2.2. PVC テンプレートで作成されたストレージプールについて
単一の大きな永続ボリューム (PV) がある場合は、ホストパスプロビジョナー (HPP) カスタムリソース (CR) で PVC テンプレートを定義することにより、ストレージプールを作成できます。
PVC テンプレートで作成されたストレージプールには、複数の HPP ボリュームを含めることができます。PV を小さなボリュームに分割すると、データ割り当ての柔軟性が向上します。
PVC テンプレートは、PersistentVolumeClaim オブジェクトの spec スタンザに基づいています。
PersistentVolumeClaim オブジェクトの例
- 1
- この値は、ブロックボリュームモードの PV にのみ必要です。
HPP CR の pvcTemplate 仕様を使用してストレージプールを定義します。Operator は、HPP CSI ドライバーを含む各ノードの pvcTemplate 仕様から PVC を作成します。PVC テンプレートから作成される PVC は単一の大きな PV を消費するため、HPP は小規模な動的ボリュームを作成できます。
基本的なストレージプールを、PVC テンプレートから作成されたストレージプールと組み合わせることができます。
10.22.2.2.1. PVC テンプレートを使用したストレージプールの作成
HPP カスタムリソース (CR) で PVC テンプレートを指定することにより、複数のホストパスプロビジョナー (HPP) ボリューム用のストレージプールを作成できます。
前提条件
-
spec.storagePools.pathで指定されたディレクトリーには、読み取り/書き込みアクセス権が必要です。 - ストレージプールは、オペレーティングシステムと同じパーティションにあってはなりません。そうしないと、オペレーティングシステムのパーティションがいっぱいになり、パフォーマンスに影響を与えたり、ノードが不安定になったり、使用できなくなったりする可能性があります。
手順
次の例に従って、
storagePoolsスタンザで永続ボリューム (PVC) テンプレートを指定する HPP CR のhpp_pvc_template_pool.yamlファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
storagePoolsスタンザは、基本ストレージプールと PVC テンプレートストレージプールの両方を含むことができるアレイです。- 2
- このノードパスの下にストレージプールディレクトリーを指定します。
- 3
- オプション:
volumeModeパラメーターは、プロビジョニングされたボリューム形式と一致する限り、BlockまたはFilesystemのいずれかにすることができます。値が指定されていない場合、デフォルトはFilesystemです。volumeModeがBlockの場合、Pod をマウントする前にブロックボリュームに XFS ファイルシステムが作成されます。 - 4
storageClassNameパラメーターを省略すると、デフォルトのストレージクラスを使用して PVC を作成します。storageClassNameを省略する場合、HPP ストレージクラスがデフォルトのストレージクラスではないことを確認してください。- 5
- 静的または動的にプロビジョニングされるストレージを指定できます。いずれの場合も、要求されたストレージサイズが仮想的に分割する必要のあるボリュームに対して適切になるようにしてください。そうしないと、PVC を大規模な PV にバインドすることができません。使用しているストレージクラスが動的にプロビジョニングされるストレージを使用する場合、典型的な要求のサイズに一致する割り当てサイズを選択します。
- ファイルを保存して終了します。
次のコマンドを実行して、ストレージ プールを使用して HPP を作成します。
oc create -f hpp_pvc_template_pool.yaml
$ oc create -f hpp_pvc_template_pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.22.3. データボリュームの作成
PVC またはストレージ API のいずれかを使用して、データボリュームを作成できます。
OpenShift Container Platform Container Storage と共に OpenShift Virtualization を使用する場合、仮想マシンディスクの作成時に RBD ブロックモードの永続ボリューム要求 (PVC) を指定します。仮想マシンディスクの場合、RBD ブロックモードのボリュームは効率的で、Ceph FS または RBD ファイルシステムモードの PVC よりも優れたパフォーマンスを提供します。
RBD ブロックモードの PVC を指定するには、'ocs-storagecluster-ceph-rbd' ストレージクラスおよび VolumeMode: Block を使用します。
可能な限り、ストレージ API を使用して、スペースの割り当てを最適化し、パフォーマンスを最大化します。
ストレージプロファイル は、CDI が管理するカスタムリソースです。関連付けられたストレージクラスに基づく推奨ストレージ設定を提供します。ストレージクラスごとにストレージクラスが割り当てられます。
ストレージプロファイルを使用すると、コーディングを減らし、潜在的なエラーを最小限に抑えながら、データボリュームをすばやく作成できます。
認識されたストレージタイプの場合、CDI は PVC の作成を最適化する値を提供します。ただし、ストレージプロファイルをカスタマイズする場合は、ストレージクラスの自動設定を行うことができます。
10.22.3.1. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.22.3.2. ストレージ API を使用したデータボリュームの作成
ストレージ API を使用してデータボリュームを作成する場合、Containerized Data Interface (CDI) は、選択したストレージクラスでサポートされるストレージのタイプに基づいて、永続ボリューム要求 (PVC) の割り当てを最適化します。データボリューム名、namespace、および割り当てるストレージの量のみを指定する必要があります。
以下に例を示します。
-
Ceph RBD を使用する場合、
accessModesはReadWriteManyに自動設定され、ライブマイグレーションが可能になります。volumeModeは、パフォーマンスを最大化するためにBlockに設定されています。 -
volumeMode: Filesystemを使用する場合、ファイルシステムのオーバーヘッドに対応する必要がある場合は、CDI が追加の領域を自動的に要求します。
以下の YAML では、ストレージ API を使用して、2 ギガバイトの使用可能な領域を持つデータボリュームを要求します。ユーザーは、必要な永続ボリューム要求 (PVC) のサイズを適切に予測するために volumeMode を把握する必要はありません。CDI は accessModes 属性と volumeMode 属性の最適な組み合わせを自動的に選択します。これらの最適値は、ストレージのタイプまたはストレージプロファイルで定義するデフォルトに基づいています。カスタム値を指定する場合は、システムで計算された値を上書きします。
DataVolume 定義の例
10.22.3.3. PVC API を使用したデータボリュームの作成
PVC API を使用してデータボリュームを作成する場合、Containerized Data Interface (CDI) は、以下のフィールドに指定する内容に基づいてデータボリュームを作成します。
-
accessModes(ReadWriteOnce、ReadWrtieMany、またはReadOnlyMany) -
volumeMode(FilesystemまたはBlock) -
storageのcapacity(例:5Gi)
以下の YAML では、PVC API を使用して、2 ギガバイトのストレージ容量を持つデータボリュームを割り当てます。ReadWriteMany のアクセスモードを指定して、ライブマイグレーションを有効にします。システムがサポートできる値がわかっているので、デフォルトの Filesystem の代わりに Block ストレージを指定します。
DataVolume 定義の例
- 1
- 新規データボリュームの名前。
- 2
sourceセクションでは、pvcはインポートのソースが既存の永続ボリューム要求 (PVC) であることを示しています。- 3
- ソース PVC が存在する namespace。
- 4
- ソース PVC の名前。
- 5
- PVC API を使用した割り当てを示します。
- 6
- PVC API を使用する場合は
accessModesが必要です。 - 7
- データボリュームに要求する領域のサイズを指定します。
- 8
- 宛先がブロック PVC であることを指定します。
- 9
- オプションで、ストレージクラスを指定します。ストレージクラスが指定されていない場合、システムデフォルトのストレージクラスが使用されます。
PVC API を使用してデータボリュームを明示的に割り当て、volumeMode: Block を使用していない場合は、ファイルシステムのオーバーヘッドを考慮してください。
ファイルシステムのオーバーヘッドは、ファイルシステムのメタデータを維持するために必要な領域のサイズです。ファイルシステムメタデータに必要な領域のサイズは、ファイルシステムに依存します。ストレージ容量要求でファイルシステムのオーバーヘッドに対応できない場合は、基礎となる永続ボリューム要求 (PVC) が仮想マシンディスクに十分に対応できない大きさとなる可能性があります。
ストレージ API を使用する場合、CDI はファイルシステムのオーバーヘッドを考慮し、割り当て要求が正常に実行されるように大きな永続ボリューム要求 (PVC) を要求します。
10.22.3.4. ストレージプロファイルのカスタマイズ
プロビジョナーのストレージクラスの StorageProfile オブジェクトを編集してデフォルトパラメーターを指定できます。これらのデフォルトパラメーターは、DataVolume オブジェクトで設定されていない場合にのみ永続ボリューム要求 (PVC) に適用されます。
前提条件
- 計画した設定がストレージクラスとそのプロバイダーでサポートされていることを確認してください。ストレージプロファイルに互換性のない設定を指定すると、ボリュームのプロビジョニングに失敗します。
ストレージプロファイルの空の status セクションは、ストレージプロビジョナーが Containerized Data Interface (CDI) によって認識されないことを示します。CDI で認識されないストレージプロビジョナーがある場合、ストレージプロファイルをカスタマイズする必要があります。この場合、管理者はストレージプロファイルに適切な値を設定し、割り当てが正常に実行されるようにします。
データボリュームを作成し、YAML 属性を省略し、これらの属性がストレージプロファイルで定義されていない場合は、要求されたストレージは割り当てられず、基礎となる永続ボリューム要求 (PVC) は作成されません。
手順
ストレージプロファイルを編集します。この例では、プロビジョナーは CDI によって認識されません。
oc edit -n openshift-cnv storageprofile <storage_class>
$ oc edit -n openshift-cnv storageprofile <storage_class>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ストレージプロファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ストレージプロファイルに必要な属性値を指定します。
ストレージプロファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変更を保存した後、選択した値がストレージプロファイルの
status要素に表示されます。
10.22.3.4.1. ストレージプロファイルを使用したデフォルトのクローンストラテジーの設定
ストレージプロファイルを使用してストレージクラスのデフォルトクローンメソッドを設定し、クローンストラテジー を作成できます。ストレージベンダーが特定のクローン作成方法のみをサポートする場合などに、クローンストラテジーを設定すると便利です。また、リソースの使用の制限やパフォーマンスの最大化を実現する手法を選択することもできます。
クローン作成ストラテジーは、ストレージプロファイルの cloneStrategy 属性を以下の値のいずれかに設定して指定できます。
-
snapshot: この方法は、スナップショットが設定されている場合にデフォルトで使用されます。このクローン作成ストラテジーは、一時的なボリュームスナップショットを使用してボリュームのクローンを作成します。ストレージプロビジョナーは CSI スナップショットをサポートする必要があります。 -
Copy: この方法では、ソース Pod およびターゲット Pod を使用して、ソースボリュームからターゲットボリュームにデータをコピーします。ホスト支援型でのクローン作成は、最も効率的な方法です。 -
csi-clone: この方法は、CSI クローン API を使用して、中間ボリュームスナップショットを使用せずに既存ボリュームのクローンを効率的に作成します。ストレージプロファイルが定義されていない場合にデフォルトで使用されるsnapshotまたはcopyとは異なり、CSI ボリュームのクローンは、プロビジョナーのストレージクラスのStorageProfileオブジェクトに指定した場合にだけ使用されます。
YAML spec セクションのデフォルトの claimPropertySets を変更せずに、CLI でクローンストラテジーを設定することもできます。
ストレージプロファイルの例
10.22.4. ファイルシステムオーバーヘッドの PVC 領域の確保
デフォルトでは、OpenShift Virtualization は、Filesystem ボリュームモードを使用する永続ボリューム要求 (PVC) のファイルシステムオーバーヘッドデータ用に領域を確保します。この目的のためにグローバルに、および特定のストレージクラス用に領域を予約する割合を設定できます。
10.22.4.1. ファイルシステムのオーバーヘッドが仮想マシンディスクの領域に影響を与える仕組み
仮想マシンディスクを Filesystem ボリュームモードを使用する永続ボリューム要求 (PVC) に追加する場合、PVC で十分な容量があることを確認する必要があります。
- 仮想マシンディスク。
- メタデータなどのファイルシステムオーバーヘッド用に予約された領域
デフォルトでは、OpenShift Virtualization は PVC 領域の 5.5% をオーバーヘッド用に予約し、その分、仮想マシンディスクに使用できる領域を縮小します。
HCO オブジェクトを編集して、別のオーバーヘッド値を設定できます。値はグローバルに変更でき、特定のストレージクラスの値を指定できます。
10.22.4.2. デフォルトのファイルシステムオーバーヘッド値の上書き
HCO オブジェクトの spec.filesystemOverhead 属性を編集することで、OpenShift Virtualization がファイルシステムオーバーヘッド用に予約する永続ボリューム要求 (PVC) 領域の量を変更します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを実行して、
HCOオブジェクトを編集用に開きます。oc edit hco -n openshift-cnv kubevirt-hyperconverged
$ oc edit hco -n openshift-cnv kubevirt-hyperconvergedCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.filesystemOverheadフィールドを編集して、選択した値でデータを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
エディターを保存して終了し、
HCOオブジェクトを更新します。
検証
次のいずれかのコマンドを実行して、
CDIConfigステータスを表示し、変更を確認します。一般的に
CDIConfigへの変更を確認するには以下を実行します。oc get cdiconfig -o yaml
$ oc get cdiconfig -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow CDIConfig に対する特定の変更を表示するには以下を実行します。oc get cdiconfig -o jsonpath='{.items..status.filesystemOverhead}'$ oc get cdiconfig -o jsonpath='{.items..status.filesystemOverhead}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.22.5. コンピュートリソースクォータを持つ namespace で機能する CDI の設定
Containerized Data Importer (CDI) を使用して、CPU およびメモリーリソースの制限が適用される namespace に仮想マシンディスクをインポートし、アップロードし、そのクローンを作成できるようになりました。
10.22.5.1. namespace の CPU およびメモリークォータについて
ResourceQuota オブジェクトで定義される リソースクォータ は、その namespace 内のリソースが消費できるコンピュートリソースの全体量を制限する制限を namespace に課します。
HyperConverged カスタムリソース (CR) は、Containerized Data Importer (CDI) のユーザー設定を定義します。CPU とメモリーの要求値と制限値は、デフォルト値の 0 に設定されています。これにより、コンピュートリソース要件を指定しない CDI によって作成される Pod にデフォルト値が付与され、クォータで制限される namespace での実行が許可されます。
10.22.5.2. CPU およびメモリーのデフォルトの上書き
HyperConverged カスタムリソース (CR) に spec.resourceRequirements.storageWorkloads スタンザを追加して、CPU およびメモリー要求のデフォルト設定とユースケースの制限を変更します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
以下のコマンドを実行して、
HyperConvergedCR を編集します。oc edit hco -n openshift-cnv kubevirt-hyperconverged
$ oc edit hco -n openshift-cnv kubevirt-hyperconvergedCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.resourceRequirements.storageWorkloadsスタンザを CR に追加し、ユースケースに基づいて値を設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
エディターを保存して終了し、
HyperConvergedCR を更新します。
10.22.6. データボリュームアノテーションの管理
データボリューム (DV) アノテーションを使用して Pod の動作を管理できます。1 つ以上のアノテーションをデータボリュームに追加してから、作成されたインポーター Pod に伝播できます。
10.22.6.1. 例: データボリュームアノテーション
以下の例は、インポーター Pod が使用するネットワークを制御するためにデータボリューム (DV) アノテーションを設定する方法を示しています。v1.multus-cni.io/default-network: bridge-network アノテーションにより、Pod は bridge-network という名前の multus ネットワークをデフォルトネットワークとして使用します。インポーター Pod にクラスターからのデフォルトネットワークとセカンダリー multus ネットワークの両方を使用させる必要がある場合は、k8s.v1.cni.cncf.io/networks: <network_name> アノテーションを使用します。
Multus ネットワークアノテーションの例
- 1
- Multus ネットワークアノテーション
10.22.7. データボリュームの事前割り当ての使用
Containerized Data Importer は、データボリュームの作成時に書き込みパフォーマンスを向上させるために、ディスク領域を事前に割り当てることができます。
特定のデータボリュームの事前割り当てを有効にできます。
10.22.7.1. 事前割り当てについて
Containerized Data Importer (CDI) は、データボリュームに QEMU 事前割り当てモードを使用し、書き込みパフォーマンスを向上できます。操作のインポートおよびアップロードには、事前割り当てモードを使用できます。また、空のデータボリュームを作成する際にも使用できます。
事前割り当てが有効化されている場合、CDI は基礎となるファイルシステムおよびデバイスタイプに応じて、より適切な事前割り当て方法を使用します。
fallocate-
ファイルシステムがこれをサポートする場合、CDI は
posix_fallocate関数を使用して領域を事前に割り当てるためにオペレーティングシステムのfallocate呼び出しを使用します。これは、ブロックを割り当て、それらを未初期化としてマークします。 full-
fallocateモードを使用できない場合は、基礎となるストレージにデータを書き込むことで、fullモードがイメージの領域を割り当てます。ストレージの場所によっては、空の割り当て領域がすべてゼロになる場合があります。
10.22.7.2. データボリュームの事前割り当ての有効化
データボリュームマニフェストに spec.preallocation フィールドを含めることにより、特定のデータボリュームの事前割り当てを有効にできます。Web コンソールで、または OpenShift CLI (oc) を使用して、事前割り当てモードを有効化することができます。
事前割り当てモードは、すべての CDI ソースタイプでサポートされます。
10.22.8. Web コンソールの使用によるローカルディスクイメージのアップロード
Web コンソールを使用して、ローカルに保存されたディスクイメージファイルをアップロードできます。
10.22.8.1. 前提条件
- 仮想マシンのイメージファイルには、IMG、ISO、または QCOW2 形式のファイルを使用する必要がある。
- CDI でサポートされる操作マトリックス に応じてスクラッチ領域が必要な場合は、この操作が正常に完了するように、まずは ストレージクラスを定義するフィルタリングCDI スクラッチ領域を用意 すること。
10.22.8.2. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
| コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
|---|---|---|---|---|---|
| KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
| KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
10.22.8.3. Web コンソールを使用したイメージファイルのアップロード
Web コンソールを使用して、イメージファイルを新規の永続ボリューム要求 (PVC) にアップロードします。この PVC を後で使用して、イメージを新規の仮想マシンに割り当てることができます。
前提条件
以下のいずれかが必要である。
- ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
- QCOW2 形式の仮想マシンのイメージファイル。
最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。
xzまたはgzipを使用して raw イメージファイルを圧縮します。注記圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。
クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。
- Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
-
Windows クライアントを使用する場合は、
xzまたはgzipを使用して QCOW2 ファイルを圧縮します。
手順
- Web コンソールのサイドメニューから、Storage → Persistent Volume Claims をクリックします。
- Create Persistent Volume Claim ドロップダウンリストをクリックし、これを拡張します。
- With Data Upload Form をクリックし、Upload Data to Persistent Volume Claim ページを開きます。
- Browse をクリックし、ファイルマネージャーを開き、アップロードするイメージを選択するか、ファイルを Drag a file here or browse to upload フィールドにドラッグします。
オプション: 特定のオペレーティングシステムのデフォルトイメージとしてこのイメージを設定します。
- Attach this data to a virtual machine operating system チェックボックスを選択します。
- リストからオペレーティングシステムを選択します。
- Persistent Volume Claim Name フィールドには、一意の名前が自動的に入力され、これを編集することはできません。PVC に割り当てられた名前をメモし、必要に応じてこれを後で特定できるようにします。
- Storage Class リストからストレージクラスを選択します。
Size フィールドに PVC のサイズ値を入力します。ドロップダウンリストから、対応する測定単位を選択します。
警告PVC サイズは圧縮解除された仮想ディスクのサイズよりも大きくなければなりません。
- 選択したストレージクラスに一致する Access Mode を選択します。
- Upload をクリックします。
10.22.9. virtctl ツールの使用によるローカルディスクイメージのアップロード
virtctl コマンドラインユーティリティーを使用して、ローカルに保存されたディスクイメージを新規または既存のデータボリュームにアップロードできます。
10.22.9.1. 前提条件
- virtctl をインストールします。
- CDI でサポートされる操作マトリックス に応じてスクラッチ領域が必要な場合は、この操作が正常に完了するように、まずは ストレージクラスを定義するフィルタリングCDI スクラッチ領域を用意 すること。
10.22.9.2. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.22.9.3. アップロードデータボリュームの作成
ローカルディスクイメージのアップロードに使用する upload データソースでデータボリュームを手動で作成できます。
手順
spec: source: upload{}を指定するデータボリューム設定を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してデータボリュームを作成します。
oc create -f <upload-datavolume>.yaml
$ oc create -f <upload-datavolume>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.22.9.4. ローカルディスクイメージのデータボリュームへのアップロード
virtctl CLI ユーティリティーを使用して、ローカルディスクイメージをクライアントマシンからクラスター内のデータボリューム (DV) にアップロードできます。この手順の実行時に、すでにクラスターに存在する DV を使用するか、新規の DV を作成することができます。
ローカルディスクイメージのアップロード後に、これを仮想マシンに追加できます。
前提条件
以下のいずれかが必要である。
- ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
- QCOW2 形式の仮想マシンのイメージファイル。
最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。
xzまたはgzipを使用して raw イメージファイルを圧縮します。注記圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。
クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。
- Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
-
Windows クライアントを使用する場合は、
xzまたはgzipを使用して QCOW2 ファイルを圧縮します。
-
kubevirt-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
10.22.9.5. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
| コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
|---|---|---|---|---|---|
| KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
| KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
10.22.10. ブロックストレージデータボリュームへのローカルディスクイメージのアップロード
virtctl コマンドラインユーティリティーを使用して、ローカルのディスクイメージをブロックデータボリュームにアップロードできます。
このワークフローでは、ローカルブロックデバイスを使用して永続ボリュームを使用し、このブロックボリュームを upload データボリュームに関連付け、 virtctl を使用してローカルディスクイメージをデータボリュームにアップロードできます。
10.22.10.1. 前提条件
- virtctl をインストールします。
- CDI でサポートされる操作マトリックス に応じてスクラッチ領域が必要な場合は、この操作が正常に完了するように、まずは ストレージクラスを定義するフィルタリングCDI スクラッチ領域を用意 すること。
10.22.10.2. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.22.10.3. ブロック永続ボリュームについて
ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。
raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block を指定してプロビジョニングされます。
10.22.10.4. ローカルブロック永続ボリュームの作成
ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック永続ボリューム (PV) を作成します。次に、このループデバイスを PV マニフェストで Block ボリュームとして参照し、これを仮想マシンイメージのブロックデバイスとして使用できます。
手順
-
ローカル PV を作成するノードに
rootとしてログインします。この手順では、node01を例に使用します。 ファイルを作成して、これを null 文字で設定し、ブロックデバイスとして使用できるようにします。以下の例では、2Gb (20 100Mb ブロック) のサイズのファイル
loop10を作成します。dd if=/dev/zero of=<loop10> bs=100M count=20
$ dd if=/dev/zero of=<loop10> bs=100M count=20Copy to Clipboard Copied! Toggle word wrap Toggle overflow loop10ファイルをループデバイスとしてマウントします。losetup </dev/loop10>d3 <loop10>
$ losetup </dev/loop10>d3 <loop10>1 2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow マウントされたループデバイスを参照する
PersistentVolumeマニフェストを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブロック PV を作成します。
oc create -f <local-block-pv10.yaml>
# oc create -f <local-block-pv10.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 直前の手順で作成された永続ボリュームのファイル名。
10.22.10.5. アップロードデータボリュームの作成
ローカルディスクイメージのアップロードに使用する upload データソースでデータボリュームを手動で作成できます。
手順
spec: source: upload{}を指定するデータボリューム設定を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してデータボリュームを作成します。
oc create -f <upload-datavolume>.yaml
$ oc create -f <upload-datavolume>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.22.10.6. ローカルディスクイメージのデータボリュームへのアップロード
virtctl CLI ユーティリティーを使用して、ローカルディスクイメージをクライアントマシンからクラスター内のデータボリューム (DV) にアップロードできます。この手順の実行時に、すでにクラスターに存在する DV を使用するか、新規の DV を作成することができます。
ローカルディスクイメージのアップロード後に、これを仮想マシンに追加できます。
前提条件
以下のいずれかが必要である。
- ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
- QCOW2 形式の仮想マシンのイメージファイル。
最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。
xzまたはgzipを使用して raw イメージファイルを圧縮します。注記圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。
クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。
- Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
-
Windows クライアントを使用する場合は、
xzまたはgzipを使用して QCOW2 ファイルを圧縮します。
-
kubevirt-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
10.22.10.7. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
| コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
|---|---|---|---|---|---|
| KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
| KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
10.22.11. 仮想マシンスナップショットの管理
仮想マシンの電源がオフ (オフライン) またはオン (オンライン) であるかに拘らず、仮想マシンの仮想マシン (VM) スナップショットを作成および削除できます。電源オフ (オフライン) 状態の仮想マシンに対してのみ復元が可能です。OpenShift Virtualization は、以下にある仮想マシンのスナップショットをサポートします。
- Red Hat OpenShift Data Foundation
- Kubernetes Volume Snapshot API をサポートする Container Storage Interface (CSI) ドライバーを使用するその他のクラウドストレージプロバイダー
オンラインスナップショットのデフォルト期限は 5 分 (5m) で、必要に応じて変更できます。
オンラインスナップショットは、ホットプラグされた仮想ディスクを持つ仮想マシンでサポートされます。ただし、仮想マシンの仕様に含まれていないホットプラグされたディスクは、スナップショットに含まれません。
整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。
QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。
10.22.11.1. 仮想マシンスナップショットについて
スナップショット は、特定の時点における仮想マシン (VM) の状態およびデータを表します。スナップショットを使用して、バックアップおよび障害復旧のために既存の仮想マシンを (スナップショットで表される) 以前の状態に復元したり、以前の開発バージョンに迅速にロールバックしたりできます。
仮想マシンのスナップショットは、電源がオフ (停止状態) またはオン (実行状態) の仮想マシンから作成されます。
実行中の仮想マシンのスナップショットを作成する場合には、コントローラーは QEMU ゲストエージェントがインストールされ、実行中であることを確認します。その場合、スナップショットを取得する前に仮想マシンファイルシステムをフリーズし、スナップショットを取得した後にファイルシステムをフリーズ解除します。
スナップショットは、仮想マシンに割り当てられた各 Container Storage Interface (CSI) ボリュームのコピーと、仮想マシンの仕様およびメタデータのコピーを保存します。スナップショットは作成後に変更できません。
仮想マシンスナップショット機能を使用すると、クラスター管理者、およびアプリケーション開発者は以下を実行できます。
- 新規 SCC の作成
- 特定の仮想マシンに割り当てられているすべてのスナップショットのリスト表示
- スナップショットからの仮想マシンの復元
- 既存の仮想マシンスナップショットの削除
10.22.11.1.1. 仮想マシンスナップショットコントローラーおよびカスタムリソース定義 (CRD)
仮想マシンスナップショット機能では、スナップショットを管理するための CRD として定義された 3 つの新規 API オブジェクトが導入されました。
-
VirtualMachineSnapshot: スナップショットを作成するユーザー要求を表します。これには、仮想マシンの現在の状態に関する情報が含まれます。 -
VirtualMachineSnapshotContent: クラスター上のプロビジョニングされたリソース (スナップショット) を表します。これは、仮想マシンのスナップショットコントローラーによって作成され、仮想マシンの復元に必要なすべてのリソースへの参照が含まれます。 -
VirtualMachineRestore: スナップショットから仮想マシンを復元するユーザー要求を表します。
仮想マシンスナップショットコントローラーは、1 対 1 のマッピングで、VirtualMachineSnapshotContent オブジェクトを、この作成に使用した VirtualMachineSnapshot オブジェクトにバインドします。
10.22.11.2. QEMU ゲストエージェントの Linux 仮想マシンへのインストール
qemu-guest-agent は広く利用されており、Red Hat 仮想マシンでデフォルトで利用できます。このエージェントをインストールし、サービスを起動します。
仮想マシン (VM) に QEMU ゲストエージェントがインストールされ、実行されているかどうかを確認するには、AgentConnected が 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
10.22.11.3. QEMU ゲストエージェントの Windows 仮想マシンへのインストール
Windows 仮想マシンの場合には、QEMU ゲストエージェントは VirtIO ドライバーに含まれます。既存または新規の Windows インストールにドライバーをインストールします。
仮想マシン (VM) に QEMU ゲストエージェントがインストールされ、実行されているかどうかを確認するには、AgentConnected が VM 仕様に表示されていることを確認します。
整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。
QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。
10.22.11.3.1. VirtIO ドライバーの既存 Windows 仮想マシンへのインストール
VirtIO ドライバーを、割り当てられた SATA CD ドライブから既存の Windows 仮想マシンにインストールします。
この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。このプロセスは Windows のバージョンごとに若干異なる可能性があります。特定のインストール手順については、お使いの Windows バージョンについてのインストールドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- 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 をクリックしてウィンドウを閉じます。
- 仮想マシンを再起動してドライバーのインストールを完了します。
10.22.11.3.2. Windows インストール時の VirtIO ドライバーのインストール
Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。
この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- Windows インストールプロセスを開始します。
- Advanced インストールを選択します。
-
ストレージの宛先は、ドライバーがロードされるまで認識されません。
Load driverをクリックします。 - ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
- 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
- Windows インストールを完了します。
10.22.11.4. Web コンソールでの仮想マシンのスナップショットの作成
Web コンソールを使用して仮想マシン (VM) を作成することができます。
整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。
QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。
仮想マシンスナップショットには、以下の要件を満たすディスクのみが含まれます。
- データボリュームまたは永続ボリューム要求 (PVC) のいずれかでなければなりません。
- Container Storage Interface (CSI) ボリュームスナップショットをサポートするストレージクラスに属している必要があります。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- 仮想マシンが実行中の場合は、Actions → Stop をクリックして電源を切ります。
- Snapshots タブをクリックしてから Take Snapshot をクリックします。
- Snapshot Name およびオプションの Description フィールドに入力します。
- Disks included in this Snapshot を拡張し、スナップショットに組み込むストレージボリュームを表示します。
- 仮想マシンにスナップショットに追加できないディスクがあり、それでも続行する場合は、I am aware of this warning and wish to proceed チェックボックスをオンにします。
- Save をクリックします。
10.22.11.5. CLI での仮想マシンのスナップショットの作成
VirtualMachineSnapshot オブジェクトを作成し、オフラインまたはオンラインの仮想マシンの仮想マシン (VM) スナップショットを作成できます。KubeVirt は QEMU ゲストエージェントと連携し、オンライン仮想マシンのスナップショットを作成します。
整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。
QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。
前提条件
- 永続ボリューム要求 (PVC) が Container Storage Interface (CSI) ボリュームスナップショットをサポートするストレージクラスにあることを確認している。
-
OpenShift CLI (
oc) がインストールされている。 - オプション: スナップショットを作成する仮想マシンの電源を切っている。
手順
YAML ファイルを作成し、新規の
VirtualMachineSnapshotの名前およびソース仮想マシンの名前を指定するVirtualMachineSnapshotオブジェトを定義します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow VirtualMachineSnapshotリソースを作成します。スナップコントローラーはVirtualMachineSnapshotContentオブジェクトを作成し、これをVirtualMachineSnapshotにバインドし、VirtualMachineSnapshotオブジェクトのstatusおよびreadyToUseフィールドを更新します。oc create -f <my-vmsnapshot>.yaml
$ oc create -f <my-vmsnapshot>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: オンラインスナップショットを作成している場合は、
waitコマンドを使用して、スナップショットのステータスを監視できます。以下のコマンドを入力します。
oc wait my-vm my-vmsnapshot --for condition=Ready
$ oc wait my-vm my-vmsnapshot --for condition=ReadyCopy to Clipboard Copied! Toggle word wrap Toggle overflow スナップショットのステータスを確認します。
-
InProgress: オンラインスナップショットの操作が進行中です。 -
Succeeded: オンラインスナップショット操作が正常に完了しました。 Failed: オンラインスナップショットの操作に失敗しました。注記オンラインスナップショットのデフォルト期限は 5 分 (
5m) です。スナップショットが 5 分後に正常に完了しない場合には、ステータスがfailedに設定されます。その後、ファイルシステムと仮想マシンのフリーズが解除され、失敗したスナップショットイメージが削除されるまで、ステータスはfailedのままになります。デフォルトの期限を変更するには、仮想マシンスナップショット仕様に
FailureDeadline属性を追加して、スナップショット操作がタイムアウトするまでの時間を分単位 (m) または秒単位 (s) で指定します。期限を指定しない場合は、
0を指定できますが、仮想マシンが応答しなくなる可能性があるため、通常は推奨していません。mまたはsなどの時間の単位を指定しない場合、デフォルトは秒 (s) です。
-
検証
VirtualMachineSnapshotオブジェクトが作成されており、VirtualMachineSnapshotContentにバインドされていることを確認します。readyToUseフラグをtrueに設定する必要があります。oc describe vmsnapshot <my-vmsnapshot>
$ oc describe vmsnapshot <my-vmsnapshot>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
VirtualMachineSnapshotContentリソースのspec:volumeBackupsプロパティーをチェックし、予想される PVC がスナップショットに含まれることを確認します。
10.22.11.6. スナップショット指示を使用したオンラインスナップショット作成の確認
スナップショットの表示は、オンライン仮想マシン (VM) スナップショット操作に関するコンテキスト情報です。オフラインの仮想マシン (VM) スナップショット操作では、指示は利用できません。イベントは、オンラインスナップショット作成の詳説する際に役立ちます。
前提条件
- 指示を表示するには、CLI または Web コンソールを使用してオンライン仮想マシンスナップショットの作成を試行する必要があります。
手順
以下のいずれかを実行して、スナップショット指示からの出力を表示します。
-
CLI で作成されたスナップショットの場合には、status フィールドの
VirtualMachineSnapshotオブジェクト YAML にあるインジケーターの出力を確認します。 - Web コンソールを使用して作成されたスナップショットの場合には、Snapshot details 画面で VirtualMachineSnapshot > Status をクリックします。
-
CLI で作成されたスナップショットの場合には、status フィールドの
オンライン仮想マシンのスナップショットのステータスを確認します。
-
Onlineは、仮想マシンがオンラインスナップショットの作成時に実行されていることを示します。 -
NoGuestAgentは、QEMU ゲストエージェントがオンラインのスナップショットの作成時に実行されていないことを示します。QEMU ゲストエージェントがインストールされていないか、実行されていないか、別のエラーが原因で、QEMU ゲストエージェントを使用してファイルシステムをフリーズしてフリーズを解除できませんでした。
-
10.22.11.7. Web コンソールでのスナップショットからの仮想マシンの復元
仮想マシン (VM) は、Web コンソールのスナップショットで表される以前の設定に復元できます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- 仮想マシンが実行中の場合は、Actions → Stop をクリックして電源を切ります。
- Snapshots タブをクリックします。このページには、仮想マシンに関連付けられたスナップショットのリストが表示されます。
仮想マシンのスナップショットを復元するには、以下のいずれかの方法を選択します。
- 仮想マシンを復元する際にソースとして使用するスナップショットの場合は、Restore をクリックします。
- スナップショットを選択して Snapshot Details 画面を開き、Actions → Restore VirtualMachineSnapshot をクリックします。
- 確認のポップアップウィンドウで Restore をクリックし、仮想マシンをスナップショットで表される以前の設定に戻します。
10.22.11.8. CLI でのスナップショットからの仮想マシンの復元
仮想マシンスナップショットを使用して、既存の仮想マシン (VM) を以前の設定に復元できます。オフラインの仮想マシンスナップショットからしか復元できません。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - 以前の状態に復元する仮想マシンの電源を切ること。
手順
復元する仮想マシンの名前およびソースとして使用されるスナップショットの名前を指定する
VirtualMachineRestoreオブジェクトを定義するために YAML ファイルを作成します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow VirtualMachineRestoreリソースを作成します。スナップショットコントローラーは、VirtualMachineRestoreオブジェクトのステータスフィールドを更新し、既存の仮想マシン設定をスナップショットのコンテンツに置き換えます。oc create -f <my-vmrestore>.yaml
$ oc create -f <my-vmrestore>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
仮想マシンがスナップショットで表される以前の状態に復元されていることを確認します。
completeフラグはtrueに設定される必要があります。oc get vmrestore <my-vmrestore>
$ oc get vmrestore <my-vmrestore>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.22.11.9. Web コンソールでの仮想マシンのスナップショットの削除
Web コンソールを使用して既存の仮想マシンスナップショットを削除できます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Snapshots タブをクリックします。このページには、仮想マシンに関連付けられたスナップショットの一覧が表示されます。
-
削除する仮想マシンスナップショットの Options メニュー
をクリックして、Delete VirtualMachineSnapshot を選択します。
- 確認のポップアップウィンドウで、Delete をクリックしてスナップショットを削除します。
10.22.11.10. CLI での仮想マシンのスナップショットの削除
適切な VirtualMachineSnapshot オブジェクトを削除して、既存の仮想マシン (VM) スナップショットを削除できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
VirtualMachineSnapshotオブジェクトを削除します。スナップショットコントローラーは、VirtualMachineSnapshotを、関連付けられたVirtualMachineSnapshotContentオブジェクトと共に削除します。oc delete vmsnapshot <my-vmsnapshot>
$ oc delete vmsnapshot <my-vmsnapshot>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
スナップショットが削除され、この仮想マシンに割り当てられていないことを確認します。
oc get vmsnapshot
$ oc get vmsnapshotCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.22.12. ローカル仮想マシンディスクの別のノードへの移動
ローカルボリュームストレージを使用する仮想マシンは、特定のノードで実行されるように移動することができます。
以下の理由により、仮想マシンを特定のノードに移動する場合があります。
- 現在のノードにローカルストレージ設定に関する制限がある。
- 新規ノードがその仮想マシンのワークロードに対して最適化されている。
ローカルストレージを使用する仮想マシンを移行するには、データボリュームを使用して基礎となるボリュームのクローンを作成する必要があります。クローン操作が完了したら、新規データボリュームを使用できるように 仮想マシン設定を編集 するフィルタリング新規データボリュームを別の仮想マシンに追加 することができます。
事前割り当てをグローバルに有効にする場合や、単一データボリュームについて、Containerized Data Importer (CDI) はクローン時にディスク領域を事前に割り当てます。事前割り当てにより、書き込みパフォーマンスが向上します。詳細は、データボリュームについての事前割り当ての使用 を参照してください。
cluster-admin ロールのないユーザーには、複数の namespace 間でボリュームのクローンを作成できるように 追加のユーザーパーミッション が必要になります。
10.22.12.1. ローカルボリュームの別のノードへのクローン作成
基礎となる永続ボリューム要求 (PVC) のクローンを作成して、仮想マシンディスクを特定のノードで実行するように移行することができます。
仮想マシンディスクのノードが適切なノードに作成されることを確認するには、新規の永続ボリューム (PV) を作成するか、該当するノードでそれを特定します。一意のラベルを PV に適用し、これがデータボリュームで参照できるようにします。
宛先 PV のサイズはソース PVC と同じか、それよりも大きくなければなりません。宛先 PV がソース PVC よりも小さい場合、クローン作成操作は失敗します。
前提条件
- 仮想マシンが実行されていないこと。仮想マシンディスクのクローンを作成する前に、仮想マシンの電源を切ります。
手順
ノードに新規のローカル PV を作成するか、ノードにすでに存在しているローカル PV を特定します。
nodeAffinity.nodeSelectorTermsパラメーターを含むローカル PV を作成します。以下のマニフェストは、node01に10Giのローカル PV を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ターゲットノードに存在する PV を特定します。設定の
nodeAffinityフィールドを確認して、PV がプロビジョニングされるノードを特定することができます。oc get pv <destination-pv> -o yaml
$ oc get pv <destination-pv> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のスニペットは、PV が
node01にあることを示しています。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
PV に一意のラベルを追加します。
oc label pv <destination-pv> node=node01
$ oc label pv <destination-pv> node=node01Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下を参照するデータボリュームマニフェストを作成します。
データボリュームマニフェストをクラスターに適用してクローン作成の操作を開始します。
oc apply -f <clone-datavolume.yaml>
$ oc apply -f <clone-datavolume.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
データボリュームは、仮想マシンの PVC のクローンを特定のノード上の PV に作成します。
10.22.13. 空のディスクイメージを追加して仮想ストレージを拡張する
空のディスクイメージを OpenShift Virtualization に追加することによって、ストレージ容量を拡張したり、新規のデータパーティションを作成したりできます。
10.22.13.1. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.22.13.2. データボリュームを使用した空のディスクイメージの作成
データボリューム設定ファイルをカスタマイズし、デプロイすることにより、新規の空のディスクイメージを永続ボリューム要求 (PVC) に作成することができます。
前提条件
- 1 つ以上の利用可能な永続ボリュームがあること。
-
OpenShift CLI (
oc) がインストールされている。
手順
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
10.22.14. smart-cloning を使用したデータボリュームのクローン作成
スマートクローニングは、Red Hat OpenShift Data Foundation の組み込み機能です。スマートクローニングは、ホストアシストクローニングよりも高速で効率的です。
smart-cloning を有効にするためにアクションを実行する必要はありませんが、この機能を使用するには、ストレージ環境が smart-cloning と互換性があることを確認する必要があります。
永続ボリューム要求 (PVC) ソースでデータボリュームを作成すると、クローン作成プロセスが自動的に開始します。お使いの環境で smart-cloning をサポートするかどうかにかかわらず、データボリュームのクローンは常に受信できます。ただし、ストレージプロバイダーが smart-cloning に対応している場合、smart-cloning によるパフォーマンス上のメリットが得られます。
10.22.14.1. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.22.14.2. smart-cloning について
データボリュームに smart-cloning が実行された場合、以下が発生します。
- ソースの永続ボリューム要求 (PVC) のスナップショットが作成されます。
- PVC はスナップショットから作成されます。
- スナップショットは削除されます。
10.22.14.3. データボリュームのクローン作成
前提条件
smart-cloning が実行されるには、以下の条件が必要です。
- ストレージプロバイダーはスナップショットをサポートする必要がある。
- ソースおよびターゲット PVC は、同じストレージクラスに定義される必要がある。
- ソースおよびターゲット PVC は同じ volumeMode を共有します。
-
VolumeSnapshotClassオブジェクトは、ソースおよびターゲット PVC の両方に定義されるストレージクラスを参照する必要がある。
手順
データボリュームのクローン作成を開始するには、以下を実行します。
新規データボリュームの名前およびソース PVC の名前と namespace 指定する
DataVolumeオブジェクトの YAML ファイルを作成します。この例では、ストレージ API を指定しているため、accessModes または volumeMode を指定する必要はありません。最適な値は、自動的に計算されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow データボリュームを作成して PVC のクローン作成を開始します。
oc create -f <cloner-datavolume>.yaml
$ oc create -f <cloner-datavolume>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。
10.22.15. ブートソースの作成および使用
ブートソースには、ブート可能なオペレーティングシステム (OS) とドライバーなどの OS のすべての設定が含まれます。
ブートソースを使用して、特定の設定で仮想マシンテンプレートを作成します。これらのテンプレートを使用して、利用可能な仮想マシンを多数作成することができます。
カスタムブートソースの作成、ブートソースのアップロード、およびその他のタスクを支援するために、OpenShift Container Platform Web コンソールでクイックスタートツアーを利用できます。Help メニューから Quick Starts を選択して、クイックスタートツアーを表示します。
10.22.15.1. 仮想マシンおよびブートソースについて
仮想マシンは、仮想マシン定義と、データボリュームでサポートされる 1 つ以上のディスクで設定されます。仮想マシンテンプレートを使用すると、事前定義された仮想マシン仕様を使用して仮想マシンを作成できます。
すべての仮想マシンテンプレートには、設定されたドライバーを含む完全に設定された仮想マシンディスクイメージであるブートソースが必要です。それぞれの仮想マシンテンプレートには、ブートソースへのポインターを含む仮想マシン定義が含まれます。各ブートソースには、事前に定義された名前および namespace があります。オペレーティングシステムによっては、ブートソースは自動的に提供されます。これが提供されない場合、管理者はカスタムブートソースを準備する必要があります。
提供されたブート ソースは、オペレーティングシステムの最新バージョンに自動的に更新されます。自動更新されたブートソースの場合、クラスターのデフォルトのストレージクラスを使用して、永続ボリューム要求 (PVC) が作成されます。設定後に別のデフォルトのストレージクラスを選択した場合は、以前のデフォルトのストレージクラスで設定されたクラスター namespace 内の既存のデータボリュームを削除する必要があります。
ブートソース機能を使用するには、OpenShift Virtualization の最新リリースをインストールします。namespace の openshift-virtualization-os-images はこの機能を有効にし、OpenShift Virtualization Operator でインストールされます。ブートソース機能をインストールしたら、ブートソースを作成してそれらをテンプレートに割り当て、テンプレートから仮想マシンを作成できます。
ローカルファイルのアップロード、既存 PVC のクローン作成、レジストリーからのインポート、または URL を使用して設定される永続ボリューム要求 (PVC) を使用してブートソースを定義します。Web コンソールを使用して、ブートソースを仮想マシンテンプレートに割り当てます。ブートソースが仮想マシンテンプレートに割り当てられた後に、テンプレートを使用して任意の数の完全に設定済みの準備状態の仮想マシンを作成できます。
10.22.15.2. RHEL イメージをブート ソースとしてインポートする
イメージの URL を指定して、Red Hat Enterprise Linux (RHEL) イメージをブートソースとしてインポートできます。
前提条件
- オペレーティングシステムイメージを含む Web ページにアクセスできる必要があります。例: イメージを含む Red Hat Enterprise Linux Web ページをダウンロードします。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → Templates をクリックします。
- ブートソースを設定する必要のある仮想マシンテンプレートを特定し、Add source をクリックします。
- Add boot source to template ウィンドウで、Boot source type リストから URL (creates PVC) を選択します。
- RHEL download page をクリックして Red Hat カスタマーポータルにアクセスします。利用可能なインストーラーおよびイメージのリストは、Red Hat Enterprise Linux のダウンロードページに表示されます。
- ダウンロードする Red Hat Enterprise Linux KVM ゲストイメージを特定します。Download Now を右クリックして、イメージの URL をコピーします。
- Add boot source to template ウィンドウで、URL を Import URL フィールドに貼り付け、Save and import をクリックします。
検証
- テンプレートの テンプレート ページの ブートソース 列に緑色のチェックマークが表示されていることを確認します。
このテンプレートを使用して RHEL 仮想マシンを作成できます。
10.22.15.3. 仮想マシンテンプレートのブートソースの追加
ブートソースは、仮想マシンの作成に使用するすべての仮想マシンテンプレートまたはカスタムテンプレートに設定できます。仮想マシンテンプレートがブートソースを使用して設定されている場合、それらには Templates ページで Source available というラベルが付けられます。ブートソースをテンプレートに追加した後に、テンプレートから新規仮想マシンを作成できます。
Web コンソールでブートソースを選択および追加する方法は 4 つあります。
- ローカルファイルのアップロード (PVC の作成)
- URL (PVC を作成)
- クローン (PVC を作成)
- レジストリー (PVC を作成)
前提条件
-
ブートソースを追加するには、
os-images.kubevirt.io:editRBAC ロールを持つユーザー、または管理者としてログインしていること。ブートソースが追加されたテンプレートから仮想マシンを作成するには、特別な権限は必要ありません。 - ローカルファイルをアップロードするには、オペレーティングシステムのイメージファイルがローカルマシンに存在している必要がある。
- URL を使用してインポートするには、オペレーティングシステムイメージのある Web サーバーへのアクセスが必要である。例: イメージが含まれる Red Hat Enterprise Linux Web ページ。
- 既存の PVC のクローンを作成するには、PVC を含むプロジェクトへのアクセスが必要である。
- レジストリーを使用してインポートするには、コンテナーレジストリーへのアクセスが必要である。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → Templates をクリックします。
- テンプレートの横にある Options メニューをクリックし、Edit boot source を選択します。
- ディスクの追加をクリックします。
- Add disk ウィンドウで、Use this disk as a boot source を選択します。
- ディスク名を入力し、Source を選択します。たとえば、Blank (creates PVC) または Use an existing PVC を選択します。
- Persistent Volume Claim size の値を入力し、圧縮解除されたイメージおよび必要な追加の領域に十分な PVC サイズを指定します。
- Type を選択します (Disk または CD-ROM など)。
オプション: Storage class をクリックし、ディスクを作成するために使用されるストレージクラスを選択します。通常、このストレージクラスはすべての PVC で使用するために作成されるデフォルトのストレージクラスです。
注記提供されたブート ソースは、オペレーティングシステムの最新バージョンに自動的に更新されます。自動更新されたブートソースの場合、クラスターのデフォルトのストレージクラスを使用して、永続ボリューム要求 (PVC) が作成されます。設定後に別のデフォルトのストレージクラスを選択した場合は、以前のデフォルトのストレージクラスで設定されたクラスター namespace 内の既存のデータボリュームを削除する必要があります。
- オプション: Apply optimized StorageProfile settings をオフにして、アクセスモードまたはボリュームモードを編集します。
ブートソースを保存する適切な方法を選択します。
- ローカルファイルをアップロードしている場合に、Save and upload をクリックします。
- URL またはレジストリーからコンテンツをインポートしている場合は、Save and import をクリックします。
- 既存の PVC のクローンを作成している場合は、Save and clone をクリックします。
ブートソースを含むカスタム仮想マシンテンプレートが Catalog ページにリスト表示されています。このテンプレートを使用して仮想マシンを作成できます。
10.22.15.4. ブートソースが割り当てられたテンプレートからの仮想マシンの作成
ブートソースをテンプレートに追加した後に、テンプレートから仮想マシンを作成できます。
手順
- Open Shift Container Platform Web コンソールのサイドメニューで、Virtualization → Catalog をクリックします。
- 更新されたテンプレートを選択し、Quick create VirtualMachine をクリックします。
VirtualMachine details が、Starting のステータスで表示されます。
10.22.16. 仮想ディスクのホットプラグ
仮想マシン (VM) または仮想マシンインスタンス (VMI) を停止することなく、仮想ディスクを追加または削除できます。
10.22.16.1. 仮想ディスクのホットプラグについて
仮想ディスクを ホットプラグ すると、仮想マシンの実行中に仮想ディスクを仮想マシンインスタンスに割り当てることができます。
仮想ディスクを ホットアンプラグ すると、仮想マシンの実行中に仮想ディスクの割り当てを仮想マシンインスタンスから解除できます。
データボリュームおよび永続ボリューム要求 (PVC) のみをホットプラグおよびホットアンプラグできます。コンテナーディスクのホットプラグおよびホットアンプラグはできません。
仮想ディスクをホットプラグした後は、仮想マシンを再起動しても、解除するまで接続されたままになります。
10.22.16.2. virtio-scsi について
OpenShift Virtualization では、ホットプラグされたディスクが SCSI バスを使用できるように、各仮想マシン (VM) に virtio-scsi コントローラーがあります。virtio-scsi コントローラーは、パフォーマンス上の利点を維持しながら、virtio の制限を克服します。スケーラビリティが高く、400 万台を超えるディスクのホットプラグをサポートします。
通常の virtio は、スケーラブルではないため、ホットプラグされたディスクでは使用できません。各 virtio ディスクは、VM 内の制限された PCI Express (PCIe) スロットの 1 つを使用します。PCIe スロットは他のデバイスでも使用され、事前に予約する必要があるため、オンデマンドでスロットを利用できない場合があります。
10.22.16.3. CLI を使用した仮想ディスクのホットプラグ
仮想マシンの実行中に仮想マシンインスタンス (VMI) に割り当てる必要のある仮想ディスクをホットプラグします。
前提条件
- 仮想ディスクをホットプラグするために実行中の仮想マシンが必要です。
- ホットプラグ用に 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 の名前に設定されます。
-
オプションの
10.22.16.4. CLI を使用した仮想ディスクのホットアンプラグ
仮想マシンの実行中に仮想マシンインスタンス (VMI) から割り当てを解除する必要のある仮想ディスクをホットアンプラグします。
前提条件
- 仮想マシンが実行中である必要があります。
- 1 つ以上のデータボリュームまたは永続ボリューム要求 (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
10.22.16.5. Web コンソールを使用した仮想ディスクのホットプラグ
仮想マシンの実行中に仮想マシンインスタンス (VMI) に割り当てる必要のある仮想ディスクをホットプラグします。仮想ディスクをホットプラグすると、ホットアンプラグするまで VMI に接続されたままになります。
前提条件
- 仮想ディスクをホットプラグするために実行中の仮想マシンが必要です。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想ディスクをホットプラグする実行中の仮想マシンを選択します。
- VirtualMachine details ページで、Disks タブをクリックします。
- ディスクの追加をクリックします。
- Add disk (hot plugged) ウィンドウで、ホットプラグする仮想ディスクの情報を入力します。
- Save をクリックします。
10.22.16.6. Web コンソールを使用した仮想ディスクのホットアンプラグ
仮想マシンの実行中に仮想マシンインスタンス (VMI) から割り当てを解除する必要のある仮想ディスクをホットアンプラグします。
前提条件
- 仮想マシンが実行中で、ホットプラグされたディスクが接続されている必要があります。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- ホットアンプラグするディスクを含む実行中の仮想マシンを選択して、VirtualMachine details ページを開きます。
-
Disks タブで、ホットアンプラグする仮想ディスクの Options メニュー
をクリックします。
- Detach をクリックします。
10.22.17. 仮想マシンでのコンテナーディスクの使用
仮想マシンイメージをコンテナーディスクにビルドし、これをコンテナーレジストリーに保存することができます。次に、コンテナーディスクを仮想マシンの永続ストレージにインポートしたり、一時ストレージの仮想マシンに直接割り当てたりすることができます。
大規模なコンテナーディスクを使用する場合、I/O トラフィックが増え、ワーカーノードに影響を与える可能性があります。これにより、ノードが利用できなくなる可能性があります。この問題を解決するには、以下を実行します。
10.22.17.1. コンテナーディスクについて
コンテナーディスクは、コンテナーイメージレジストリーにコンテナーイメージとして保存される仮想マシンのイメージです。コンテナーディスクを使用して、同じディスクイメージを複数の仮想マシンに配信し、多数の仮想マシンのクローンを作成することができます。
コンテナーディスクは、仮想マシンに割り当てられるデータボリュームを使用して永続ボリューム要求 (PVC) にインポートするか、一時 containerDisk ボリュームとして仮想マシンに直接割り当てることができます。
10.22.17.1.1. データボリュームの使用によるコンテナーディスクの PVC へのインポート
Containerized Data Importer (CDI) を使用し、データボリュームを使用してコンテナーディスクを PVC にインポートします。次に、データボリュームを永続ストレージの仮想マシンに割り当てることができます。
10.22.17.1.2. コンテナーディスクの containerDisk ボリュームとしての仮想マシンへの割り当て
containerDisk ボリュームは一時的なボリュームです。これは、仮想マシンが停止されるか、再起動するか、削除される際に破棄されます。containerDisk ボリュームを持つ仮想マシンが起動すると、コンテナーイメージはレジストリーからプルされ、仮想マシンをホストするノードでホストされます。
containerDisk ボリュームは、CD-ROM などの読み取り専用ファイルシステム用に、または破棄可能な仮想マシン用に使用します。
データはホストノードのローカルストレージに一時的に書き込まれるため、読み取り/書き込みファイルシステムに containerDisk ボリュームを使用することは推奨されません。これにより、データを移行先ノードに移行する必要があるため、ノードのメンテナンス時など、仮想マシンのライブマイグレーションが遅くなります。さらに、ノードの電源が切れた場合や、予期せずにシャットダウンする場合にすべてのデータが失われます。
10.22.17.2. 仮想マシン用のコンテナーディスクの準備
仮想マシンイメージでコンテナーディスクをビルドし、これを仮想マシンで使用する前にこれをコンテナーレジストリーにプッシュする必要があります。次に、データボリュームを使用してコンテナーディスクを PVC にインポートし、これを仮想マシンに割り当てるか、コンテナーディスクを一時的な containerDisk ボリュームとして仮想マシンに直接割り当てることができます。
コンテナーディスク内のディスクイメージのサイズは、コンテナーディスクがホストされるレジストリーの最大レイヤーサイズによって制限されます。
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
コンテナーレジストリーに TLS がない場合は、コンテナーディスクを永続ストレージにインポートする前に非セキュアなレジストリーとしてこれを追加する必要があります。
10.22.17.3. 非セキュアなレジストリーとして使用するコンテナーレジストリーの TLS の無効化
HyperConverged カスタムリソースの insecureRegistries フィールドを編集して、1 つ以上のコンテナーレジストリーの TLS(トランスポート層セキュリティー) を無効にできます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにログインすること。
手順
HyperConvergedカスタムリソースを編集し、非セキュアなレジストリーの一覧をspec.storageImport.insecureRegistriesフィールドに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このリストのサンプルを、有効なレジストリーホスト名に置き換えます。
10.22.17.4. 次のステップ
- コンテナーディスクを仮想マシンの永続ストレージにインポート します。
-
一時ストレージの
containerDiskボリュームを使用する 仮想マシンを作成 します。
10.22.18. CDI のスクラッチ領域の用意
10.22.18.1. データボリュームについて
DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplateフィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.22.18.2. スクラッチ領域について
Containerized Data Importer (CDI) では、仮想マシンイメージのインポートやアップロードなどの、一部の操作を実行するためにスクラッチ領域 (一時ストレージ) が必要になります。このプロセスで、CDI は、宛先データボリューム (DV) をサポートする PVC のサイズと同じサイズのスクラッチ領域 PVC をプロビジョニングします。スクラッチ領域 PVC は操作の完了または中止後に削除されます。
HyperConverged カスタムリソースの spec.scratchSpaceStorageClass フィールドで、スクラッチ領域 PVC をバインドするために使用されるストレージクラスを定義できます。
定義されたストレージクラスがクラスターのストレージクラスに一致しない場合、クラスターに定義されたデフォルトのストレージクラスが使用されます。クラスターで定義されたデフォルトのストレージクラスがない場合、元の DV または PVC のプロビジョニングに使用されるストレージクラスが使用されます。
CDI では、元のデータボリュームをサポートする PVC の種類を問わず、file ボリュームモードが設定されているスクラッチ領域が必要です。元の PVC が block ボリュームモードでサポートされる場合、file ボリュームモード PVC をプロビジョニングできるストレージクラスを定義する必要があります。
手動プロビジョニング
ストレージクラスがない場合、CDI はイメージのサイズ要件に一致するプロジェクトの PVC を使用します。これらの要件に一致する PVC がない場合、CDI インポート Pod は適切な PVC が利用可能になるまで、またはタイムアウト機能が Pod を強制終了するまで Pending 状態になります。
10.22.18.3. スクラッチ領域を必要とする CDI 操作
| 型 | 理由 |
|---|---|
| レジストリーのインポート | CDI はイメージをスクラッチ領域にダウンロードし、イメージファイルを見つけるためにレイヤーを抽出する必要があります。その後、raw ディスクに変換するためにイメージファイルが QEMU-IMG に渡されます。 |
| イメージのアップロード | QEMU-IMG は STDIN の入力を受け入れません。代わりに、アップロードするイメージは、変換のために QEMU-IMG に渡される前にスクラッチ領域に保存されます。 |
| アーカイブされたイメージの HTTP インポート | QEMU-IMG は、CDI がサポートするアーカイブ形式の処理方法を認識しません。イメージが QEMU-IMG に渡される前にアーカイブは解除され、スクラッチ領域に保存されます。 |
| 認証されたイメージの HTTP インポート | QEMU-IMG が認証を適切に処理しません。イメージが QEMU-IMG に渡される前にスクラッチ領域に保存され、認証されます。 |
| カスタム証明書の HTTP インポート | QEMU-IMG は HTTPS エンドポイントのカスタム証明書を適切に処理しません。代わりに CDI は、ファイルを QEMU-IMG に渡す前にイメージをスクラッチ領域にダウンロードします。 |
10.22.18.4. ストレージクラスの定義
spec.scratchSpaceStorageClass フィールドを HyperConverged カスタムリソース (CR) に追加することにより、スクラッチ領域を割り当てる際に、Containerized Data Importer (CDI) が使用するストレージクラスを定義できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
以下のコマンドを実行して、
HyperConvergedCR を編集します。oc edit hco -n openshift-cnv kubevirt-hyperconverged
$ oc edit hco -n openshift-cnv kubevirt-hyperconvergedCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.scratchSpaceStorageClassフィールドを CR に追加し、値をクラスターに存在するストレージクラスの名前に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ストレージクラスを指定しない場合、CDI は設定されている永続ボリューム要求のストレージクラスを使用します。
-
デフォルトのエディターを保存して終了し、
HyperConvergedCR を更新します。
10.22.18.5. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
| コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
|---|---|---|---|---|---|
| KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
| KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
10.22.19. 永続ボリュームの再利用
静的にプロビジョニングされた永続ボリューム (PV) を再利用するには、まずボリュームを回収する必要があります。これには、ストレージ設定を再利用できるように PV を削除する必要があります。
10.22.19.1. 静的にプロビジョニングされた永続ボリュームの回収について
永続ボリューム (PV) を回収する場合、PV のバインドを永続ボリューム要求 (PVC) から解除し、PV を削除します。基礎となるストレージによっては、共有ストレージを手動で削除する必要がある場合があります。
次に、PV 設定を再利用し、異なる名前の PV を作成できます。
静的にプロビジョニングされる PV には、回収に Retain の回収 (reclaim) ポリシーが必要です。これがない場合、PV は PVC が PV からのバインド解除時に failed 状態になります。
Recycle 回収ポリシーは OpenShift Container Platform 4 では非推奨となっています。
10.22.19.2. 静的にプロビジョニングされた永続ボリュームの回収
永続ボリューム要求 (PVC) のバインドを解除し、PV を削除して静的にプロビジョニングされた永続ボリューム (PV) を回収します。共有ストレージを手動で削除する必要がある場合もあります。
静的にプロビジョニングされる PV の回収方法は、基礎となるストレージによって異なります。この手順では、ストレージに応じてカスタマイズする必要がある可能性のある一般的な方法を示します。
手順
PV の回収ポリシーが
Retainに設定されていることを確認します。PV の回収ポリシーを確認します。
oc get pv <pv_name> -o yaml | grep 'persistentVolumeReclaimPolicy'
$ oc get pv <pv_name> -o yaml | grep 'persistentVolumeReclaimPolicy'Copy to Clipboard Copied! Toggle word wrap Toggle overflow persistentVolumeReclaimPolicyがRetainに設定されていない場合、以下のコマンドで回収ポリシーを編集します。oc patch pv <pv_name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'$ oc patch pv <pv_name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
PV を使用しているリソースがないことを確認します。
oc describe pvc <pvc_name> | grep 'Mounted By:'
$ oc describe pvc <pvc_name> | grep 'Mounted By:'Copy to Clipboard Copied! Toggle word wrap Toggle overflow PVC を使用するリソースをすべて削除してから継続します。
PVC を削除して PV を解放します。
oc delete pvc <pvc_name>
$ oc delete pvc <pvc_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: PV 設定を YAML ファイルにエクスポートします。この手順の後半で共有ストレージを手動で削除する場合は、この設定を参照してください。このファイルで
specパラメーターをベースとして使用し、PV の回収後に同じストレージ設定で新規 PV を作成することもできます。oc get pv <pv_name> -o yaml > <file_name>.yaml
$ oc get pv <pv_name> -o yaml > <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow PV を削除します。
oc delete pv <pv_name>
$ oc delete pv <pv_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ストレージタイプによっては、共有ストレージフォルダーの内容を削除する必要がある場合があります。
rm -rf <path_to_share_storage>
$ rm -rf <path_to_share_storage>Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 削除された PV と同じストレージ設定を使用する PV を作成します。回収された PV 設定をすでにエクスポートしている場合、そのファイルの
specパラメーターを新規 PV マニフェストのベースとして使用することができます。注記競合の可能性を回避するには、新規 PV オブジェクトに削除されたものとは異なる名前を割り当てることが推奨されます。
oc create -f <new_pv_name>.yaml
$ oc create -f <new_pv_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.22.20. 仮想マシンディスクの拡張
仮想マシン (VM) のディスクのサイズを拡大して、ストレージ容量を増やすには、ディスクの永続ボリューム要求 (PVC) のサイズを変更します。
ただし、仮想マシンディスクのサイズを縮小することはできません。
10.22.20.1. 仮想マシンディスクの拡張
仮想マシンディスクの拡大により、仮想マシンに対して追加の領域が利用可能になります。ただし、仮想マシンの所有者は、ストレージの使用方法を決定する必要があります。
ディスクが Filesystem PVC の場合、一致するファイルは、ファイルシステムのオーバーヘッド用に一部の領域を確保しながら残りのサイズに拡張します。
手順
拡張する必要のある仮想マシンディスクの
PersistentVolumeClaimマニフェストを編集します。oc edit pvc <pvc_name>
$ oc edit pvc <pvc_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.resource.requests.storage属性の値を大きなサイズに変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 拡張できる仮想マシンのディスクサイズ
第11章 仮想マシンテンプレート
11.1. 仮想マシンテンプレートの作成
11.1.1. 仮想マシンテンプレートについて
事前設定された Red Hat 仮想マシンテンプレートは、Virtualization → Templates ページにリスト表示されます。このテンプレートは、Red Hat Enterprise Linux、Fedora、Microsoft Windows 10、および Microsoft Windows Server の異なるバージョンで利用できます。各 Red Hat 仮想マシンテンプレートは、オペレーティングシステムイメージ、オペレーティングシステム、フレーバー (CPU およびメモリー)、およびワークロードタイプ (サーバー) のデフォルト設定で事前に設定されます。
Templates ページには、4 種類の仮想マシンテンプレートが表示されます。
- Red Hat でサポートされる テンプレートは、Red Hat によって完全にサポートされています。
- ユーザーがサポート するテンプレートは、ユーザーがクローンして作成した Red Hat でサポートされる テンプレートです。
- Red Hat が提供する テンプレートには、Red Hat の制限されたサポートがあります。
- User Provided テンプレートは、ユーザーがクローンして作成した Red Hat Provided テンプレートです。
テンプレートカタログのフィルターを使用して、ブート ソースの可用性、オペレーティングシステム、ワークロードなどの属性でテンプレートを並べ替えることができます。
Red Hat が サポートするテンプレートまたは Red Hat が提供するテンプレートを編集または削除することはできません。テンプレートのクローンを作成し、カスタム仮想マシンテンプレートとして保存してから編集できます。
YAML ファイルの例を編集して、カスタム仮想マシンテンプレートを作成することもできます。
11.1.2. 仮想マシンおよびブートソースについて
仮想マシンは、仮想マシン定義と、データボリュームでサポートされる 1 つ以上のディスクで設定されます。仮想マシンテンプレートを使用すると、事前定義された仮想マシン仕様を使用して仮想マシンを作成できます。
すべての仮想マシンテンプレートには、設定されたドライバーを含む完全に設定された仮想マシンディスクイメージであるブートソースが必要です。それぞれの仮想マシンテンプレートには、ブートソースへのポインターを含む仮想マシン定義が含まれます。各ブートソースには、事前に定義された名前および namespace があります。オペレーティングシステムによっては、ブートソースは自動的に提供されます。これが提供されない場合、管理者はカスタムブートソースを準備する必要があります。
提供されたブート ソースは、オペレーティングシステムの最新バージョンに自動的に更新されます。自動更新されたブートソースの場合、クラスターのデフォルトのストレージクラスを使用して、永続ボリューム要求 (PVC) が作成されます。設定後に別のデフォルトのストレージクラスを選択した場合は、以前のデフォルトのストレージクラスで設定されたクラスター namespace 内の既存のデータボリュームを削除する必要があります。
ブートソース機能を使用するには、OpenShift Virtualization の最新リリースをインストールします。namespace の openshift-virtualization-os-images はこの機能を有効にし、OpenShift Virtualization Operator でインストールされます。ブートソース機能をインストールしたら、ブートソースを作成してそれらをテンプレートに割り当て、テンプレートから仮想マシンを作成できます。
ローカルファイルのアップロード、既存 PVC のクローン作成、レジストリーからのインポート、または URL を使用して設定される永続ボリューム要求 (PVC) を使用してブートソースを定義します。Web コンソールを使用して、ブートソースを仮想マシンテンプレートに割り当てます。ブートソースが仮想マシンテンプレートに割り当てられた後に、テンプレートを使用して任意の数の完全に設定済みの準備状態の仮想マシンを作成できます。
11.1.3. Web コンソールでの仮想マシンテンプレートの作成
OpenShift Container Platform Web コンソールで YAML ファイルの例を編集して、仮想マシンテンプレートを作成します。
手順
- Web コンソールのサイドメニューで、Virtualization → Templates をクリックします。
-
オプション: Project ドロップダウンメニューを使用して、新しいテンプレートに関連付けられたプロジェクトを変更します。すべてのテンプレートは、デフォルトで
openshiftプロジェクトに保存されます。 - Create Template をクリックします。
- YAML ファイルを編集して、テンプレートパラメーターを指定します。
Create をクリックします。
テンプレートが Templates ページに表示されます。
- オプション: Download をクリックして、YAML ファイルをダウンロードして保存します。
11.1.4. 仮想マシンテンプレートのブートソースの追加
ブートソースは、仮想マシンの作成に使用するすべての仮想マシンテンプレートまたはカスタムテンプレートに設定できます。仮想マシンテンプレートがブートソースを使用して設定されている場合、それらには Templates ページで Source available というラベルが付けられます。ブートソースをテンプレートに追加した後に、テンプレートから新規仮想マシンを作成できます。
Web コンソールでブートソースを選択および追加する方法は 4 つあります。
- ローカルファイルのアップロード (PVC の作成)
- URL (PVC を作成)
- クローン (PVC を作成)
- レジストリー (PVC を作成)
前提条件
-
ブートソースを追加するには、
os-images.kubevirt.io:editRBAC ロールを持つユーザー、または管理者としてログインしていること。ブートソースが追加されたテンプレートから仮想マシンを作成するには、特別な権限は必要ありません。 - ローカルファイルをアップロードするには、オペレーティングシステムのイメージファイルがローカルマシンに存在している必要がある。
- URL を使用してインポートするには、オペレーティングシステムイメージのある Web サーバーへのアクセスが必要である。例: イメージが含まれる Red Hat Enterprise Linux Web ページ。
- 既存の PVC のクローンを作成するには、PVC を含むプロジェクトへのアクセスが必要である。
- レジストリーを使用してインポートするには、コンテナーレジストリーへのアクセスが必要である。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → Templates をクリックします。
- テンプレートの横にある Options メニューをクリックし、Edit boot source を選択します。
- ディスクの追加をクリックします。
- Add disk ウィンドウで、Use this disk as a boot source を選択します。
- ディスク名を入力し、Source を選択します。たとえば、Blank (creates PVC) または Use an existing PVC を選択します。
- Persistent Volume Claim size の値を入力し、圧縮解除されたイメージおよび必要な追加の領域に十分な PVC サイズを指定します。
- Type を選択します (Disk または CD-ROM など)。
オプション: Storage class をクリックし、ディスクを作成するために使用されるストレージクラスを選択します。通常、このストレージクラスはすべての PVC で使用するために作成されるデフォルトのストレージクラスです。
注記提供されたブート ソースは、オペレーティングシステムの最新バージョンに自動的に更新されます。自動更新されたブートソースの場合、クラスターのデフォルトのストレージクラスを使用して、永続ボリューム要求 (PVC) が作成されます。設定後に別のデフォルトのストレージクラスを選択した場合は、以前のデフォルトのストレージクラスで設定されたクラスター namespace 内の既存のデータボリュームを削除する必要があります。
- オプション: Apply optimized StorageProfile settings をオフにして、アクセスモードまたはボリュームモードを編集します。
ブートソースを保存する適切な方法を選択します。
- ローカルファイルをアップロードしている場合に、Save and upload をクリックします。
- URL またはレジストリーからコンテンツをインポートしている場合は、Save and import をクリックします。
- 既存の PVC のクローンを作成している場合は、Save and clone をクリックします。
ブートソースを含むカスタム仮想マシンテンプレートが Catalog ページにリスト表示されています。このテンプレートを使用して仮想マシンを作成できます。
11.1.4.1. ブートソースを追加するための仮想マシンテンプレートフィールド
以下の表は、Add boot source to template ウインドウのフィールドについて説明しています。このウィンドウは、Virtualization → Templates ページで仮想マシンテンプレートの Add source をクリックしたときに表示されます。
| Name | パラメーター | Description |
|---|---|---|
| ブートソースタイプ | ローカルファイルのアップロード (PVC の作成) | ローカルデバイスからファイルをアップロードします。サポートされるファイルタイプには、gz、xz、tar、および qcow2 が含まれます。 |
| URL (PVC を作成) | HTTP または HTTPS エンドポイントで利用できるイメージからコンテンツをインポートします。イメージのダウンロードが可能な Web ページからダウンロードリンクの URL を取得し、その URL リンクを Import URL フィールドに入力します。例: Red Hat Enterprise Linux イメージについては、Red Hat カスタマーポータルにログインしてイメージのダウンロードページにアクセスし、KVM ゲストイメージのダウンロードリンク URL をコピーします。 | |
| PVC (PVC を作成) | クラスターですでに利用可能な PVC を使用し、このクローンを作成します。 | |
| レジストリー (PVC を作成) | クラスターからアクセスでき、レジストリーにある起動可能なオペレーティングシステムコンテナーを指定します。例: kubevirt/cirros-registry-dis-demo | |
| ソースプロバイダー | オプションフィールド。テンプレートのソース、またはテンプレートを作成したユーザーの名前についての説明テキストを追加します。例: Red Hat | |
| ストレージの詳細設定 | StorageClass | ディスクの作成に使用されるストレージクラス。 |
| アクセスモード |
永続ボリュームのアクセスモード。サポートされるアクセスモードは、Single User(RWO)、Shared Access(RWX)、Read Only (ROX) です。Single User (RWO) が選択される場合、ディスクは単一ノードによって読み取り/書き込み ( read/write) としてマウントできます。Shared Access (RWX) が選択される場合、ディスクは多数のノードによって読み取り/書き込み (read-write) としてマウントできます。 注記 Shared Access (RWX) は、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。 | |
| ボリュームモード |
永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。サポートされるモードは Block および Filesystem です。 |
11.2. 仮想マシンテンプレートの編集
Web コンソールで仮想マシンテンプレートを削除できます。
Red Hat Virtualization Operator が提供するテンプレートは編集できません。テンプレートのクローンを作成すると、編集できます。
11.2.1. Web コンソールでの仮想マシンテンプレートの編集
OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイスを使用して、仮想マシンテンプレートを編集できます。
仮想マシンテンプレートの編集は、そのテンプレートですでに作成された仮想マシンには影響を与えません。
手順
- Web コンソールで Virtualization → Templates に移動します。
-
仮想マシンテンプレートの横にある
オプションメニューをクリックし、編集するオブジェクトを選択します。
Red Hat テンプレートを編集するには、
オプションメニューで、Clone を選択してカスタムテンプレートを作成し、カスタムテンプレートを編集します。
注記テンプレートのデータソースが
DataImportCronカスタムリソースによって管理されている場合、またはテンプレートにデータボリューム参照がない場合、Edit boot source reference は無効になります。- Save をクリックします。
11.2.1.1. ネットワークインターフェイスの仮想マシンテンプレートへの追加
以下の手順を使用して、ネットワークインターフェイスを仮想マシンテンプレートに追加します。
手順
- サイドメニューから Virtualization → Templates をクリックします。
- 仮想マシンテンプレートを選択して、Template details 画面を開きます。
- Network Interfaces タブをクリックします。
- Add Network Interface をクリックします。
- Add Network Interface ウィンドウで、ネットワークインターフェイスの Name、Model、Network、 Type、および MAC Address を指定します。
- Add をクリックします。
11.2.1.2. 仮想マシンテンプレートへの仮想ディスクの追加
以下の手順を使用して、仮想ディスクを仮想マシンテンプレートに追加します。
手順
- サイドメニューから Virtualization → Templates をクリックします。
- 仮想マシンテンプレートを選択して、Template details 画面を開きます。
- Disks タブをクリックし、Add disk をクリックします。
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 をクリックします。
11.2.1.3. テンプレートの CD-ROM の編集
以下の手順を使用して、仮想マシンテンプレートの CD-ROM を設定します。
手順
- サイドメニューから Virtualization → Templates をクリックします。
- 仮想マシンテンプレートを選択して、Template details 画面を開きます。
- Disks タブをクリックします。
-
編集する CD-ROM の Options メニュー
をクリックし、Edit を選択します。
- Edit CD-ROM ウィンドウで、Source、Persistent Volume Claim、Name、Type、および Interface フィールドを編集します。
- Save をクリックします。
11.3. 仮想マシンテンプレートの専用リソースの有効化
パフォーマンスを向上させるために、仮想マシンには CPU などのノードの専用リソースを持たせることができます。
11.3.1. 専用リソースについて
仮想マシンの専用リソースを有効にする場合、仮想マシンのワークロードは他のプロセスで使用されない CPU でスケジュールされます。専用リソースを使用することで、仮想マシンのパフォーマンスとレイテンシーの予測の精度を向上させることができます。
11.3.2. 前提条件
-
CPU マネージャー がノードに設定されている。仮想マシンのワークロードをスケジュールする前に、ノードに
cpumanager=trueラベルが設定されていることを確認します。
11.3.3. 仮想マシンテンプレートの専用リソースの有効化
Details タブで仮想マシンテンプレートの専用リソースを有効にします。Red Hat テンプレートから作成された仮想マシンは、専用のリソースで設定できます。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → Templates をクリックします。
- 仮想マシン テンプレートを選択して、Template details ページを開きます。
- Scheduling タブで、Dedicated Resources の横にある鉛筆アイコンをクリックします。
- Schedule this workload with dedicated resources (guaranteed policy) を選択します。
- Save をクリックします。
11.4. 仮想マシンテンプレートのカスタム namespace へのデプロイ
Red Hat は、openshift namespace にインストールされる、事前に設定された仮想マシンテンプレートを提供します。ssp-operator は、デフォルトで仮想マシンテンプレートを openshift namespace にデプロイします。openshift namespace のテンプレートは、すべてのユーザーに広く公開されます。これらのテンプレートは、さまざまなオペレーティングシステムの Virtualization → Templates ページにリスト表示されています。
11.4.1. テンプレート用のカスタム namespace の作成
仮想マシンテンプレートをデプロイするために使用されるカスタム namespace を作成できます。このテンプレートは、アクセス権のある任意のユーザーが使用できます。テンプレートをカスタム namespace に追加するには、HyperConverged カスタムリソース (CR) を編集し、commonTemplatesNamespace を spec に追加し、仮想マシンテンプレートのカスタム namespace を指定します。HyperConverged CR の変更後に、ssp-operator はカスタム namespace のテンプレートに反映します。
前提条件
-
OpenShift Container Platform CLI (
oc) をインストールしている。 - cluster-admin 権限を持つユーザーとしてログインしている。
手順
以下のコマンドを使用してカスタム namespace を作成します。
oc create namespace <mycustomnamespace>
$ oc create namespace <mycustomnamespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.4.2. カスタム namespace へのテンプレートの追加
ssp-operator は、デフォルトで仮想マシンテンプレートを openshift namespace にデプロイします。openshift namespace のテンプレートは、すべてのユーザーに広く公開されます。カスタム namespace が作成され、テンプレートがその namespace に追加されると、openshift namespace の仮想マシンテンプレートを変更または削除することができます。テンプレートをカスタム namespace に追加するには、ssp-operator が含まれる HyperConverged カスタムリソース (CR) を編集します。
手順
openshiftnamespace で利用可能な仮想マシンテンプレートの一覧を表示します。oc get templates -n openshift
$ oc get templates -n openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、デフォルトエディターで
HyperConvergedCR を編集します。oc edit hco -n openshift-cnv kubevirt-hyperconverged
$ oc edit hco -n openshift-cnv kubevirt-hyperconvergedCopy to Clipboard Copied! Toggle word wrap Toggle overflow カスタム namespace で利用可能な仮想マシンテンプレートのリストを表示します。
oc get templates -n customnamespace
$ oc get templates -n customnamespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow commonTemplatesNamespace属性を追加し、カスタム namespace を指定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- テンプレートをデプロイするためのカスタム namespace。
-
変更を保存し、エディターを終了します。
ssp-operatorは、デフォルトのopenshiftnamespace にある仮想マシンテンプレートをカスタム namespace に追加します。
11.4.2.1. カスタム namespace からのテンプレートの削除
カスタム namespace から仮想マシンテンプレートを削除するには、HyperConverged カスタムリソース (CR) から commonTemplateNamespace 属性を削除し、そのカスタム namespace から各テンプレートを削除します。
手順
以下のコマンドを実行して、デフォルトエディターで
HyperConvergedCR を編集します。oc edit hco -n openshift-cnv kubevirt-hyperconverged
$ oc edit hco -n openshift-cnv kubevirt-hyperconvergedCopy to Clipboard Copied! Toggle word wrap Toggle overflow commonTemplateNamespace属性を削除します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 削除する
commonTemplatesNamespace属性。
削除されたカスタム namespace から特定のテンプレートを削除します。
oc delete templates -n customnamespace <template_name>
$ oc delete templates -n customnamespace <template_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
テンプレートがカスタム namespace から削除されていることを確認します。
oc get templates -n customnamespace
$ oc get templates -n customnamespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.5. 仮想マシンテンプレートの削除
Web コンソールを使用して、Red Hat テンプレートに基づいてカスタマイズされた仮想マシンテンプレートを削除できます。
Red Hat テンプレートは削除できません。
11.5.1. Web コンソールでの仮想マシンテンプレートの削除
仮想マシンテンプレートを削除すると、仮想マシンはクラスターから永続的に削除されます。
カスタマイズされた仮想マシンテンプレートを削除できます。Red Hat 提供のテンプレートは削除できません。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → Templates をクリックします。
-
テンプレートの Options メニュー
をクリックし、Delete template を選択します。
- Delete をクリックします。
第12章 ライブマイグレーション
12.1. 仮想マシンのライブマイグレーション
12.1.1. ライブマイグレーションについて
ライブマイグレーションは、仮想ワークロードまたはアクセスに支障を与えることなく、実行中の仮想マシンインスタンス (VMI) をクラスター内の別のノードに移行するプロセスです。VMI が LiveMigrate エビクションストラテジーを使用する場合、VMI が実行されるノードがメンテナンスモードになると自動的に移行されます。移行する VMI を選択して、ライブマイグレーションを手動で開始することもできます。
以下の条件を満たす場合は、ライブマイグレーションを使用できます。
-
ReadWriteMany(RWX) アクセスモードの共有ストレージ - 十分な RAM およびネットワーク帯域幅
- 仮想マシンがホストモデルの CPU を使用する場合、ノードは仮想マシンのホストモデルの CPU をサポートする必要があります。
デフォルトでは、ライブマイグレーショントラフィックは Transport Layer Security (TLS) を使用して暗号化されます。
12.2. ライブマイグレーションの制限およびタイムアウト
ライブマイグレーションの制限およびタイムアウトを適用し、移行プロセスによる負荷がクラスターにかからないようにします。HyperConverged カスタムリソース (CR) を編集してこれらの設定を行います。
12.2.1. ライブマイグレーションの制限およびタイムアウトの設定
openshift-cnv namespace にある HyperConverged カスタムリソース (CR) を更新して、クラスターのライブマイグレーションの制限およびタイムアウトを設定します。
手順
HyperConvergedCR を編集し、必要なライブマイグレーションパラメーターを追加します。oc edit hco -n openshift-cnv kubevirt-hyperconverged
$ oc edit hco -n openshift-cnv kubevirt-hyperconvergedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この例では、
spec.liveMigrationConfig配列には各フィールドのデフォルト値が含まれます。
注記キー/値のペアを削除し、ファイルを保存して、
spec.liveMigrationConfigフィールドのデフォルト値を復元できます。たとえば、progressTimeout: <value>を削除してデフォルトのprogressTimeout: 150を復元します。
12.2.2. クラスター全体のライブマイグレーションの制限およびタイムアウト
| パラメーター | 説明 | デフォルト |
|---|---|---|
|
| クラスターで並行して実行される移行の数。 | 5 |
|
| ノードごとのアウトバウンドの移行の最大数。 | 2 |
|
|
各マイグレーションの帯域幅制限。値は 1 秒あたりのバイト数です。たとえば、値 | 0 [1] |
|
|
移行がこの時間内に終了しない場合 (単位はメモリーの GiB あたりの秒数)、移行は取り消されます。たとえば、6GiB メモリーを持つ仮想マシンインスタンスは、4800 秒内に移行を完了しない場合にタイムアウトします。 | 800 |
|
| メモリーのコピーの進捗がこの時間内 (秒単位) に見られない場合に、移行は取り消されます。 | 150 |
-
デフォルト値の
0は無制限です。
12.3. 仮想マシンインスタンスの別のノードへの移行
Web コンソールまたは CLI のいずれかで仮想マシンインスタンスのライブマイグレーションを手動で開始します。
仮想マシンがホストモデルの CPU を使用する場合は、そのホストモデル CPU をサポートするノード間でのみ仮想マシンのライブマイグレーションを行うことができます。
12.3.1. Web コンソールでの仮想マシンインスタンスのライブマイグレーションの開始
実行中の仮想マシンインスタンスをクラスター内の別のノードに移行します。
Migrate アクションはすべてのユーザーに表示されますが、管理者ユーザーのみが仮想マシンの移行を開始できます。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
このページから移行を開始すると、同じページで複数の仮想マシンに対してアクションを簡単に実行できます。または、選択した仮想マシンの包括的な詳細を表示できる VirtualMachine details ページから移行を開始できます。
-
仮想マシンの横にある Options メニュー
をクリックし、Migrate を選択します。
- 仮想マシン名をクリックして VirtualMachine details ページを開き、Actions → Migrate をクリックします。
-
仮想マシンの横にある Options メニュー
- Migrate をクリックして、仮想マシンを別のノードに移行します。
12.3.2. CLI での仮想マシンインスタンスのライブマイグレーションの開始
クラスターに VirtualMachineInstanceMigration オブジェクトを作成し、仮想マシンインスタンスの名前を参照して、実行中の仮想マシンインスタンスのライブマイグレーションを開始します。
手順
移行する仮想マシンインスタンスの
VirtualMachineInstanceMigration設定ファイルを作成します。vmi-migrate.yamlはこの例になります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、クラスター内にオブジェクトを作成します。
oc create -f vmi-migrate.yaml
$ oc create -f vmi-migrate.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
VirtualMachineInstanceMigration オブジェクトは、仮想マシンインスタンスのライブマイグレーションをトリガーします。このオブジェクトは、手動で削除されない場合、仮想マシンインスタンスが実行中である限りクラスターに存在します。
12.4. 専用の追加ネットワークを介した仮想マシンの移行
ライブマイグレーション専用の Multus ネットワーク を設定できます。専用ネットワークは、ライブマイグレーション中のテナントワークロードに対するネットワークの飽和状態の影響を最小限に抑えます。
12.4.1. 仮想マシンのライブマイグレーション用の専用セカンダリーネットワークの設定
ライブマイグレーション専用のセカンダリーネットワークを設定するには、最初に CLI を使用して openshift-cnv namespace のブリッジネットワークアタッチメント定義を作成する必要があります。次に、NetworkAttachmentDefinition オブジェクトの名前を HyperConverged カスタムリソース (CR) に追加します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインしている。 - Multus Container Network Interface (CNI) プラグインがクラスターにインストールされている。
- クラスター内のすべてのノードには少なくとも 2 つのネットワークインターフェイスカード (NIC) があり、ライブマイグレーションに使用される NIC が同じ VLAN に接続されている。
-
仮想マシン (VM) が
LiveMigrateエビクションストラテジーで実行されている。
手順
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スタンザに追加します。以下に例を示します。設定ファイルのサンプル
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
12.4.2. Web コンソールを使用して専用ネットワークを選択する
OpenShift Container Platform Web コンソールを使用して、ライブマイグレーション用の専用ネットワークを選択できます。
前提条件
- ライブマイグレーション用に Multus ネットワークが設定されている。
手順
- OpenShift Container Platform Web コンソールで Virtualization > Overview に移動します。
- Settings タブをクリックし、Live migration をクリックします。
- Live migration network リストからネットワークを選択します。
12.4.3. 関連情報
12.5. 仮想マシンインスタンスのライブマイグレーションの取り消し
仮想マシンインスタンスを元のノードに残すためにライブマイグレーションを取り消すことができます。
Web コンソールまたは CLI のいずれかでライブマイグレーションを取り消します。
12.5.1. Web コンソールでの仮想マシンインスタンスのライブマイグレーションの取り消し
Web コンソールで仮想マシンインスタンスのライブマイグレーションをキャンセルできます。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
-
仮想マシンの横にある Options メニュー
をクリックし、Cancel Migration を選択します。
12.5.2. CLI での仮想マシンインスタンスのライブマイグレーションの取り消し
移行に関連付けられた VirtualMachineInstanceMigration オブジェクトを削除して、仮想マシンインスタンスのライブマイグレーションを取り消します。
手順
ライブマイグレーションをトリガーした
VirtualMachineInstanceMigrationオブジェクトを削除します。 この例では、migration-jobが使用されています。oc delete vmim migration-job
$ oc delete vmim migration-jobCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.6. 仮想マシンのエビクションストラテジーの設定
LiveMigrate エビクションストラテジーは、ノードがメンテナンス状態になるか、ドレイン (解放) される場合に仮想マシンインスタンスが中断されないようにします。このエビクションストラテジーを持つ仮想マシンインスタンスのライブマイグレーションが別のノードに対して行われます。
12.6.1. LiveMigration エビクションストラテジーでのカスタム仮想マシンの設定
LiveMigration エビクションストラテジーはカスタム仮想マシンでのみ設定する必要があります。共通テンプレートには、デフォルトでこのエビクションストラテジーが設定されています。
手順
evictionStrategy: LiveMigrateオプションを、仮想マシン設定ファイルのspec.template.specセクションに追加します。この例では、oc editを使用してVirtualMachine設定ファイルの関連するスニペットを更新します。oc edit vm <custom-vm> -n <my-namespace>
$ oc edit vm <custom-vm> -n <my-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新を有効にするために仮想マシンを再起動します。
virtctl restart <custom-vm> -n <my-namespace>
$ virtctl restart <custom-vm> -n <my-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.7. ライブマイグレーションポリシーの設定
ライブマイグレーションポリシーを使用して、指定した仮想マシンインスタンス (VMI) のグループに対して、さまざまな移行設定を定義できます。
ライブマイグレーションポリシーは、テクノロジープレビュー機能のみとなります。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Web コンソールを使用してライブマイグレーションポリシーを設定するには、MigrationPolicies ページのドキュメント を参照してください。
12.7.1. コマンドラインからのライブマイグレーションポリシーの設定
MigrationPolicy カスタムリソース定義 (CRD) を使用して、選択した仮想マシンインスタンス (VMI) の 1 つ以上のグループの移行ポリシーを定義します。
次の任意の組み合わせを使用して、VMI のグループを指定できます。
-
size、os、gpu、およびその他の VMI ラベルなどの仮想マシンインスタンスラベル。 -
priority、bandwidth、hpc-workload、およびその他の namespace ラベルなどの namespace ラベル。
ポリシーを特定の VMI グループに適用するには、VMI グループのすべてのラベルがポリシーのラベルと一致する必要があります。
複数のライブマイグレーションポリシーが VMI に適用される場合は、一致するラベルの数が最も多いポリシーが優先されます。複数のポリシーがこの基準を満たす場合、ポリシーは一致するラベルキーの辞書式順序でソートされ、その順序の最初のポリシーが優先されます。
手順
指定した VMI グループの
MigrationPolicyCRD を作成します。次の YAML の例では、ラベルhpc-workloads:true、xyz-workloads-type: ""、workload-type: db、およびoperating-system: ""でグループを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第13章 ノードのメンテナンス
13.1. ノードのメンテナンスについて
13.1.1. ノードのメンテナンスモードについて
oc adm ユーティリティーまたは NodeMaintenance カスタムリソース (CR) を使用してノードをメンテナンスモードにすることができます。
node-maintenance-operator (NMO) は OpenShift Virtualization に同梱されなくなりました。OpenShift Container Platform Web コンソールの OperatorHub から、または OpenShift CLI (oc) を使用して、スタンドアロン Operator としてデプロイできるようになりました。
ノードがメンテナンス状態になると、ノードにはスケジュール対象外のマークが付けられ、ノードからすべての仮想マシンおよび Pod がドレイン (解放) されます。LiveMigrate エビクションストラテジーを持つ仮想マシンインスタンスのライブマイグレーションは、サービスが失われることなく実行されます。このエビクションストラテジーはデフォルトで共通テンプレートから作成される仮想マシンで設定されますが、カスタム仮想マシンの場合には手動で設定される必要があります。
エビクションストラテジーのない仮想マシンインスタンスはシャットダウンします。RunStrategy が Running または RerunOnFailure の仮想マシンは別のノードで再作成されます。RunStrategy が Manual の仮想マシンは自動的に再起動されません。
仮想マシンでは、共有 ReadWriteMany (RWX) アクセスモードを持つ永続ボリューム要求 (PVC) のライブマイグレーションが必要です。
Node Maintenance Operator は、新規または削除された NodeMaintenance CR をモニタリングします。新規の NodeMaintenance CR が検出されると、新規ワークロードはスケジュールされず、ノードは残りのクラスターから遮断されます。エビクトできるすべての Pod はノードからエビクトされます。NodeMaintenance CR が削除されると、CR で参照されるノードは新規ワークロードで利用可能になります。
ノードのメンテナンスタスクに NodeMaintenance CR を使用すると、標準の OpenShift Container Platform カスタムリソース処理を使用して oc adm cordon および oc adm drain コマンドの場合と同じ結果が得られます。
13.1.2. ベアメタルノードのメンテナンス
OpenShift Container Platform をベアメタルインフラストラクチャーにデプロイする場合、クラウドインフラストラクチャーにデプロイする場合と比較すると、追加で考慮する必要のある点があります。クラスターノードが一時的とみなされるクラウド環境とは異なり、ベアメタルノードを再プロビジョニングするには、メンテナンスタスクにより多くの時間と作業が必要になります。
致命的なカーネルエラーが発生したり、NIC カードのハードウェア障害が発生する場合などにベアメタルノードに障害が発生した場合には、障害のあるノードが修復または置き換えられている間に、障害が発生したノード上のワークロードをクラスターの別の場所で再起動する必要があります。ノードのメンテナンスモードにより、クラスター管理者はノードの電源を正常に停止し、ワークロードをクラスターの他の部分に移動させ、ワークロードが中断されないようにします。詳細な進捗とノードのステータスの詳細は、メンテナンス時に提供されます。
13.2. TLS 証明書の自動更新
OpenShift Virtualization コンポーネントの TLS 証明書はすべて更新され、自動的にローテーションされます。手動で更新する必要はありません。
13.2.1. TLS 証明書の自動更新スケジュール
TLS 証明書は自動的に削除され、以下のスケジュールに従って置き換えられます。
- KubeVirt 証明書は毎日更新されます。
- Containerized Data Importer controller (CDI) 証明書は、15 日ごとに更新されます。
- MAC プール証明書は毎年更新されます。
TLS 証明書の自動ローテーションはいずれの操作も中断しません。たとえば、以下の操作は中断せずに引き続き機能します。
- 移行
- イメージのアップロード
- VNC およびコンソールの接続
13.3. 古い CPU モデルのノードラベルの管理
VM CPU モデルおよびポリシーがノードでサポートされている限り、ノードで仮想マシン (VM) をスケジュールできます。
13.3.1. 古い CPU モデルのノードラベリングについて
OpenShift Virtualization Operator は、古い CPU モデルの事前定義されたリストを使用して、ノードがスケジュールされた仮想マシンの有効な CPU モデルのみをサポートするようにします。
デフォルトでは、以下の CPU モデルはノード用に生成されたラベルのリストから削除されます。
例13.1 古い CPU モデル
この事前定義された一覧は HyperConverged CR には表示されません。このリストから CPU モデルを 削除 できませんが、HyperConverged CR の spec.obsoleteCPUs.cpuModels フィールドを編集してリストに追加することはできます。
13.3.2. CPU 機能のノードのラベル付けについて
反復処理により、最小 CPU モデルのベース CPU 機能は、ノード用に生成されたラベルのリストから削除されます。
以下に例を示します。
-
環境には、
PenrynとHaswellという 2 つのサポートされる CPU モデルが含まれる可能性があります。 PenrynがminCPUの CPU モデルとして指定される場合、Penrynのベース CPU の各機能はHaswellによってサポートされる CPU 機能のリストと比較されます。例13.2
Penrynでサポートされる CPU 機能Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例13.3
Haswellでサポートされる CPU 機能Copy to Clipboard Copied! Toggle word wrap Toggle overflow PenrynとHaswellの両方が特定の CPU 機能をサポートする場合、その機能にラベルは作成されません。ラベルは、Haswellでのみサポートされ、Penrynではサポートされていない CPU 機能用に生成されます。例13.4 反復後に CPU 機能用に作成されるノードラベル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.3.3. 古い CPU モデルの設定
HyperConverged カスタムリソース (CR) を編集して、古い CPU モデルのリストを設定できます。
手順
古い CPU モデルを
obsoleteCPUs配列で指定して、HyperConvergedカスタムリソースを編集します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.4. ノードの調整の防止
skip-node アノテーションを使用して、node-labeller がノードを調整できないようにします。
13.4.1. skip-node アノテーションの使用
node-labeller でノードを省略するには、oc CLI を使用してそのノードにアノテーションを付けます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
以下のコマンドを実行して、スキップするノードにアノテーションを付けます。
oc annotate node <node_name> node-labeller.kubevirt.io/skip-node=true
$ oc annotate node <node_name> node-labeller.kubevirt.io/skip-node=true1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<node_name>は、スキップする関連ノードの名前に置き換えます。
調整は、ノードアノテーションが削除されるか、false に設定された後に、次のサイクルで再開されます。
第14章 ロギング、イベント、およびモニタリング
14.1. Virtualization Overview ページ
Virtualization Overview ページには、仮想化リソース、詳細、ステータス、およびトップコンシューマーの包括的なビューが表示されます。
- Overview タブには、OpenShift Virtualization 環境に関する スタートガイド のリソース、詳細、インベントリー、アラート、およびその他の情報が表示されます。
- Top consumers タブには、プロジェクト、仮想マシン、またはノードごとの特定のリソースの高い使用率が表示されます。
- Migrations タブには、ライブマイグレーションのステータスが表示されます。
- Settings タブには、ライブマイグレーション設定やパーミッションなど、クラスター全体の設定が表示されます。
OpenShift Virtualization の全体的な健全性に関する洞察を得ることで、データを調べることで特定される特定の問題を解決するために介入が必要かどうかを判断できます。
14.1.1. トップコンシューマーの確認
Virtualization Overview ページの Top consumers タブで、選択したプロジェクト、仮想マシン、またはノードのリソースのトップコンシューマーを表示できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
Top consumers タブで vCPU wait メトリックを使用するには、
schedstats=enableカーネル引数をMachineConfigオブジェクトに適用する必要があります。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Virtualization → Overview に移動します。
- Top consumers タブをクリックします。
- オプション: 期間を選択するか、上位 5 人または 10 人のコンシューマーを選択して、結果をフィルタリングできます。
14.2. OpenShift Virtualization ログの表示
Web コンソールまたは oc CLI を使用して、OpenShift Virtualization コンポーネントおよび仮想マシンのログを表示できます。virt-launcher Pod から仮想マシンのログを取得できます。ログの詳細度を制御するには、HyperConverged カスタムリソースを編集します。
14.2.1. CLI を使用した OpenShift Virtualization ログの表示
HyperConverged カスタムリソース (CR) を編集して、OpenShift Virtualization コンポーネントのログ詳細度を設定します。次に、oc CLI ツールを使用して、コンポーネント Pod のログを表示します。
手順
特定のコンポーネントのログの詳細度を設定するには、次のコマンドを実行して、デフォルトのテキストエディターで
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.logVerbosityConfigスタンザを編集して、1 つ以上のコンポーネントのログレベルを設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ログの詳細度の値は
1 ~ 9の範囲の整数である必要があり、数値が大きいほど詳細なログであることを示します。この例では、virtAPIコンポーネントのログは、優先度が5以上の場合に公開されます。
- エディターを保存して終了し、変更を適用します。
以下のコマンドを実行して、OpenShift Virtualization の namespace 内の Pod のリストを表示します。
oc get pods -n openshift-cnv
$ oc get pods -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例14.1 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンポーネント Pod のログを表示するには、次のコマンドを実行します。
oc logs -n openshift-cnv <pod_name>
$ oc logs -n openshift-cnv <pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc logs -n openshift-cnv virt-handler-2m86x
$ oc logs -n openshift-cnv virt-handler-2m86xCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Pod の起動に失敗した場合は、
--previousオプションを使用して、最後の試行からのログを表示できます。ログ出力をリアルタイムで監視するには、
-fオプションを使用します。例14.2 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.2.2. Web コンソールでの仮想マシンログの表示
関連付けられた仮想マシンランチャー Pod から仮想マシンログを取得します。
手順
- OpenShift Container Platform コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
- Details タブをクリックします。
-
Pod セクションの
virt-launcher-<name>Pod をクリックして、Pod details ページを開きます。 - Logs タブをクリックして、Pod のログを表示します。
14.2.3. 一般的なエラーメッセージ
以下のエラーメッセージが OpenShift Virtualization ログに表示される場合があります。
ErrImagePullまたはImagePullBackOff- デプロイメント設定が正しくないか、参照されているイメージに問題があることを示します。
14.3. イベントの表示
14.3.1. 仮想マシンイベントについて
OpenShift Container Platform イベントは、namespace 内の重要なライフサイクル情報のレコードであり、リソースのスケジュール、作成、および削除に関する問題のモニターおよびトラブルシューティングに役立ちます。
OpenShift Virtualization は、仮想マシンおよび仮想マシンインスタンスについてのイベントを追加します。これらは Web コンソールまたは CLI のいずれかで表示できます。
OpenShift Container Platform クラスター内のシステムイベント情報の表示 も参照してください。
14.3.2. Web コンソールでの仮想マシンのイベントの表示
Web コンソールの VirtualMachine details ページで、実行中の仮想マシンのストリーミング イベントを表示できます。
手順
- サイドメニューから Virtualization → VirtualMachines をクリックします。
- 仮想マシンを選択して、VirtualMachine details ページを開きます。
Events タブをクリックして、仮想マシンのストリーミングイベントを表示します。
- ▮▮ ボタンはイベントストリームを一時停止します。
- ▶ ボタンは、一時停止したイベントストリームを再開します。
14.3.3. CLI での namespace イベントの表示
OpenShift Container Platform クライアントを使用して namespace のイベントを取得します。
手順
namespace で、
oc getコマンドを使用します。oc get events
$ oc get eventsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.3.4. CLI でのリソースイベントの表示
イベントはリソース説明に組み込むこともできます。 これは OpenShift Container Platform クライアントを使用して取得できます。
手順
namespace で、
oc describeコマンドを使用します。以下の例は、仮想マシン、仮想マシンインスタンス、および仮想マシンの virt-launcher Pod のイベント取得する方法を示しています。oc describe vm <vm>
$ oc describe vm <vm>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe vmi <vmi>
$ oc describe vmi <vmi>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe pod virt-launcher-<name>
$ oc describe pod virt-launcher-<name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.4. ライブマイグレーションの監視
ライブマイグレーションの進行状況は、Web コンソールまたは CLI から監視できます。
14.4.1. Web コンソールを使用したライブマイグレーションの監視
Web コンソールの Overview → Migrations タブ で、すべてのライブマイグレーションの進行状況を監視できます。
仮想マシンの移行メトリクスは、Web コンソールの VirtualMachine details → Metrics タブ で表示できます。
14.4.2. CLI での仮想マシンインスタンスのライブマイグレーションのモニター
仮想マシンの移行のステータスは、VirtualMachineInstance 設定の Status コンポーネントに保存されます。
手順
移行中の仮想マシンインスタンスで
oc describeコマンドを使用します。oc describe vmi vmi-fedora
$ oc describe vmi vmi-fedoraCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.4.3. メトリック
Prometheus クエリー を使用して、ライブマイグレーションを監視できます。
14.4.3.1. ライブマイグレーションのメトリック
次のメトリックをクエリーして、ライブマイグレーションのステータスを表示できます。
kubevirt_migrate_vmi_data_processed_bytes- 新しい仮想マシン (VM) に移行されたゲストオペレーティングシステム (OS) データの量。タイプ: ゲージ。
kubevirt_migrate_vmi_data_remaining_bytes- 移行されていないゲスト OS データの量。タイプ: ゲージ。
kubevirt_migrate_vmi_dirty_memory_rate_bytes- ゲスト OS でメモリーがダーティになる速度。ダーティメモリーとは、変更されたがまだディスクに書き込まれていないデータです。タイプ: ゲージ。
kubevirt_migrate_vmi_pending_count- 保留中の移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_scheduling_count- スケジュール移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_running_count- 実行中の移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_succeeded- 正常に完了した移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_failed- 失敗した移行の数。タイプ: ゲージ。
14.5. イベントおよび状態を使用したデータボリュームの診断
oc describe コマンドを使用してデータボリュームの問題を分析し、解決できるようにします。
14.5.1. 状態およびイベントについて
コマンドで生成される Conditions および Events セクションの出力を検査してデータボリュームの問題を診断します。
oc describe dv <DataVolume>
$ oc describe dv <DataVolume>
表示される Conditions セクションには、3 つの Types があります。
-
Bound -
running -
Ready
Events セクションでは、以下の追加情報を提供します。
-
イベントの
Type -
ロギングの
Reason -
イベントの
Source -
追加の診断情報が含まれる
Message
oc describe からの出力には常に Events が含まれるとは限りません。
イベントは Status、Reason、または Message のいずれかの変更時に生成されます。状態およびイベントはどちらもデータボリュームの状態の変更に対応します。
たとえば、インポート操作中に URL のスペルを誤ると、インポートにより 404 メッセージが生成されます。メッセージの変更により、理由と共にイベントが生成されます。Conditions セクションの出力も更新されます。
14.5.2. 状態およびイベントを使用したデータボリュームの分析
describe コマンドで生成される Conditions セクションおよび Events セクションを検査することにより、永続ボリューム要求 (PVC) に関連してデータボリュームの状態を判別します。また、操作がアクティブに実行されているか、完了しているかどうかを判断します。また、データボリュームのステータスに関する特定の詳細、およびどのように現在の状態になったかに関する情報を提供するメッセージを受信する可能性があります。
状態の組み合わせは多数あります。それぞれは一意のコンテキストで評価される必要があります。
各種の組み合わせの例を以下に示します。
Bound: この例では正常にバインドされた PVC が表示されます。TypeはBoundであるため、StatusはTrueになります。PVC がバインドされていない場合、StatusはFalseになります。PVC がバインドされると、PVC がバインドされていることを示すイベントが生成されます。この場合、
ReasonはBoundで、StatusはTrueです。Messageはデータボリュームを所有する PVC を示します。EventsセクションのMessageでは、PVC がバインドされている期間 (Age) およびどのリソース (From) によってバインドされているか、datavolume-controllerに関する詳細が提供されます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Running: この場合、TypeがRunningであり、StatusがFalseであることに注意してください。これは、操作の失敗の原因となったイベントが発生したことを示しています。ステータスをTrueからFalseに変更します。ただし、
ReasonがCompletedであり、MessageフィールドにはImport Completeが表示されることに注意してください。Eventsセクションには、ReasonおよびMessageに失敗した操作に関する追加のトラブルシューティング情報が含まれます。この例では、Eventsセクションの最初のWarningに一覧表示されるMessageに、404によって接続できないことが示唆されます。この情報から、インポート操作が実行されており、データボリュームにアクセスしようとしている他の操作に対して競合が生じることを想定できます。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ready:TypeがReadyであり、StatusがTrueの場合、以下の例のようにデータボリュームは使用可能な状態になります。データボリュームが使用可能な状態にない場合、StatusはFalseになります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.6. 仮想マシンのワークロードに関する情報の表示
OpenShift Container Platform Web コンソールで Virtual Machines ダッシュボードを使用して、仮想マシンについての概要を表示できます。
14.6.1. 仮想マシン ダッシュボード
Virtualization → VirtualMachines ページに移動し、仮想マシン (VM) をクリックして VirtualMachine details ページを表示することにより、OpenShift Container Platform Web コンソールから仮想マシン (VM) にアクセスします。
Overview タブには、次のカードが表示されます。
Details: 以下を含む、仮想マシンについての識別情報を提供します。
- 名前
- ステータス
- 作成日
- オペレーティングシステム
- CPU とメモリー
- Hostname
- テンプレート
仮想マシンが実行中の場合、アクティブな VNC プレビュー ウィンドウと、VNC Web コンソールを開くためのリンクが表示されます。Details カードの Options メニュー
には、仮想マシンを停止または一時停止するオプションと、SSH トンネリング用の ssh over nodeportコマンドをコピーするオプションが用意されています。Alerts には、次の 3 つの重大度レベルの仮想マシンアラートがリスト表示されます。
- Critical
- Warning
- Info
Snapshots は、仮想マシンスナップショットとスナップショットを作成する機能に関する情報を提供します。リストされている各スナップショットについて、Snapshots カードには以下が含まれます。
- スナップショットが正常に作成されたか、まだ進行中か、失敗したかを示す視覚的なインジケーター。
-
オプション メニュー
スナップショットを復元または削除するオプションがあります。
Network interfaces は、次のような仮想マシンのネットワークインターフェイスに関する情報を提供します。
- 名前 (ネットワークとタイプ)
- IP アドレス、IP アドレスをクリップボードにコピーする機能
Disks には、次のような仮想マシンディスクの詳細がリスト表示されます。
- 名前
- ドライブ
- サイズ
Utilization: 以下の使用率についてのデータを表示するグラフが含まれます。
- CPU
- メモリー
- ストレージ
- ネットワーク転送
注記ドロップダウンリストを使用して、使用率データの期間を選択します。利用可能なオプションは、5 minutes、1 hour、6 hours、および 24 hours です。
Hardware Devices は、次のような GPU およびホスト デバイスに関する情報を提供します。
- リソース名
- ハードウェアデバイス名
14.7. 仮想マシンの正常性のモニタリング
仮想マシンインスタンス (VMI) は、接続の損失、デッドロック、または外部の依存関係に関する問題など、一時的な問題が原因で正常でなくなることがあります。ヘルスチェックは、readiness および liveness プローブの組み合わせを使用して VMI で診断を定期的に実行します。
14.7.1. readiness および liveness プローブについて
readiness および liveness プローブを使用して、正常でない仮想マシンインスタンス (VMI) を検出して処理します。VMI の仕様に 1 つ以上のプローブを追加して、トラフィックが準備状態にない VMI に到達せず、VMI が応答不能になると新規インスタンスが作成されるようにすることができます。
readiness プローブ は、VMI がサービス要求を受け入れることができるかどうかを判別します。プローブに失敗すると、VMI は準備状態になるまで、利用可能なエンドポイントのリストから削除されます。
liveness プローブは、VMI が応答しているかどうかを判断します。プローブに失敗すると、VMI が削除され、新規インスタンスが作成されて応答性を復元します。
VirtualMachineInstance オブジェクトの spec.readinessProbe と spec.livenessProbe フィールドを設定して、readiness および liveness プローブを設定できます。これらのフィールドは、以下のテストをサポートします。
- HTTP GET
- プローブは Web フックを使用して VMI の正常性を判別します。このテストは、HTTP の応答コードが 200 から 399 までの値の場合に正常と見なされます。完全に初期化されている場合に、HTTP ステータスコードを返すアプリケーションで HTTP GET テストを使用できます。
- TCP ソケット
- プローブは、VMI に対してソケットを開くことを試行します。VMI はプローブで接続を確立できる場合にのみ正常であるとみなされます。TCP ソケットテストは、初期化が完了するまでリスニングを開始しないアプリケーションで使用できます。
- ゲストエージェントの ping
-
プローブは、
guest-pingコマンドを使用して、QEMU ゲストエージェントが仮想マシンで実行されているかどうかを判断します。
14.7.2. HTTP readiness プローブの定義
仮想マシンインスタンス (VMI) 設定の spec.readinessProbe.httpGet フィールドを設定して HTTP readiness プローブを定義します。
手順
VMI 設定ファイルに readiness プローブの詳細を追加します。
HTTP GET テストを使用した readiness プローブの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- VMI への接続に使用する HTTP GET 要求。
- 2
- プローブがクエリーする VMI のポート。上記の例では、プローブはポート 1500 をクエリーします。
- 3
- HTTP サーバーでアクセスするパス。上記の例では、サーバーの /healthz パスのハンドラーが成功コードを返す場合に、VMI は正常であるとみなされます。ハンドラーが失敗コードを返すと、VMI は利用可能なエンドポイントのリストから削除されます。
- 4
- VMI が起動してから readiness プローブが開始されるまでの時間 (秒単位)。
- 5
- プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は
timeoutSecondsよりも大きくなければなりません。 - 6
- プローブがタイムアウトし、VMI が失敗したと想定されてから非アクティブになるまでの時間 (秒数)。デフォルト値は 1 です。この値は
periodSeconds未満である必要があります。 - 7
- プローブが失敗できる回数。デフォルトは 3 です。指定された試行回数になると、Pod には
Unreadyというマークが付けられます。 - 8
- 成功とみなされるまでにプローブが失敗後に成功を報告する必要のある回数。デフォルトでは 1 回です。
以下のコマンドを実行して VMI を作成します。
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.7.3. TCP readiness プローブの定義
仮想マシンインスタンス (VMI) 設定の spec.readinessProbe.tcpSocket フィールドを設定して TCP readiness プローブを定義します。
手順
TCP readiness プローブの詳細を VMI 設定ファイルに追加します。
TCP ソケットテストを含む readiness プローブの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して VMI を作成します。
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.7.4. HTTP liveness プローブの定義
仮想マシンインスタンス (VMI) 設定の spec.livenessProbe.httpGet フィールドを設定して HTTP liveness プローブを定義します。readiness プローブと同様に、liveness プローブの HTTP および TCP テストの両方を定義できます。この手順では、HTTP GET テストを使用して liveness プローブのサンプルを設定します。
手順
HTTP liveness プローブの詳細を VMI 設定ファイルに追加します。
HTTP GET テストを使用した liveness プローブの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- VMI が起動してから liveness プローブが開始されるまでの時間 (秒単位)。
- 2
- プローブの実行間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は
timeoutSecondsよりも大きくなければなりません。 - 3
- VMI への接続に使用する HTTP GET 要求。
- 4
- プローブがクエリーする VMI のポート。上記の例では、プローブはポート 1500 をクエリーします。VMI は、cloud-init 経由でポート 1500 に最小限の HTTP サーバーをインストールし、実行します。
- 5
- HTTP サーバーでアクセスするパス。上記の例では、サーバーの
/healthzパスのハンドラーが成功コードを返す場合に、VMI は正常であるとみなされます。ハンドラーが失敗コードを返すと、VMI が削除され、新規インスタンスが作成されます。 - 6
- プローブがタイムアウトし、VMI が失敗したと想定されてから非アクティブになるまでの時間 (秒数)。デフォルト値は 1 です。この値は
periodSeconds未満である必要があります。
以下のコマンドを実行して VMI を作成します。
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.7.5. ゲストエージェントの ping プローブの定義
仮想マシンインスタンス (VMI) 設定の spec.readinessProbe.guestAgentPing フィールドを設定して、ゲストエージェント ping プローブを定義します。
ゲストエージェント ping プローブは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
- 仮想マシンに QEMU ゲストエージェントをインストールして有効にする必要があります。
手順
ゲストエージェント ping プローブの詳細を VMI 設定ファイルに含めます。以下に例を示します。
ゲストエージェント ping プローブの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- VMI に接続するためのゲストエージェント ping プローブ。
- 2
- オプション: VMI が開始してからゲストエージェントプローブが開始されるまでの時間 (秒単位)。
- 3
- オプション: プローブを実行する間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は
timeoutSecondsよりも大きくなければなりません。 - 4
- オプション: プローブがタイムアウトし、VMI が失敗したと想定されてから非アクティブになるまでの時間 (秒数)。デフォルト値は 1 です。この値は
periodSeconds未満である必要があります。 - 5
- オプション: プローブが失敗できる回数。デフォルトは 3 です。指定された試行回数になると、Pod には
Unreadyというマークが付けられます。 - 6
- オプション: 成功とみなされるまでにプローブが失敗後に成功を報告する必要のある回数。デフォルトでは 1 回です。
以下のコマンドを実行して VMI を作成します。
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.7.6. テンプレート: ヘルスチェックを定義するための仮想マシンの設定ファイル
14.8. OpenShift Container Platform Dashboard を使用したクラスター情報の取得
OpenShift Container Platform Web コンソールから Home > Dashboards > Overview をクリックしてクラスターについてのハイレベルな情報をキャプチャーする OpenShift Container Platform ダッシュボードにアクセスします。
OpenShift Container Platform ダッシュボードは、個別のダッシュボード カード でキャプチャーされるさまざまなクラスター情報を提供します。
14.8.1. OpenShift Container Platform ダッシュボードページについて
OpenShift Container Platform Web コンソールから Home → Overview に移動して、クラスターに関する概要情報を取得する OpenShift Container Platform ダッシュボードにアクセスします。
OpenShift Container Platform ダッシュボードは、個別のダッシュボードカードでキャプチャーされるさまざまなクラスター情報を提供します。
OpenShift Container Platform ダッシュボードは以下のカードで構成されます。
Details は、クラスターの詳細情報の概要を表示します。
ステータスには、ok、error、warning、in progress、および unknown が含まれます。リソースでは、カスタムのステータス名を追加できます。
- クラスター
- プロバイダー
- バージョン
Cluster Inventory は、リソースの数および関連付けられたステータスの詳細を表示します。これは、問題の解決に介入が必要な場合に役立ちます。以下に関する情報が含まれます。
- ノード数
- Pod 数
- 永続ストレージボリューム要求
- 仮想マシン (OpenShift Virtualization がインストールされている場合に利用可能)
- クラスター内のベアメタルホスト。これらはステータス別にリスト表示されます (metal3 環境でのみ利用可能)。
Cluster Health では、関連するアラートおよび説明を含む、クラスターの現在の健全性についてのサマリーを表示します。OpenShift Virtualization がインストールされている場合、OpenShift Virtualization の健全性についても全体的に診断されます。複数のサブシステムが存在する場合は、See All をクリックして、各サブシステムのステータスを表示します。
- 状態別にリスト表示されたクラスター内のベアメタルホスト (metal3 環境でのみ利用可能)
- Status は、管理者がクラスターリソースの消費状況を把握するのに役立ちます。リソースをクリックし、指定されたクラスターリソース (CPU、メモリー、またはストレージ) の最大量を消費する Pod およびノードを一覧表示する詳細ページに切り替えます。
Cluster Utilization には、指定期間におけるさまざまなリソースの容量が表示されます。これは、リソース消費量が多い場合に、管理者がその規模と頻度を把握するのに役立ちます。次の情報が表示されます。
- CPU 時間
- メモリー割り当て
- 消費されたストレージ
- 消費されたネットワークリソース
- Pod 数
- Activity には、Pod の作成や別のホストへの仮想マシンの移行など、クラスター内の最近のアクティビティーに関連するメッセージがリスト表示されます。
14.9. 仮想マシンによるリソース使用率の確認
OpenShift Container Platform Web コンソールのダッシュボードには、クラスターの状態をすぐに理解できるようにするクラスターのメトリックの視覚的な表示が含まれます。ダッシュボードは、コアプラットフォームコンポーネントを監視する Monitoring overview に属します。
OpenShift Virtualization ダッシュボードでは、仮想マシンおよび関連付けられた Pod のリソース消費に関するデータが得られます。OpenShift Virtualization ダッシュボードに表示される可視化メトリックは、Prometheus Query Language(PromQL) クエリー に基づいています。
OpenShift Virtualization ダッシュボードでユーザー定義の namespace をモニターするには、モニタリングロール が必要です。
Web コンソールの VirtualMachine details ページ → Metrics タブ で、特定の仮想マシンのリソース使用状況を表示できます。
14.9.1. トップコンシューマーの確認について
OpenShift Virtualization ダッシュボードでは、特定の期間を選択して、その期間内のリソースのトップコンシューマーを表示できます。トップコンシューマーとは、最も多くリソースを消費する仮想マシンまたは virt-launcher Pod のことです。
以下の表は、ダッシュボードでモニターされたリソースと、トップコンシューマーの各リソースに関連付けられたメトリックを示しています。
| モニタリングされたリソース | Description |
| メモリースワップトラフィック | 仮想マシンは、メモリーのスワップ時に最も多くのメモリーを消費します。 |
| vCPU 待機時間 | vCPU の待機時間 (秒単位) が最大の仮想マシン。 |
| Pod 別の CPU 使用率 |
CPU を最も使用している |
| ネットワークトラフィック | 最も多くのネットワークトラフィック (バイト単位) を受信することによってネットワークを飽和させている仮想マシン。 |
| ストレージトラフィック | ストレージ関連のトラフィック量 (バイト単位) が最大の仮想マシン。 |
| ストレージ IOPS | 一定期間における 1 秒あたりの I/O 操作が最も多い仮想マシン。 |
| メモリー使用率 |
メモリー (バイト単位) を最も使用している |
リソース消費の最大値の表示は、トップコンシューマー 5 件に制限されます。
14.9.2. トップコンシューマーの確認
Administrator パースペクティブでは、リソースのトップコンシューマーが表示される OpenShift Virtualization ダッシュボードを確認できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
- OpenShift Virtualization Web コンソールの Administrator パースペクティブで、Observe → Dashboards に移動します。
- Dashboard リストから KubeVirt/Infrastructure Resources/Top Consumers ダッシュボードを選択します。
- Period のドロップダウンメニューから事前に定義された期間を選択します。表でトップコンシューマーのデータを確認できます。
- オプション:Inspect をクリックして、テーブルの上部コンシューマーに関連付けられた Prometheus クエリー言語 (PromQL) クエリーを表示または編集します。
14.10. OpenShift Container Platform クラスターモニタリング、ロギング、および Telemetry
OpenShift Container Platform は、クラスターレベルでモニターするための各種のリソースを提供します。
14.10.1. OpenShift Container Platform モニタリングについて
OpenShift Container Platform には、コアプラットフォームコンポーネントのモニタリング を提供する、事前に設定およびインストールされた自己更新型のモニタリングスタックが組み込まれています。OpenShift Container Platform は、追加設定が不要のモニタリングのベストプラクティスを提供します。クラスター管理者にクラスターの問題について即時に通知するアラートのセットがデフォルトで含まれます。OpenShift Container Platform Web コンソールのデフォルトのダッシュボードには、クラスターの状態をすぐに理解できるようにするクラスターのメトリックの視覚的な表示が含まれます。
OpenShift Container Platform 4.12 のインストール後に、クラスター管理者はオプションでユーザー定義プロジェクトのモニタリングを有効にできます。この機能を使用することで、クラスター管理者、開発者、および他のユーザーは、サービスと Pod を独自のプロジェクトでモニターする方法を指定できます。次に、OpenShift Container Platform Web コンソールでメトリックのクエリー、ダッシュボードの確認、および独自のプロジェクトのアラートルールおよびサイレンスを管理できます。
クラスター管理者は、開発者およびその他のユーザーに、独自のプロジェクトをモニターするパーミッションを付与できます。事前に定義されたモニタリングロールのいずれかを割り当てると、特権が付与されます。
14.10.2. ロギングアーキテクチャー
ロギングの主なコンポーネントは次のとおりです。
- Collector
コレクターは、Pod を各 OpenShift Container Platform ノードにデプロイするデーモンセットです。各ノードからログデータを収集し、データを変換して、設定された出力に転送します。Vector コレクターまたは従来の Fluentd コレクターを使用できます。
注記Fluentd は非推奨となっており、今後のリリースで削除される予定です。Red Hat は、現在のリリースのライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は拡張されなくなりました。Fluentd の代わりに、Vector を使用できます。
- ログストア
ログストアは分析用のログデータを保存し、ログフォワーダーのデフォルトの出力です。デフォルトの LokiStack ログストア、従来の Elasticsearch ログストアを使用したり、追加の外部ログストアにログを転送したりできます。
注記Logging 5.9 リリースに、OpenShift Elasticsearch Operator の更新バージョンは含まれていません。ロギング 5.8 でリリースされた OpenShift Elasticsearch Operator を現在使用している場合、Logging 5.8 の EOL まで引き続き Logging で機能します。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。Logging のライフサイクルの日付の詳細は、Platform Agnostic Operator を参照してください。
- 可視化
UI コンポーネントを使用して、ログデータの視覚的表現を表示できます。UI は、保存されたログを検索、クエリー、および表示するためのグラフィカルインターフェイスを提供します。OpenShift Container Platform Web コンソール UI は、OpenShift Container Platform コンソールプラグインを有効にすることで提供されます。
注記Kibana Web コンソールは現在非推奨となっており、将来のログリリースで削除される予定です。
ロギングはコンテナーログとノードログを収集します。これらは次のタイプに分類されます。
- アプリケーションログ
- クラスターで実行される、インフラストラクチャーコンテナーアプリケーションを除くユーザーアプリケーションによって生成されるコンテナーログ。
- インフラストラクチャーログ
-
インフラストラクチャー namespace (
openshift*、kube*、またはdefault)によって生成されたコンテナーのログ、およびノードからの journald メッセージ。 - 監査ログ
-
/var/log/audit/audit.log ファイルに保存されるノード監査システムである auditd によって生成されたログ、
auditd、kube-apiserver、openshift-apiserverサービス、および有効な場合はovnプロジェクトからのログ。
OpenShift Logging の詳細は、OpenShift Logging のドキュメントを参照してください。
14.10.3. Telemetry について
Telemetry は厳選されたクラスターモニタリングメトリクスのサブセットを Red Hat に送信します。Telemeter Client はメトリクスの値を 4 分 30 秒ごとに取得し、データを Red Hat にアップロードします。これらのメトリクスは、このドキュメントで説明しています。
このデータのストリームは、Red Hat によってリアルタイムでクラスターをモニターし、お客様に影響を与える問題に随時対応するために使用されます。またこれにより、Red Hat がサービスへの影響を最小限に抑えつつつアップグレードエクスペリエンスの継続的な改善に向けた OpenShift Container Platform のアップグレードのデプロイメントを可能にします。
このデバッグ情報は、サポートケースでレポートされるデータへのアクセスと同じ制限が適用された状態で Red Hat サポートおよびエンジニアリングチームが利用できます。接続クラスターのすべての情報は、OpenShift Container Platform をより使用しやすく、より直感的に使用できるようにするために Red Hat によって使用されます。
14.10.3.1. Telemetry で収集される情報
以下の情報は、Telemetry によって収集されます。
14.10.3.1.1. システム情報
- OpenShift Container Platform クラスターのバージョン情報、および更新バージョンの可用性を特定するために使用されるインストールの更新の詳細を含むバージョン情報
- クラスターごとに利用可能な更新の数、更新に使用されるチャネルおよびイメージリポジトリー、更新の進捗情報、および更新で発生するエラーの数などの更新情報
- インストール時に生成される一意でランダムな識別子
- クラウドインフラストラクチャーレベルのノード設定、ホスト名、IP アドレス、Kubernetes Pod 名、namespace、およびサービスなど、Red Hat サポートがお客様にとって有用なサポートを提供するのに役立つ設定の詳細
- クラスターにインストールされている OpenShift Container Platform フレームワークコンポーネントおよびそれらの状態とステータス
- 動作が低下した Operator の "関連オブジェクト" として一覧表示されるすべての namespace のイベント
- 動作が低下したソフトウェアに関する情報
- 証明書の有効性に関する情報
- OpenShift Container Platform がデプロイされているプラットフォームの名前およびデータセンターの場所
14.10.3.1.2. サイジング情報
- CPU コアの数およびそれぞれに使用される RAM の容量を含む、クラスター、マシンタイプ、およびマシンに関するサイジング情報
- クラスター内での実行中の仮想マシンインスタンスの数
- etcd メンバーの数および etcd クラスターに保存されるオブジェクトの数
- ビルドストラテジータイプ別のアプリケーションビルドの数
14.10.3.1.3. 使用情報
- コンポーネント、機能および拡張機能に関する使用率の情報
- テクノロジープレビューおよびサポート対象外の設定に関する使用率の詳細
Telemetry は、ユーザー名やパスワードなどの識別情報を収集しません。Red Hat は、意図的な個人情報の収集は行いません。誤って個人情報を受信したことが明らかになった場合、Red Hat はその情報を削除します。Telemetry データが個人データを設定する場合において、Red Hat のプライバシー方針については、Red Hat Privacy Statement を参照してください。
14.10.4. CLI のトラブルシューティングおよびデバッグコマンド
oc クライアントのトラブルシューティングおよびデバッグコマンドの一覧については、OpenShift Container Platform CLI ツール のドキュメントを参照してください。
14.11. クラスターチェックの実行
OpenShift Virtualization には、クラスターのメンテナンスとトラブルシューティングに使用できる定義済みのチェックアップが含まれています。
OpenShift Container Platform クラスターチェックアップフレームワークは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
14.11.1. OpenShift Container Platform クラスターチェックアップフレームワークについて
チェックアップは、特定のクラスター機能が期待どおりに機能するかどうかを確認できる自動テストワークロードです。クラスター検査フレームワークは、ネイティブの Kubernetes リソースを使用して、チェックアップを設定および実行します。
事前定義されたチェックアップを使用することで、クラスター管理者はクラスターの保守性を向上させ、予期しない動作をトラブルシューティングし、エラーを最小限に抑え、時間を節約できます。また、チェックアップの結果を確認し、専門家と共有してさらに分析することもできます。ベンダーは、提供する機能やサービスのチェックアップを作成して公開し、顧客環境が正しく設定されていることを確認できます。
既存の namespace で事前定義されたチェックアップを実行するには、チェックアップ用のサービスアカウントの設定、サービスアカウント用の Role および RoleBinding オブジェクトの作成、チェックアップのパーミッションの有効化、入力 config map とチェックアップジョブの作成が含まれます。チェックアップは複数回実行できます。
以下が常に必要になります。
- チェックアップイメージを適用する前に、信頼できるソースからのものであることを確認します。
-
RoleおよびRoleBindingオブジェクトを作成する前に、チェックアップパーミッションを確認してください。
14.11.2. セカンダリーネットワーク上の仮想マシンのネットワーク接続と遅延の確認
定義済みのチェックアップを使用して、ネットワーク接続を確認し、セカンダリーネットワークインターフェイスに接続されている 2 つの仮想マシン (VM) 間の待機時間を測定します。
初めてチェックアップを実行するには、手順のステップに従います。
以前にチェックアップを実行したことがある場合は、手順のステップ 5 にスキップしてください。これは、フレームワークをインストールしてチェックアップのパーミッションを有効にする手順は必要ないためです。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスターには少なくとも 2 つのワーカーノードがあります。
- Multus Container Network Interface (CNI) プラグインがクラスターにインストールされている。
- namespace のネットワーク接続定義を設定しました。
手順
ServiceAccount、Role、およびRoleBindingオブジェクトを含むマニフェストファイルを作成し、チェックアップでクラスターアクセスに必要なパーミッションを設定します。例14.3 ロールマニフェストファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow チェックアップロールマニフェストを適用します。
oc apply -n <target_namespace> -f <latency_roles>.yaml
$ oc apply -n <target_namespace> -f <latency_roles>.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<target_namespace>は、チェックアップを実行する namespace です。これは、NetworkAttachmentDefinitionオブジェクトが存在する既存の namespace である必要があります。
チェックアップの入力パラメーターを含む
ConfigMapマニフェストを作成します。config map は、フレームワークがチェックアップを実行するための入力を提供し、チェックアップの結果も保存します。入力 config map の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ターゲット namespace に config map マニフェストを適用します。
oc apply -n <target_namespace> -f <latency_config_map>.yaml
$ oc apply -n <target_namespace> -f <latency_config_map>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow チェックアップを実行する
Jobオブジェクトを作成します。ジョブマニフェストの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Jobマニフェストを適用します。チェックアップでは、ping ユーティリティーを使用して接続を確認し、レイテンシーを測定します。oc apply -n <target_namespace> -f <latency_job>.yaml
$ oc apply -n <target_namespace> -f <latency_job>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ジョブが完了するまで待ちます。
oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m
$ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、レイテンシーチェックアップの結果を確認します。測定された最大レイテンシーが
spec.param.max_desired_latency_milliseconds属性の値よりも大きい場合、チェックアップは失敗し、エラーが返されます。oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yaml
$ oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力 config map の例 (成功)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 測定された最大レイテンシー (ナノ秒)。
オプション: チェックアップが失敗した場合に詳細なジョブログを表示するには、次のコマンドを使用します。
oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>
$ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、以前に作成したジョブおよび設定マップリソースを削除します。
oc delete job -n <target_namespace> kubevirt-vm-latency-checkup
$ oc delete job -n <target_namespace> kubevirt-vm-latency-checkupCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config
$ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 別のチェックアップを実行する予定がない場合は、チェックアップロールとフレームワークマニフェストファイルを削除します。
oc delete -f <file_name>.yaml
$ oc delete -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.12. 仮想リソースの Prometheus クエリー
OpenShift Virtualization は、vCPU、ネットワーク、ストレージ、ゲストメモリースワッピングなどのクラスターインフラストラクチャーリソースの消費を監視するために使用できるメトリックを提供します。メトリックを使用して、ライブマイグレーションのステータスを照会することもできます。
OpenShift Container Platform モニタリングダッシュボードを使用して仮想化メトリックをクエリーします。
14.12.1. 前提条件
-
vCPU メトリックを使用するには、
schedstats=enableカーネル引数をMachineConfigオブジェクトに適用する必要があります。このカーネル引数を使用すると、デバッグとパフォーマンスチューニングに使用されるスケジューラーの統計が有効になり、スケジューラーに小規模な負荷を追加できます。カーネル引数の適用に関する詳細は、OpenShift Container Platform マシン設定タスク のドキュメントを参照してください。 - ゲストメモリースワップクエリーがデータを返すには、仮想ゲストでメモリースワップを有効にする必要があります。
14.12.2. メトリックのクエリー
OpenShift Container Platform モニタリングダッシュボードでは、Prometheus のクエリー言語 (PromQL) クエリーを実行し、プロットに可視化されるメトリックを検査できます。この機能により、クラスターの状態と、モニターしているユーザー定義のワークロードに関する情報が提供されます。
クラスター管理者 は、すべての OpenShift Container Platform のコアプロジェクトおよびユーザー定義プロジェクトのメトリックをクエリーできます。
開発者 として、メトリックのクエリー時にプロジェクト名を指定する必要があります。選択したプロジェクトのメトリックを表示するには、必要な権限が必要です。
14.12.2.1. クラスター管理者としてのすべてのプロジェクトのメトリクスのクエリー
クラスター管理者またはすべてのプロジェクトの表示権限を持つユーザーとして、メトリクス UI ですべてのデフォルト OpenShift Container Platform およびユーザー定義プロジェクトのメトリクスにアクセスできます。
前提条件
-
cluster-adminクラスターロールまたはすべてのプロジェクトの表示権限を持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Observe → Dashboards に移動します。
1 つ以上のクエリーを追加するために、次のいずれかの操作を実行します。
Expand オプション 説明 カスタムクエリーを作成します。
Prometheus Query Language (PromQL) クエリーを Expression フィールドに追加します。
PromQL 式を入力すると、オートコンプリートの提案がリストに表示されます。これらの提案には、関数、メトリクス、ラベル、および時間トークンが含まれます。キーボードの矢印を使用して提案された項目のいずれかを選択し、Enter を押して項目を式に追加できます。また、マウスポインターを推奨項目の上に移動して、その項目の簡単な説明を表示することもできます。
複数のクエリーを追加する
Add query をクリックします。
既存のクエリーを複製する
オプションメニューをクリックします
クエリーの横にある Duplicate query を選択します。
クエリーを削除します。
オプションメニューをクリックします
クエリーの横にある Delete query を選択します。
クエリーの実行を無効する
オプションメニューをクリックします
クエリーの横にある Disable query を選択します。
作成したクエリーを実行するために、Run queries をクリックします。クエリーからのメトリクスはプロットで可視化されます。クエリーが無効な場合は、UI にエラーメッセージが表示されます。
注記大量のデータで動作するクエリーは、時系列グラフの描画時にタイムアウトするか、ブラウザーをオーバーロードする可能性があります。これを回避するには、Hide graph をクリックし、メトリクステーブルのみを使用してクエリーを調整してください。次に、使用できるクエリーを確認した後に、グラフを描画できるようにプロットを有効にします。
- オプション: ページ URL には、実行したクエリーが含まれます。このクエリーのセットを再度使用できるようにするには、この URL を保存します。
14.12.2.2. 開発者が行うユーザー定義プロジェクトのメトリックのクエリー
ユーザー定義のプロジェクトのメトリクスには、開発者またはプロジェクトの表示権限を持つユーザーとしてアクセスできます。
Developer パースペクティブには、選択したプロジェクトの事前に定義された CPU、メモリー、帯域幅、およびネットワークパケットのクエリーが含まれます。また、プロジェクトの CPU、メモリー、帯域幅、ネットワークパケット、およびアプリケーションメトリクスについてカスタム Prometheus Query Language (PromQL) クエリーを実行することもできます。
開発者は Developer パースペクティブのみを使用でき、Administrator パースペクティブは使用できません。開発者は、Web コンソールの Observe -→ Metrics ページで一度に 1 つのプロジェクトのメトリックのみをクエリーできます。
前提条件
- 開発者として、またはメトリクスで表示しているプロジェクトの表示権限を持つユーザーとしてクラスターへのアクセスがある。
- ユーザー定義プロジェクトのモニタリングが有効化されている。
- ユーザー定義プロジェクトにサービスをデプロイしている。
-
サービスのモニター方法を定義するために、サービスの
ServiceMonitorカスタムリソース定義 (CRD) を作成している。
手順
- OpenShift Container Platform Web コンソールの Developer パースペクティブを選択します。
- Observe → Metrics の順に選択します。
- Project: 一覧でメトリックで表示するプロジェクトを選択します。
- Select query 一覧からクエリーを選択するか、Show PromQL を選択して、選択したクエリーに基づいてカスタム PromQL クエリーを作成します。
オプション: Select query リストから Custom query を選択し、新規クエリーを入力します。入力時に、オートコンプリートの提案がドロップダウンリストに表示されます。これらの提案には、関数およびメトリックが含まれます。推奨項目をクリックして選択します。
注記Developer パースペクティブでは、1 度に 1 つのクエリーのみを実行できます。
14.12.3. 仮想化メトリック
以下のメトリクスの記述には、Prometheus Query Language (PromQL) クエリーのサンプルが含まれます。これらのメトリクスは API ではなく、バージョン間で変更される可能性があります。
以下の例では、期間を指定する topk クエリーを使用します。その期間中に仮想マシンが削除された場合でも、クエリーの出力に依然として表示されます。
14.12.3.1. vCPU メトリック
以下のクエリーは、入出力 I/O) を待機している仮想マシンを特定します。
kubevirt_vmi_vcpu_wait_seconds- 仮想マシンの vCPU の待機時間 (秒単位) を返します。タイプ: カウンター。
'0' より大きい値は、仮想 CPU は実行する用意ができているが、ホストスケジューラーがこれをまだ実行できないことを意味します。実行できない場合には I/O に問題があることを示しています。
vCPU メトリックをクエリーするには、最初に schedstats=enable カーネル引数を MachineConfig オブジェクトに適用する必要があります。このカーネル引数を使用すると、デバッグとパフォーマンスチューニングに使用されるスケジューラーの統計が有効になり、スケジューラーに小規模な負荷を追加できます。
vCPU 待機時間クエリーの例
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_vcpu_wait_seconds[6m]))) > 0
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_vcpu_wait_seconds[6m]))) > 0 - 1
- このクエリーは、6 分間の任意の全タイミングで I/O を待機する上位 3 の仮想マシンを返します。
14.12.3.2. ネットワークメトリック
以下のクエリーは、ネットワークを飽和状態にしている仮想マシンを特定できます。
kubevirt_vmi_network_receive_bytes_total- 仮想マシンのネットワークで受信したトラフィックの合計量 (バイト単位) を返します。タイプ: カウンター。
kubevirt_vmi_network_transmit_bytes_total- 仮想マシンのネットワーク上で送信されるトラフィックの合計量 (バイト単位) を返します。タイプ: カウンター。
ネットワークトラフィッククエリーの例
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_network_receive_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_network_transmit_bytes_total[6m]))) > 0
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_network_receive_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_network_transmit_bytes_total[6m]))) > 0 - 1
- このクエリーは、6 分間の任意のタイミングで最大のネットワークトラフィックを送信する上位 3 の仮想マシンを返します。
14.12.3.3. ストレージメトリクス
14.12.3.3.1. ストレージ関連のトラフィック
以下のクエリーは、大量のデータを書き込んでいる仮想マシンを特定できます。
kubevirt_vmi_storage_read_traffic_bytes_total- 仮想マシンのストレージ関連トラフィックの合計量 (バイト単位) を返します。タイプ: カウンター。
kubevirt_vmi_storage_write_traffic_bytes_total- 仮想マシンのストレージ関連トラフィックのストレージ書き込みの合計量 (バイト単位) を返します。タイプ: カウンター。
ストレージ関連のトラフィッククエリーの例
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_storage_read_traffic_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_storage_write_traffic_bytes_total[6m]))) > 0
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_storage_read_traffic_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_storage_write_traffic_bytes_total[6m]))) > 0 - 1
- 上記のクエリーは、6 分間の任意のタイミングで最も大きなストレージトラフィックを送信する上位 3 の仮想マシンを返します。
14.12.3.3.2. ストレージスナップショットデータ
kubevirt_vmsnapshot_disks_restored_from_source_total- ソース仮想マシンから復元された仮想マシンディスクの総数を返します。タイプ: ゲージ。
kubevirt_vmsnapshot_disks_restored_from_source_bytes- ソース仮想マシンから復元された容量をバイト単位で返します。タイプ: ゲージ。
ストレージスナップショットデータクエリーの例
kubevirt_vmsnapshot_disks_restored_from_source_total{vm_name="simple-vm", vm_namespace="default"}
kubevirt_vmsnapshot_disks_restored_from_source_total{vm_name="simple-vm", vm_namespace="default"} - 1
- このクエリーは、ソース仮想マシンから復元された仮想マシンディスクの総数を返します。
kubevirt_vmsnapshot_disks_restored_from_source_bytes{vm_name="simple-vm", vm_namespace="default"}
kubevirt_vmsnapshot_disks_restored_from_source_bytes{vm_name="simple-vm", vm_namespace="default"} - 1
- このクエリーは、ソース仮想マシンから復元された容量をバイト単位で返します。
14.12.3.3.3. I/O パフォーマンス
以下のクエリーで、ストレージデバイスの I/O パフォーマンスを判別できます。
kubevirt_vmi_storage_iops_read_total- 仮想マシンが実行している 1 秒あたりの書き込み I/O 操作の量を返します。タイプ: カウンター。
kubevirt_vmi_storage_iops_write_total- 仮想マシンが実行している 1 秒あたりの読み取り I/O 操作の量を返します。タイプ: カウンター。
I/O パフォーマンスクエリーの例
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_storage_iops_read_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_storage_iops_write_total[6m]))) > 0
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_storage_iops_read_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_storage_iops_write_total[6m]))) > 0 - 1
- 上記のクエリーは、6 分間の任意のタイミングで最も大きな I/O 操作を実行している上位 3 の仮想マシンを返します。
14.12.3.4. ゲストメモリーのスワップメトリクス
以下のクエリーにより、メモリースワップを最も多く実行しているスワップ対応ゲストを特定できます。
kubevirt_vmi_memory_swap_in_traffic_bytes_total- 仮想ゲストがスワップされているメモリーの合計量 (バイト単位) を返します。タイプ: ゲージ。
kubevirt_vmi_memory_swap_out_traffic_bytes_total- 仮想ゲストがスワップアウトされているメモリーの合計量 (バイト単位) を返します。タイプ: ゲージ。
メモリースワップクエリーの例
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_memory_swap_in_traffic_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_memory_swap_out_traffic_bytes_total[6m]))) > 0
topk(3, sum by (name, namespace) (rate(kubevirt_vmi_memory_swap_in_traffic_bytes_total[6m])) + sum by (name, namespace) (rate(kubevirt_vmi_memory_swap_out_traffic_bytes_total[6m]))) > 0 - 1
- 上記のクエリーは、6 分間の任意のタイミングでゲストが最も大きなメモリースワップを実行している上位 3 の仮想マシンを返します。
メモリースワップは、仮想マシンがメモリー不足の状態にあることを示します。仮想マシンのメモリー割り当てを増やすと、この問題を軽減できます。
14.12.4. ライブマイグレーションのメトリクス
次のメトリックをクエリーして、ライブマイグレーションのステータスを表示できます。
kubevirt_migrate_vmi_data_processed_bytes- 新しい仮想マシン (VM) に移行されたゲストオペレーティングシステム (OS) データの量。タイプ: ゲージ。
kubevirt_migrate_vmi_data_remaining_bytes- 移行されていないゲスト OS データの量。タイプ: ゲージ。
kubevirt_migrate_vmi_dirty_memory_rate_bytes- ゲスト OS でメモリーがダーティになる速度。ダーティメモリーとは、変更されたがまだディスクに書き込まれていないデータです。タイプ: ゲージ。
kubevirt_migrate_vmi_pending_count- 保留中の移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_scheduling_count- スケジュール移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_running_count- 実行中の移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_succeeded- 正常に完了した移行の数。タイプ: ゲージ。
kubevirt_migrate_vmi_failed- 失敗した移行の数。タイプ: ゲージ。
14.13. 仮想マシンのカスタムメトリクスの公開
OpenShift Container Platform には、コアプラットフォームコンポーネントのモニタリングを提供する事前に設定され、事前にインストールされた自己更新型のモニタリングスタックが含まれます。このモニタリングスタックは、Prometheus モニタリングシステムをベースにしています。Prometheus は Time Series を使用するデータベースであり、メトリクスのルール評価エンジンです。
OpenShift Container Platform モニタリングスタックの使用のほかに、CLI を使用してユーザー定義プロジェクトのモニタリングを有効にし、node-exporter サービスで仮想マシン用に公開されるカスタムメトリックをクエリーできます。
14.13.1. ノードエクスポーターサービスの設定
node-exporter エージェントは、メトリクスを収集するクラスター内のすべての仮想マシンにデプロイされます。node-exporter エージェントをサービスとして設定し、仮想マシンに関連付けられた内部メトリクスおよびプロセスを公開します。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 -
cluster-monitoring-configConfigMapオブジェクトをopenshift-monitoringプロジェクトに作成する。 -
enableUserWorkloadをtrueに設定して、user-workload-monitoring-configConfigMapオブジェクトをopenshift-user-workload-monitoringプロジェクトに設定する。
手順
ServiceYAML ファイルを作成します。以下の例では、このファイルはnode-exporter-service.yamlという名前です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 仮想マシンからメトリクスを公開する node-exporter サービス。
- 2
- サービスが作成される namespace。
- 3
- サービスのラベル。
ServiceMonitorはこのラベルを使用してこのサービスを照会します。 - 4
ClusterIPサービスのポート 9100 でメトリクスを公開するポートに指定された名前。- 5
- リクエストをリッスンするために
node-exporter-serviceによって使用されるターゲットポート。 - 6
monitorラベルが設定された仮想マシンの TCP ポート番号。- 7
- 仮想マシンの Pod を照会するために使用されるラベル。この例では、ラベル
monitorのある仮想マシンの Pod と、metricsの値がマッチします。
node-exporter サービスを作成します。
oc create -f node-exporter-service.yaml
$ oc create -f node-exporter-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.13.2. ノードエクスポーターサービスが設定された仮想マシンの設定
node-exporter ファイルを仮想マシンにダウンロードします。次に、仮想マシンの起動時に node-exporter サービスを実行する systemd サービスを作成します。
前提条件
-
コンポーネントの Pod は
openshift-user-workload-monitoringプロジェクトで実行されます。 -
このユーザー定義プロジェクトをモニターする必要のあるユーザーに
monitoring-editロールを付与します。
手順
- 仮想マシンにログインします。
node-exporterファイルのバージョンに適用されるディレクトリーパスを使用して、node-exporterファイルを仮想マシンにダウンロードします。wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
$ wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow 実行ファイルを展開して、
/usr/binディレクトリーに配置します。sudo tar xvf node_exporter-1.3.1.linux-amd64.tar.gz \ --directory /usr/bin --strip 1 "*/node_exporter"$ sudo tar xvf node_exporter-1.3.1.linux-amd64.tar.gz \ --directory /usr/bin --strip 1 "*/node_exporter"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ディレクトリーのパス
/etc/systemd/systemにnode_exporter.serviceファイルを作成します。このsystemdサービスファイルは、仮想マシンの再起動時に node-exporter サービスを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemdサービスを有効にし、起動します。sudo systemctl enable node_exporter.service sudo systemctl start node_exporter.service
$ sudo systemctl enable node_exporter.service $ sudo systemctl start node_exporter.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
node-exporter エージェントが仮想マシンからのメトリクスを報告していることを確認します。
curl http://localhost:9100/metrics
$ curl http://localhost:9100/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
go_gc_duration_seconds{quantile="0"} 1.5244e-05 go_gc_duration_seconds{quantile="0.25"} 3.0449e-05 go_gc_duration_seconds{quantile="0.5"} 3.7913e-05go_gc_duration_seconds{quantile="0"} 1.5244e-05 go_gc_duration_seconds{quantile="0.25"} 3.0449e-05 go_gc_duration_seconds{quantile="0.5"} 3.7913e-05Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.13.3. 仮想マシンのカスタムモニタリングラベルの作成
単一サービスから複数の仮想マシンに対するクエリーを有効にするには、仮想マシンの YAML ファイルにカスタムラベルを追加します。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - 仮想マシンを停止および再起動するための Web コンソールへのアクセス権限がある。
手順
仮想マシン設定ファイルの
templatespec を編集します。この例では、ラベルmonitorの値がmetricsになります。spec: template: metadata: labels: monitor: metricsspec: template: metadata: labels: monitor: metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
仮想マシンを停止して再起動し、
monitorラベルに指定されたラベル名を持つ新しい Pod を作成します。
14.13.3.1. メトリクスを取得するための node-exporter サービスのクエリー
仮想マシンのメトリクスは、/metrics の正規名の下に HTTP サービスエンドポイント経由で公開されます。メトリクスのクエリー時に、Prometheus は仮想マシンによって公開されるメトリクスエンドポイントからメトリクスを直接収集し、これらのメトリクスを確認用に表示します。
前提条件
-
cluster-admin権限を持つユーザーまたはmonitoring-editロールを持つユーザーとしてクラスターにアクセスできる。 - node-exporter サービスを設定して、ユーザー定義プロジェクトのモニタリングを有効にしている。
手順
サービスの namespace を指定して、HTTP サービスエンドポイントを取得します。
oc get service -n <namespace> <node-exporter-service>
$ oc get service -n <namespace> <node-exporter-service>Copy to Clipboard Copied! Toggle word wrap Toggle overflow node-exporter サービスの利用可能なすべてのメトリクスを一覧表示するには、
metricsリソースをクエリーします。curl http://<172.30.226.162:9100>/metrics | grep -vE "^#|^$"
$ curl http://<172.30.226.162:9100>/metrics | grep -vE "^#|^$"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.13.4. ノードエクスポーターサービスの ServiceMonitor リソースの作成
Prometheus クライアントライブラリーを使用し、/metrics エンドポイントからメトリクスを収集して、node-exporter サービスが公開するメトリクスにアクセスし、表示できます。ServiceMonitor カスタムリソース定義 (CRD) を使用して、ノードエクスポーターサービスをモニターします。
前提条件
-
cluster-admin権限を持つユーザーまたはmonitoring-editロールを持つユーザーとしてクラスターにアクセスできる。 - node-exporter サービスを設定して、ユーザー定義プロジェクトのモニタリングを有効にしている。
手順
ServiceMonitorリソース設定の YAML ファイルを作成します。この例では、サービスモニターはラベルmetricsが指定されたサービスとマッチし、30 秒ごとにexmetポートをクエリーします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow node-exporter サービスの
ServiceMonitor設定を作成します。oc create -f node-exporter-metrics-monitor.yaml
$ oc create -f node-exporter-metrics-monitor.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.13.4.1. クラスター外のノードエクスポーターサービスへのアクセス
クラスター外の node-exporter サービスにアクセスし、公開されるメトリクスを表示できます。
前提条件
-
cluster-admin権限を持つユーザーまたはmonitoring-editロールを持つユーザーとしてクラスターにアクセスできる。 - node-exporter サービスを設定して、ユーザー定義プロジェクトのモニタリングを有効にしている。
手順
node-exporter サービスを公開します。
oc expose service -n <namespace> <node_exporter_service_name>
$ oc expose service -n <namespace> <node_exporter_service_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートの FQDN(完全修飾ドメイン名) を取得します。
oc get route -o=custom-columns=NAME:.metadata.name,DNS:.spec.host
$ oc get route -o=custom-columns=NAME:.metadata.name,DNS:.spec.hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DNS node-exporter-service node-exporter-service-dynamation.apps.cluster.example.org
NAME DNS node-exporter-service node-exporter-service-dynamation.apps.cluster.example.orgCopy to Clipboard Copied! Toggle word wrap Toggle overflow curlコマンドを使用して、node-exporter サービスのメトリクスを表示します。curl -s http://node-exporter-service-dynamation.apps.cluster.example.org/metrics
$ curl -s http://node-exporter-service-dynamation.apps.cluster.example.org/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
go_gc_duration_seconds{quantile="0"} 1.5382e-05 go_gc_duration_seconds{quantile="0.25"} 3.1163e-05 go_gc_duration_seconds{quantile="0.5"} 3.8546e-05 go_gc_duration_seconds{quantile="0.75"} 4.9139e-05 go_gc_duration_seconds{quantile="1"} 0.000189423go_gc_duration_seconds{quantile="0"} 1.5382e-05 go_gc_duration_seconds{quantile="0.25"} 3.1163e-05 go_gc_duration_seconds{quantile="0.5"} 3.8546e-05 go_gc_duration_seconds{quantile="0.75"} 4.9139e-05 go_gc_duration_seconds{quantile="1"} 0.000189423Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.14. OpenShift Virtualization の runbook
OpenShift Virtualization Operator の runbook は、openshift/runbooks Git リポジトリーで管理されており、GitHub で表示できます。OpenShift Virtualization アラート をトリガーする問題を診断して解決するには、runbook の手順に従います。
OpenShift Virtualization のアラートは、Web コンソールの Virtualization → Overview タブに表示されます。
14.14.1. CDIDataImportCronOutdated
-
CDIDataImportCronOutdatedアラートの runbook を表示 します。
14.14.2. CDIDataVolumeUnusualRestartCount
-
CDIDataVolumeUnusualRestartCountアラートの runbook を表示 します。
14.14.3. CDIDefaultStorageClassDegraded
-
CDIDefaultStorageClassDegradedアラートの runbook を表示 します。
14.14.4. CDIMultipleDefaultVirtStorageClasses
-
CDIMultipleDefaultVirtStorageClassesアラートの runbook を表示 します。
14.14.5. CDINoDefaultStorageClass
-
CDINoDefaultStorageClassアラートの runbook を表示 します。
14.14.6. CDINotReady
-
CDINotReadyアラートの runbook を表示 します。
14.14.7. CDIOperatorDown
-
CDIOperatorDownアラートの runbook を表示 します。
14.14.8. CDIStorageProfilesIncomplete
-
CDIStorageProfilesIncompleteアラートの runbook を表示 します。
14.14.9. CnaoDown
-
CnaoDownアラートの runbook を表示 します。
14.14.10. CnaoNMstateMigration
-
CnaoNMstateMigrationアラートの runbook を表示 します。
14.14.11. HCOInstallationIncomplete
-
HCOInstallationIncompleteアラートの runbook を表示 します。
14.14.12. HPPNotReady
-
HPPNotReadyアラートの runbook を表示します。
14.14.13. HPPOperatorDown
-
HPPOperatorDownアラートの runbook を表示 します。
14.14.14. HPPSharingPoolPathWithOS
-
HPPSharingPoolPathWithOSアラートの runbook を表示 します。
14.14.15. KubemacpoolDown
-
KubemacpoolDownアラートの runbook を表示 します。
14.14.16. KubeMacPoolDuplicateMacsFound
-
KubeMacPoolDuplicateMacsFoundアラートの runbook を表示 します。
14.14.17. KubeVirtComponentExceedsRequestedCPU
-
KubeVirtComponentExceedsRequestedCPUアラートが 非推奨 になりました。
14.14.18. KubeVirtComponentExceedsRequestedMemory
-
KubeVirtComponentExceedsRequestedMemoryアラートは 非推奨 になりました。
14.14.19. KubeVirtCRModified
-
KubeVirtCRModifiedアラートの runbook を表示 します。
14.14.20. KubeVirtDeprecatedAPIRequested
-
KubeVirtDeprecatedAPIRequestedアラートの runbook を表示 します。
14.14.21. KubeVirtNoAvailableNodesToRunVMs
-
KubeVirtNoAvailableNodesToRunVMsアラートの runbook を表示 します。
14.14.22. KubevirtVmHighMemoryUsage
-
KubevirtVmHighMemoryUsageアラートの runbook を表示 します。
14.14.23. KubeVirtVMIExcessiveMigrations
-
KubeVirtVMIExcessiveMigrationsアラートの runbook を表示 します。
14.14.24. LowKVMNodesCount
-
LowKVMNodesCountアラートの runbook を表示 します。
14.14.25. LowReadyVirtControllersCount
-
LowReadyVirtControllersCountアラートの runbook を表示 します。
14.14.26. LowReadyVirtOperatorsCount
-
LowReadyVirtOperatorsCountアラートの runbook を表示 します。
14.14.27. LowVirtAPICount
-
LowVirtAPICountアラートの runbook を表示 します。
14.14.28. LowVirtControllersCount
-
LowVirtControllersCountアラートの runbook を表示 します。
14.14.29. LowVirtOperatorCount
-
LowVirtOperatorCountアラートの runbook を表示 します。
14.14.30. NetworkAddonsConfigNotReady
-
NetworkAddonsConfigNotReadyアラートの runbook を表示 します。
14.14.31. NoLeadingVirtOperator
-
NoLeadingVirtOperatorアラートの runbook を表示 します。
14.14.32. NoReadyVirtController
-
NoReadyVirtControllerアラートの runbook を表示 します。
14.14.33. NoReadyVirtOperator
-
NoReadyVirtOperatorアラートの runbook を表示 します。
14.14.34. OrphanedVirtualMachineInstances
-
OrphanedVirtualMachineInstancesアラートの runbook を表示 します。
14.14.35. OutdatedVirtualMachineInstanceWorkloads
-
OutdatedVirtualMachineInstanceWorkloadsアラートの runbook を表示 します。
14.14.36. SingleStackIPv6Unsupported
-
SingleStackIPv6Unsupportedアラートの runbook を表示 します。
14.14.37. SSPCommonTemplatesModificationReverted
-
SSPCommonTemplatesModificationRevertedアラートの runbook を表示 します。
14.14.38. SSPDown
-
SSPDownアラートの runbook を表示 します。
14.14.39. SSPFailingToReconcile
-
SSPFailingToReconcileアラートの runbook を表示します。
14.14.40. SSPHighRateRejectedVms
-
SSPHighRateRejectedVmsアラートの runbook を表示 します。
14.14.41. SSPTemplateValidatorDown
-
SSPTemplateValidatorDownアラートの runbook を表示 します。
14.14.42. UnsupportedHCOModification
-
UnsupportedHCOModificationアラートの runbook を表示 します。
14.14.43. VirtAPIDown
-
VirtAPIDownアラートの runbook を表示 します。
14.14.44. VirtApiRESTErrorsBurst
-
VirtApiRESTErrorsBurstアラートの runbook を表示 します。
14.14.45. VirtApiRESTErrorsHigh
-
VirtApiRESTErrorsHighアラートの runbook を表示 します。
14.14.46. VirtControllerDown
-
VirtControllerDownアラートの runbook を表示 します。
14.14.47. VirtControllerRESTErrorsBurst
-
VirtControllerRESTErrorsBurstアラートの runbook を表示 します。
14.14.48. VirtControllerRESTErrorsHigh
-
VirtControllerRESTErrorsHighアラートの runbook を表示 します。
14.14.49. VirtHandlerDaemonSetRolloutFailing
-
VirtHandlerDaemonSetRolloutFailingアラートの runbook を表示 します。
14.14.50. VirtHandlerRESTErrorsBurst
-
VirtHandlerRESTErrorsBurstアラートの runbook を表示 します。
14.14.51. VirtHandlerRESTErrorsHigh
-
VirtHandlerRESTErrorsHighアラートの runbook を表示 します。
14.14.52. VirtOperatorDown
-
VirtOperatorDownアラートの runbook を表示 します。
14.14.53. VirtOperatorRESTErrorsBurst
-
VirtOperatorRESTErrorsBurstアラートの runbook を表示 します。
14.14.54. VirtOperatorRESTErrorsHigh
-
VirtOperatorRESTErrorsHighアラートの runbook を表示 します。
14.14.55. VirtualMachineCRCErrors
VirtualMachineCRCErrorsアラートの runbook は、アラートの名前がVMStorageClassWarningに変更されたため非推奨になりました。-
VMStorageClassWarningアラートの runbook を表示 します。
-
14.14.56. VMCannotBeEvicted
-
VMCannotBeEvictedアラートの runbook を表示 します。
14.14.57. VMStorageClassWarning
-
VMStorageClassWarningアラートの runbook を表示 します。
14.15. Red Hat サポート用のデータ収集
Red Hat サポートに サポートケース を送信する際に、以下のツールを使用して OpenShift Container Platform と OpenShift Virtualization のデバッグ情報を提供すると役立ちます。
- must-gather ツール
-
must-gatherツールは、リソース定義やサービスログなどの診断情報を収集します。 - Prometheus
- Prometheus は Time Series を使用するデータベースであり、メトリクスのルール評価エンジンです。Prometheus は処理のためにアラートを Alertmanager に送信します。
- Alertmanager
- Alertmanager サービスは、Prometheus から送信されるアラートを処理します。また、Alertmanager は外部の通知システムにアラートを送信します。
14.15.1. 環境に関するデータの収集
環境に関するデータを収集すると、根本原因の分析および特定に必要な時間が最小限に抑えられます。
前提条件
- Prometheus メトリックデータの保持期間を最低 7 日間に設定します。
- Alertmanager を設定して、関連するアラートを取得して、それらを専用のメールボックスに送信して、クラスター外で表示および保持できるようにします。
- 影響を受けるノードおよび仮想マシンの正確な数を記録します。
手順
-
デフォルトの
must-gatherイメージを使用して、クラスターのmust-gatherデータを収集します。 -
必要に応じて、Red Hat OpenShift Data Foundation の
must-gatherデータを収集します。 -
OpenShift Virtualization の
must-gatherイメージを使用して、OpenShift Virtualization のmust-gatherデータを収集します。 - クラスターの Prometheus メトリックを収集します。
14.15.2. 仮想マシンに関するデータの収集
仮想マシン (VM) の誤動作に関するデータを収集することで、根本原因の分析および特定に必要な時間を最小限に抑えることができます。
前提条件
Windows 仮想マシン:
- Red Hat サポート用に Windows パッチ更新の詳細を記録します。
- VirtIO ドライバーの最新バージョンをインストールします。VirtIO ドライバーには、QEMU ゲストエージェントが含まれています。
- リモートデスクトッププロトコル (RDP) が有効になっている場合は、RDP を使用して仮想マシンに接続し、接続ソフトウェアに問題があるかどうかを判断します。
手順
-
誤動作している仮想マシンに関する詳細な
must-gatherを収集します。 - 仮想マシンを再起動する前に、クラッシュした仮想マシンのスクリーンショットを収集します。
- 誤動作している仮想マシンに共通する要因を記録します。たとえば、仮想マシンには同じホストまたはネットワークがあります。
14.15.3. OpenShift Virtualization の must-gather ツールの使用
OpenShift Virtualization イメージで must-gather コマンドを実行することにより、OpenShift Virtualization リソースに関するデータを収集できます。
デフォルトのデータ収集には、次のリソースに関する情報が含まれています。
- 子オブジェクトを含む OpenShift Virtualization Operator namespace
- すべての OpenShift Virtualization カスタムリソース定義
- 仮想マシンを含むすべての namespace
- 基本的な仮想マシン定義
手順
以下のコマンドを実行して、OpenShift Virtualization に関するデータを収集します。
oc adm must-gather --image-stream=openshift/must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16
$ oc adm must-gather --image-stream=openshift/must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.15.3.1. must-gather ツールオプション
次のオプションに対して、スクリプトおよび環境変数の組み合わせを指定できます。
- namespace から詳細な仮想マシン (VM) 情報の収集する
- 特定の仮想マシンに関する詳細情報の収集
- image、image-stream、および image-stream-tags 情報の収集
-
must-gatherツールが使用する並列プロセスの最大数の制限
14.15.3.1.1. パラメーター
環境変数
互換性のあるスクリプトの環境変数を指定できます。
NS=<namespace_name>-
指定した namespace から
virt-launcherPod の詳細を含む仮想マシン情報を収集します。VirtualMachineおよびVirtualMachineInstanceCR データはすべての namespace で収集されます。 VM=<vm_name>-
特定の仮想マシンに関する詳細を収集します。このオプションを使用するには、
NS環境変数を使用して namespace も指定する必要があります。 PROS=<number_of_processes>must-gatherツールが使用する並列処理の最大数を変更します。デフォルト値は5です。重要並列処理が多すぎると、パフォーマンスの問題が発生する可能性があります。並列処理の最大数を増やすことは推奨されません。
スクリプト
各スクリプトは、特定の環境変数の組み合わせとのみ互換性があります。
/usr/bin/gather-
デフォルトの
must-gatherスクリプトを使用します。すべての namespace からクラスターデータが収集され、基本的な仮想マシン情報のみが含まれます。このスクリプトは、PROS変数とのみ互換性があります。 /usr/bin/gather --vms_details-
OpenShift Virtualization リソースに属する VM ログファイル、VM 定義、コントロールプレーンログ、および namespace を収集します。namespace の指定には、その子オブジェクトが含まれます。namespace または仮想マシンを指定せずにこのパラメーターを使用する場合、
must-gatherツールはクラスター内のすべての仮想マシンについてこのデータを収集します。このスクリプトはすべての環境変数と互換性がありますが、VM変数を使用する場合は namespace を指定する必要があります。 /usr/bin/gather --images-
image、image-stream、および image-stream-tags カスタムリソース情報を収集します。このスクリプトは、
PROS変数とのみ互換性があります。
14.15.3.1.2. 使用方法および例
環境変数はオプションです。スクリプトは、単独で実行することも、1 つ以上の互換性のある環境変数を使用して実行することもできます。
| スクリプト | 互換性のある環境変数 |
|---|---|
|
|
|
|
|
|
|
|
|
構文
oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16 \ -- <environment_variable_1> <environment_variable_2> <script_name>
$ oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16 \
-- <environment_variable_1> <environment_variable_2> <script_name>デフォルトのデータ収集の並列プロセス
デフォルトでは、5 つのプロセスを並行して実行します。
oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16 \ -- PROS=5 /usr/bin/gather
$ oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16 \
-- PROS=5 /usr/bin/gather - 1
- デフォルトを変更することで、並列プロセスの数を変更できます。
詳細な仮想マシン情報
次のコマンドは、mynamespace namespace にある my-vm 仮想マシンの詳細な仮想マシン情報を収集します。
oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16 \ -- NS=mynamespace VM=my-vm /usr/bin/gather --vms_details
$ oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16 \
-- NS=mynamespace VM=my-vm /usr/bin/gather --vms_details - 1
VM環境変数を使用する場合、NS環境変数は必須です。
image、image-stream、および image-stream-tags 情報
以下のコマンドは、クラスターからイメージ、image-stream、および image-stream-tags 情報を収集します。
oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16 \ -- /usr/bin/gather --images
$ oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.16 \
-- /usr/bin/gather --images第15章 バックアップおよび復元
15.1. OADP のインストールおよび設定
クラスター管理者は、OADP Operator をインストールして、OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.12 をインストールします。
バックアップストレージプロバイダーのデフォルトの Secret を作成し、Data Protection Application をインストールします。
15.1.1. OADP Operator のインストール
Operator Lifecycle Manager (OLM) を使用して、OpenShift Container Platform 4.12 に OpenShift API for Data Protection (OADP) オペレーターをインストールします。
OADP Operator は Velero 1.12 をインストールします。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドを使用して、OADP Operator を検索します。
- OADP Operator を選択し、Install をクリックします。
-
Install をクリックして、
openshift-adpプロジェクトに Operator をインストールします。 - Operators → Installed Operators をクリックして、インストールを確認します。
15.1.2. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
バックアップの場所として、Multicloud Object Gateway、Ceph RADOS Gateway (Ceph Object Gateway とも呼ばれます)、MinIO などの AWS S3 互換オブジェクトストレージを指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplicationCR で指定する、バックアップの場所用のカスタムSecret。 -
DataProtectionApplicationCR で参照されない、スナップショットの場所用のデフォルトSecret。
Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。
15.1.2.1. デフォルト Secret の作成
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。
インストール時にバックアップの場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用してデフォルト名前で Secret を作成できます。
前提条件
- オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
- Velero のオブジェクトストレージを設定する必要があります。
-
オブジェクトストレージ用の
credentials-veleroファイルを適切な形式で作成する必要があります。
手順
デフォルト名で
Secretを作成します。oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-veleroCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。
15.1.3. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
15.1.3.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
15.1.3.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplicationCR マニフェストのspec.backupLocations.velero.objectStorage.caCertパラメーターとspec.backupLocations.velero.configパラメーターを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.1.4. Data Protection Application のインストール
DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。
前提条件
- OADP Operator をインストールする。
- オブジェクトストレージをバックアップロケーションとして設定する必要がある。
- スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
-
バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である
cloud-credentialsを使用してSecretを作成する必要がある。 バックアップとスナップショットの場所で異なる認証情報を使用する場合は、以下のように 2 つの
Secretsを作成する必要がある。-
バックアップの場所用のカスタム名を持つ
Secret。このSecretをDataProtectionApplicationCR に追加します。 スナップショットの場所のデフォルト名である
cloud-credentialsのSecret。このSecretは、DataProtectionApplicationCR では参照されません。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-veleroファイルを使用してデフォルトのSecretを作成できます。デフォルトのSecretがない場合、インストールは失敗します。注記Velero は、OADP namespace に
velero-repo-credentialsという名前のシークレットを作成します。これには、デフォルトのバックアップリポジトリーパスワードが含まれます。バックアップリポジトリーを対象とした最初のバックアップを実行する 前 に、base64 としてエンコードされた独自のパスワードを使用してシークレットを更新できます。更新するキーの値はData[repository-password]です。DPA を作成した後、バックアップリポジトリーを対象としたバックアップを初めて実行するときに、Velero はシークレットが
velero-repo-credentialsのバックアップリポジトリーを作成します。これには、デフォルトのパスワードまたは置き換えたパスワードが含まれます。最初のバックアップの 後 にシークレットパスワードを更新すると、新しいパスワードがvelero-repo-credentialsのパスワードと一致しなくなり、Velero は古いバックアップに接続できなくなります。
-
バックアップの場所用のカスタム名を持つ
手順
- Operators → Installed Operators をクリックして、OADP Operator を選択します。
- Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
YAML View をクリックして、
DataProtectionApplicationマニフェストのパラメーターを更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
kubevirtプラグインは OpenShift Virtualization に必須です。- 2
- バックアッププロバイダーのプラグインがある場合には、それを指定します (例:
gcp)。 - 3
- CSI スナップショットを使用して PV をバックアップするには、
csiプラグインが必須です。csiプラグインは、Velero CSI ベータスナップショット API を使用します。スナップショットの場所を設定する必要はありません。 - 4
openshiftプラグインは必須です。- 5
- Velero CRD の可用性、volumeSnapshot の削除、バックアップリポジトリーの可用性など、タイムアウトが発生するまでに複数の Velero リソースを待機する時間を分単位で指定します。デフォルトは 10m です。
- 6
- Restic インストールを無効にする場合は、この値を
falseに設定します。Restic はデーモンセットをデプロイします。これは、Restic Pod が各動作ノードで実行していることを意味します。OADP バージョン 1.2 以降では、spec.defaultVolumesToFsBackup: trueをBackupCR に追加することで、バックアップ用に Restic を設定できます。OADP バージョン 1.1 では、spec.defaultVolumesToRestic: trueをBackupCR に追加します。 - 7
- Restic を使用できるノードを指定します。デフォルトでは、Restic はすべてのノードで実行されます。
- 8
- バックアッププロバイダーを指定します。
- 9
- バックアッププロバイダーにデフォルトのプラグインを使用する場合は、
Secretの正しいデフォルト名を指定します (例:cloud-credentials-gcp)。カスタム名を指定すると、そのカスタム名がバックアップの場所に使用されます。Secret名を指定しない場合は、デフォルトの名前が使用されます。 - 10
- バックアップ保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
- 11
- バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例:
velero)。
- Create をクリックします。
OADP リソースを表示して、インストールを確認します。
oc get all -n openshift-adp
$ oc get all -n openshift-adpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.1.4.1. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplicationCR を編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
csiデフォルトプラグインを追加します。
15.1.5. OADP のアンインストール
OpenShift API for Data Protection (OADP) をアンインストールするには、OADP Operator を削除します。詳細は、クラスターからの Operators の削除 を参照してください。
15.2. 仮想マシンのバックアップと復元
OpenShift Virtualization の OADP は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
OpenShift API for Data Protection (OADP) を使用して、仮想マシンをバックアップおよび復元します。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
- ストレージプロバイダーの指示に従って、OADP Operator をインストールします。
-
kubevirtおよびopenshiftプラグイン を使用して データ保護アプリケーション をインストールします。 -
Backupカスタムリソース (CR) を作成して、仮想マシンをバックアップします。 -
RestoreCR を作成して、BackupCR を復元します。
15.3. 仮想マシンのバックアップ
OpenShift Virtualization の OADP は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
OpenShift API for Data Protection (OADP) の Backup カスタムリソース (CR) を作成して、仮想マシン (VM) をバックアップします。
Backup CR は以下のアクションを実行します。
- Multicloud Object Gateway、Noobaa、または Minio などの S3 互換オブジェクトストレージにアーカイブファイルを作成して、OpenShift Virtualization リソースをバックアップします。
以下のオプションのいずれかを使用して、仮想マシンディスクをバックアップします。
- Ceph RBD または Ceph FS などの CSI 対応クラウドストレージ上の Container Storage Interface (CSI) スナップショット。
- ファイルシステムバックアップを使用してアプリケーションをバックアップします。オブジェクトストレージ上の Kopia または Restic。
OADP はバックアップフックを提供し、バックアップ操作の前に仮想マシンのファイルシステムをフリーズし、バックアップの完了時にフリーズを解除します。
kubevirt-controller は、バックアップ操作の前後に Velero が virt-freezer バイナリーを実行できるようにするアノテーションで virt-launcher Pod を作成します。
freeze および unfreeze API は、仮想マシンスナップショット API のサブリソースです。詳細は、仮想マシンのスナップショットについてを参照してください。
フックを Backup CR に追加して、バックアップ操作の前後に特定の仮想マシンでコマンドを実行できます。
Backup CR の代わりに Schedule CR を作成することにより、バックアップをスケジュールします。
15.3.1. Backup CR の作成
Kubernetes リソース、内部イメージ、および永続ボリューム(PV)をバックアップするには、Backup カスタムリソース(CR)を作成します。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplicationCR がReady状態である。 バックアップロケーションの前提条件:
- Velero 用に S3 オブジェクトストレージを設定する必要があります。
-
DataProtectionApplicationCR でバックアップの場所を設定する必要があります。
スナップショットの場所の前提条件:
- クラウドプロバイダーには、ネイティブスナップショット API が必要であるか、Container Storage Interface (CSI) スナップショットをサポートしている必要があります。
-
CSI スナップショットの場合、CSI ドライバーを登録するために
VolumeSnapshotClassCR を作成する必要があります。 -
DataProtectionApplicationCR でボリュームの場所を設定する必要があります。
手順
次のコマンドを入力して、
backupStorageLocationsCR を取得します。oc get backupStorageLocations -n openshift-adp
$ oc get backupStorageLocations -n openshift-adpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、
BackupCR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- バックアップする namespace の配列を指定します。
- 2
- オプション: バックアップに含めるリソースの配列を指定します。リソースは、省略語 ('pods' は 'po' など) または完全修飾の場合があります。指定しない場合、すべてのリソースが含まれます。
- 3
- オプション: バックアップから除外するリソースの配列を指定します。リソースは、省略語 ('pods' は 'po' など) または完全修飾の場合があります。
- 4
backupStorageLocationsCR の名前を指定します。- 5
- 指定したラベルを すべて 持つバックアップリソースの {key,value} ペアのマップ。
- 6
- 指定したラベルを 1 つ以上 持つバックアップリソースの {key,value} ペアのマップ。
BackupCR のステータスがCompletedしたことを確認します。oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'$ oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3.1.1. CSI スナップショットを使用した永続ボリュームのバックアップ
Backup CR を作成する前に、クラウドストレージの VolumeSnapshotClass カスタムリソース (CR) を編集して、Container Storage Interface (CSI) スナップショットを使用して永続ボリュームをバックアップします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
-
DataProtectionApplicationCR で CSI を有効にする必要があります。
手順
metadata.labels.velero.io/csi-volumesnapshot-class: "true"のキー: 値ペアをVolumeSnapshotClassCR に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
これで、Backup CR を作成できます。
15.3.1.2. Restic を使用したアプリケーションのバックアップ
Backup カスタムリソース (CR) を編集して、Restic を使用して Kubernetes リソース、内部イメージ、および永続ボリュームをバックアップします。
DataProtectionApplication CR でスナップショットの場所を指定する必要はありません。
Restic は、hostPath ボリュームのバックアップをサポートしません。詳細は、追加の Restic 制限事項 を参照してください。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplicationCR でspec.configuration.restic.enableをfalseに設定して、デフォルトの Restic インストールを無効にしていない。 -
DataProtectionApplicationCR がReady状態である。
手順
次の例のように、
BackupCR を編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OADP バージョン 1.2 以降では、
defaultVolumesToFsBackup: true設定をspecブロック内に追加します。OADP バージョン 1.1 では、defaultVolumesToRestic: trueを追加します。
15.3.1.3. バックアップフックの作成
Backup カスタムリソース (CR) を編集して、Pod 内のコンテナーでコマンドを実行するためのバックアップフックを作成します。
プレ フックは、Pod のバックアップが作成される前に実行します。ポスト フックはバックアップ後に実行します。
手順
次の例のように、
BackupCR のspec.hooksブロックにフックを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- オプション: フックが適用される namespace を指定できます。この値が指定されていない場合、フックはすべてのネームスペースに適用されます。
- 2
- オプション: フックが適用されない namespace を指定できます。
- 3
- 現在、Pod は、フックを適用できる唯一のサポート対象リソースです。
- 4
- オプション: フックが適用されないリソースを指定できます。
- 5
- オプション: このフックは、ラベルに一致するオブジェクトにのみ適用されます。この値が指定されていない場合、フックはすべてのネームスペースに適用されます。
- 6
- バックアップの前に実行するフックの配列。
- 7
- オプション: コンテナーが指定されていない場合、コマンドは Pod の最初のコンテナーで実行されます。
- 8
- これは、追加される init コンテナーのエントリーポイントです。
- 9
- エラー処理に許可される値は、
FailとContinueです。デフォルトはFailです。 - 10
- オプション: コマンドの実行を待機する時間。デフォルトは
30sです。 - 11
- このブロックでは、バックアップ後に実行するフックの配列を、バックアップ前のフックと同じパラメーターで定義します。
15.3.2. 関連情報
15.4. 仮想マシンの復元
Restore CR を作成して、OpenShift API for Data Protection (OADP) のBackup カスタムリソース (CR) を復元します。
フック を Restore CR に追加して、アプリケーションコンテナーの起動前に init コンテナーでコマンドを実行するか、アプリケーションコンテナー自体でコマンドを実行することができます。
15.4.1. 復元 CR の作成
Restore CR を作成して、Backup カスタムリソース (CR) を復元します。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplicationCR がReady状態である。 -
Velero
BackupCR がある。 - 永続ボリューム (PV) の容量は、バックアップ時に要求されたサイズと一致する必要があります。必要に応じて、要求されたサイズを調整します。
手順
次の例のように、
RestoreCR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
BackupCR の名前- 2
- オプション: 復元プロセスに含めるリソースの配列を指定します。リソースは、ショートカット (
Podsはpoなど) または完全修飾の場合があります。指定しない場合、すべてのリソースが含まれます。 - 3
- オプション:
restorePVsパラメーターをfalseに設定すると、コンテナーストレージインターフェイス (CSI) スナップショットのVolumeSnapshotから、またはVolumeSnapshotLocationが設定されている場合はネイティブスナップショットからのPersistentVolumesの復元をオフにすることができます。
次のコマンドを入力して、
RestoreCR のステータスがCompletedであることを確認します。oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'$ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、バックアップリソースが復元されたことを確認します。
oc get all -n <namespace>
$ oc get all -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- バックアップした namespace。
Restic を使用して
DeploymentConfigオブジェクトを復元する場合、または復元後のフックを使用する場合は、次のコマンドを入力してdc-restic-post-restore.shクリーンアップスクリプトを実行します。bash dc-restic-post-restore.sh <restore-name>
$ bash dc-restic-post-restore.sh <restore-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記復元プロセス中に、OADP Velero プラグインは
DeploymentConfigオブジェクトをスケールダウンし、Pod をスタンドアロン Pod として復元します。これは、クラスターが復元されたDeploymentConfigPod を復元時にすぐに削除することを防ぎ、Restic フックと復元後のフックが復元された Pod 上でアクションを完了できるようにするために行われます。以下に示すクリーンアップスクリプトは、これらの切断された Pod を削除し、DeploymentConfigオブジェクトを適切な数のレプリカにスケールアップします。例15.1
dc-restic-post-restore.shクリーンアップスクリプトCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.1.1. 復元フックの作成
Restore カスタムリソース (CR) を編集して、Pod 内のコンテナーでコマンドを実行する復元フックを作成します。
2 種類の復元フックを作成できます。
initフックは、init コンテナーを Pod に追加して、アプリケーションコンテナーが起動する前にセットアップタスクを実行します。Restic バックアップを復元する場合は、復元フック init コンテナーの前に
restic-waitinit コンテナーが追加されます。-
execフックは、復元された Pod のコンテナーでコマンドまたはスクリプトを実行します。
手順
次の例のように、
Restore CRのspec.hooksブロックにフックを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- オプション: フックが適用される namespace の配列。この値が指定されていない場合、フックはすべてのネームスペースに適用されます。
- 2
- 現在、Pod は、フックを適用できる唯一のサポート対象リソースです。
- 3
- オプション: このフックは、ラベルセレクターに一致するオブジェクトにのみ適用されます。
- 4
- オプション: Timeout は、
initContainersが完了するまで Velero が待機する最大時間を指定します。 - 5
- オプション: コンテナーが指定されていない場合、コマンドは Pod の最初のコンテナーで実行されます。
- 6
- これは、追加される init コンテナーのエントリーポイントです。
- 7
- オプション: コンテナーの準備が整うまでの待機時間。これは、コンテナーが起動して同じコンテナー内の先行するフックが完了するのに十分な長さである必要があります。設定されていない場合、復元プロセスの待機時間は無期限になります。
- 8
- オプション: コマンドの実行を待機する時間。デフォルトは
30sです。 - 9
- エラー処理に許可される値は、
FailおよびContinueです。-
Continue: コマンドの失敗のみがログに記録されます。 -
Fail: Pod 内のコンテナーで復元フックが実行されなくなりました。RestoreCR のステータスはPartiallyFailedになります。
-
Legal Notice
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}