仮想化

OpenShift Container Platform 4.12

OpenShift Virtualization のインストール、使用方法、およびリリースノート

Red Hat OpenShift Documentation Team

概要

本書では、OpenShift Container Platform で 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 Virtualization は、OVN-KubernetesOpenShift SDN、または Certified OpenShift CNI Plug-ins にリストされているその他の認定ネットワークプラグインのいずれかで使用できます。

Compliance Operator をインストールし、ocp4-moderate および ocp4-moderate-node プロファイル を使用してスキャンを実行することにより、OpenShift Virtualization クラスターのコンプライアンスの問題を確認できます。Compliance Operator は、NIST 認定ツール である OpenSCAP を使用して、セキュリティーポリシーをスキャンし、適用します。

重要

OpenShift Virtualization と Compliance Operator の統合は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat の実稼働環境におけるサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

1.1.1. OpenShift Virtualization サポートのクラスターバージョン

OpenShift Virtualization 4.12 は OpenShift Container Platform 4.12 クラスターで使用するためにサポートされます。Open Shift Virtualization の最新の z-stream リリースを使用するには、最初に Open Shift 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 と互換性がありません。互換性を確保するために、データボリュームまたはストレージプロファイルを使用するテンプレートまたは仮想マシンにエビクションストラテジーを設定しないでください。

1.3. 関連情報

第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-operatorKubeVirt CR を作成すると、virt-operator はそれを調整し、virt-controllervirt-handlervirt-api などの追加リソースを作成します。

OLM は hostpath-provisioner-operator をデプロイしますが、hostpath provisioner (HPP) CR を作成するまで機能しません。

CNV のデプロイメント

2.2. hco-operator について

hco- operator (HCO) は、OpenShift Virtualization をデプロイおよび管理するための単一のエントリーポイントと、独自のデフォルトを持ついくつかのヘルパー Operator を提供します。また、これらの Operator のカスタム リソース (CR) も作成します。

hco-operator コンポーネント

表2.1 hco-operator コンポーネント

コンポーネント説明

deployment/hco-webhook

HyperConverged カスタム リソースの内容を検証します。

deployment/hyperconverged-cluster-cli-download

クラスターから直接ダウンロードできるように、virtctl ツールのバイナリーをクラスターに提供します。

KubeVirt/kubevirt-kubevirt-hyperconverged

OpenShift Virtualization に必要なすべての Operator、CR、およびオブジェクトが含まれています。

SSP/ssp-kubevirt-hyperconverged

SSP CR。これは、HCO によって自動的に作成されます。

CDI/cdi-kubevirt-hyperconverged

A CDI CR。これは、HCO によって自動的に作成されます。

NetworkAddonsConfig/cluster

cluster-network-addons-operator によって指示および管理される CR。

2.3. cdi-operator について

cdi-operator は、Containerized Data Importer (CDI) とその関連リソースを管理します。これは、データ ボリュームを使用して仮想マシン (VM) イメージを永続ボリューム要求 (PVC) にインポートします。

cdi-operator コンポーネント

表2.2 cdi-operator コンポーネント

コンポーネント説明

deployment/cdi-apiserver

安全なアップロードトークンを発行して、VM ディスクを PVC にアップロードするための承認を管理します。

deployment/cdi-uploadproxy

外部ディスクのアップロードトラフィックを適切なアップロードサーバー Pod に転送して、正しい PVC に書き込むことができるようにします。有効なアップロードトークンが必要です。

pod/cdi-importer

データ ボリュームの作成時に仮想マシンイメージを PVC にインポートするヘルパー Pod。

2.4. cluster-network-addons-operator について

cluster-network-addons-operator は、ネットワーク コンポーネントをクラスターにデプロイし、ネットワーク機能を拡張するための関連リソースを管理します。

cluster-network-addons-operator コンポーネント

表2.3 cluster-network-addons-operator コンポーネント

コンポーネント説明

deployment/kubemacpool-cert-manager

Kubemacpool の Webhook の TLS 証明書を管理します。

deployment/kubemacpool-mac-controller-manager

仮想マシン (VM) ネットワークインターフェイス カード (NIC) の MAC アドレスプールサービスを提供します。

daemonset/bridge-marker

ノードで使用可能なネットワークブリッジをノードリソースとしてマークします。

daemonset/kube-cni-linux-bridge-plugin

クラスターノードに CNI プラグインをインストールし、ネットワーク接続定義を介して Linux ブリッジに VM を接続できるようにします。

2.5. hostpath-provisioner-operator について

hostpath-provisioner-operator は、マルチノードホストパスプロビジョナー (HPP) および関連リソースをデプロイおよび管理します。

hpp-operator components

表2.4 hostpath-provisioner-operator コンポーネント

コンポーネント説明

deployment/hpp-pool-hpp-csi-pvc-block-<worker_node_name>

ホストパスプロビジョナー (HPP) の実行が指定されている各ノードにワーカーを提供します。Pod は、指定されたバッキングストレージをノードにマウントします。

daemonset/hostpath-provisioner-csi

HPP の Container Storage Interface (CSI) ドライバーインターフェイスを実装します。

daemonset/hostpath-provisioner

HPP のレガシードライバーインターフェイスを実装します。

2.6. ssp-operator について

ssp-operator は、共通テンプレート、関連するデフォルトのブートソース、およびテンプレートバリデーターをデプロイします。

ssp-operator components

表2.5 ssp-operator components

コンポーネント説明

deployment/virt-template-validator

テンプレートから作成された仮想マシンの vm.kubevirt.io/validations アノテーションをチェックし、無効な場合は拒否します。

2.7. tekton-tasks-operator について

tekton-tasks-operator は、VM 用の OpenShift パイプラインの使用法を示すサンプルパイプラインをデプロイします。また、ユーザーがテンプレートから VM を作成し、テンプレートをコピーおよび変更し、データボリュームを作成できるようにする追加の OpenShift Pipeline タスクをデプロイします。

tekton-tasks-operator components

表2.6 tekton-tasks-operator components

コンポーネント説明

deployment/create-vm-from-template

テンプレートから仮想マシンを作成します。

deployment/copy-template

仮想マシンテンプレートをコピーします。

deployment/modify-vm-template

仮想マシンテンプレートを作成または削除します。

deployment/modify-data-object

データボリュームまたはデータソースを作成または削除します。

deployment/cleanup-vm

仮想マシンでスクリプトまたはコマンドを実行し、後で仮想マシンを停止または削除します。

deployment/disk-virt-customize

virt-customize を使用して、ターゲット PVC で customize スクリプトを実行します。

deployment/disk-virt-sysprep

virt-sysprep を使用して、ターゲット PVC で sysprep スクリプトを実行します。

deployment/wait-for-vmi-status

特定の VMI ステータスを待機し、そのステータスに従って失敗または成功します。

2.8. 仮想 Operator について

virt-operator は、現在の仮想マシン (VM) のワークロードを中断することなく、OpenShift Virtualization をデプロイ、アップグレード、および管理します。

virt-operator コンポーネント

表2.7 virt-operator コンポーネント

コンポーネント説明

deployment/virt-api

すべての仮想化関連フローのエントリーポイントとして機能する HTTP API サーバー。

deployment/virt-controller

新しい VM インスタンス オブジェクトの作成を監視し、対応する Pod を作成します。Pod がノードでスケジュールされると、virt-controller は VM をノード名で更新します。

daemonset/virt-handler

VM への変更を監視し、必要な操作を実行するように virt-launcher に指示します。このコンポーネントはノード固有です。

pod/virt-launcher

libvirt および qemu によって実装された、ユーザーによって作成された VM が含まれます。

第3章 OpenShift Virtualization の開始

基本的な環境をインストールして設定することにより、OpenShift Virtualization の特徴と機能を調べることができます。

注記

クラスター設定手順には、cluster-admin 権限が必要です。

3.1. OpenShift Virtualization の計画とインストール

OpenShift Container Platform クラスターで OpenShift Virtualization を計画およびインストールします。

計画およびインストールのリソース

3.2. 仮想マシンの作成と管理

Web コンソールを使用して仮想マシン (VM) を作成します。

仮想マシンに接続します。

VM を管理します。

3.3. 次のステップ

第4章 Web コンソールの概要

OpenShift Container Platform Web コンソールの Virtualization セクションには、OpenShift Virtualization 環境を管理および監視するための以下のページが含まれています。

表4.1 Virtualization ページ

Page説明

Overview ページ

OpenShift Virtualization 環境を管理および監視します。

Catalog ページ

テンプレートのカタログから VirtualMachine を作成します。

VirtualMachines ページ

VirtualMachine を設定および監視します。

Templates ページ

テンプレートを作成および管理します。

DataSources ページ

VirtualMachine ブートソースの DataSource を作成および管理します。

MigrationPolicies ページ

ワークロードの MigrationPolicy を作成および管理します。

表4.2 キー

Icon説明

icon pencil

Edit アイコン

icon link

Link アイコン

4.1. Overview ページ

Overview ページには、リソース、メトリック、移行の進行状況、およびクラスターレベルの設定が表示されます。

例4.1 Overview ページ

要素説明

virtctl のダウンロード icon link

リソースを管理するには、virtctl コマンドラインツールをダウンロードします。

Overview タブ

リソース、使用率、アラート、およびステータス。

Top consumers タブ

CPU、メモリー、およびストレージリソースのトップコンシューマー。

Migrations タブ

ライブマイグレーションのステータス。

Settings タブ

ライブマイグレーションの制限やパーミッションなど、クラスター全体の設定。

4.1.1. Overview タブ

Overview タブには、リソース、使用率、アラート、およびステータスが表示されます。

例4.2 Overview タブ

要素説明

Getting started resources カード

  • Quick Starts タイル: VirtualMachine の作成、インポート、および実行の方法について、段階的な手順とタスクを使用して学習します。
  • Feature highlights タイル: 主要な仮想化機能に関する最新情報をお読みください。
  • Related operators タイル: Kubernetes NMState オペレーターや OpenShift Data Foundation オペレーターなどのオペレーターをインストールします。

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 タブ

要素説明

仮想化ダッシュボードを表示 icon link

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 タブには、次のタブにクラスター全体の設定が表示されます。

表4.3 Settings タブ上のタブ

タブ説明

General タブ

OpenShift Virtualization のバージョンと更新ステータス。

Live migration タブ

ライブマイグレーションの制限とネットワーク設定。

Templates project タブ

Red Hat テンプレートのプロジェクト。

User permissions タブ

クラスター全体のパーミッション。

4.1.4.1. General タブ

General タブには、OpenShift Virtualization のバージョンと更新ステータスが表示されます。

例4.5 General タブ

Label説明

サービス名

OpenShift Virtualization

Provider

Red Hat

インストール済みバージョン

4.12.3

更新ステータス

例: Up to date

チャネル

更新用に選択されたチャネル。

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 テンプレートを保存するプロジェクトを選択します。デフォルトのテンプレートプロジェクトは openshift です。

複数のテンプレートプロジェクトを定義する場合は、各プロジェクトの 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 テンプレートは openshift プロジェクトに保存されます。Overview → Settings → Template project タブ でテンプレートプロジェクトを編集できます。

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 メニュー kebab をクリックして、StopRestartPauseCloneMigrateCopy SSH commandEdit labelsEdit annotations、または Delete を選択します。

VirtualMachine をクリックして、VirtualMachine details ページに移動します。

4.3.1. VirtualMachine details ページ

VirtualMachine details ページで VirtualMachine を設定できます。

例4.11 VirtualMachine details ページ

要素説明

Actions メニュー

Actions メニューをクリックして、StopRestartPauseCloneMigrateCopy SSH commandEdit labelsEdit annotations、または Delete を選択します。

Overview タブ

リソースの使用率、アラート、ディスク、およびデバイス。

Details タブ

VirtualMachine 設定。

Metrics タブ

メモリー、CPU、ストレージ、ネットワーク、移行のメトリック。

YAML タブ

VirtualMachine YAML 設定ファイル。

Scheduling タブ

スケジューリング設定。

Environment タブ

設定マップ、シークレット、およびサービスアカウントの管理。

Events タブ

VirtualMachine イベントストリーム。

Console タブ

コンソールセッション管理。

Network interfaces タブ

ネットワークインターフェイス管理。

Disks タブ

ディスク管理。

Scripts タブ

Cloud-init と SSH キーの管理。

Snapshots タブ

スナップショット管理

4.3.1.1. Overview タブ

Overview タブには、リソースの使用率、アラート、および設定情報が表示されます。

例4.12 Overview タブ

要素説明

Details タイル

VirtualMachine の一般情報。

Utilization タイル

CPUMemoryStorage、および Network transfer グラフ。

Hardware devices タイル

GPU とホストデバイス。

Alerts タイル

重大度別にグループ化された OpenShift Virtualization アラート。

Snapshots タイル

Take snapshot icon link および Snapshots テーブル。

Network interfaces タイル

Network interfaces テーブル。

Disks タイル

Disks テーブル。

4.3.1.2. Details タブ

Details タブで VirtualMachine を設定できます。

例4.13 Details タブ

要素説明

YAML スイッチ

ON を設定して、YAML 設定ファイルでライブの変更を表示します。

名前

VirtualMachine 名。

Namespace

VirtualMachine の namespace。

Labels

編集アイコンをクリックして、ラベルを編集します。

Annotations

編集アイコンをクリックして、注釈を編集します。

説明

編集アイコンをクリックして、説明を入力します。

オペレーティングシステム

オペレーティングシステム名。

CPU|Memory

編集アイコンをクリックして、CPU|Memory 要求を編集します。

CPU の数は、sockets * threads * cores の式を使用して計算されます。

マシンタイプ

VirtualMachine マシンタイプ。

起動モード

編集アイコンをクリックして、起動モードを編集します。

一時停止モードで開始

編集アイコンをクリックして、この設定を有効にします。

Template

VirtualMachine の作成に使用されるテンプレートの名前。

作成日時

VirtualMachine の作成日。

Owner

VirtualMachine の所有者。

Status

VirtualMachine の状態。

Pod

virt-launcher Pod 名。

VirtualMachineInstance

VirtualMachine インスタンス名。

ブート順序

編集アイコンをクリックして、起動ソースを選択します。

IP アドレス

VirtualMachine の IP アドレス。

ホスト名

VirtualMachine のホスト名。

タイムゾーン

VirtualMachine のタイムゾーン。

Node

VirtualMachine が実行されているノード。

Workload profile

編集アイコンをクリックして、ワークロードプロファイルを編集します。

virtctl を使用している SSH

コピーアイコンをクリックして、virtctl ssh コマンドをクリップボードにコピーします。

SSH over NodePort

Create a Service to expose your VirtualMachine for SSH access を選択すると、ssh -p <port> コマンドが生成されます。コピーアイコンをクリックして、コマンドをクリップボードにコピーします。

GPU デバイス

編集アイコンをクリックして、GPU デバイスを追加します。

ホストデバイス

編集アイコンをクリックして、ホストデバイスを追加します。

Services セクション

サービスを表示します。

Active users セクション

アクティブなユーザーを表示します。

4.3.1.3. Metrics タブ

Metrics タブには、メモリー、CPU、ストレージ、ネットワーク、および移行の使用率グラフが表示されます。

例4.14 Metrics タブ

要素説明

Time range リスト

結果をフィルターリングする期間を選択します。

Virtualization ダッシュボード icon link

現在のプロジェクトの Workloads タブにリンクします。

Utilization セクション

MemoryCPU、および Network interface グラフ。

Storage セクション

Storage total read/write および Storage iops total read/write グラフ。

Network セクション

Network inNetwork 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 タブ

設定説明

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 icon link

リンクをクリックして、リソースリストから設定マップ、シークレット、またはサービスアカウントを選択します。

4.3.1.7. Events タブ

Events タブには、VirtualMachine イベントのリストが表示されます。

4.3.1.8. Console タブ

Console タブで、VirtualMachine へのコンソールセッションを開くことができます。

例4.18 Console タブ

要素説明

Guest login credentials セクション

Guest login credentials を展開して、cloud-init で作成された認証情報を表示します。コピーアイコンをクリックして、認証情報をクリップボードにコピーします。

Console リスト

VNC コンソール または Serial コンソール を選択します。

デスクトップビューアー を選択して、リモートデスクトッププロトコル (RDP) を使用して Windows Virtual Machines に接続できます。同じネットワーク上のマシンに RDP クライアントをインストールする必要があります。

Send key リスト

コンソールに送信するキーストロークの組み合わせを選択します。

Disconnect ボタン

コンソール接続を切断します。

