Virtualization

• Linux および Windows 仮想マシン (VM) の作成と管理
• クラスター内で Pod と仮想マシンのワークロードの同時実行
• 各種コンソールおよび CLI ツールの使用による仮想マシンへの接続
• 既存の仮想マシンのインポートおよびクローン作成
• ネットワークインターフェイスコントローラーおよび仮想マシンに割り当てられたストレージディスクの管理
• 仮想マシンのノード間でのライブマイグレーション

• ライブマイグレーションには ReadWriteMany (RWX) アクセスモードが必要です。

• Block ボリュームモードは、Filesystem ボリュームモードと比較してパフォーマンスが大幅に向上します。これは、Filesystem ボリュームモードでは、ファイルシステムレイヤーやディスクイメージファイルなどを含め、より多くのストレージレイヤーが使用されるためです。仮想マシンのディスクストレージに、これらのレイヤーは必要ありません。

  たとえば、Red Hat OpenShift Data Foundation を使用する場合は、CephFS ボリュームよりも Ceph RBD ボリュームの方が推奨されます。

  重要

  以下を使用する仮想マシンのライブマイグレーションを行うことはできません。

  • ReadWriteOnce (RWO) アクセスモードのストレージボリューム
  • GPU などのパススルー機能

  それらの仮想マシンの evictionStrategy フィールドを LiveMigrate に設定しないでください。

• 高可用性
• Pod の中断
• ライブマイグレーション
• エビクションストラテジーが設定されている仮想マシンまたはテンプレート

• コンピューティング: virt-operator
• ストレージ: cdi-operator
• ネットワーク: cluster-network-addons-operator
• スケーリング: ssp-operator
• テンプレート作成: tekton-tasks-operator

• OpenShift Virtualization のベアメタルクラスターを計画 します。
• OpenShift Virtualization 用にクラスターを準備 します。
• OpenShift Virtualization Operator をインストール します。
• virtctl コマンドラインインターフェイス (CLI) ツールをインストール します。

• 仮想マシンディスクのストレージボリュームについて
• CSI 対応のストレージプロバイダーの使用
• 仮想マシンのローカルストレージの設定
• Kubernetes NMState Operator のインストール
• 仮想マシンのノードの指定
• Virtctl コマンド

• 仮想マシンをクイック作成します。
• テンプレートをカスタマイズして仮想マシンを作成します。

• Web コンソールを使用して、仮想マシンの Serial コンソール または VNC コンソール に接続します。
• SSH を使用して仮想マシンに接続します。
• RDP を使用して Windows 仮想マシンに接続します。

• Web コンソールを使用して、仮想マシンを停止、開始、一時停止、再起動します。
• virtctl CLI ツールを使用して、仮想マシンを管理したり、ポートを公開したり、シリアルコンソールに接続したりします。
• 仮想マシンのエクスポート。

• VM をセカンダリーネットワークに接続します。

  • 仮想マシンを Linux ブリッジネットワークに接続します。

  • 仮想マシンを SR-IOV ネットワークに接続します。

    注記

    VM はデフォルトで Pod ネットワークに接続されます。Linux ブリッジや SR-IOV などのセカンダリーネットワークを設定してから、そのネットワークを仮想マシン設定に追加する必要があります。

• 仮想マシンをライブマイグレーションします。
• 仮想マシンをバックアップおよび復元します。
• クラスターのチューニングとスケーリング

• OpenShift Virtualization が FIPS に対応しました。ただし、OpenShift Container Platform 4.13 は Red Hat Enterprise Linux (RHEL) 9.2 をベースにしています。RHEL 9.2 はまだ FIPS 認定のために提出されていません。ただし、特定の期限は確約できませんが、Red Hat は RHEL 9.0 および RHEL 9.2 モジュール、その後は RHEL 9.x のマイナーリリースについても、FIPS 認定を取得することを想定しています。更新は Compliance Activities and Government Standards から入手できる予定です。

• OpenShift Virtualization は、Windows Server のワークロードを実行する Microsoft の Windows Server Virtualization Validation Program (SVVP) で認定されています。

  SVVP の認定は以下に適用されます。

  • Red Hat Enterprise Linux CoreOS ワーカー。Microsoft SVVP カタログでは、Red Hat OpenShift Container Platform 4.13 という名前になっています。
  • Intel および AMD CPU。

• OpenShift Virtualization は、restricted Kubernetes pod security standardsプロファイルに準拠するようになりました。詳細は、OpenShift Virtualization の セキュリティーポリシー ドキュメントを参照してください。

• 現在、OpenShift Virtualization は Red Hat Enterprise Linux (RHEL) 9 をベースにしています。

  • 仮想マシン用の新しい RHEL 9 マシンタイプ (machineType: pc-q35-rhel9.2.0) があります。

    OpenShift Virtualization に含まれるすべての仮想マシンテンプレートは、デフォルトでこのマシンタイプを使用するようになりました。

  • 詳細は、RHEL 9 上の OpenShift Virtualization を参照してください。

• 仮想マシンまたはスナップショットをエクスポートした後、エクスポートサーバーから VirtualMachine、ConfigMap、Secret マニフェストを取得できるようになりました。詳細は、エクスポートされた仮想マシンマニフェストへのアクセス を参照してください。

• 「ロギング、イベント、モニタリング」ドキュメントの名前は、サポート に変更されました。モニタリングツールのドキュメントは モニタリング に移動されました。

• LokiStack を使用すると、Web コンソールに集約された OpenShift Virtualization ログを表示およびフィルタリングできます。

• Prometheus を使用して次のメトリクスを監視できるようになりました。

  • kubevirt_vmi_cpu_system_usage_seconds は、ハイパーバイザーが消費した物理システム CPU 時間を返します。
  • kubevirt_vmi_cpu_user_usage_seconds は、ハイパーバイザーが消費した物理ユーザー CPU 時間を返します。
  • kubevirt_vmi_cpu_usage_seconds は、vCPU とハイパーバイザーの合計使用量を計算し、使用された合計 CPU 時間を秒単位で返します。

• checkup を実行して、OpenShift Container Platform クラスターノードがパケット損失ゼロで Data Plane Development Kit (DPDK) ワークロードがある仮想マシンを実行できるか検証できるようになりました。

• 仮想マシンを DPDK ワークロードを実行するように設定 すると、ユーザー空間でのパケット処理を高速化するために、レイテンシーの短縮とスループットの向上を実現できます。

• 完全修飾ドメイン名 (FQDN) を使用して、クラスター外部から セカンダリーネットワークインターフェイスにアタッチされている仮想マシンにアクセス できるようになりました。

• OpenShift Virtualization VM によってホストされるワーカーノードを使用して OpenShift Container Platform クラスターを作成できるようになりました。詳細は、Red Hat Advanced Cluster Management (RHACM) ドキュメントの OpenShift Virtualization でのホストされたコントロールプレーンクラスターの管理 を参照してください。

• Microsoft Windows 11 をゲスト OS として使用できるようになりました。ただし、OpenShift Virtualization 4.13 は、BitLocker リカバリーの重要な機能に必要な USB ディスクをサポートしていません。回復キーを保護するには、BitLocker recovery guide で説明されている他の方法を使用します。