新しいコンソールセッションを開く場合は、コンソール接続を手動で切断する必要があります。それ以外の場合、最初のコンソールセッションは引き続きバックグラウンドで実行されます。

4.3.1.9. Network interfaces タブ

Network interfaces タブでネットワークインターフェイスを管理できます。

例4.19 Network interfaces タブ

設定説明

YAML スイッチ

ON を設定して、YAML 設定ファイルでライブの変更を表示します。

Add network interface ボタン

VirtualMachine にネットワークインターフェイスを追加します。

Filter フィールド

インターフェイスタイプでフィルターリングします。

Search フィールド

名前またはラベルでネットワークインターフェイスを検索します。

Network interface テーブル

ネットワークインターフェイスのリスト。

ネットワークインターフェースの横にある Options メニュー kebab をクリックして、Edit または Delete を選択します。

4.3.1.10. Disks タブ

Disks タブでディスクを管理できます。

例4.20 Disks タブ

設定説明

YAML スイッチ

ON を設定して、YAML 設定ファイルでライブの変更を表示します。

Add disk ボタン

VirtualMachine にディスクを追加します。

Filter フィールド

ディスクの種類でフィルターリングします。

Search フィールド

ディスクを名前で検索します。

Disks テーブル

VirtualMachine ディスクのリスト。

ディスクの横にある Options メニュー kebab をクリックして、Edit または Detach を選択します。

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 メニュー kebab をクリックして、Edit labelsEdit annotationsEdit VirtualMachineSnapshotDelete VirtualMachineSnapshot を選択します。

4.4. Templates ページ

Templates ページで VirtualMachine テンプレートを作成、編集、および複製できます。

注記

Red Hat テンプレートは編集できません。Red Hat テンプレートを複製して編集し、カスタムテンプレートを作成できます。

例4.23 Templates ページ

要素説明

Create Template ボタン

YAML 設定ファイルを編集してテンプレートを作成します。

Filter フィールド

テンプレートをタイプ、ブートソース、テンプレートプロバイダー、またはオペレーティングシステムでフィルターリングします。

Search フィールド

名前またはラベルでテンプレートを検索します。

Templates テーブル

テンプレートのリスト。

テンプレートの横にある Options メニュー kebab をクリックして、EditCloneEdit boot sourceEdit boot source referenceEdit labelsEdit annotations、または Delete を選択します。

4.4.1. テンプレートの詳細ページ

テンプレートの詳細 ページで、テンプレートの設定を表示し、カスタムテンプレートを編集できます。

例4.24 テンプレートの詳細ページ

要素説明

Actions メニュー

Actions メニューをクリックして、EditCloneEdit boot sourceEdit boot source referenceEdit labelsEdit annotations、または Delete を選択します。

Details タブ

テンプレートの設定と設定。

YAML タブ

YAML 設定ファイル。

Scheduling タブ

スケジューリング設定。

Network interfaces タブ

ネットワークインターフェイス管理。

Disks タブ

ディスク管理。

Scripts タブ

Cloud-init、SSH キー、および Sysprep の管理。

Parameters タブ

パラメーター

4.4.1.1. Details タブ

Details タブでカスタムテンプレートを設定できます。

例4.25 Details タブ

要素説明

YAML スイッチ

ON を設定して、YAML 設定ファイルでライブの変更を表示します。

名前

テンプレート名

Namespace

テンプレートの namespace。

Labels

編集アイコンをクリックして、ラベルを編集します。

Annotations

編集アイコンをクリックして、注釈を編集します。

表示名

編集アイコンをクリックして、表示名を編集します。

説明

編集アイコンをクリックして、説明を入力します。

オペレーティングシステム

オペレーティングシステム名。

CPU|Memory

編集アイコンをクリックして、CPU|Memory 要求を編集します。

CPU の数は、sockets * threads * cores の式を使用して計算されます。

マシンタイプ

テンプレートマシンタイプ。

起動モード

編集アイコンをクリックして、起動モードを編集します。

ベーステンプレート

このテンプレートの作成に使用されたベーステンプレートの名前。

Created at

テンプレートの作成日。

Owner

テンプレート所有者。

ブート順序

テンプレートの起動順序。

ブートソース

ブートソースの可用性。

Provider

テンプレートプロバイダー

サポート

テンプレートのサポートレベル。

GPU デバイス

編集アイコンをクリックして、GPU デバイスを追加します。

ホストデバイス

編集アイコンをクリックして、ホストデバイスを追加します。

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 タブ

設定説明

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 タブ

設定説明

YAML スイッチ

ON を設定して、YAML 設定ファイルでライブの変更を表示します。

Add network interface ボタン

テンプレートにネットワークインターフェイスを追加します。

Filter フィールド

インターフェイスタイプでフィルターリングします。

Search フィールド

名前またはラベルでネットワークインターフェイスを検索します。

Network interface テーブル

ネットワークインターフェイスのリスト。

ネットワークインターフェースの横にある Options メニュー kebab をクリックして、Edit または Delete を選択します。

4.4.1.5. Disks タブ

Disks タブでディスクを管理できます。

例4.29 Disks タブ

設定説明

YAML スイッチ

ON を設定して、YAML 設定ファイルでライブの変更を表示します。

Add disk ボタン

テンプレートにディスクを追加します。

Filter フィールド

ディスクの種類でフィルターリングします。

Search フィールド

ディスクを名前で検索します。

Disks テーブル

テンプレートディスクのリスト。

ディスクの横にある Options メニュー kebab をクリックして、Edit または Detach を選択します。

4.4.1.6. Scripts タブ

Scripts タブで、cloud-init 設定、SSH キー、および Sysprep 応答ファイルを管理できます。

例4.30 Scripts タブ

要素説明

YAML スイッチ

ON を設定して、YAML 設定ファイルでライブの変更を表示します。

Cloud-init

編集アイコンをクリックして、cloud-init 設定を編集します。

認可された SSH キー

編集アイコンをクリックして、新しいシークレットを作成するか、既存のシークレットを添付します。

Sysprep

編集アイコンをクリックして Autounattend.xml または Unattend.xml 応答ファイルをアップロードし、Windows VirtualMachine のセットアップを自動化します。

4.4.1.7. パラメータータブ

パラメーター タブで、選択したテンプレート設定を編集できます。

例4.31 パラメータータブ

要素説明

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 ページ

要素説明

Create DataSource → With form

レジストリー URL、ディスクサイズ、リビジョン数、および cron 式をフォームに入力して、DataSource を作成します。

Create DataSources → With YAML

YAML 設定ファイルを編集して DataSource を作成します。

Filter フィールド

利用可能な DataImportCron などの属性で DataSource をフィルターリングします。

Search フィールド

名前またはラベルで DataSource を検索します。

DataSources テーブル

データソースのリスト。

DataSource の横にある Options メニュー kebab をクリックして、Edit labelsEdit annotations、または Delete を選択します。

DataSource をクリックして、DataSource details ページを表示します。

4.5.1. DataSource details ページ

DataSource details ページで DataSource を設定できます。

例4.33 DataSource details ページ

要素説明

Details タブ

フォームを編集して DataSource を設定します。

YAML タブ

YAML 設定ファイルを編集して DataSource を設定します。

Actions メニュー

Edit labelsEdit annotations、または Delete を選択します。

名前

データソース名。

Namespace

データソースの namespace。

Labels

編集アイコンをクリックして、ラベルを編集します。

Annotations

編集アイコンをクリックして、注釈を編集します。

Conditions

DataSource のステータス条件を表示します。

4.6. MigrationPolicies ページ

MigrationPolicies ページでワークロードの MigrationPolicy を管理できます。

例4.34 MigrationPolicies ページ

要素説明

Create MigrationPolicy → With form

フォームに設定とラベルを入力して、MigrationPolicy を作成します。

Create MigrationPolicy → With YAML

YAML 設定ファイルを編集して MigrationPolicy を作成します。

Name | Label 検索フィールド

名前またはラベルで MigrationPolicy を検索します。

MigrationPolicies テーブル

MigrationPolicy のリスト。

MigrationPolicy の横にある Options メニューをクリックして、 kebab Edit または Delete を選択します。

MigrationPolicy をクリックして、MigrationPolicy details ページを表示します。

4.6.1. MigrationPolicy details ページ

MigrationPolicy details ページで MigrationPolicy を設定できます。

例4.35 MigrationPolicy details ページ

要素説明

Details タブ

フォームを編集して MigrationPolicy を設定します。

YAML タブ

YAML 設定ファイルを編集して MigrationPolicy を設定します。

Actions メニュー

Edit または Delete を選択します。

名前

MigrationPolicy 名。

説明

MigrationPolicy の説明。

設定

編集アイコンをクリックして、MigrationPolicy 設定を更新します。

移行ごとの帯域幅

移行ごとの帯域幅要求。帯域幅を無制限にするには、値を 0 に設定します。

自動収束

自動収束ポリシー。

ポストコピー

ポストコピーポリシー。

完了タイムアウト

秒単位の完了タイムアウト値。

プロジェクトラベル

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 は、 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 クラスターで使用するためにサポートされます。Open Shift Virtualization の最新の z-stream リリースを使用するには、最初に Open Shift 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 ロゴを使用しません。OpenShift Virtualization は現在、バージョン 4.9 以降の OpenShift Virtualization ロゴで表されます。
  • virtctl vmexport コマンドを使用するか VirtualMachineExport カスタムリソースを作成することにより、仮想マシン (VM) や VM スナップショット、または永続ボリューム請求 (PVC) から ボリュームをエクスポートおよびダウンロード して、異なるクラスタまたは同じクラスタの異なるネームスペースで再作成することが可能です。フォレンジック分析のためにメモリーダンプをエクスポートすることもできます。
  • スタンドアロンのデータボリューム、および dataVolumeTemplate を使用して VM 用のディスクを準備するときに作成されたデータボリュームは、システムに保存されなくなりました。PVC の作成後、データボリュームは自動的にガベージコレクションおよび削除されるようになりました。
  • OpenShift Virtualization Operator は、APIServer カスタムリソースからクラスター全体の TLS セキュリティープロファイル を読み取り、それを仮想化、ストレージ、ネットワーキング、およびインフラストラクチャーを含む OpenShift Virtualization コンポーネントに伝播するようになりました。
  • OpenShift Virtualization には、アラートをトリガーする問題のトラブルシューティングに役立つ ランブック があります。アラートは、Web コンソールの VirtualizationOverview ページに表示されます。各 Runbook はアラートを定義し、問題を診断して解決するための手順を提供します。この機能は、以前はテクノロジープレビューとして導入されていましたが、現在一般提供されています。

5.3.1. クイックスタート

  • クイックスタートツアーは、複数の OpenShift Virtualization 機能で利用できます。ツアーを表示するには、OpenShift Virtualization コンソールのヘッダーのメニューバーにある Help アイコン ? をクリックし、Quick Starts を選択します。Filter フィールドに virtualization キーワードを入力して、利用可能なツアーをフィルターできます。

5.3.2. ネットワーク

  • OpenShift Container Platform クラスターのチェックアップを実行する namespace を指定 できるようになりました。

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 タブには、設定可能な期間における仮想マシンインスタンスの移行の進行状況が表示されます。
  • ライブマイグレーション専用のネットワークを定義して、テナントワークロードの中断を最小限に抑えることができるようになりました。ネットワークを選択するには、VirtualizationOverviewSettingsLive 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.io CR に置き換えます。

5.4. テクノロジープレビューの機能

現在、今回のリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。これらの機能に関しては、Red Hat カスタマーポータルの以下のサポート範囲を参照してください。

テクノロジープレビュー機能のサポート範囲

  • Tekton Tasks Operator (TTO) は、OpenShift Virtualization を Red Hat OpenShift Pipelines と統合 するようになりました。TTO には、次のことを可能にするクラスタータスクとサンプルパイプラインが含まれています。

    • 仮想マシン (VM)、永続ボリューム要求 (PVC)、およびデータボリュームを作成および管理します。
    • 仮想マシンでコマンドを実行します。
    • libguestfs ツールを使用してディスクイメージを操作します。
    • Windows インストールイメージ (ISO ファイル) から新しいデータボリュームに Windows 10 をインストールします。
    • 基本的な Windows 10 インストールをカスタマイズしてから、新しいイメージとテンプレートを作成します。
  • Microsoft Windows 11 をゲスト OS として使用できるようになりました。ただし、OpenShift Virtualization 4.12 は、BitLocker リカバリーの重要な機能に必要な USB ディスクをサポートしていません。回復キーを保護するには、BitLocker recovery guide で説明されている他の方法を使用します。
  • 帯域幅の使用率、並列移行の最大数、タイムアウトなどの特定のパラメーターを使用してライブマイグレーションポリシーを作成し、仮想マシンと namespace のラベルを使用して、仮想マシンのグループにポリシーを適用できます。