• Containerized Data Importer (CDI) が作成した一部の Persistent Volume Claim (PVC) アノテーションが原因で、仮想マシンのスナップショットのリストア操作が無期限にハングすることがなくなりました。(BZ#2070366)

• RHSA-2023:3722 アドバイザリーのリリースにより、FIPS 対応 RHEL 9 システム上の TLS 1.2 接続に、TLS Extended Master Secret (EMS) エクステンション (RFC 7627) エクステンションが必須になりました。これは FIPS-140-3 要件に準拠しています。TLS 1.3 は影響を受けません。

  EMS または TLS 1.3 をサポートしていないレガシー OpenSSL クライアントは、RHEL 9 で実行されている FIPS サーバーに接続できなくなりました。同様に、FIPS モードの RHEL 9 クライアントは、EMS なしでは TLS 1.2 のみをサポートするサーバーに接続できません。これは実際には、これらのクライアントが RHEL 6、RHEL 7、および RHEL 以外のレガシーオペレーティングシステム上のサーバーに接続できないことを意味します。これは、OpenSSL のレガシー 1.0.x バージョンが EMS または TLS 1.3 をサポートしていないためです。詳細は、TLS Extension "Extended Master Secret" enforced with Red Hat Enterprise Linux 9.2 を参照してください。

  回避策として、レガシー OpenSSL クライアントを TLS 1.3 をサポートするバージョンにアップグレードし、FIPS モードで 最新の TLS セキュリティープロファイルタイプで TLS 1.3 を使用するように OpenShift Virtualization を設定します。

• OpenShift Virtualization 4.12.4 で HyperConverged カスタムリソースを編集して DisableMDEVConfiguration 機能ゲートを有効にした場合は、バージョン 4.13.0 または 4.13.1 にアップグレードした後、JSON Patch アノテーション (BZ#2184439) を作成して機能ゲートを再度有効にする必要があります。):

  $ oc annotate --overwrite -n openshift-cnv hyperconverged kubevirt-hyperconverged \
      kubevirt.kubevirt.io/jsonpatch='[{"op": "add","path": "/spec/configuration/developerConfiguration/featureGates/-", \
      "value": "DisableMDEVConfiguration"}]'

  Copy to Clipboard Toggle word wrap

• OpenShift Virtualization バージョン 4.12.2 以前は、OpenShift Container Platform 4.13 との互換性がありません。OpenShift Virtualization 4.12.1 および 4.12.2 では、設計により OpenShift Container Platform 4.13 への更新がブロックされますが、この制限は OpenShift Virtualization 4.12.0 に追加できませんでした。OpenShift Virtualization 4.12.0 を使用している場合は、OpenShift Container Platform を 4.13 に更新しないでください。

  重要

  OpenShift Container Platform と OpenShift Virtualization の互換性のないバージョンを実行すると、クラスターはサポートされなくなります。

• 仮想マシン上での Descheduler エビクションの有効化はテクニカルプレビュー機能であり、移行の失敗や不安定なスケジューリングを引き起こす可能性があります。
• シングルスタックの IPv6 クラスターで OpenShift Virtualization は実行できません。(BZ#2193267)

• 異なる SELinux コンテキストで 2 つの Pod を使用すると、ocs-storagecluster-cephfs ストレージクラスの VM が移行に失敗し、VM のステータスが Paused に変わります。これは、両方の Pod が ReadWriteMany CephFS の共有ボリュームに同時にアクセスしようとするためです。(BZ#2092271)

  • 回避策として、ocs-storagecluster-ceph-rbd ストレージクラスを使用して、Red Hat Ceph Storage を使用するクラスターで VM をライブマイグレーションします。

• csi-clone クローンストラテジーを使用して 100 台以上の仮想マシンのクローンを作成する場合、Ceph CSI はクローンをパージしない可能性があります。クローンの手動削除も失敗する可能性があります。(BZ#2055595)

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

• クラスター上のノードを停止し、Node Health Check Operator を使用してノードを再起動すると、Multus への接続が失われる可能性があります。(OCPBUGS-8398)

• OpenShift Virtualization 4.12 では、TopoLVM プロビジョナー名の文字列が変更されました。その結果、オペレーティングシステムイメージの自動インポートが失敗し、次のエラーメッセージが表示される場合があります (BZ#2158521)。

  DataVolume.storage spec is missing accessMode and volumeMode, cannot get access mode from StorageProfile.

  Copy to Clipboard Toggle word wrap

  • 回避策として、以下を実施します。

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

       $ oc patch storageprofile <storage_profile> --type=merge -p '{"spec": {"claimPropertySets": [{"accessModes": ["ReadWriteOnce"], "volumeMode": "Block"}, \
           {"accessModes": ["ReadWriteOnce"], "volumeMode": "Filesystem"}]}}'

       Copy to Clipboard Toggle word wrap
    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)

• Windows 11 仮想マシンは、FIPS モード で実行されているクラスターで起動しません。Windows 11 には、デフォルトで Trusted Platform Module (TPM) デバイスが必要です。ただし、swtpm (ソフトウェア TPM エミュレーター) パッケージは FIPS と互換性がありません。(BZ#2089301)

• OpenShift Container Platform クラスターが OVN-Kubernetes をデフォルトの Container Network Interface (CNI) プロバイダーとして使用する場合、OVN-Kubernetes のホストネットワークトポロジーの変更により、Linux ブリッジまたはボンディングデバイスをホストのデフォルトインターフェイスに割り当てることはできません。(BZ#1885605)

  • 回避策として、ホストに接続されたセカンダリーネットワークインターフェイスを使用するか、OpenShift SDN デフォルト CNI プロバイダーに切り替えることができます。

• 場合によっては、複数の仮想マシンが読み取り/書き込みモードで同じ PVC をマウントできるため、データが破損する可能性があります。(BZ#1992753)

  • 回避策として、複数の仮想マシンで読み取り/書き込みモードで単一の PVC を使用しないでください。

• Pod Disruption Budget (PDB) は、移行可能な仮想マシンイメージについての Pod の中断を防ぎます。PDB が Pod の中断を検出する場合、openshift-monitoring は LiveMigrate エビクションストラテジーを使用する仮想マシンイメージに対して 60 分ごとに PodDisruptionBudgetAtLimit アラートを送信します。(BZ#2026733)

  • 回避策として、アラートをサイレント にします。

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

  • 回避策として、サービスアカウントではなくユーザーアカウントを使用してください。ユーザーアカウントトークンは特定の Pod にバインドされていないためです。

• コンピュートノードがさまざま含まれる、異種クラスターでは、HyperV Reenlightenment が有効になっている仮想マシンは、タイムスタンプカウンタースケーリング (TSC) をサポートしていないノード、TSC 頻度が非季節なノードでスケジュールできません。(BZ#2151169)

• Red Hat OpenShift Data Foundation を使用して OpenShift Virtualization をデプロイする場合は、Windows 仮想マシンディスク用の専用ストレージクラスを作成する必要があります。詳細は Optimizing ODF PersistentVolumes for Windows VMs を参照してください。

• ブロックストレージデバイスと論理ボリューム管理(LVM)を使用する仮想マシンには、Red Hat Enterprise Linux CoreOS (RHCOS)ホストと競合しないように追加の設定が必要です。

  • 回避策として、仮想マシンの作成、LVM のプロビジョニング、仮想マシンの再起動が可能です。これにより、空の system.lvmdevices ファイルが作成されます。(OCPBUGS-5223)

• 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.13 は OpenShift Container Platform 4.13 で実行する必要があります。

  • クラスターのサポート容易性および機能が損なわれるリスクがあるので、Manual 承認ストラテジーを選択することは可能ですが、推奨していません。Manual 承認ストラテジーでは、保留中のすべての更新を手動で承認する必要があります。OpenShift Container Platform および OpenShift Virtualization の更新の同期が取れていない場合には、クラスターはサポートされなくなります。
• 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。
• OpenShift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
• データボリュームおよびその関連付けられた永続ボリューム要求は更新時に保持されます。

前提条件

• OpenShift Container Platform の EUS バージョンを実行中で、次の EUS バージョンに更新する予定である。その間、奇数番号のバージョンにまだ更新していません。
• 「EUS から EUS への更新を実行するための準備」を読み、OpenShift Container Platform クラスターに関連する警告と要件を学習しました。
• OpenShift Container Platform ドキュメントの指示に従って、ワーカーノードのマシン設定プールを一時停止しました。
• デフォルトの Automatic 承認ストラテジーを使用することを推奨します。Manual 承認ストラテジーを使用する場合は、Web コンソールで保留中のすべての更新を承認する必要があります。詳細は、「保留中の Operator の更新を手動で承認する」セクションを参照してください。