5.5. バグ修正

  • ドライバーのインストール後に新しいデバイス設定を失うことなく、ドライバーをインストールする前に仲介デバイスを有効にするように HyperConverged CR を設定できるようになりました。(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 が ReadWriteMany CephFS の共有ボリュームに同時にアクセスしようとするためです。(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.
    • 回避策として、以下を実施します。

      1. ストレージプロファイルの claimPropertySets 配列を更新します。

        $ oc patch storageprofile <storage_profile> --type=merge -p '{"spec": {"claimPropertySets": [{"accessModes": ["ReadWriteOnce"], "volumeMode": "Block"}, \
            {"accessModes": ["ReadWriteOnce"], "volumeMode": "Filesystem"}]}}'
      2. openshift-virtualization-os-images namespace で影響を受けるデータボリュームを削除します。これらは、更新されたストレージプロファイルのアクセスモードとボリュームモードで再作成されます。
  • バインディングモードが WaitForFirstConsumer であるストレージの VM スナップショットを復元すると、復元された PVC が Pending 状態のままになり、復元操作が進行しません。

    • 回避策として、復元された仮想マシンを起動し、停止してから、再度起動します。仮想マシンがスケジュールされ、PVC が Bound 状態になり、復元操作が完了します。(BZ#2149654)
  • テンプレートのデフォルトのエビクションストラテジーが 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)

    • 回避策として、アノテーションを手動で削除できます。

      1. VirtualMachineSnapshot CR の status.virtualMachineSnapshotContentName 値から、VirtualMachineSnapshotContent カスタムリソース (CR) 名を取得します。
      2. VirtualMachineSnapshotContent CR を編集し、k8s.io/cloneRequest を含むすべての行を削除します。
      3. VirtualMachine オブジェクトで spec.dataVolumeTemplates の値を指定しなかった場合は、次の両方の条件に該当するこの namespace の DataVolume および PersistentVolumeClaim オブジェクトを削除します。

        1. オブジェクトの名前は restore- で始まります。
        2. オブジェクトは仮想マシンによって参照されません。

          spec.dataVolumeTemplates の値を指定した場合、この手順はオプションとなります。

      4. 更新された VirtualMachineSnapshot CR で 復元操作 を繰り返します。
  • 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-monitoringLiveMigrate エビクションストラテジーを使用する仮想マシンイメージに対して 60 分ごとに PodDisruptionBudgetAtLimit アラートを送信します。(BZ#2026733)

  • OpenShift Virtualization は、Pod によって使用されるサービスアカウントトークンをその特定の Pod にリンクします。OpenShift Virtualization は、トークンが含まれるディスクイメージを作成してサービスアカウントボリュームを実装します。仮想マシンを移行すると、サービスアカウントボリュームが無効になります。(BZ#2037611)

    • 回避策として、サービスアカウントではなくユーザーアカウントを使用してください。ユーザーアカウントトークンは特定の Pod にバインドされていないためです。
  • csi-clone クローンストラテジーを使用して 100 台以上の仮想マシンのクローンを作成する場合、Ceph CSI はクローンをパージしない可能性があります。クローンの手動削除も失敗する可能性があります。(BZ#2055595)

    • 回避策として、ceph-mgr を再起動して仮想マシンのクローンをパージすることができます。

第6章 インストール

6.1. OpenShift Virtualization のクラスターの準備

OpenShift Virtualization をインストールする前にこのセクションを確認して、クラスターが要件を満たしていることを確認してください。

重要

ユーザープロビジョニング、インストーラープロビジョニング、または支援付きインストーラーなど、任意のインストール方法を使用して、OpenShift Container Platform をデプロイできます。ただし、インストール方法とクラスタートポロジーは、スナップショットやライブマイグレーションなどの OpenShift Virtualization 機能に影響を与える可能性があります。

FIPS mode

クラスターを FIPS モード でインストールする場合、OpenShift Virtualization に追加の設定は必要ありません。

IPv6

シングルスタックの IPv6 クラスターで OpenShift Virtualization は実行できません。(BZ#2193267)

6.1.1. ハードウェアとオペレーティングシステムの要件

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 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 worker node ≈ 360 MiB

さらに、OpenShift Virtualization 環境リソースには、すべてのインフラストラクチャーノードに分散される合計 2179 MiB の RAM が必要です。

仮想マシンのメモリーオーバーヘッド

Memory overhead per virtual machine ≈ (1.002 * requested memory) + 146 MiB  \
                + 8 MiB * (number of vCPUs) \ 1
             + 16 MiB * (number of graphics devices) 2

1
仮想マシンが要求する仮想 CPU の数
2
仮想マシンが要求する仮想グラフィックスカードの数

お使いの環境に Single Root I/O Virtualization (SR-IOV) ネットワークデバイスまたは Graphics Processing Unit (GPU) が含まれる場合、それぞれのデバイスに 1 GiB の追加のメモリーオーバーヘッドを割り当てます。

6.1.2.2. CPU オーバーヘッド

以下の式を使用して、OpenShift Virtualization のクラスタープロセッサーのオーバーヘッド要件を計算します。仮想マシンごとの CPU オーバーヘッドは、個々の設定によって異なります。

クラスターの CPU オーバーヘッド

CPU overhead for infrastructure nodes ≈ 4 cores

OpenShift Virtualization は、ロギング、ルーティング、およびモニタリングなどのクラスターレベルのサービスの全体的な使用率を増加させます。このワークロードに対応するには、インフラストラクチャーコンポーネントをホストするノードに、4 つの追加コア (4000 ミリコア) の容量があり、これがそれらのノード間に分散されていることを確認します。

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

10 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 をサポートする必要があります。

6.1.6. スナップショットとクローン作成

スナップショットとクローン作成の要件は、OpenShift Virtualization ストレージ機能 を参照してください。

6.1.7. クラスターの高可用性オプション

クラスターには、次の高可用性 (HA) オプションのいずれかを設定できます。

  • インストーラーによってプロビジョニングされたインフラストラクチャー (IPI) の 自動高可用性は、マシンの可用性チェック をデプロイすることで利用できます。

    注記

    インストーラーでプロビジョニングされるインフラストラクチャーを使用してインストールされ、MachineHealthCheck が適切に設定された OpenShift Container Platform クラスターで、ノードで MachineHealthCheck が失敗し、クラスターで利用できなくなると、そのノードは再利用されます。障害が発生したノードで実行された仮想マシンでは、一連の条件によって次に起こる動作が変わります。潜在的な結果と RunStrategy がそれらの結果にどのように影響するかについての詳細情報は、仮想マシンの RunStrategy について を参照してください。

  • IPI と非 IPI の両方の自動高可用性は、OpenShift Container Platform クラスターで Node Health Check Operator を使用して NodeHealthCheck コントローラーをデプロイすることで利用できます。コントローラーは異常なノードを識別し、セルフノード修復 Operator を使用して異常なノードを修復します。

    重要

    Node Health Check Operator は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat の実稼働環境におけるサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

    Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

  • モニタリングシステムまたは有資格者を使用してノードの可用性をモニターすることにより、あらゆるプラットフォームの高可用性を利用できます。ノードが失われた場合は、これをシャットダウンして 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 フィールドにノードの配置ルールを追加できます。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.12.3
  channel: "stable"
  config: 1
1
config フィールドは nodeSelector および tolerations をサポートしますが、affinity はサポートしません。

6.2.1.3. HyperConverged オブジェクトのノード配置

OpenShift Virtualization がそのコンポーネントをデプロイするノードを指定するには、OpenShift Virtualization のインストール時に作成する HyperConverged Cluster カスタムリソース (CR) ファイルに nodePlacement オブジェクトを含めることができます。以下の例のように、spec.infra および spec.workloads フィールドに nodePlacement を含めることができます。

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra:
    nodePlacement: 1
    ...
  workloads:
    nodePlacement:
    ...
1
nodePlacement フィールドは、nodeSelectoraffinity、および tolerations フィールドをサポートします。

6.2.1.4. HostPathProvisioner オブジェクトのノード配置

ノードの配置ルールは、ホストパスプロビジョナーのインストール時に作成する HostPathProvisioner オブジェクトの spec.workload フィールドで設定できます。

apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
kind: HostPathProvisioner
metadata:
  name: hostpath-provisioner
spec:
  imagePullPolicy: IfNotPresent
  pathConfig:
    path: "</path/to/backing/directory>"
    useNamingPrefix: false
  workload: 1
1
workload フィールドは、nodeSelectoraffinity、および tolerations フィールドをサポートします。

6.2.1.5. 関連情報

6.2.2. マニフェストの例

以下の YAML ファイルの例では、nodePlacementaffinity、および 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 を設定します。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.12.3
  channel: "stable"
  config:
    nodeSelector:
      example.io/example-infra-key: example-infra-value
6.2.2.1.2. 例: OLM Subscription オブジェクトの容認を使用したノード配置

この例では、OLM が OpenShift Virtualization Operator をデプロイするために予約されるノードには key=virtualization:NoSchedule テイントのラベルが付けられます。一致する容認のある Pod のみがこれらのノードにスケジュールされます。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.12.3
  channel: "stable"
  config:
    tolerations:
    - key: "key"
      operator: "Equal"
      value: "virtualization"
      effect: "NoSchedule"

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 のラベルが付けられたノードに配置されるように設定されます。

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra:
    nodePlacement:
      nodeSelector:
        example.io/example-infra-key: example-infra-value
  workloads:
    nodePlacement:
      nodeSelector:
        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 は依然としてスケジュールされます。

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra:
    nodePlacement:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-infra-key
                operator: In
                values:
                - example-infra-value
  workloads:
    nodePlacement:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-workloads-key
                operator: In
                values:
                - example-workloads-value
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: example.io/num-cpus
                operator: Gt
                values:
                - 8
6.2.2.2.3. 例: HyperConverged Cluster CR の容認を使用したノード配置

この例では、OpenShift Virtualization コンポーネント用に予約されるノードには key=virtualization:NoSchedule テイントのラベルが付けられます。一致する容認のある Pod のみがこれらのノードにスケジュールされます。

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  workloads:
    nodePlacement:
      tolerations:
      - key: "key"
        operator: "Equal"
        value: "virtualization"
        effect: "NoSchedule"

6.2.2.3. HostPathProvisioner オブジェクト

6.2.2.3.1. 例: HostPathProvisioner オブジェクトの nodeSelector を使用したノード配置

この例では、example.io/example-workloads-key = example-workloads-value のラベルが付けられたノードにワークロードが配置されるように nodeSelector を設定します。

apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
kind: HostPathProvisioner
metadata:
  name: hostpath-provisioner
spec:
  imagePullPolicy: IfNotPresent
  pathConfig:
    path: "</path/to/backing/directory>"
    useNamingPrefix: false
  workload:
    nodeSelector:
      example.io/example-workloads-key: example-workloads-value

6.3. Web コンソールを使用した OpenShift Virtualization のインストール

OpenShift Virtualization をインストールし、仮想化機能を OpenShift Container Platform クラスターに追加します。

OpenShift Container Platform 4.12 web console を使用して、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 コンソールにログインすること。

手順

  1. Administrator パースペクティブから、OperatorsOperatorHub をクリックします。
  2. Filter by keyword フィールドに OpenShift Virtualization を入力します。
  3. OpenShift Virtualization タイルを選択します。
  4. Operator についての情報を確認してから、Install をクリックします。
  5. Install Operator ページで以下を行います。

    1. 選択可能な Update Channel オプションの一覧から stable を選択します。これにより、OpenShift Container Platform バージョンと互換性がある OpenShift Virtualization のバージョンをインストールすることができます。
    2. インストールされた namespace の場合、Operator recommended namespace オプションが選択されていることを確認します。これにより、Operator が必須の openshift-cnv namespace にインストールされます。この namespace は存在しない場合は、自動的に作成されます。

      警告

      OpenShift Virtualization Operator を openshift-cnv 以外の namespace にインストールしようとすると、インストールが失敗します。

    3. Approval Strategy の場合に、stable 更新チャネルで新しいバージョンが利用可能になったときに OpenShift Virtualization が自動更新されるように、デフォルト値である Automaticを選択することを強くお勧めします。

      Manual 承認ストラテジーを選択することは可能ですが、クラスターのサポート容易性および機能に対応するリスクが高いため、お勧めできません。これらのリスクを完全に理解していて、Automatic を使用できない場合のみ、Manual を選択してください。

      警告

      OpenShift Virtualization は対応する OpenShift Container Platform バージョンで使用される場合にのみサポートされるため、OpenShift Virtualization が更新されないと、クラスターがサポートされなくなる可能性があります。

  6. Install をクリックし、Operator を openshift-cnv namespace で利用可能にします。
  7. Operator が正常にインストールされたら、Create HyperConverged をクリックします。
  8. オプション: OpenShift Virtualization コンポーネントの Infra および Workloads ノード配置オプションを設定します。
  9. Create をクリックして OpenShift Virtualization を起動します。

検証

  • WorkloadsPods ページに移動して、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 へのアクセスが付与されます。

単一マニフェストをクラスターに適用して NamespaceOperatorGroup、および Subscription オブジェクトをサブスクライブし、設定します。

手順

  1. 以下のマニフェストを含む YAML ファイルを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-cnv
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: kubevirt-hyperconverged-group
      namespace: openshift-cnv
    spec:
      targetNamespaces:
        - openshift-cnv
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: hco-operatorhub
      namespace: openshift-cnv
    spec:
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      name: kubevirt-hyperconverged
      startingCSV: kubevirt-hyperconverged-operator.v4.12.3
      channel: "stable" 1
    1
    stable チャネルを使用することで、OpenShift Container Platform バージョンと互換性のある OpenShift Virtualization のバージョンをインストールすることができます。
  2. 以下のコマンドを実行して、OpenShift Virtualization に必要な NamespaceOperatorGroup、および Subscription オブジェクトを作成します。

    $ oc apply -f <file name>.yaml
注記

YAML ファイルで、証明書のローテーションパラメーターを設定 できます。

6.4.3. CLI を使用した OpenShift Virtualization Operator のデプロイ

oc CLI を使用して OpenShift Virtualization Operator をデプロイすることができます。

前提条件

  • openshift-cnv namespace の OpenShift Virtualization カタログへのアクティブなサブスクリプション。

手順

  1. 以下のマニフェストを含む YAML ファイルを作成します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
  2. 以下のコマンドを実行して OpenShift Virtualization Operator をデプロイします。

    $ oc apply -f <file_name>.yaml

検証

  • openshift-cnv namespace の Cluster Service Version (CSV) の PHASE を監視して、OpenShift Virtualization が正常にデプロイされたことを確認します。以下のコマンドを実行します。

    $ watch oc get csv -n openshift-cnv

    以下の出力は、デプロイメントに成功したかどうかを表示します。

    出力例

    NAME                                      DISPLAY                    VERSION   REPLACES   PHASE
    kubevirt-hyperconverged-operator.v4.12.3   OpenShift Virtualization   4.12.3                Succeeded

6.4.4. 次のステップ

以下のコンポーネントを追加で設定する必要がある場合があります。

  • ホストパスプロビジョナー は、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。

6.5. virtctl クライアントのインストール

virtctl クライアントは、OpenShift Virtualization リソースを管理するためのコマンドラインユーティリティーです。Linux、Windows、および macOS で使用できます。

6.5.1. Linux、Windows、および macOS への virtctl クライアントのインストール

お使いのオペレーティングシステム用の virtctl クライアントをダウンロードしてインストールします。

手順

  1. OpenShift Container Platform Web コンソールで Virtualization > Overview に移動します。
  2. ページの右上隅にある Download virtctl リンクをクリックして、お使いのオペレーティングシステム用の virtctl クライアントをダウンロードします。
  3. virtctl をインストールします。

    • Linux の場合

      1. アーカイブファイルを解凍します。

        $ tar -xvf <virtctl-version-distribution.arch>.tar.gz
      2. 次のコマンドを実行して、virtctl バイナリーを実行可能にします。

        $ chmod +x <path/virtctl-file-name>
      3. virtctl バイナリーを PATH 環境変数 にあるディレクトリーに移動します。

        次のコマンドを実行して、パスを確認できます。

        $ echo $PATH
      4. KUBECONFIG 環境変数を設定します。

        $ export KUBECONFIG=/home/<user>/clusters/current/auth/kubeconfig
    • Windows の場合:

      1. アーカイブファイルを解凍します。
      2. 展開したフォルダー階層に移動し、virtctl 実行可能ファイルをダブルクリックしてクライアントをインストールします。
      3. virtctl バイナリーを PATH 環境変数 にあるディレクトリーに移動します。

        次のコマンドを実行して、パスを確認できます。

        C:\> path
    • MacOS の場合:

      1. アーカイブファイルを解凍します。
      2. virtctl バイナリーを PATH 環境変数 にあるディレクトリーに移動します。

        次のコマンドを実行して、パスを確認できます。

        echo $PATH

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-manager CLI ツールを使用して、オペレーティングシステムに適切な OpenShift Virtualization リポジトリーを有効にします。

    • RHEL 8 のリポジトリーを有効にするには、次を実行します。

      # subscription-manager repos --enable cnv-4.12-for-rhel-8-x86_64-rpms
    • RHEL 7 のリポジトリーを有効にするには、次を実行します。

      # subscription-manager repos --enable rhel-7-server-cnv-4.12-rpms

6.5.2.2. yum ユーティリティーを使用した virtctl クライアントのインストール

kubevirt-virtctl パッケージから virtctl クライアントをインストールします。

前提条件

  • Red Hat Enterprise Linux (RHEL) システムで OpenShift Virtualization リポジトリーを有効にしました。

手順

  • kubevirt-virtctl パッケージをインストールします。

    # yum install kubevirt-virtctl

6.5.3. 関連情報

6.6. OpenShift Virtualization のアンインストール

Web コンソールまたはコマンドラインインターフェイス (CLI) を使用して OpenShift Virtualization をアンインストールし、OpenShift Virtualization ワークロード、Operator、およびそのリソースを削除します。

6.6.1. Web コンソールを使用した OpenShift Virtualization のアンインストール

Web コンソール を使用して OpenShift Virtualization をアンインストールし、以下のタスクを実行します。

重要

まず、すべての 仮想マシン仮想マシンインスタンス を削除する必要があります。

ワークロードがクラスターに残っている間は、OpenShift Virtualization をアンインストールできません。

6.6.1.1. HyperConverged カスタムリソースの削除

OpenShift Virtualization をアンインストールするには、最初に HyperConverged カスタムリソース (CR) を削除します。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

手順

  1. OperatorsInstalled Operators ページに移動します。
  2. OpenShift Virtualization Operator を選択します。
  3. OpenShift Virtualization Deployment タブをクリックします。
  4. kubevirt-hyperconverged の横にある Options メニュー kebab をクリックし、Delete HyperConverged を選択します。
  5. 確認ウィンドウで Delete をクリックします。

6.6.1.2. Web コンソールの使用によるクラスターからの Operator の削除

クラスター管理者は Web コンソールを使用して、選択した namespace からインストールされた Operator を削除できます。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスター Web コンソールにアクセスできる。

手順

  1. OperatorsInstalled Operators ページに移動します。
  2. スクロールするか、またはキーワードを Filter by name フィールドに入力して、削除する Operator を見つけます。次に、それをクリックします。
  3. Operator Details ページの右側で、Actions 一覧から Uninstall Operator を選択します。

    Uninstall Operator? ダイアログボックスが表示されます。

  4. 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 クラスターにアクセスできる。

手順

  1. AdministrationNamespaces に移動します。
  2. namespace の一覧で削除する必要のある namespace を見つけます。
  3. namespace の一覧の右端で、Options メニュー kebab から Delete Namespace を選択します。
  4. Delete Namespace ペインが表示されたら、フィールドから削除する namespace の名前を入力します。
  5. Delete をクリックします。

6.6.1.4. OpenShift Virtualization カスタムリソース定義の削除

Web コンソールを使用して、OpenShift Virtualization カスタムリソース定義 (CRD) を削除できます。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

手順

  1. AdministrationCustomResourceDefinitions に移動します。
  2. Label フィルターを選択し、Search フィールドに operators.coreos.com/kubevirt-hyperconverged.openshift-cnv と入力して OpenShift Virtualization CRD を表示します。
  3. 各 CRD の横にある Options メニュー kebab をクリックし、Delete CustomResourceDefinition の削除を選択します。

6.6.2. CLI を使用した OpenShift Virtualization のアンインストール

OpenShift CLI (oc) を使用して OpenShift Virtualization をアンインストールできます。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • すべての仮想マシンと仮想マシンインスタンスを削除した。ワークロードがクラスターに残っている間は、OpenShift Virtualization をアンインストールできません。

手順

  1. HyperConverged カスタムリソースを削除します。

    $ oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnv
  2. OpenShift Virtualization Operator サブスクリプションを削除します。

    $ oc delete subscription kubevirt-hyperconverged -n openshift-cnv
  3. OpenShift Virtualization ClusterServiceVersion リソースを削除します。

    $ oc delete csv -n openshift-cnv -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv
  4. dry-run オプションを指定して oc delete crd コマンドを実行し、OpenShift Virtualization カスタムリソース定義 (CRD) を一覧表示します。

    $ oc delete crd --dry-run=client -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv

    出力例

    customresourcedefinition.apiextensions.k8s.io "cdis.cdi.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "hostpathprovisioners.hostpathprovisioner.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "hyperconvergeds.hco.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "kubevirts.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "networkaddonsconfigs.networkaddonsoperator.network.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "ssps.ssp.kubevirt.io" deleted (dry run)
    customresourcedefinition.apiextensions.k8s.io "tektontasks.tektontasks.kubevirt.io" deleted (dry run)

  5. dry-run オプションを指定せずに oc delete crd コマンドを実行して、CRD を削除します。

    $ oc delete crd -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv

第7章 OpenShift Virtualization の更新

Operator Lifecycle Manager(OLM) が OpenShift Virtualization の z-stream およびマイナーバージョンの更新を提供する方法を確認します。

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 分以内に完了します。
  • Open Shift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
  • データボリュームおよびその関連付けられた永続ボリューム要求 (PVC) は更新時に保持されます。
重要

ホストパスプロビジョナーストレージを使用する仮想マシンを実行している場合、それらをライブマイグレーションすることはできず、Open Shift Container Platform クラスターの更新をブロックする可能性があります。

回避策として、仮想マシンを再設定し、クラスターの更新時にそれらの電源を自動的にオフになるようにできます。evictionStrategy: LiveMigrate フィールドを削除し、runStrategy フィールドを Always に設定します。

7.1.1. ワークロードの更新について

OpenShift Virtualization を更新すると、ライブマイグレーションをサポートしている場合には libvirtvirt-launcher、および qemu などの仮想マシンのワークロードが自動的に更新されます。

注記

各仮想マシンには、仮想マシンインスタンス (VMI) を実行する virt-launcher Pod があります。virt-launcher Pod は、仮想マシン (VM) のプロセスを管理するために使用される libvirt のインスタンスを実行します。

HyperConverged カスタムリソース (CR) の spec.workloadUpdateStrategy スタンザを編集して、ワークロードの更新方法を設定できます。ワークロードの更新方法として、LiveMigrateEvict の 2 つが利用可能です。

Evictメソッドは VMI Pod をシャットダウンするため、デフォルトではLiveMigrate更新ストラテジーのみが有効になっています。

LiveMigrateが有効な唯一の更新ストラテジーである場合:

  • ライブマイグレーションをサポートする VMI は更新プロセス時に移行されます。VM ゲストは、更新されたコンポーネントが有効になっている新しい Pod に移動します。
  • ライブマイグレーションをサポートしない VMI は中断または更新されません。

    • VMI にLiveMigrateエビクションストラテジーがあるが、ライブマイグレーションをサポートしていない場合、VMI は更新されません。

LiveMigrateEvictの両方を有効にした場合:

  • ライブマイグレーションをサポートする 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 ドキュメントの指示に従って、ワーカーノードのマシン設定プールを一時停止しました。
  • デフォルトの 自動 承認ストラテジーを使用することをお勧めします。手動 承認ストラテジーを使用する場合、Web コンソールですべての保留中の更新を承認する必要があります。詳細については、保留中のオペレーターの更新を手動で承認するセクションを参照してください。

手順

  1. 次のコマンドを実行して、現在の workloadUpdateMethods 設定をバックアップします。

    $ WORKLOAD_UPDATE_METHODS=$(oc get kv kubevirt-kubevirt-hyperconverged -n openshift-cnv -o jsonpath='{.spec.workloadUpdateStrategy.workloadUpdateMethods}')
  2. 次のコマンドを実行して、すべてのワークロード更新方法をオフにします。

    $ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op":"replace","path":"/spec/workloadUpdateStrategy/workloadUpdateMethods", "value":[]}]'

    出力例

    hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched

  3. 続行する前に、HyperConverged Operator が アップグレード可能 であることを確認してください。次のコマンドを入力して、出力をモニターします。

    $ oc get hco kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"

    例7.1 出力例

    [
      {
        "lastTransitionTime": "2022-12-09T16:29:11Z",
        "message": "Reconcile completed successfully",
        "observedGeneration": 3,
        "reason": "ReconcileCompleted",
        "status": "True",
        "type": "ReconcileComplete"
      },
      {
        "lastTransitionTime": "2022-12-09T20:30:10Z",
        "message": "Reconcile completed successfully",
        "observedGeneration": 3,
        "reason": "ReconcileCompleted",
        "status": "True",
        "type": "Available"
      },
      {
        "lastTransitionTime": "2022-12-09T20:30:10Z",
        "message": "Reconcile completed successfully",
        "observedGeneration": 3,
        "reason": "ReconcileCompleted",
        "status": "False",
        "type": "Progressing"
      },
      {
        "lastTransitionTime": "2022-12-09T16:39:11Z",
        "message": "Reconcile completed successfully",
        "observedGeneration": 3,
        "reason": "ReconcileCompleted",
        "status": "False",
        "type": "Degraded"
      },
      {
        "lastTransitionTime": "2022-12-09T20:30:10Z",
        "message": "Reconcile completed successfully",
        "observedGeneration": 3,
        "reason": "ReconcileCompleted",
        "status": "True",
        "type": "Upgradeable" 1
      }
    ]
    1
    OpenShift Virtualization Operator のステータスは Upgradeable です。
  4. クラスターをソース EUS バージョンから OpenShift Container Platform の次のマイナーバージョンに手動で更新します。

    $ oc adm upgrade

    検証

    • 次のコマンドを実行して、現在のバージョンを確認します。

      $ oc get clusterversion
      注記

      OpenShift Container Platform を次のバージョンに更新することは、OpenShift Virtualization を更新するための前提条件です。詳細は、OpenShift Container Platform ドキュメントのクラスターの更新セクションを参照してください。

  5. OpenShift Virtualization を更新します。

    • デフォルトの 自動 承認ストラテジーでは、OpenShift Container Platform を更新した後、OpenShift Virtualization は対応するバージョンに自動的に更新します。
    • 手動 承認ストラテジーを使用する場合は、Web コンソールを使用して保留中の更新を承認します。
  6. 次のコマンドを実行して、OpenShift Virtualization の更新をモニターします。

    $ oc get csv -n openshift-cnv
  7. OpenShift Virtualization を非 EUS マイナーバージョンで使用可能なすべての z-stream バージョンに更新し、前の手順で示したコマンドを実行して各更新を監視します。
  8. 以下のコマンドを実行して、OpenShift Virtualization が非 EUS バージョンの最新の z-stream リリースに正常に更新されたことを確認します。

    $ oc get hco kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"

    出力例

    [
      {
        "name": "operator",
        "version": "4.12.3"
      }
    ]

  9. 次の更新を実行する前に、HyperConverged Operator が Upgradeable ステータスになるまで待ちます。次のコマンドを入力して、出力をモニターします。

    $ oc get hco kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
  10. OpenShift Container Platform をターゲットの EUS バージョンに更新します。
  11. クラスターのバージョンを確認して、更新が成功したことを確認します。

    $ oc get clusterversion
  12. OpenShift Virtualization をターゲットの EUS バージョンに更新します。

    • デフォルトの 自動 承認ストラテジーでは、OpenShift Container Platform を更新した後、OpenShift Virtualization は対応するバージョンに自動的に更新します。
    • 手動 承認ストラテジーを使用する場合は、Web コンソールを使用して保留中の更新を承認します。
  13. 次のコマンドを実行して、OpenShift Virtualization の更新をモニターします。

    $ oc get csv -n openshift-cnv

    VERSION フィールドがターゲットの EUS バージョンと一致し、PHASE フィールドが Succeeded になると、更新が完了します。

  14. バックアップしたワークロードの更新方法の設定を復元します。

    $ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":$WORKLOAD_UPDATE_METHODS}]"

    出力例

    hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched

    検証

    • 次のコマンドを実行して、VM 移行のステータスを確認します。

      $ oc get vmim -A

次のステップ

  • ワーカーノードのマシン設定プールの一時停止を解除できるようになりました。

7.3. ワークロードの更新方法の設定

HyperConvergedカスタムリソース (CR) を編集することにより、ワークロードの更新方法を設定できます。

前提条件

  • ライブマイグレーションを更新方法として使用するには、まずクラスターでライブマイグレーションを有効にする必要があります。

    注記

    VirtualMachineInstance CR に evictionStrategy: LiveMigrate が含まれており、仮想マシンインスタンス (VMI) がライブマイグレーションをサポートしない場合には、VMI は更新されません。

手順

  1. デフォルトエディターで HyperConverged CR を作成するには、以下のコマンドを実行します。

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged
  2. HyperConverged CR の workloadUpdateStrategy スタンザを編集します。以下に例を示します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      workloadUpdateStrategy:
        workloadUpdateMethods: 1
        - LiveMigrate 2
        - Evict 3
        batchEvictionSize: 10 4
        batchEvictionInterval: "1m0s" 5
    ...
    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メソッドには適用されません。
    注記

    HyperConverged CR のspec.liveMigrationConfigスタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。

  3. 変更を適用するには、エディターを保存し、終了します。

7.4. 保留中の Operator 更新の承認

7.4.1. 保留中の Operator 更新の手動による承認

インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。

前提条件

  • Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
  2. 更新が保留中の Operator は Upgrade available のステータスを表示します。更新する Operator の名前をクリックします。
  3. Subscription タブをクリックします。承認が必要な更新は、アップグレードステータス の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
  4. 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
  5. 更新に利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
  6. 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) をインストールしている。

手順

  1. 以下のコマンドを実行します。

    $ oc get csv -n openshift-cnv
  2. 出力を確認し、PHASE フィールドをチェックします。以下に例を示します。

    出力例

    VERSION  REPLACES                                        PHASE
    4.9.0    kubevirt-hyperconverged-operator.v4.8.2         Installing
    4.9.0    kubevirt-hyperconverged-operator.v4.9.0         Replacing

  3. オプション: 以下のコマンドを実行して、すべての OpenShift Virtualization コンポーネントの状態の集約されたステータスをモニターします。

    $ oc get hco -n openshift-cnv kubevirt-hyperconverged \
    -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'

    アップグレードが成功すると、以下の出力が得られます。

    出力例

    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

7.5.2. 以前の OpenShift Virtualization ワークロードの表示

CLI を使用して、以前のワークロードの一覧を表示できます。

注記

クラスターに以前の仮想化 Pod がある場合には、OutdatedVirtualMachineInstanceWorkloads アラートが実行されます。

手順

  • 以前の仮想マシンインスタンス (VMI) の一覧を表示するには、以下のコマンドを実行します。

    $ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
注記

ワークロードの更新を設定して、VMI が自動的に更新されるようにします。

7.6. 関連情報

第8章 セキュリティーポリシー

仮想マシン (VM) のワークロードは、特権のない Pod として実行されます。仮想マシンが OpenShift Virtualization 機能を使用できるように、一部の Pod には、他の Pod 所有者が使用できないカスタムセキュリティーポリシーが付与されます。

  • 拡張された container_t SELinux ポリシーが virt-launcher Pod に適用されます。
  • セキュリティーコンテキスト制約 (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 拒否でいっぱいになる可能性があります。

  • 次のポリシーによって、libvirtdhugetblfs にアクセスできます。これは、巨大なページをサポートするために必要です。

    • 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 をサポートしていません。

8.3. kubevirt-controller サービスアカウントの追加の OpenShift Container Platform SCC (Security Context Constraints) および Linux 機能

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-controllerSecurityContextConstraints 定義を表示できます。

$ oc get scc kubevirt-controller -o yaml

oc ツールを使用して kubevirt-controller クラスターロールの RBAC 定義を表示できます。

$ oc get clusterrole kubevirt-controller -o yaml

8.4. 関連情報

第9章 CLI ツールの使用

クラスターでリソースを管理するために使用される 2 つの主な CLI ツールは以下の通りです。

  • OpenShift virtualization virtctl クライアント
  • OpenShift Container Platform oc クライアント

9.1. 前提条件

9.2. OpenShift Container Platform クライアントコマンド

OpenShift Container Platform oc クライアントは、VirtualMachine (vm) および VirtualMachineInstance (vmi) オブジェクトタイプを含む、OpenShift Container Platform リソースを管理するためのコマンドラインユーティリティーです。

注記

-n <namespace> フラグを使用して、別のプロジェクトを指定できます。

表9.1 oc コマンド

コマンド説明

oc login -u <user_name>

OpenShift Container Platform クラスターに <user_name> としてログインします。

oc get <object_type>

現在のプロジェクトの指定されたオブジェクトタイプのオブジェクトの一覧を表示します。

oc describe <object_type> <resource_name>

現在のプロジェクトで特定のリソースの詳細を表示します。

oc create -f <object_config>

現在のプロジェクトで、ファイル名または標準入力 (stdin) からリソースを作成します。

oc edit <object_type> <resource_name>

現在のプロジェクトのリソースを編集します。

oc delete <object_type> <resource_name>

現在のプロジェクトのリソースを削除します。

oc client コマンドについてのより総合的な情報については、OpenShift Container Platform CLI ツール のドキュメントを参照してください。

9.3. Virtctl コマンド

virtctl クライアントは、OpenShift Virtualization リソースを管理するためのコマンドラインユーティリティーです。

表9.2 virtctl 一般コマンド

コマンド説明

virtctl version

virtctl クライアントとサーバーのバージョンを表示します。

virtctl help

virtctl コマンドのリストを表示します。

virtctl <command> -h|--help

特定のコマンドのオプションのリストを表示します。

virtctl オプション

任意の virtctl コマンドのグローバルコマンドオプションのリストを表示します。

9.3.1. 仮想マシンおよび VMI 管理コマンド

virtctl を使用して、仮想マシン (VM) または仮想マシンインスタンス (VMI) の状態を管理し、仮想マシンを移行できます。

表9.3 virtctl 仮想マシン管理コマンド

コマンド説明

virtctl start <vm_name>

仮想マシンを開始します。

virtctl start --paused <vm_name>

仮想マシンを一時停止状態で起動します。このオプションを使用すると、VNC コンソールからブートプロセスを中断できます。

virtctl stop <vm_name>

仮想マシンを停止します。

virtctl stop <vm_name> --grace-period 0 --force

仮想マシンを強制停止します。このオプションは、データの不整合またはデータ損失を引き起こす可能性があります。

virtctl pause vm|vmi <vm_name>

仮想マシンまたは VMI を一時停止します。マシンの状態がメモリーに保持されます。

virtctl unpause vm|vmi <vm_name>

仮想マシンまたは VMI の一時停止を解除します。

virtctl migrate <vm_name>

仮想マシンを移行します。

virtctl restart <vm_name>

仮想マシンを再起動します。

9.3.2. 仮想マシンおよび VMI 接続コマンド

virtctl を使用して、シリアルコンソールに接続し、ポートを公開し、プロキシー接続を設定し、ポートを指定し、仮想マシンへの VNC 接続を開くことができます。

表9.4 virtctl consoleexpose、および vnc コマンド

コマンド説明

virtctl console <vmi_name>

VMI のシリアルコンソールに接続します。

virtctl expose <vm_name>

仮想マシンまたは VMI の指定されたポートを転送するサービスを作成し、ノードの指定されたポートでサービスを公開します。

virtctl vnc --kubeconfig=$KUBECONFIG <vmi_name>

VMI への仮想ネットワーククライアント (VNC) 接続を開きます。

VNC を介して VMI のグラフィカルコンソールにアクセスするには、ローカルマシンにリモートビューアーが必要です。

virtctl vnc --kubeconfig=$KUBECONFIG --proxy-only=true <vmi_name>

ポート番号を表示し、VNC 接続を介してビューアーを使用して手動で VMI に接続します。

virtctl vnc --kubeconfig=$KUBECONFIG --port=<port-number> <vmi_name>

ポートが利用可能な場合、その指定されたポートでプロキシーを実行するためにポート番号を指定します。

ポート番号が指定されていない場合、プロキシーはランダムポートで実行されます。

9.3.3. 仮想マシンボリュームエクスポートコマンド

virtctl vmexport コマンドを使用して、仮想マシン、仮想マシンスナップショット、または永続ボリューム要求 (PVC) からエクスポートされたボリュームを作成、ダウンロード、または削除できます。

表9.5 virtctl vmexport コマンド

コマンド説明

virtctl vmexport create <vmexport_name> --vm|snapshot|pvc=<object_name>

仮想マシン、仮想マシンスナップショット、または PVC からボリュームをエクスポートするには、VirtualMachineExport カスタムリソース (CR) を作成します。

  • --vm: 仮想マシンの PVC をエクスポートします。
  • --snapshot: VirtualMachineSnapshot CR に含まれる PVC をエクスポートします。
  • --pvc: PVC をエクスポートします。
  • オプション: --ttl=1h は存続時間を指定します。デフォルトの期間は 2 時間です。

virtctl vmexport delete <vmexport_name>

VirtualMachineExport CR を手動で削除します。

virtctl vmexport download <vmexport_name> --output=<output_file> --volume=<volume_name>

VirtualMachineExport CR で定義されたボリュームをダウンロードします。

  • --output はファイル形式を指定します。例: disk.img.gz
  • --volume は、ダウンロードするボリュームを指定します。使用可能なボリュームが 1 つだけの場合、このフラグはオプションです。

オプション:

  • --keep-vme は、ダウンロード後に VirtualMachineExport CR を保持します。デフォルトの動作では、ダウンロード後に VirtualMachineExport CR を削除します。
  • --insecure は、安全でない HTTP 接続を有効にします。

virtctl vmexport download <vmexport_name> --<vm|snapshot|pvc>=<object_name> --output=<output_file> --volume=<volume_name>

VirtualMachineExport CR を作成し、CR で定義されたボリュームをダウンロードします。

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"}]'

メモリーダンプのダウンロード

メモリーダンプをダウンロードするには、virtctl vmexport download コマンドを使用する必要があります。

$ virtctl vmexport download <vmexport_name> --vm\|pvc=<object_name> \
  --volume=<volume_name> --output=<output_file>

表9.6 virtctl memory-dump コマンド

コマンド説明

virtctl memory-dump get <vm_name> --claim-name=<pvc_name>

仮想マシンのメモリーダンプを PVC に保存します。メモリーダンプのステータスは、VirtualMachine リソースの status セクションに表示されます。

オプション:

  • --create-claim は、適切なサイズで新しい PVC を作成します。このフラグには次のオプションがあります。

    • --storage-class=<storage_class>: PVC のストレージクラスを指定します。
    • --access-mode=<access_mode>: ReadWriteOnce または ReadWriteMany を指定します。

virtctl memory-dump get <vm_name>

同じ PVC で virtctl memory-dump コマンドを再実行します。

このコマンドは、以前のメモリーダンプを上書きします。

virtctl memory-dump remove <vm_name>

メモリーダンプを削除します。

ターゲット PVC を変更する場合は、メモリーダンプを手動で削除する必要があります。

このコマンドは、VirtualMachine リソースの status セクションにメモリーダンプが表示されないように、仮想マシンと PVC の間の関連付けを削除します。PVC は影響を受けません。

9.3.5. イメージアップロードコマンド

virtctl image-upload コマンドを使用して、VM イメージをデータボリュームにアップロードできます。

表9.7 virtctl image-upload コマンド

コマンド説明

virtctl image-upload dv <datavolume_name> --image-path=</path/to/image> --no-create

VM イメージを既存のデータボリュームにアップロードします。

virtctl image-upload dv <datavolume_name> --size=<datavolume_size> --image-path=</path/to/image>

指定された要求されたサイズの新しいデータボリュームに VM イメージをアップロードします。

9.3.6. 環境情報コマンド

virtctl を使用して、バージョン、ファイルシステム、ゲストオペレーティングシステム、およびログインユーザーに関する情報を表示できます。

表9.8 virtctl 環境情報コマンド

コマンド説明

virtctl fslist <vmi_name>

ゲストマシンで使用可能なファイルシステムを表示します。

virtctl guestosinfo <vmi_name>

ゲストマシンのオペレーティングシステムに関する情報を表示します。

virtctl userlist <vmi_name>

ゲストマシンにログインしているユーザーを表示します。

9.4. virtctl guestfs を使用したコンテナーの作成

virtctl guestfs コマンドを使用して、libguestfs-tools および永続ボリューム要求 (PVC) がアタッチされた対話型コンテナーをデプロイできます。

手順

  • libguestfs-tools でコンテナーをデプロイして PVC をマウントし、シェルを割り当てるには、以下のコマンドを実行します。

    $ virtctl guestfs -n <namespace> <pvc_name> 1
    1
    PVC 名は必須の引数です。この引数を追加しないと、エラーメッセージが表示されます。

9.5. Libguestfs ツールおよび virtctl guestfs

Libguestfs ツールは、仮想マシン (VM) のディスクイメージにアクセスして変更するのに役立ちます。libguestfs ツールを使用して、ゲスト内のファイルの表示および編集、仮想マシンのクローンおよびビルド、およびディスクのフォーマットおよびサイズ変更を実行できます。

virtctl guestfs コマンドおよびそのサブコマンドを使用して、PVC で仮想マシンディスクを変更して検査し、デバッグすることもできます。使用可能なサブコマンドの完全な一覧を表示するには、コマンドラインで virt- と入力して Tab を押します。以下に例を示します。

コマンド説明

virt-edit -a /dev/vda /etc/motd

ターミナルでファイルを対話的に編集します。

virt-customize -a /dev/vda --ssh-inject root:string:<public key example>

ゲストに ssh キーを挿入し、ログインを作成します。

virt-df -a /dev/vda -h

仮想マシンによって使用されるディスク容量を確認します。

virt-customize -a /dev/vda --run-command 'rpm -qa > /rpm-list'

詳細の一覧を含む出力ファイルを作成して、ゲストにインストールされたすべての RPM の詳細一覧を参照してください。

virt-cat -a /dev/vda /rpm-list

ターミナルで virt-customize -a /dev/vda --run-command 'rpm -qa > /rpm-list' コマンドを使用して作成されたすべての RPM の出力ファイルの一覧を表示します。

virt-sysprep -a /dev/vda

テンプレートとして使用する仮想マシンディスクイメージをシールします。

デフォルトでは、virtctl guestfs は、仮想ディスク管理に必要な項目を含めてセッションを作成します。ただし、動作をカスタマイズできるように、コマンドは複数のフラグオプションもサポートしています。

フラグオプション説明

--h または --help

guestfs のヘルプを提供します。

-n <namespace> オプションと <pvc_name> 引数

特定の namespace から PVC を使用します。

-n <namespace> オプションを使用しない場合には、現在のプロジェクトが使用されます。プロジェクトを変更するには、oc project <namespace> を使用します。

<pvc_name> 引数を追加しないと、エラーメッセージが表示されます。

--image string

libguestfs-tools コンテナーイメージを一覧表示します。

--image オプションを使用して、コンテナーがカスタムイメージを使用するように設定できます。

--kvm

kvmlibguestfs-tools コンテナーによって使用されることを示します。

デフォルトでは、virtctl guestfs はインタラクティブなコンテナー向けに kvm を設定します。これは、QEMU を使用するため、libguest-tools の実行が大幅に加速されます。

クラスターに kvm をサポートするノードがない場合は、オプション --kvm=false を設定して kvm を無効にする必要があります。

設定されていない場合、libguestfs-tools Pod はいずれのノードにもスケジュールできないため保留状態のままになります。

--pull-policy string

libguestfs イメージのプルポリシーを表示します。

pull-policy オプションを設定してイメージのプルポリシーを上書きすることもできます。

このコマンドは、PVC が別の Pod によって使用されているかどうかを確認します。使用されている場合には、エラーメッセージが表示されます。ただし、libguestfs-tools プロセスが開始されると、設定では同じ PVC を使用する新規 Pod を回避できません。同じ PVC にアクセスする仮想マシンを起動する前に、アクティブな virtctl guestfs Pod がないことを確認する必要があります。

注記

virtctl guestfs コマンドは、インタラクティブな Pod に割り当てられている PVC 1 つだけを受け入れます。

9.6. 関連情報

第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 サイトにアクセスすること。

手順

  1. Web コンソールで、Help メニューから Quick Starts を選択します。
  2. Quick Starts カタログのタイルをクリックします。例: Red Hat Linux Enterprise Linux 仮想マシンの作成
  3. ガイド付きツアーの手順に従い、オペレーティングシステムイメージのインポートと仮想マシンの作成タスクを実行します。VirtualizationVirtualMachines ページに仮想マシンが表示されます。

10.1.2. 仮想マシンのクイック作成

使用可能なブートソースを含むテンプレートを使用して、仮想マシン (VM) をすばやく作成できます。

手順

  1. サイドメニューの VirtualizationCatalog をクリックします。
  2. 利用可能なブートソース をクリックして、テンプレートをブートソースでフィルターリングします。

    注記

    デフォルトでは、テンプレートリストには Default Templates のみが表示されます。選択したフィルターで使用可能なすべてのテンプレートを表示するには、フィルターリング時に すべてのアイテムをクリックします。

  3. テンプレートをクリックして詳細を表示します。
  4. 仮想マシンのクイック作成をクリックして、テンプレートから VM を作成します。

    仮想マシンの詳細ページに、プロビジョニングステータスが表示されます。

検証

  1. Events をクリックして、仮想マシンがプロビジョニングされたときにイベントのストリームを表示します。
  2. Console をクリックして、仮想マシンが正常に起動したことを確認します。

10.1.3. カスタマイズされたテンプレートからの仮想マシンの作成

一部のテンプレートでは、追加のパラメーターが必要です。たとえば、ブート ソースを持つ PVC などです。テンプレートの選択パラメーターをカスタマイズして、仮想マシン (VM) を作成できます。

手順

  1. Web コンソールで、テンプレートを選択します。

    1. サイドメニューの VirtualizationCatalog をクリックします。
    2. オプション: プロジェクト、キーワード、オペレーティングシステム、またはワークロードプロファイルでテンプレートをフィルター処理します。
    3. カスタマイズするテンプレートをクリックします。
  2. Customize VirtualMachineを クリックします。
  3. NameDisk source など、仮想マシンのパラメーターを指定します。オプションで、複製するデータソースを指定できます。

検証

  1. Events をクリックして、仮想マシンがプロビジョニングされたときにイベントのストリームを表示します。
  2. Console をクリックして、仮想マシンが正常に起動したことを確認します。

Web コンソールから仮想マシンを作成する場合は、仮想マシンのフィールドセクションを参照してください。

10.1.3.1. ネットワークフィールド

Name説明

Name

ネットワークインターフェイスコントローラーの名前。

モデル

ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。

ネットワーク

利用可能なネットワーク接続定義の一覧。

Type

利用可能なバインディングメソッドの一覧。ネットワークインターフェイスに適したバインド方法を選択します。

  • デフォルトの Pod ネットワーク: masquerade
  • Linux ブリッジネットワーク: bridge
  • SR-IOV ネットワーク: SR-IOV

MAC Address

ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。

10.1.3.2. ストレージフィールド

Name選択説明

Source

空白 (PVC の作成)

空のディスクを作成します。

URL を使用したインポート (PVC の作成)

URL (HTTP または HTTPS エンドポイント) を介してコンテンツをインポートします。

既存 PVC の使用

クラスターですでに利用可能な PVC を使用します。

既存の PVC のクローン作成 (PVC の作成)

クラスターで利用可能な既存の PVC を選択し、このクローンを作成します。

レジストリーを使用したインポート (PVC の作成)

コンテナーレジストリーを使用してコンテンツをインポートします。

コンテナー (一時的)

クラスターからアクセスできるレジストリーにあるコンテナーからコンテンツをアップロードします。コンテナーディスクは、CD-ROM や一時的な仮想マシンなどの読み取り専用ファイルシステムにのみ使用する必要があります。

Name

 

ディスクの名前。この名前には、小文字 (a-z)、数字 (0-9)、ハイフン (-) およびピリオド (.) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、または特殊文字を使用できません。

Size

 

ディスクのサイズ (GiB 単位)。

Type

 

ディスクのタイプ。例: Disk または CD-ROM

Interface

 

ディスクデバイスのタイプ。サポートされるインターフェイスは、virtIOSATA、および SCSI です。

Storage Class

 

ディスクの作成に使用されるストレージクラス。

ストレージの詳細設定

以下のストレージの詳細設定はオプションであり、BlankImport via URLURL、および Clone existing PVC ディスクで利用できます。OpenShift Virtualization 4.11 より前では、これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。OpenShift Virtualization 4.11 以降では、システムは ストレージプロファイル のデフォルト値を使用します。

注記

ストレージプロファイルを使用して、OpenShift Virtualization のストレージをプロビジョニングするときに一貫した高度なストレージ設定を確保します。

Volume ModeAccess Mode を手動で指定するには、デフォルトで選択されている Apply optimized StorageProfile settings チェックボックスをオフにする必要があります。

Nameモードの説明パラメーターパラメーターの説明

ボリュームモード

永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。

Filesystem

ファイルシステムベースのボリュームで仮想ディスクを保存します。

Block

ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 Block を使用します。

アクセスモード

永続ボリュームのアクセスモード。

ReadWriteOnce (RWO)

ボリュームは単一ノードで読み取り/書き込みとしてマウントできます。

ReadWriteMany (RWX)

ボリュームは、一度に多くのノードで読み取り/書き込みとしてマウントできます。

注記

これは、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。

ReadOnlyMany (ROX)

ボリュームは数多くのノードで読み取り専用としてマウントできます。

10.1.3.3. Cloud-init フィールド

Name説明

認可された SSH キー

仮想マシンの ~/.ssh/authorized_keys にコピーされるユーザーの公開鍵。

カスタムスクリプト

他のオプションを、カスタム cloud-init スクリプトを貼り付けるフィールドに置き換えます。

ストレージクラスのデフォルトを設定するには、ストレージプロファイルを使用します。詳細については、ストレージプロファイルのカスタマイズを参照してください。

10.1.3.4. 仮想マシンウィザードの作成用の事前に設定された YAML ファイルの貼り付け

YAML 設定ファイルを作成し、解析して仮想マシンを作成します。YAML 編集画面を開くと、常に有効な example 仮想マシン設定がデフォルトで提供されます。

Create をクリックする際に YAML 設定が無効な場合、エラーメッセージでエラーが発生したパラメーターが示唆されます。エラーは一度に 1 つのみ表示されます。

注記

編集中に YAML 画面から離れると、設定に対して加えた変更が取り消されます。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. Create をクリックし、With YAML を選択します。
  3. 編集可能なウィンドウで仮想マシンの設定を作成するか、またはこれを貼り付けます。

    1. または、YAML 画面にデフォルトで提供される example 仮想マシンを使用します。
  4. オプション: Download をクリックして YAML 設定ファイルをその現在の状態でダウンロードします。
  5. Create をクリックして仮想マシンを作成します。

仮想マシンが VirtualMachines ページに一覧表示されます。

10.1.4. CLI の使用による仮想マシンの作成

virtualMachine マニフェストから仮想マシンを作成できます。

手順

  1. 仮想マシンの VirtualMachine マニフェストを編集します。たとえば、次のマニフェストは Red Hat Enterprise Linux (RHEL) 仮想マシンを設定します。

    例10.1 RHEL 仮想マシンのマニフェストの例

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      labels:
        app: <vm_name> 1
      name: <vm_name>
    spec:
      dataVolumeTemplates:
      - apiVersion: cdi.kubevirt.io/v1beta1
        kind: DataVolume
        metadata:
          name: <vm_name>
        spec:
          sourceRef:
            kind: DataSource
            name: rhel9
            namespace: openshift-virtualization-os-images
          storage:
            resources:
              requests:
                storage: 30Gi
      running: false
      template:
        metadata:
          labels:
            kubevirt.io/domain: <vm_name>
        spec:
          domain:
            cpu:
              cores: 1
              sockets: 2
              threads: 1
            devices:
              disks:
              - disk:
                  bus: virtio
                name: rootdisk
              - disk:
                  bus: virtio
                name: cloudinitdisk
              interfaces:
              - masquerade: {}
                name: default
              rng: {}
            features:
              smm:
                enabled: true
            firmware:
              bootloader:
                efi: {}
            resources:
              requests:
                memory: 8Gi
          evictionStrategy: LiveMigrate
          networks:
          - name: default
            pod: {}
          volumes:
          - dataVolume:
              name: <vm_name>
            name: rootdisk
          - cloudInitNoCloud:
              userData: |-
                #cloud-config
                user: cloud-user
                password: '<password>' 2
                chpasswd: { expire: False }
            name: cloudinitdisk
    1
    仮想マシンの名前を指定します。
    2
    cloud-user のパスワードを指定します。
  2. マニフェストファイルを使用して仮想マシンを作成します。

    $ oc create -f <vm_manifest_file>.yaml
  3. オプション: 仮想マシンを開始します。

    $ virtctl start <vm_name>

10.1.5. 仮想マシンのストレージボリュームタイプ

ストレージボリュームタイプ説明

ephemeral

ネットワークボリュームを読み取り専用のバッキングストアとして使用するローカルの copy-on-write (COW) イメージ。バッキングボリュームは PersistentVolumeClaim である必要があります。一時イメージは仮想マシンの起動時に作成され、すべての書き込みをローカルに保存します。一時イメージは、仮想マシンの停止、再起動または削除時に破棄されます。バッキングボリューム (PVC) はいずれの方法でも変更されません。

persistentVolumeClaim

利用可能な PV を仮想マシンに割り当てます。PV の割り当てにより、仮想マシンデータのセッション間での永続化が可能になります。

CDI を使用して既存の仮想マシンディスクを PVC にインポートし、PVC を仮想マシンインスタンスに割り当てる方法は、既存の仮想マシンを OpenShift Container Platform にインポートするための推奨される方法です。ディスクを PVC 内で使用できるようにするためのいくつかの要件があります。

dataVolume

データボリュームは、インポート、クローンまたはアップロード操作で仮想マシンディスクの準備プロセスを管理することによって persistentVolumeClaim ディスクタイプにビルドされます。このボリュームタイプを使用する仮想マシンは、ボリュームが準備できるまで起動しないことが保証されます。

type: dataVolume または type: "" を指定します。persistentVolumeClaim などの type に他の値を指定すると、警告が表示され、仮想マシンは起動しません。

cloudInitNoCloud

参照される cloud-init NoCloud データソースが含まれるディスクを割り当て、ユーザーデータおよびメタデータを仮想マシンに提供します。cloud-init インストールは仮想マシンディスク内で必要になります。

containerDisk

コンテナーイメージレジストリーに保存される、仮想マシンディスクなどのイメージを参照します。イメージはレジストリーからプルされ、仮想マシンの起動時にディスクとして仮想マシンに割り当てられます。

containerDisk ボリュームは、単一の仮想マシンに制限されず、永続ストレージを必要としない多数の仮想マシンのクローンを作成するのに役立ちます。

RAW および QCOW2 形式のみがコンテナーイメージレジストリーのサポートされるディスクタイプです。QCOW2 は、縮小されたイメージサイズの場合に推奨されます。

注記

containerDisk ボリュームは一時的なボリュームです。これは、仮想マシンが停止されるか、再起動するか、または削除される際に破棄されます。containerDisk ボリュームは、CD-ROM などの読み取り専用ファイルシステムや破棄可能な仮想マシンに役立ちます。

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 (手動)
startstop、および restart virtctl クライアントコマンドは、 VMI の状態および存在を制御するために使用できます。
Halted
仮想マシンが作成される際に VMI は存在しません。これは spec.running: false と同じ動作です。

startstop、および restart の virtctl コマンドの各種の組み合わせは、どの RunStrategy が使用されるかに影響を与えます。

以下の表は、仮想マシンの各種の状態からの移行について示しています。最初の列には、仮想マシンの初期の RunStrategy が表示されます。それぞれの追加の列には、virtctl コマンドと、このコマンド実行後の新規 RunStrategy が表示されます。

初期 RunStrategystartstoprestart

Always

-

Halted

Always

RerunOnFailure

-

Halted

RerunOnFailure

Manual

Manual

Manual

Manual

Halted

Always

-

-

注記

インストーラーでプロビジョニングされるインフラストラクチャーを使用してインストールされた OpenShift Virtualization クラスターでは、ノードで MachineHealthCheck に失敗し、クラスターで利用できなくなると、RunStrategy が Always または RerunOnFailure の仮想マシンが新規ノードで再スケジュールされます。

apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  RunStrategy: Always 1
  template:
...
1
VMI の現在の RunStrategy 設定。

10.1.7. 関連情報

10.2. 仮想マシンの編集

Web コンソールの YAML エディターまたはコマンドラインの OpenShift CLI のいずれかを使用して、仮想マシン設定を更新できます。Virtual Machine Details 画面でパラメーターのサブセットを更新することもできます。

10.2.1. Web コンソールでの仮想マシンの編集

OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイスを使用して、仮想マシンを編集できます。

手順

  1. Web コンソールで VirtualizationVirtualMachines に移動します。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. フィールドが編集可能であることを示す鉛筆アイコンが付いているフィールドをクリックします。たとえば、BIOS や UEFI などの現在の ブートモード 設定をクリックして、Boot mode ウィンドウを開き、リストからオプションを選択します。
  4. Save をクリックします。
注記

仮想マシンが実行されている場合、Boot Order または Flavor への変更は仮想マシンを再起動するまで反映されません。

関連するフィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

10.2.2. Web コンソールを使用した仮想マシンの YAML 設定の編集

Web コンソールで、仮想マシンの YAML 設定を編集できます。一部のパラメーターは変更できません。無効な設定で Save をクリックすると、エラーメッセージで変更できないパラメーターが示唆されます。

注記

編集中に YAML 画面から離れると、設定に対して加えた変更が取り消されます。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択します。
  3. YAML タブをクリックして編集可能な設定を表示します。
  4. オプション: Download をクリックして YAML ファイルをその現在の状態でローカルにダウンロードできます。
  5. ファイルを編集し、Save をクリックします。

オブジェクトの更新されたバージョン番号を含む、変更が正常に行われたことを示す確認メッセージが表示されます。

10.2.3. CLI を使用した仮想マシン YAML 設定の編集

以下の手順を使用し、CLI を使用して仮想マシン YAML 設定を編集します。

前提条件

  • YAML オブジェクト設定ファイルを使って仮想マシンを設定していること。
  • oc CLI をインストールしていること。

手順

  1. 以下のコマンドを実行して、仮想マシン設定を更新します。

    $ oc edit <object_type> <object_ID>
  2. オブジェクト設定を開きます。
  3. YAML を編集します。
  4. 実行中の仮想マシンを編集する場合は、以下のいずれかを実行する必要があります。

    • 仮想マシンを再起動します。
    • 新規の設定を有効にするために、以下のコマンドを実行します。

      $ oc apply <object_type> <object_ID>

10.2.4. 仮想マシンへの仮想ディスクの追加

以下の手順を使用して仮想ディスクを仮想マシンに追加します。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details 画面を開きます。
  3. Disks タブをクリックし、Add disk をクリックします。
  4. Add disk ウィンドウで、SourceNameSizeTypeInterface、および Storage Class を指定します。

    1. オプション: 空のディスクソースを使用し、データボリュームの作成時に最大の書き込みパフォーマンスが必要な場合に、事前割り当てを有効にできます。そのためには、Enable preallocation チェックボックスをオンにします。
    2. オプション: Apply optimized StorageProfile settings をクリアして、仮想ディスクの Volume ModeAccess Mode を変更できます。これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults config map のデフォルト値を使用します。
  5. Add をクリックします。
注記

仮想マシンが実行中の場合、新規ディスクは pending restart 状態にあり、仮想マシンを再起動するまで割り当てられません。

ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

ストレージクラスのデフォルトを設定するには、ストレージプロファイルを使用します。詳細については、ストレージプロファイルのカスタマイズを参照してください。

10.2.4.1. VirtualMachine の CD-ROM の編集

以下の手順を使用して、仮想マシンの CD-ROM を編集します。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details 画面を開きます。
  3. Disks タブをクリックします。
  4. 編集する CD-ROM の Options メニュー kebab をクリックし、Edit を選択します。
  5. Edit CD-ROM ウィンドウで、SourcePersistent Volume ClaimNameType、および Interface フィールドを編集します。
  6. Save をクリックします。

10.2.4.2. ストレージフィールド

Name選択説明

Source

空白 (PVC の作成)

空のディスクを作成します。

URL を使用したインポート (PVC の作成)

URL (HTTP または HTTPS エンドポイント) を介してコンテンツをインポートします。

既存 PVC の使用

クラスターですでに利用可能な PVC を使用します。

既存の PVC のクローン作成 (PVC の作成)

クラスターで利用可能な既存の PVC を選択し、このクローンを作成します。

レジストリーを使用したインポート (PVC の作成)

コンテナーレジストリーを使用してコンテンツをインポートします。

コンテナー (一時的)

クラスターからアクセスできるレジストリーにあるコンテナーからコンテンツをアップロードします。コンテナーディスクは、CD-ROM や一時的な仮想マシンなどの読み取り専用ファイルシステムにのみ使用する必要があります。

Name

 

ディスクの名前。この名前には、小文字 (a-z)、数字 (0-9)、ハイフン (-) およびピリオド (.) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、または特殊文字を使用できません。

Size

 

ディスクのサイズ (GiB 単位)。

Type

 

ディスクのタイプ。例: Disk または CD-ROM

Interface

 

ディスクデバイスのタイプ。サポートされるインターフェイスは、virtIOSATA、および SCSI です。

Storage Class

 

ディスクの作成に使用されるストレージクラス。

ストレージの詳細設定

以下のストレージの詳細設定はオプションであり、BlankImport via URLURL、および Clone existing PVC ディスクで利用できます。OpenShift Virtualization 4.11 より前では、これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。OpenShift Virtualization 4.11 以降では、システムは ストレージプロファイル のデフォルト値を使用します。

注記

ストレージプロファイルを使用して、OpenShift Virtualization のストレージをプロビジョニングするときに一貫した高度なストレージ設定を確保します。

Volume ModeAccess Mode を手動で指定するには、デフォルトで選択されている Apply optimized StorageProfile settings チェックボックスをオフにする必要があります。

Nameモードの説明パラメーターパラメーターの説明

ボリュームモード

永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。

Filesystem

ファイルシステムベースのボリュームで仮想ディスクを保存します。

Block

ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 Block を使用します。

アクセスモード

永続ボリュームのアクセスモード。

ReadWriteOnce (RWO)

ボリュームは単一ノードで読み取り/書き込みとしてマウントできます。

ReadWriteMany (RWX)

ボリュームは、一度に多くのノードで読み取り/書き込みとしてマウントできます。

注記

これは、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。

ReadOnlyMany (ROX)

ボリュームは数多くのノードで読み取り専用としてマウントできます。

10.2.5. 仮想マシンへのネットワークインターフェイスの追加

以下の手順を使用してネットワークインターフェイスを仮想マシンに追加します。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details 画面を開きます。
  3. Network Interfaces タブをクリックします。
  4. Add Network Interface をクリックします。
  5. Add Network Interface ウィンドウで、ネットワークインターフェイスの NameModelNetworkType、および MAC Address を指定します。
  6. Add をクリックします。
注記

仮想マシンが実行中の場合、新規ネットワークインターフェイスは pending restart 状態にあり、仮想マシンを再起動するまで変更は反映されません。

ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

10.2.5.1. ネットワークフィールド

Name説明

Name

ネットワークインターフェイスコントローラーの名前。

モデル

ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。

ネットワーク

利用可能なネットワーク接続定義の一覧。

Type

利用可能なバインディングメソッドの一覧。ネットワークインターフェイスに適したバインド方法を選択します。

  • デフォルトの Pod ネットワーク: masquerade
  • Linux ブリッジネットワーク: bridge
  • SR-IOV ネットワーク: SR-IOV

MAC Address

ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。

10.2.6. 関連情報

10.3. ブート順序の編集

Web コンソールまたは CLI を使用して、ブート順序リストの値を更新できます。

Virtual Machine Overview ページの Boot Order で、以下を実行できます。

  • ディスクまたはネットワークインターフェイスコントローラー (NIC) を選択し、これをブート順序の一覧に追加します。
  • ブート順序の一覧でディスクまたは NIC の順序を編集します。
  • ブート順序の一覧からディスクまたは NIC を削除して、起動可能なソースのインベントリーに戻します。

10.3.1. Web コンソールでのブート順序一覧への項目の追加

Web コンソールを使用して、ブート順序一覧に項目を追加します。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Details タブをクリックします。
  4. Boot Order の右側にある鉛筆アイコンをクリックします。YAML 設定が存在しない場合や、これがブート順序一覧の初回作成時の場合、以下のメッセージが表示されます。No resource selected.仮想マシンは、YAML ファイルでの出現順にディスクからの起動を試行します。
  5. Add Source をクリックして、仮想マシンのブート可能なディスクまたはネットワークインターフェイスコントローラー (NIC) を選択します。
  6. 追加のディスクまたは NIC をブート順序一覧に追加します。
  7. Save をクリックします。
注記

仮想マシンが実行されている場合、Boot Order への変更は仮想マシンを再起動するまで反映されません。

Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

10.3.2. Web コンソールでのブート順序一覧の編集

Web コンソールで起動順序一覧を編集します。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Details タブをクリックします。
  4. Boot Order の右側にある鉛筆アイコンをクリックします。
  5. ブート順序一覧で項目を移動するのに適した方法を選択します。

    • スクリーンリーダーを使用しない場合、移動する項目の横にある矢印アイコンにカーソルを合わせ、項目を上下にドラッグし、選択した場所にドロップします。
    • スクリーンリーダーを使用する場合は、上矢印キーまたは下矢印を押して、ブート順序一覧で項目を移動します。次に Tab キーを押して、選択した場所に項目をドロップします。
  6. Save をクリックします。
注記

仮想マシンが実行されている場合、ブート順序の変更は仮想マシンが再起動されるまで反映されません。

Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

10.3.3. YAML 設定ファイルでのブート順序一覧の編集

CLI を使用して、YAML 設定ファイルのブート順序の一覧を編集します。

手順

  1. 以下のコマンドを実行して、仮想マシンの YAML 設定ファイルを開きます。

    $ oc edit vm example
  2. YAML ファイルを編集し、ディスクまたはネットワークインターフェイスコントローラー (NIC) に関連付けられたブート順序の値を変更します。以下に例を示します。

    disks:
      - bootOrder: 1 1
        disk:
          bus: virtio
        name: containerdisk
      - disk:
          bus: virtio
        name: cloudinitdisk
      - cdrom:
          bus: virtio
        name: cd-drive-1
    interfaces:
      - boot Order: 2 2
        macAddress: '02:96:c4:00:00'
        masquerade: {}
        name: default
    1
    ディスクに指定されたブート順序の値。
    2
    ネットワークインターフェイスコントローラーに指定されたブート順序の値。
  3. YAML ファイルを保存します。
  4. reload the content をクリックして、Web コンソールで YAML ファイルの更新されたブート順序の値をブート順序一覧に適用します。

10.3.4. Web コンソールでのブート順序一覧からの項目の削除

Web コンソールを使用して、ブート順序の一覧から項目を削除します。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Details タブをクリックします。
  4. Boot Order の右側にある鉛筆アイコンをクリックします。
  5. 項目の横にある Remove アイコン delete をクリックします。この項目はブート順序の一覧から削除され、利用可能なブートソースの一覧に保存されます。ブート順序一覧からすべての項目を削除する場合、以下のメッセージが表示されます。No resource selected.仮想マシンは、YAML ファイルでの出現順にディスクからの起動を試行します。
注記

仮想マシンが実行されている場合、Boot Order への変更は仮想マシンを再起動するまで反映されません。

Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

10.4. 仮想マシンの削除

Web コンソールまたは oc コマンドラインインターフェイスを使用して、仮想マシンを削除できます。

10.4.1. Web コンソールの使用による仮想マシンの削除

仮想マシンを削除すると、仮想マシンはクラスターから永続的に削除されます。

注記

仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 削除する仮想マシンの Options メニュー kebab をクリックし、Delete を選択します。

    • または、仮想マシン名をクリックして VirtualMachine details ページを開き、ActionsDelete をクリックします。
  3. 確認のポップアップウィンドウで、Delete をクリックし、仮想マシンを永続的に削除します。

10.4.2. CLI の使用による仮想マシンの削除

oc コマンドラインインターフェイス (CLI) を使用して仮想マシンを削除できます。oc クライアントを使用すると、複数の仮想マシンで各種のアクションを実行できます。

注記

仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。

前提条件

  • 削除する仮想マシンの名前を特定すること。

手順

  • 以下のコマンドを実行し、仮想マシンを削除します。

    $ oc delete vm <vm_name>
    注記

    このコマンドは、現在のプロジェクトに存在するオブジェクトのみを削除します。削除する必要のあるオブジェクトが別のプロジェクトまたは namespace にある場合、-n <project_name> オプションを指定します。

10.5. 仮想マシンのエクスポート

仮想マシンを別のクラスターにインポートしたり、フォレンジック目的でボリュームを分析したりするために、仮想マシン (VM) とそれに関連付けられたディスクをエクスポートできます。

コマンドラインインターフェイスを使用して、VirtualMachineExport カスタムリソース (CR) を作成します。

または、virtctl vmexport コマンド を使用して VirtualMachineExport CR を作成し、エクスポートされたボリュームをダウンロードすることもできます。

10.5.1. VirtualMachineExport カスタムリソースの作成

VirtualMachineExport カスタムリソース (CR) を作成して、次のオブジェクトをエクスポートできます。

  • 仮想マシン (VM): 指定された仮想マシンの永続ボリューム要求 (PVC) をエクスポートします。
  • VM スナップショット: VirtualMachineSnapshot CR に含まれる PVC をエクスポートします。
  • PVC: PVC をエクスポートします。PVC が virt-launcher Pod などの別の Pod で使用されている場合、エクスポートは PVC が使用されなくなるまで Pending 状態のままになります。

VirtualMachineExport CR は、エクスポートされたボリュームの内部および外部リンクを作成します。内部リンクはクラスター内で有効です。外部リンクには、Ingress または Route を使用してアクセスできます。

エクスポートサーバーは、次のファイル形式をサポートしています。

  • raw: raw ディスクイメージファイル。
  • gzip: 圧縮されたディスクイメージファイル。
  • dir: PVC ディレクトリーとファイル。
  • tar.gz: 圧縮された PVC ファイル。

前提条件

  • 仮想マシンをエクスポートするには、仮想マシンをシャットダウンする必要があります。

手順

  1. 次の例に従って VirtualMachineExport マニフェストを作成し、VirtualMachineVirtualMachineSnapshot、または PersistentVolumeClaim CR からボリュームをエクスポートし、example-export.yaml として保存します。

    VirtualMachineExport の例

    apiVersion: export.kubevirt.io/v1alpha1
    kind: VirtualMachineExport
    metadata:
      name: example-export
    spec:
      source:
        apiGroup: "kubevirt.io" 1
        kind: VirtualMachine 2
        name: example-vm
      ttlDuration: 1h 3

    1
    適切な API グループを指定します。
    • VirtualMachine"kubevirt.io"
    • VirtualMachineSnapshot"snapshot.kubevirt.io"
    • PersistentVolumeClaim""
    2
    VirtualMachineVirtualMachineSnapshot、または PersistentVolumeClaim を指定します。
    3
    オプション:デフォルトの期間は 2 時間です。
  2. VirtualMachineExport CR を作成します。

    $ oc create -f example-export.yaml
  3. VirtualMachineExport CR を取得します。

    $ oc get vmexport example-export -o yaml

    エクスポートされたボリュームの内部および外部リンクは、status スタンザに表示されます。

    出力例

    apiVersion: export.kubevirt.io/v1alpha1
    kind: VirtualMachineExport
    metadata:
      name: example-export
      namespace: example
    spec:
      source:
        apiGroup: ""
        kind: PersistentVolumeClaim
        name: example-pvc
      tokenSecretRef: example-token
    status:
      conditions:
      - lastProbeTime: null
        lastTransitionTime: "2022-06-21T14:10:09Z"
        reason: podReady
        status: "True"
        type: Ready
      - lastProbeTime: null
        lastTransitionTime: "2022-06-21T14:09:02Z"
        reason: pvcBound
        status: "True"
        type: PVCReady
      links:
        external: 1
          cert: |-
            -----BEGIN CERTIFICATE-----
            ...
            -----END CERTIFICATE-----
          volumes:
          - formats:
            - format: raw
              url: https://vmexport-proxy.test.net/api/export.kubevirt.io/v1alpha1/namespaces/example/virtualmachineexports/example-export/volumes/example-disk/disk.img
            - format: gzip
              url: https://vmexport-proxy.test.net/api/export.kubevirt.io/v1alpha1/namespaces/example/virtualmachineexports/example-export/volumes/example-disk/disk.img.gz
            name: example-disk
        internal:  2
          cert: |-
            -----BEGIN CERTIFICATE-----
            ...
            -----END CERTIFICATE-----
          volumes:
          - formats:
            - format: raw
              url: https://virt-export-example-export.example.svc/volumes/example-disk/disk.img
            - format: gzip
              url: https://virt-export-example-export.example.svc/volumes/example-disk/disk.img.gz
            name: example-disk
      phase: Ready
      serviceName: virt-export-example-export

    1
    外部リンクは、Ingress または Route を使用してクラスターの外部からアクセスできます。
    2
    内部リンクは、クラスター内でのみ有効です。

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

10.6.3. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの一覧表示

Web コンソールを使用して、仮想マシンによって所有されていないクラスター内のスタンドアロンの仮想マシンインスタンス (VMI) の一覧を表示できます。

注記

仮想マシンまたは他のオブジェクトが所有する VMI は、Web コンソールには表示されません。Web コンソールは、スタンドアロンの VMI のみを表示します。クラスター内のすべての VMI を一覧表示するには、CLI を使用する必要があります。

手順

  • サイドメニューから VirtualizationVirtualMachines をクリックします。

    スタンドアロン VMI は、名前の横にある濃い色のバッジで識別できます。

10.6.4. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの編集

Web コンソールを使用して、スタンドアロン仮想マシンインスタンスのアノテーションおよびラベルを編集できます。他のフィールドは編集できません。

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. スタンドアロン VMI を選択して、VirtualMachineInstance details ページを開きます。
  3. Details タブで、Annotations または Labels の横にある鉛筆アイコンをクリックします。
  4. 関連する変更を加え、Save をクリックします。

10.6.5. CLI を使用したスタンドアロン仮想マシンインスタンスの削除

oc コマンドラインインターフェイス (CLI) を使用してスタンドアロン仮想マシンインスタンス (VMI) を削除できます。

前提条件

  • 削除する必要のある VMI の名前を特定すること。

手順

  • 以下のコマンドを実行して VMI を削除します。

    $ oc delete vmi <vmi_name>

10.6.6. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの削除

Web コンソールからスタンドアロン仮想マシンインスタンス (VMI) を削除します。

手順

  1. Open Shift Container Platform Web コンソールで、サイドメニューからVirtualizationVirtualMachinesをクリックします。
  2. ActionsDelete VirtualMachineInstance をクリックします。
  3. 確認のポップアップウィンドウで、Delete をクリックし、スタンドアロン VMI を永続的に削除します。

10.7. 仮想マシンの状態の制御

Web コンソールから仮想マシンを停止し、起動し、再起動し、一時停止を解除することができます。

virtctl を使用して仮想マシンの状態を管理し、CLI から他のアクションを実行できます。たとえば、virtctl を使用して仮想マシンを強制停止したり、ポートを公開したりできます。

10.7.1. 仮想マシンの起動

Web コンソールから仮想マシンを起動できます。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 起動する仮想マシンが含まれる行を見つけます。
  3. ユースケースに適したメニューに移動します。

    • 複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。

      1. 行の右端にある Options メニュー kebab をクリックします。
    • 選択した仮想マシンを起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。

      1. 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
      2. Actions をクリックします。
  4. 再起動を選択します。
  5. 確認ウィンドウで Start をクリックし、仮想マシンを起動します。
注記

URL ソースからプロビジョニングされる仮想マシンの初回起動時に、OpenShift Virtualization が URL エンドポイントからコンテナーをインポートする間、仮想マシンの状態は Importing になります。このプロセスは、イメージのサイズによって数分の時間がかかる可能性があります。

10.7.2. 仮想マシンの再起動

Web コンソールから実行中の仮想マシンを再起動できます。

重要

エラーを回避するには、ステータスが Importing の仮想マシンは再起動しないでください。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 再起動する仮想マシンが含まれる行を見つけます。
  3. ユースケースに適したメニューに移動します。

    • 複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。

      1. 行の右端にある Options メニュー kebab をクリックします。
    • 選択した仮想マシンを再起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。

      1. 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
      2. ActionsRestart をクリックします。
  4. 確認ウィンドウで Restart をクリックし、仮想マシンを再起動します。

10.7.3. 仮想マシンの停止

Web コンソールから仮想マシンを停止できます。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 停止する仮想マシンが含まれる行を見つけます。
  3. ユースケースに適したメニューに移動します。

    • 複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。

      1. 行の右端にある Options メニュー kebab をクリックします。
    • 選択した仮想マシンを停止する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。

      1. 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
      2. ActionsStop をクリックします。
  4. 確認ウィンドウで Stop をクリックし、仮想マシンを停止します。

10.7.4. 仮想マシンの一時停止の解除

Web コンソールから仮想マシンの一時停止を解除できます。

前提条件

  • 1 つ以上の仮想マシンのステータスが Paused である必要がある。

    注記

    virtctl クライアントを使用して仮想マシンを一時停止することができます。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 一時停止を解除する仮想マシンが含まれる行を見つけます。
  3. ユースケースに適したメニューに移動します。

    • 複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。

      1. Status 列で、Paused をクリックします。
    • 選択した仮想マシンの一時停止を解除する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。

      1. 仮想マシンの名前をクリックして、VirtualMachine details ページにアクセスします。
      2. Status の右側にある鉛筆アイコンをクリックします。
  4. 確認ウィンドウで Stop をクリックし、仮想マシンの一時停止を解除します。

10.8. 仮想マシンコンソールへのアクセス

OpenShift Virtualization は、異なる製品タスクを実現するために使用できる異なる仮想マシンコンソールを提供します。これらのコンソールには、OpenShift Container Platform Web コンソールから、また CLI コマンドを使用してアクセスできます。

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 タブから、実行中の仮想マシンのシリアルコンソールに接続します。

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Console タブをクリックします。VNC コンソールがデフォルトで開きます。
  4. 一度に 1 つのコンソール セッションのみが開かれるようにするには、Disconnect をクリックします。それ以外の場合、VNC コンソール セッションはバックグラウンドでアクティブなままになります。
  5. VNC Console ドロップダウンリストをクリックし、Serial Console を選択します。
  6. Disconnect をクリックして、コンソールセッションを終了します。
  7. オプション: Open Console in New Window をクリックして、別のウィンドウでシリアルコンソールを開きます。

10.8.1.2. VNC コンソールへの接続

Web コンソールの VirtualMachine details ページにある Console タブから、実行中の仮想マシンの VNC コンソールに接続します。

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Console タブをクリックします。VNC コンソールがデフォルトで開きます。
  4. オプション: Open Console in New Window をクリックして、別のウィンドウで VNC コンソールを開きます。
  5. オプション: Send Key をクリックして、キーの組み合わせを仮想マシンに送信します。
  6. コンソールウィンドウの外側をクリックし、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 クライアント。

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. Windows 仮想マシンをクリックして、VirtualMachine details ページを開きます。
  3. Console タブをクリックします。
  4. コンソールのリストから、Desktop viewer を選択します。
  5. Launch Remote Desktop をクリックし、 console.rdp ファイルをダウンロードします。
  6. 優先する RDP クライアントで console.rdp ファイルを参照して、Windows 仮想マシンに接続します。

10.8.1.4. 仮想マシンの表示の切り替え

Windows 仮想マシン (VM) に vGPU が接続されている場合、Web コンソールを使用してデフォルトのディスプレイと vGPU ディスプレイを切り替えることができます。

前提条件

  • 仲介されたデバイスは、HyperConverged カスタムリソースで設定され、仮想マシンに割り当てられます。
  • 仮想マシンは実行中です。

手順

  1. OpenShift Container Platform コンソールで、VirtualizationVirtualMachines をクリックします。
  2. Windows 仮想マシンを選択して Overview 画面を開きます。
  3. Console タブをクリックします。
  4. コンソールのリストから、VNC console を選択します。
  5. Send Key リストから適切なキーの組み合わせを選択します。

    1. デフォルトの仮想マシン表示にアクセスするには、Ctl + Alt+ 1 を選択します。
    2. vGPU ディスプレイにアクセスするには、Ctl + Alt + 2 を選択します。

10.8.1.5. Web コンソールを使用した SSH コマンドのコピー

コマンドをコピーして、SSH 経由で仮想マシン (VM) ターミナルに接続します。

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. オプション メニューをクリック kebab 仮想マシンの SSH コマンドのコピー を選択します。
  3. ターミナルに貼り付け、仮想マシンにアクセスします。

10.8.2. CLI コマンドの使用による仮想マシンコンソールへのアクセス

10.8.2.1. virtctl を使用して SSH 経由で仮想マシンにアクセスする

virtctl ssh コマンドを使用して、ローカル SSH クライアントを使用して SSH トラフィックを仮想マシン (VM) に転送できます。

注記

コントロールプレーンの SSH トラフィックが多いと、API サーバーの速度が低下する可能性があります。定期的に多数の接続が必要な場合は、専用の Kubernetes Service オブジェクトを使用して仮想マシンにアクセスします。

前提条件

  • cluster-admin パーミッションを持つ OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • virtctl クライアントをインストールしました。
  • アクセスする仮想マシンが実行されています。
  • 仮想マシンと同じプロジェクトにいます。

手順

  1. ssh-keygen コマンドを使用して、SSH 公開鍵ペアを生成します。

    $ ssh-keygen -f <key_file> 1
    1
    キーを格納するファイルを指定します。
  2. 仮想マシンにアクセスするための SSH 公開鍵を含む SSH 認証シークレットを作成します。

    $ oc create secret generic my-pub-key --from-file=key1=<key_file>.pub
  3. VirtualMachine マニフェストにシークレットへの参照を追加します。以下に例を示します。

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: testvm
    spec:
      running: true
      template:
        spec:
          accessCredentials:
          - sshPublicKey:
              source:
                secret:
                  secretName: my-pub-key 1
              propagationMethod:
                configDrive: {} 2
    # ...
    1
    SSH 認証 Secret オブジェクトへの参照。
    2
    SSH 公開鍵は、configDrive プロバイダーを使用して cloud-init メタデータとして仮想マシンに挿入されます。
  4. 仮想マシンを再起動して変更を適用します。
  5. 次のコマンドを実行して、SSH 経由で仮想マシンにアクセスします。

    $ virtctl ssh -i <key_file> <vm_username>@<vm_name>
  6. オプション: 仮想マシンとの間でファイルを安全に転送するには、次のコマンドを使用します。

    マシンから仮想マシンにファイルをコピーする

    $ virtctl scp -i <key_file> <filename> <vm_username>@<vm_name>:

    仮想マシンからマシンにファイルをコピーする

    $ virtctl scp -i <key_file> <vm_username@<vm_name>:<filename> .

10.8.2.2. 仮想マシンインスタンスのシリアルコンソールへのアクセス

virtctl console コマンドは、指定された仮想マシンインスタンスへのシリアルコンソールを開きます。

前提条件

  • virt-viewer パッケージがインストールされていること。
  • アクセスする仮想マシンインスタンスが実行中であること。

手順

  • virtctl でシリアルコンソールに接続します。

    $ virtctl console <VMI>

10.8.2.3. VNC を使用した仮想マシンインスタンスのグラフィカルコンソールへのアクセス

virtctl クライアントユーティリティーは remote-viewer 機能を使用し、実行中の仮想マシンインスタンスに対してグラフィカルコンソールを開くことができます。この機能は virt-viewer パッケージに組み込まれています。

前提条件

  • virt-viewer パッケージがインストールされていること。
  • アクセスする仮想マシンインスタンスが実行中であること。
注記

リモートマシンで SSH 経由で virtctl を使用する場合、X セッションをマシンに転送する必要があります。

手順

  1. virtctl ユーティリティーを使用してグラフィカルインターフェイスに接続します。

    $ virtctl vnc <VMI>
  2. コマンドが失敗した場合には、トラブルシューティング情報を収集するために -v フラグの使用を試行します。

    $ virtctl vnc <VMI> -v 4

10.8.2.4. RDP コンソールの使用による Windows 仮想マシンへの接続

ローカルのリモートデスクトッププロトコル (RDP) クライアントを使用して、Windows 仮想マシン (VM) に接続するための Kubernetes Service オブジェクトを作成します。

前提条件

  • QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。qemu-guest-agent オブジェクトは VirtIO ドライバーに含まれています。
  • ローカルマシンにインストールされた RDP クライアント。

手順

  1. VirtualMachine マニフェストを編集して、サービス作成のラベルを追加します。

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: vm-ephemeral
      namespace: example-namespace
    spec:
      running: false
      template:
        metadata:
          labels:
            special: key 1
    # ...
    1
    ラベル special: keyspec.template.metadata.labels セクションに追加します。
    注記

    仮想マシンのラベルは Pod に渡されます。special: キー ラベルは、Service マニフェストの spec.selector 属性のラベルと一致する必要があります。

  2. VirtualMachine マニフェストファイルを保存して変更を適用します。
  3. 仮想マシンを公開するための Service マニフェストを作成します。

    apiVersion: v1
    kind: Service
    metadata:
      name: rdpservice 1
      namespace: example-namespace 2
    spec:
      ports:
      - targetPort: 3389 3
        protocol: TCP
      selector:
        special: key 4
      type: NodePort 5
    # ...
    1
    Service オブジェクトの名前。
    2
    Service オブジェクトが存在する namespace。これは VirtualMachine マニフェストの metadata.namespace フィールドと同じである必要があります。
    3
    サービスによって公開される仮想マシンポート。ポートリストが仮想マシンマニフェストに定義されている場合は、オープンポートを参照する必要があります。
    4
    VirtualMachine マニフェストの spec.template.metadata.labels スタンザに追加したラベルへの参照。
    5
    サービスのタイプ。
  4. サービス マニフェストファイルを保存します。
  5. 以下のコマンドを実行してサービスを作成します。

    $ oc create -f <service_name>.yaml
  6. 仮想マシンを起動します。仮想マシンがすでに実行中の場合は、再起動します。
  7. Service オブジェクトをクエリーし、これが利用可能であることを確認します。

    $ oc get service -n example-namespace

    NodePort サービスの出力例

    NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)            AGE
    rdpservice   NodePort    172.30.232.73   <none>       3389:30000/TCP    5m

  8. 以下のコマンドを実行して、ノードの IP アドレスを取得します。

    $ oc get node <node_name> -o wide

    出力例

    NAME    STATUS   ROLES   AGE    VERSION  INTERNAL-IP      EXTERNAL-IP
    node01  Ready    worker  6d22h  v1.24.0  192.168.55.101   <none>

  9. 優先する RDP クライアントでノード IP アドレスと割り当てられたポートを指定します。
  10. Windows 仮想マシンに接続するためのユーザー名とパスワードを入力します。

10.9. sysprep を使用した Windows のインストールの自動化

Microsoft DVD イメージとsysprepを使用して、Windows 仮想マシンのインストール、セットアップ、およびソフトウェアプロビジョニングを自動化できます。

10.9.1. Windows DVD を使用した VM ディスクイメージの作成

Microsoft はダウンロード用のディスクイメージを提供していませんが、Windows DVD を使用してディスクイメージを作成できます。このディスクイメージを使用して、仮想マシンを作成できます。

手順

  1. Open Shift Virtualization Web コンソールで、StoragePersistentVolumeClaimsCreate PersistentVolumeClaim With Data upload formをクリックします。
  2. 目的のプロジェクトを選択します。
  3. 永続ボリューム要求の名前を設定します。
  4. Windows DVD から仮想マシンディスクイメージをアップロードします。これで、イメージをブートソースとして使用して、新しい Windows 仮想マシンを作成できます。

10.9.2. ディスクイメージを使用した Windows のインストール

ディスクイメージを使用して、仮想マシンに Windows をインストールできます。

前提条件

  • Windows DVD を使用してディスクイメージを作成する必要があります。
  • autounattend.xml 応答ファイルを作成する必要があります。詳細は、Microsoft のドキュメント を参照してください。

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから VirtualizationCatalog をクリックします。
  2. Windows テンプレートを選択し、Customize VirtualMachine をクリックします。
  3. Disk source リストから Upload (Upload a new file to a PVC) を選択し、DVD イメージを参照します。
  4. Review and create VirtualMachine をクリックします。
  5. Clone available operating system source to this Virtual Machine のチェックを外します。
  6. Start this VirtualMachine after creation のチェックを外します。
  7. Scripts タブの Sysprep セクションで、Edit をクリックします。
  8. autounattend.xml 応答ファイルを参照し、Save をクリックします。
  9. Create VirtualMachine をクリックします。
  10. YAML タブで、running:falserunStrategy: RerunOnFailure に置き換え、Save をクリックします。

VM は、autounattend.xml 応答ファイルを含む sysprep ディスクで開始されます。

10.9.3. sysprep を使用した Windows 仮想マシンの一般化

イメージを一般化すると、イメージが仮想マシン (VM) にデプロイされる際に、システム固有の設定データがすべて削除されます。

仮想マシンを一般化する前に、Windows の無人インストール後にsysprepツールが応答ファイルを検出できないことを確認する必要があります。

手順

  1. OpenShift Container Platform コンソールで、VirtualizationVirtualMachines をクリックします。
  2. Windows 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Disks タブをクリックします。
  4. sysprep ディスクの Options メニュー kebab をクリックし、Detach を選択します。
  5. デタッチ をクリックします。
  6. sysprepツールによる検出を回避するために、C:\Windows\Panther\unattend.xmlの名前を変更します。
  7. 次のコマンドを実行して、 sysprepプログラムを開始します。

    %WINDIR%\System32\Sysprep\sysprep.exe /generalize /shutdown /oobe /mode:vm
  8. sysprepツールが完了すると、Windows 仮想マシンがシャットダウンします。これで、仮想マシンのディスクイメージを Windows 仮想マシンのインストールイメージとして使用できるようになりました。

これで、仮想マシンを特殊化できます。

10.9.4. Windows 仮想マシンの特殊化

仮想マシン (VM) を特殊化すると、一般化された Windows イメージから VM にコンピューター固有の情報が設定されます。

前提条件

  • 一般化された Windows ディスクイメージが必要です。
  • unattend.xml 応答ファイルを作成する必要があります。詳細は、Microsoft のドキュメント を参照してください。

手順

  1. OpenShift Container Platform コンソールで、VirtualizationCatalog をクリックします。
  2. Windows テンプレートを選択し、Customize VirtualMachine をクリックします。
  3. Disk source リストから PVC (clone PVC) を選択します。
  4. 一般化された Windows イメージの Persistent Volume Claim project および Persistent Volume Claim name を指定します。
  5. Review and create VirtualMachine をクリックします。
  6. Scripts タブをクリックします。
  7. Sysprep セクションで、Edit をクリックし、unattend.xml 応答ファイルを参照して、Save をクリックします。
  8. Create VirtualMachine をクリックします。

Windows は初回起動時に、unattend.xml 応答ファイルを使用して VM を特殊化します。これで、仮想マシンを使用する準備が整いました。

10.9.5. 関連情報

10.10. 障害が発生したノードの解決による仮想マシンのフェイルオーバーのトリガー

ノードに障害が発生し、マシンヘルスチェック がクラスターにデプロイされていない場合、RunStrategy: Always が設定された仮想マシン (VM) は正常なノードに自動的に移動しません。仮想マシンのフェイルオーバーをトリガーするには、Node オブジェクトを手動で削除する必要があります。

注記

インストーラーでプロビジョニングされるインフラストラクチャー を使用してクラスターをインストールし、マシンヘルスチェックを適切に設定している場合は、以下のようになります。

  • 障害が発生したノードは自動的に再利用されます。
  • RunStrategyAlways または RerunOnFailure に設定された仮想マシンは正常なノードで自動的にスケジュールされます。

10.10.1. 前提条件

  • 仮想マシンが実行されているノードには NotReady 状態 が設定されている。
  • 障害のあるノードで実行されていた仮想マシンでは、 RunStrategyAlways に設定されている。
  • OpenShift CLI (oc) がインストールされている。

10.10.2. ベアメタルクラスターからのノードの削除

CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーで管理されないベア Pod は、OpenShift Container Platform からはアクセスできなくなります。レプリケーションコントローラーで管理されるベア Pod は、他の利用可能なノードに再スケジュールされます。ローカルのマニフェスト Pod は削除する必要があります。

手順

以下の手順を実行して、ベアメタルで実行されている OpenShift Container Platform クラスターからノードを削除します。

  1. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

    $ oc adm cordon <node_name>
  2. ノード上のすべての Pod をドレイン (解放) します。

    $ oc adm drain <node_name> --force=true

    このステップは、ノードがオフラインまたは応答しない場合に失敗する可能性があります。ノードが応答しない場合でも、共有ストレージに書き込むワークロードを実行している可能性があります。データの破損を防ぐには、続行する前に物理ハードウェアの電源を切ります。

  3. クラスターからノードを削除します。

    $ oc delete node <node_name>

    ノードオブジェクトはクラスターから削除されていますが、これは再起動後や kubelet サービスが再起動される場合にクラスターに再び参加することができます。ノードとそのすべてのデータを永続的に削除するには、ノードの使用を停止 する必要があります。

  4. 物理ハードウェアを電源を切っている場合は、ノードがクラスターに再度加わるように、そのハードウェアを再びオンに切り替えます。

10.10.3. 仮想マシンのフェイルオーバーの確認

すべてのリソースが正常でないノードで終了すると、移行した仮想マシンのそれぞれについて、新しい仮想マシンインスタンス (VMI) が正常なノードに自動的に作成されます。VMI が作成されていることを確認するには、oc CLI を使用してすべての VMI を表示します。

10.10.3.1. CLI を使用した仮想マシンインスタンスの一覧表示

oc コマンドラインインターフェイス (CLI) を使用して、スタンドアロンおよび仮想マシンによって所有されている VMI を含むすべての仮想マシンの一覧を表示できます。

手順

  • 以下のコマンドを実行して、すべての VMI の一覧を表示します。

    $ oc get vmis -A

10.11. QEMU ゲストエージェントの仮想マシンへのインストール

QEMU ゲストエージェント は、仮想マシンで実行され、仮想マシン、ユーザー、ファイルシステム、およびセカンダリーネットワークに関する情報をホストに渡すデーモンです。

10.11.1. QEMU ゲストエージェントの Linux 仮想マシンへのインストール

qemu-guest-agent は広く利用されており、Red Hat 仮想マシンでデフォルトで利用できます。このエージェントをインストールし、サービスを起動します。

仮想マシン (VM) に QEMU ゲストエージェントがインストールされ、実行されているかどうかを確認するには、AgentConnected が VM 仕様に表示されていることを確認します。

注記

整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。

QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。

手順

  1. コンソールのいずれか、または SSH を使用して仮想マシンのコマンドラインにアクセスします。
  2. QEMU ゲストエージェントを仮想マシンにインストールします。

    $ yum install -y qemu-guest-agent
  3. サービスに永続性があることを確認し、これを起動します。

    $ systemctl enable --now qemu-guest-agent

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 バージョンについてのインストールドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows ユーザーセッションにログインします。
  3. Device Manager を開き、Other devices を拡張して、Unknown device を一覧表示します。

    1. Device Properties を開いて、不明なデバイスを特定します。デバイスを右クリックし、Properties を選択します。
    2. Details タブをクリックし、Property リストで Hardware Ids を選択します。
    3. Hardware IdsValue をサポートされる VirtIO ドライバーと比較します。
  4. デバイスを右クリックし、Update Driver Software を選択します。
  5. Browse my computer for driver software をクリックし、VirtIO ドライバーが置かれている割り当て済みの SATA CD ドライブの場所に移動します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. Next をクリックしてドライバーをインストールします。
  7. 必要なすべての VirtIO ドライバーに対してこのプロセスを繰り返します。
  8. ドライバーのインストール後に、Close をクリックしてウィンドウを閉じます。
  9. 仮想マシンを再起動してドライバーのインストールを完了します。

10.11.2.2. Windows インストール時の VirtIO ドライバーのインストール

Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。

注記

この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows インストールプロセスを開始します。
  3. Advanced インストールを選択します。
  4. ストレージの宛先は、ドライバーがロードされるまで認識されません。Load driver をクリックします。
  5. ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
  7. Windows インストールを完了します。

10.12. 仮想マシンの QEMU ゲストエージェント情報の表示

QEMU ゲストエージェントが仮想マシンで実行されている場合は、Web コンソールを使用して、仮想マシン、ユーザー、ファイルシステム、およびセカンダリーネットワークに関する情報を表示できます。

10.12.1. 前提条件

10.12.2. Web コンソールでの QEMU ゲストエージェント情報について

QEMU ゲストエージェントがインストールされると、VirtualMachine details ページの Overview タブおよび Details タブに、ホスト名、オペレーティングシステム、タイムゾーン、およびログインユーザーに関する情報が表示されます。

VirtualMachine details ページには、仮想マシンにインストールされているゲストオペレーティングシステムに関する情報が表示されます。Details タブには、ログインユーザーの情報が含まれる表が表示されます。Disks タブには、ファイルシステムの情報が含まれる表が表示されます。

注記

QEMU ゲストエージェントがインストールされていないと、Overview タブおよび Details タブには、仮想マシンの作成時に指定したオペレーティングシステムについての情報が表示されます。

10.12.3. Web コンソールでの QEMU ゲストエージェント情報の表示

Web コンソールを使用して、QEMU ゲストエージェントによってホストに渡される仮想マシンの情報を表示できます。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシン名を選択して、VirtualMachine details ページを開きます。
  3. Details タブをクリックして、アクティブなユーザーを表示します。
  4. 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 に存在する必要がある。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Environment タブで、Add Config Map, Secret or Service Account をクリックします。
  4. Select a resource をクリックし、リストから resource を選択します。6 文字のシリアル番号が、選択したリソースについて自動的に生成されます。
  5. オプション: Reload をクリックして、環境を最後に保存した状態に戻します。
  6. Save をクリックします。

検証

  1. VirtualMachine details ページで、Disks タブをクリックし、シークレット、config map、またはサービスアカウントがディスクのリストに含まれていることを確認します。
  2. ActionsRestart をクリックして、仮想マシンを再起動します。

他のディスクをマウントするように、シークレット、設定マップ、またはサービスアカウントをマウントできるようになりました。

10.13.2. 仮想マシンからのシークレット、設定マップ、またはサービスアカウントの削除

OpenShift Container Platform Web コンソールを使用して、シークレット、設定マップ、またはサービスアカウントを仮想マシンから削除します。

前提条件

  • 仮想マシンに割り当てられるシークレット、設定マップ、またはサービスアカウントが少なくとも 1 つ必要である。

手順

  1. サイドメニューから VirtualizationVirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Environment タブをクリックします。
  4. 一覧で削除する項目を見つけ、項目の右上にある Remove delete をクリックします。
  5. Save をクリックします。
注記

Reload をクリックし、最後に保存された状態にフォームをリセットできます。

検証

  1. VirtualMachine details ページで、Disks タブをクリックします。
  2. 削除したシークレット、設定マップ、またはサービスアカウントがディスクの一覧に含まれていないことを確認します。

10.13.3. 関連情報

10.14. VirtIO ドライバーの既存の Windows 仮想マシンへのインストール

10.14.1. VirtIO ドライバーについて

VirtIO ドライバーは、Microsoft Windows 仮想マシンが OpenShift Virtualization で実行されるために必要な準仮想化デバイスドライバーです。サポートされるドライバーは、Red Hat Ecosystem Catalogcontainer-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 ドライバー

表10.1 サポートされるドライバー

ドライバー名ハードウェア ID説明

viostor

VEN_1AF4&DEV_1001
VEN_1AF4&DEV_1042

ブロックドライバー。Other devices グループの SCSI Controller として表示される場合があります。

viorng

VEN_1AF4&DEV_1005
VEN_1AF4&DEV_1044

エントロピーソースドライバー。Other devices グループの PCI Device として表示される場合があります。

NetKVM

VEN_1AF4&DEV_1000
VEN_1AF4&DEV_1041

ネットワークドライバー。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 レジストリーからダウンロードされるため、これは必須ではありません。

手順

  1. container-native-virtualization/virtio-win コンテナーディスクを cdrom ディスクとして Windows 仮想マシン設定ファイルに追加します。コンテナーディスクは、クラスターにない場合はレジストリーからダウンロードされます。

    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2 1
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk