Menu Close
仮想化
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-Kubernetes、OpenShift SDN、または Certified OpenShift CNI プラグイン に記載されている、その他の認定 デフォルトの Container Network Interface(CNI)ネットワークプロバイダーの 1 つと使用できます。
1.1.1. OpenShift Virtualization サポートのクラスターバージョン
OpenShift Virtualization 4.10 は OpenShift Container Platform 4.10 クラスターで使用するためにサポートされます。Open Shift Virtualization の最新の z-stream リリースを使用するには、最初に Open Shift Container Platform の最新バージョンにアップグレードする必要があります。
第2章 OpenShift Virtualization の使用開始
以下の表を使用して、OpenShift Virtualization について確認し、使用に役立つコンテンツを見てください。
2.1. クラスター管理者
詳細情報 | プラン | デプロイ | 関連情報 |
---|---|---|---|
OpenShift Virtualization コンソールまたは CLIを使用した OpenShift Virtualization のインストール | |||
2.2. 仮想化管理者
2.3. 仮想マシン管理者/開発者
第3章 OpenShift Virtualization リリースノート
3.1. Red Hat OpenShift Virtualization について
Red Hat OpenShift Virtualization は、従来の仮想マシン (VM) をコンテナーと共に実行される OpenShift Container Platform に組み込み、それらをネイティブ Kubernetes オブジェクトとして管理することを可能にします。
OpenShift Virtualization は、
ロゴで表されます。
OVN-Kubernetes または OpenShiftSDN のデフォルトの Container Network Interface(CNI)ネットワークプロバイダーのいずれかで OpenShift Virtualization を使用できます。
OpenShift Virtualization の機能について参照し てください。
3.1.1. OpenShift Virtualization サポートのクラスターバージョン
OpenShift Virtualization 4.10 は OpenShift Container Platform 4.10 クラスターで使用するためにサポートされます。Open Shift Virtualization の最新の z-stream リリースを使用するには、最初に Open Shift Container Platform の最新バージョンにアップグレードする必要があります。
3.1.2. サポート対象のゲストオペレーティングシステム
OpenShift Virtualizationでサポートされているゲストオペレーティングシステムを確認するにはCertified Guest Operating Systems in Red Hat OpenStack Platform, Red Hat Virtualization and OpenShift Virtualization参照してください。
3.2. 多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージをご覧ください。
3.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 Service Mesh に統合されるようになりました。仮想マシンをサービスメッシュに接続 して、IPv4 を使用して仮想マシンワークロードを実行する Pod 間のトラフィックを監視し、可視化し、制御できます。
- OpenShift Virtualization は、事前に定義されたブートソースの自動インポートおよび更新 用に統一された API を提供するようになりました。
3.3.1. クイックスタート
-
クイックスタートツアーは、複数の OpenShift Virtualization 機能で利用できます。ツアーを表示するには、OpenShift Virtualization コンソールのヘッダーのメニューバーにある Help アイコン ? をクリックし、Quick Starts を選択します。Filter フィールドに
virtual machine
キーワードを入力して、利用可能なツアーをフィルターできます。
3.3.2. インストール
-
virt-launcher
Pod などの OpenShift Virtualization ワークロードは、ライブマイグレーションをサポートしている場合に自動更新されるようになりました。HyperConverged
カスタムリソースを編集して、ワークロード更新ストラテジーを設定 したり、今後の自動更新をオプトアウトしたりできます。
Single Node OpenShift(SNO)として知られる単一ノードクラスターで OpenShift Virtualization を使用できるようになりました。
注記シングルノードクラスターは高可用性操作用に設定されていないため、OpenShift Virtualizationの動作が大幅に変更されます。
- リソース要求および優先順位クラスは、すべての OpenShift Virtualization コントロールプレーンコンポーネントに対して定義されるようになりました。
3.3.3. ネットワーキング
-
単一の
NodeNetworkConfigurationPolicy
マニフェストを使用して、複数の nmstate 対応ノードを同時に設定 できるようになりました。
- SR-IOV ネットワークインターフェースに接続されている仮想マシンに対して、ライブマイグレーションがデフォルトでサポートされるようになりました。
3.3.4. ストレージ
- ホットプラグされた仮想ディスクの仮想マシンで、オンラインスナップショットがサポートされます。ただし、仮想マシンの仕様に含まれていないホットプラグされたディスクは、スナップショットに含まれません。
- ホストパスプロビジョナー(HPP)で Kubernetes Container Storage Interface(CSI)ドライバー を使用し、仮想マシンのローカルストレージを設定できます。CSI ドライバーを使用すると、ローカルストレージの設定時に既存の OpenShift Container Platform ノードおよびクラスターの中断を最小限に抑えることができます。
3.3.5. Web コンソール
- OpenShift Virtualization ダッシュボードでは、仮想マシンおよび関連付けられた Pod のリソース消費に関するデータが得られます。OpenShift Virtualization ダッシュボードに表示される可視化メトリクスは、Prometheus Query Language(PromQL)クエリー に基づいています。
3.4. 非推奨および削除された機能
3.4.1. 非推奨の機能
非推奨の機能は現在のリリースに含まれており、サポートされています。ただし、これらは今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
- 今後のリリースでは、従来の HPP カスタムリソースと関連するストレージクラスのサポートは非推奨になります。OpenShift Virtualization 4.10 以降、HPP Operator は Kubernetes Container Storage Interface (CSI)ドライバーを使用してローカルストレージを設定します。Operator は、引き続き HPP カスタムリソースの既存の(レガシー)形式および関連付けられたストレージクラスをサポートします。HPP Operator を使用する場合、移行ストラテジーの一部として CSI ドライバーのストレージクラスを作成する ことを計画してください。
3.4.2. 削除された機能
削除された機能は、現在のリリースではサポートされません。
- このリリースでは、VM Import Operatorが OpenShift Virtualizationから削除されました。これは、 Migration Toolkit for Virtualizationに置き換えられました。
本リリースでは、2021 年 12 月 31 日に End of Life (EOL) に到達した CentOS Linux 8 のテンプレートが削除されました。ただし、OpenShift Container Platform には CentOS Stream 8 および CentOS Stream 9 のテンプレートが含まれるようになりました。
注記CentOS ディストリビューションはすべてコミュニティーでサポートされています。
3.5. テクノロジープレビューの機能
現在、今回のリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。これらの機能については、Red Hat カスタマーポータルのTechnology Preview Features Support Scope を参照してください。
- Red Hat Enterprise Linux 9 Beta テンプレートを使用し、仮想マシンを作成できます。
- OpenShift Virtualization を AWS ベアメタルノードにデプロイできるようになりました。
- OpenShift Virtualization の重大なアラート には、早急な対応が必要な問題に対する説明、各アラートが発生する理由、問題の原因を診断するためのトラブルシューティングプロセス、および各アラートを解決する手順が含まれるようになりました。
- クラスター管理者は、OpenShift Virtualization プラグインで OpenShift API for Data Protection を使用して、仮想マシンが含まれる namespace をバックアップできるようになりました。
-
管理者は、
HyperConverged
CR を編集することにより、宣言的に、仮想グラフィックス処理ユニット(vGPU)などの仲介デバイスを作成および公開できるようになりました。仮想マシンの所有者は、これらのデバイスを仮想マシンに割り当てることができます。
-
単一の
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用することにより、ブリッジに接続されている NIC の静的 IP 設定を転送できます。
- OpenShift Virtualization を IBM Cloud ベアメタルサーバーにインストールできるようになりました。他のクラウドプロバイダーが提供するベアメタルサーバーはサポートされません。
3.6. バグ修正
- クローンソースが利用可能になる前にクローン操作を開始すると、クローン操作は回避策を使用せずに正常に完了するようになりました。(BZ#1855182)
- バージョン 4.8 より前の Open Shift Virtualization によって提供された削除済みテンプレートを仮想マシンが参照している場合、仮想マシンの編集は失敗します。Open Shift Virtualization 4.8 以降では、削除された Open Shift Virtualization が提供するテンプレートは、Open Shift Virtualization Operator によって自動的に再作成されます。(BZ#1929165)
-
VNC コンソールで仮想マシンを使用する場合は、
Send Keys
およびDisconnect
ボタンを正常に使用できるようになりました。(BZ#1964789) - 仮想マシンを作成すると、一意の完全修飾ドメイン名(FQDN)にクラスターのドメイン名が含まれるようになりました。(BZ#1998300)
-
仮想ディスクをホットプラグしてから
virt-launcher
Pod を強制的に削除した場合に、データが失われることはなくなりました。(BZ#2007397) OpenShift Virtualization は、他の重要なコンポーネントとファイルシステムを共有するパスにホストパスプロビジョナー(HPP)をインストールしようとすると、HPPSharingPoolPathWithOS アラートを発行するようになりました。
HPP を使用して仮想マシンディスクのストレージを提供するには、ノードのルートファイルシステムとは別の専用のストレージで設定します。そうしない場合には、ノードはストレージが不足し、機能しなくなる可能性があります。(BZ#2038985)
- 仮想マシンディスクをプロビジョニングする場合、OpenShift Virtualization は、各仮想マシンディスク PVC に KubePersistentVolumeFillingUp アラートを発行するのではなく、要求されるディスクサイズに対応するのに十分な大きさの永続ボリューム要求(PVC)を割り当てるようになりました。仮想マシン内からディスク使用量をモニタリングできます。(BZ#2039489)
- ホットプラグされたディスクを持つ仮想マシンの仮想マシンスナップショットを作成できるようになりました。(BZ#2042908)
- クラスター全体のプロキシー設定を使用する場合に、仮想マシンイメージを正常にインポートできるようになりました。(BZ#2046271)
3.7. 既知の問題
単一ノードに 50 を超えるイメージが含まれる場合、Pod のスケジューリングはノード間で不安定になる可能性があります。これは、ノード上のイメージの一覧はデフォルトで 50 に短縮されるためです。(BZ#1984442)
-
回避策として、
KubeletConfig
オブジェクトを編集し、nodeStatusMaxImages
の値を -1 に設定すると、イメージ制限を無効にすることができます
。
-
回避策として、
42 文字を超える完全修飾ドメイン名( FQDN) を持つノードがあるクラスターに ホストパスプロビジョナー をデプロイする場合、プロビジョナーは PVC をバインドできません。(BZ#2057157)
エラーメッセージの例
E0222 17:52:54.088950 1 reflector.go:138] k8s.io/client-go/informers/factory.go:134: Failed to watch *v1beta1.CSIStorageCapacity: failed to list *v1beta1.CSIStorageCapacity: unable to parse requirement: values[0][csi.storage.k8s.io/managed-by]: Invalid value: "external-provisioner-<node_FQDN>": must be no more than 63 characters 1
- 1
- エラーメッセージの最大文字数は 63 文字ですが、これにはノードの FQDN の先頭に付く
external-provisioner-
の文字列が含まれます。
回避策として、以下のコマンドを実行して、ホストパスプロビジョナー CSI ドライバーの
storageCapacity
オプションを無効にします。$ oc patch csidriver kubevirt.io.hostpath-provisioner --type merge --patch '{"spec": {"storageCapacity": false}}'
OpenShift Container Platform クラスターが OVN-Kubernetes をデフォルトの Container Network Interface (CNI)プロバイダーとして使用する場合、OVN-Kubernetes のホストネットワークトポロジーの変更により、Linux ブリッジまたはボンディングデバイスをホストのデフォルトインターフェースに割り当てることはできません。(BZ#1885605)
- 回避策として、ホストに接続されたセカンダリーネットワークインターフェースを使用するか、OpenShift SDN デフォルト CNI プロバイダーに切り替えることができます。
ライブマイグレーションを実行できない仮想マシンを実行すると、OpenShift Container Platform クラスターのアップグレードがブロックされる可能性があります。これには、hostpath-provisioner ストレージまたは SR-IOV ネットワークインターフェースを使用する仮想マシンが含まれます。
回避策として、仮想マシンを再設定し、クラスターのアップグレード時にそれらの電源をオフにするようにできます。仮想マシン設定ファイルの
spec
セクションで、以下を実行します。evictionStrategy
およびrunStrategy
フィールドを変更します。-
evictionStrategy: LiveMigrate
フィールドを削除します。エビクションストラテジーの設定方法についての詳細は、「仮想マシン のエビクションストラテジーの設定」を参照してください。 -
runStrategy
フィールドをAlways
に設定します。
-
以下のコマンドを実行して、デフォルトの CPU モデルを設定します。
注記ライブマイグレーションをサポートする仮想マシンを起動する前に、この変更を行う必要があります。
$ oc annotate --overwrite -n openshift-cnv hyperconverged kubevirt-hyperconverged kubevirt.kubevirt.io/jsonpatch='[ { "op": "add", "path": "/spec/configuration/cpuModel", "value": "<cpu_model>" 1 } ]'
- 1
<cpu-model>
を実際の CPU モデルの値に置き換えます。すべてのノードにoc describe node <node>
を実行し、cpu-model-<name>
ラベルを確認してこの値を判別できます。すべてのノードに存在する CPU モデルを選択します。
Red Hat Ceph Storage または Red Hat OpenShift Data Foundation Storage を使用する場合は、一度に 100 台以上の仮想マシンのクローンを作成できない場合があります。(BZ#1989527)
回避策として、ストレージプロファイルマニフェストに
spec.cloneStrategy: copy
を設定して、ホスト支援コピーを実行できます。以下に例を示します。apiVersion: cdi.kubevirt.io/v1beta1 kind: StorageProfile metadata: name: <provisioner_class> # ... spec: claimPropertySets: - accessModes: - ReadWriteOnce volumeMode: Filesystem cloneStrategy: copy 1 status: provisioner: <provisioner> storageClass: <provisioner_class>
- 1
- デフォルトのクローン作成方法は、
copy
として設定されます。
場合によっては、複数の仮想マシンが読み取り/書き込みモードで同じ PVC をマウントできるため、データが破損する可能性があります。(BZ#1992753)
- 回避策として、複数の仮想マシンで読み取り/書き込みモードで単一の PVC を使用しないでください。
Pod Disruption Budget (PDB)は、移行可能な仮想マシンイメージについての Pod の中断を防ぎます。PDB が Pod の中断を検出する場合、
openshift-monitoring
はLiveMigrate
エビクションストラテジーを使用する仮想マシンイメージに対して 60 分ごとにPodDisruptionBudgetAtLimit
アラートを送信します。(BZ#2026733)- 回避策として、アラートをサイレンスにします。
大規模なクラスターでは、OpenShift Virtualization MAC プールマネージャーの起動に時間がかかりすぎる可能性があり、OpenShift Virtualization が準備状態にならない可能性があります。(BZ#2035344)
回避策として、MAC プーリング機能が必要ない場合には、以下のコマンドを実行してこのサブコンポーネントを無効にします。
$ oc annotate --overwrite -n openshift-cnv hco kubevirt-hyperconverged 'networkaddonsconfigs.kubevirt.io/jsonpatch=[ { "op": "replace" "path": "/spec/kubeMacPool" "value": null } ]'
OpenShift Virtualization は、Pod によって使用されるサービスアカウントトークンをその特定の Pod にリンクします。OpenShift Virtualization は、トークンが含まれるディスクイメージを作成してサービスアカウントボリュームを実装します。仮想マシンを移行すると、サービスアカウントボリュームが無効になります。(BZ#2037611)
- 回避策として、サービスアカウントではなくユーザーアカウントを使用してください。ユーザーアカウントトークンは特定の Pod にバインドされていないためです。
- シャットダウン中に仮想マシンがクラッシュしたりハングアップしたりした場合に、新しいシャットダウン要求は仮想マシンを停止しません。(BZ#2040766)
ドライバーをインストールする前に仲介デバイスを有効にするように
HyperConverged
カスタムリソース(CR)を設定する場合は、仲介デバイスの有効化は発生しません。この問題は更新によってトリガーされます。たとえば、NVIDIA ドライバーをインストールするdaemonset
の前にvirt-handler
を更新した場合、ノードは仮想マシン GPU を提供することができません。(BZ#2046298)回避策として、以下を実施します。
-
HyperConverged
CR からmediatedDevicesConfiguration
およびpermittedHostDevices
を削除します。 -
使用する設定で、
mediatedDevicesConfiguration
およびpermittedHostDevices
スタンザの両方を更新します。
-
- 仮想マシンウィザードの YAML サンプルはハードコーディングされており、常に最新のアップストリーム変更が含まれるわけではありません。(BZ#2055492)
csi-clone
クローンストラテジーを使用して 100 台以上の仮想マシンのクローンを作成する場合、Ceph CSI はクローンをパージしない可能性があります。クローンの手動削除も失敗する可能性があります。(BZ#2055595)-
回避策として、
ceph-mgr
を再起動して仮想マシンのクローンをパージすることができます。
-
回避策として、
非特権ユーザーは、
VM Network Interfaces
タブの Add Network Interface ボタンを使用できません。(BZ#2056420)- 回避策として、非特権ユーザーは、仮想マシンウィザードを使用して仮想マシンを作成する間に追加のネットワークインターフェースを追加できます。
非特権ユーザーは、RBAC ルールにより仮想マシンにディスクを追加できません。(BZ#2056421)
- 回避策として、特定のユーザーがディスクを追加できるように RBAC ルールを手動で追加します。
Web コンソールには、カスタムnamespaceにデプロイされた仮想マシンテンプレートが表示されません。Web コンソールには、デフォルトの namespace にデプロイされたテンプレートしか表示されません。(BZ#2054650)
- 回避策として、カスタムnamespaceにテンプレートをデプロイすることは避けてください。
Single Node OpenShift(SNO)クラスターでは、VMI の
spec.evictionStrategy
フィールドがLiveMigrate
に設定されていると、クラスターの更新に失敗します。ライブマイグレーションを正常に実行するには、クラスターに複数のワーカーノードが必要です。(BZ#2073880)回避策としては、以下の 2 つのオプションがあります。
-
spec.evictionStrategy
フィールドを VM 宣言から削除します。 - OpenShift Container Platform を更新する前に、仮想マシンを手動で停止します。
-
第4章 インストール
4.1. OpenShift Virtualization のクラスターの準備
OpenShift Virtualization をインストールする前に、このセクションを確認して、クラスターが要件を満たしていることを確認してください。
ユーザーによってプロビジョニングされる、インストーラーでプロビジョニングされる、または支援付きインストーラーなどのインストール方法を使用して、OpenShift Container Platform をデプロイすることができます。ただし、インストール方法およびクラスタートポロジーは、スナップショットやライブマイグレーションなどの OpenShift Virtualization 機能に影響する可能性があります。
単一ノードの OpenShift の相違点
OpenShift Virtualization は、Single Node OpenShift (SNO)として知られる単一ノードクラスターにインストールできます。SNO は高可用性をサポートしていないため、以下の違いが発生します。
- Pod の Disruption Budget(停止状態の予算) はサポートされません。
- ライブマイグレーション はサポートされていません。
-
データボリュームまたはストレージプロファイルを使用するテンプレートまたは仮想マシンには、
evictionStrategy
を設定することはできません。
FIPS モード
クラスターを FIPS モード にインストールする場合、OpenShift Virtualization に追加の設定は必要ありません。
4.1.1. ハードウェアおよびオペレーティングシステムの要件
OpenShift Virtualization の以下のハードウェアおよびオペレーティングシステムの要件を確認してください。
サポートされるプラットフォーム
- オンプレミスのベアメタルサーバー
- Amazon Web Services ベアメタルインスタンス
- IBM Cloud ベアメタルサーバー。「 IBM Cloud Bare Metal ノードへの OpenShift Virtualization のデプロイ 」を参照してください。
AWS ベアメタルインスタンスまたは IBM Cloud ベアメタルサーバーへの OpenShift Virtualization のインストールはテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
- 他のクラウドプロバイダーが提供するベアメタルインスタンスまたはサーバーはサポートされません。
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 ワーカーノードはサポートされません。
関連情報
- RHCOS について
- サポートされる CPU 向け Red Hat Ecosystem Catalog
- サポート対象のストレージ
4.1.2. 物理リソースのオーバーヘッド要件
OpenShift Virtualization は OpenShift Container Platform のアドオンであり、クラスターの計画時に考慮する必要のある追加のオーバーヘッドを強要します。各クラスターマシンは、OpenShift Container Platform の要件に加えて、以下のオーバーヘッドの要件を満たす必要があります。クラスター内の物理リソースを過剰にサブスクライブすると、パフォーマンスに影響する可能性があります。
本書に記載されている数は、Red Hat のテスト方法およびセットアップに基づいています。これらの数は、独自のセットアップおよび環境に応じて異なります。
4.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
お使いの環境に Single Root I/O Virtualization (SR-IOV) ネットワークデバイスまたは Graphics Processing Unit (GPU) が含まれる場合、それぞれのデバイスに 1 GiB の追加のメモリーオーバーヘッドを割り当てます。
4.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 の数に関する特別なルールはありません。
4.1.2.3. ストレージのオーバーヘッド
以下のガイドラインを使用して、OpenShift Virtualization 環境のストレージオーバーヘッド要件を見積もります。
クラスターストレージオーバーヘッド
Aggregated storage overhead per node ≈ 10 GiB
10 GiB は、OpenShift Virtualization のインストール時にクラスター内の各ノードについてのディスク上のストレージの予想される影響に相当します。
仮想マシンのストレージオーバーヘッド
仮想マシンごとのストレージオーバーヘッドは、仮想マシン内のリソース割り当ての特定の要求により異なります。この要求は、クラスター内の別の場所でホストされるノードまたはストレージリソースの一時ストレージに対するものである可能性があります。OpenShift Virtualization は現在、実行中のコンテナー自体に追加の一時ストレージを割り当てていません。
4.1.2.4. 例
クラスター管理者が、クラスター内の 10 台の (それぞれ 1 GiB の RAM と 2 つの vCPU の) 仮想マシンをホストする予定の場合、クラスター全体で影響を受けるメモリーは 11.68 GiB になります。クラスターの各ノードについて予想されるディスク上のストレージの影響は 10 GiB で示され、仮想マシンのワークロードをホストするワーカーノードについての CPU の影響は最小 2 コアで示されます。
4.1.3. オブジェクトの最大値
クラスターの計画時に以下のテスト済みのオブジェクトの最大値を考慮する必要があります。
4.1.4. ネットワークが制限された環境
インターネット接続のない制限された環境で OpenShift Virtualization をインストールする場合、Operator Lifecycle Manager をネットワークが制限された環境用に設定する必要があり ます。
インターネット接続が制限されている場合、Operator Lifecycle Manager でプロキシーサポートを設定 して、Red Hat が提供する OperatorHub にアクセスすることができます。
4.1.5. ライブマイグレーション
ライブマイグレーションには以下の要件があります。
-
ReadWriteMany
(RWX)アクセスモードの共有ストレージ - 十分な RAM およびネットワーク帯域幅
- ワーカーノードに十分な容量を持つ適切な CPU。CPU の容量が異なる場合、ライブマイグレーションが非常に遅くなるか、または失敗する可能性があります。
4.1.6. スナップショットおよびクローン作成
スナップショットおよびクローン作成の要件については、「 OpenShift Virtualization ストレージ機能 」を参照してください。
4.1.7. クラスターの高可用性オプション
以下の高可用性(HA)オプションのいずれかをクラスターに設定できます。
インストーラーでプロビジョニングされるインフラストラクチャー (IPI)の自動高可用性は、マシンのヘルスチェック をデプロイすることで利用できます。
注記インストーラーでプロビジョニングされるインフラストラクチャーを使用してインストールされ、MachineHealthCheck が適切に設定された OpenShift Container Platform クラスターでは、ノードが MachineHealthCheck に失敗し、クラスターで利用できなくなると、そのノードは再利用されます。障害が発生したノードで実行された仮想マシンでは、一連の条件によって次に起こる動作が変わります。予想される結果 や RunStrategies がそれらの結果に与える影響についての詳細は、「仮想マシン の RunStrategies」を参照してください。
IPI および非 IPI の両方の高可用性は、OpenShift Container Platform クラスターで Node Health Check Operator を使用して
NodeHealthCheck
コントローラーをデプロイすることで利用できます。コントローラーは正常でないノードを特定し、Self Node Remediation Operator を使用して正常でないノードを修正します。重要Node Health Check Operatorは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
すべてのプラットフォームの高可用性は、モニタリングシステムを使用するか、または資格のある人のいずれかを使用してノードの可用性を監視することで利用できます。ノードが失われた場合は、これをシャットダウンして
oc delete node <lost_node>
を実行します。注記外部モニタリングシステムまたは資格のある人材によるノードの正常性の監視が行われない場合、仮想マシンは高可用性を失います。
4.2. OpenShift Virtualization コンポーネントのノードの指定
ノードの配置ルールを設定して、OpenShift Virtualization Operator、ワークロード、およびコントローラーをデプロイするノードを指定します。
OpenShift Virtualization のインストール後に一部のコンポーネントのノードの配置を設定できますが、ワークロード用にノードの配置を設定する場合には仮想マシンを含めることはできません。
4.2.1. 仮想化コンポーネントのノード配置について
OpenShift Virtualization がそのコンポーネントをデプロイする場所をカスタマイズして、以下を確認する必要がある場合があります。
- 仮想マシンは、仮想化ワークロード用のノードにのみデプロイされる。
- Operator はインフラストラクチャーノードにのみデプロイされる。
- 特定のノードは OpenShift Virtualization の影響を受けない。たとえば、クラスターで実行される仮想化に関連しないワークロードがあり、それらのワークロードを OpenShift Virtualization から分離する必要があるとします。
4.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 のみを受け入れます。
4.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.10.2
channel: "stable"
config: 1
- 1
config
フィールドはnodeSelector
およびtolerations
をサポートしますが、affinity
はサポートしません。
4.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
フィールドは、nodeSelector
、affinity
、およびtolerations
フィールドをサポートします。
4.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
フィールドは、nodeSelector
、affinity
、およびtolerations
フィールドをサポートします。
4.2.1.5. 関連情報
4.2.2. マニフェストの例
以下の YAML ファイルの例では、nodePlacement
、affinity
、および tolerations
オブジェクトを使用して OpenShift Virtualization コンポーネントのノード配置をカスタマイズします。
4.2.2.1. Operator Lifecycle Manager サブスクリプションオブジェクト
4.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.10.2 channel: "stable" config: nodeSelector: example.io/example-infra-key: example-infra-value
4.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.10.2 channel: "stable" config: tolerations: - key: "key" operator: "Equal" value: "virtualization" effect: "NoSchedule"
4.2.2.2. HyperConverged オブジェクト
4.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
4.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
4.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"
4.2.2.3. HostPathProvisioner オブジェクト
4.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
4.3. Web コンソールを使用した OpenShift Virtualization のインストール
OpenShift Virtualization をインストールし、仮想化機能を OpenShift Container Platform クラスターに追加します。
OpenShift Container Platform 4.10 web console を使用して、OpenShift Virtualization Operator にサブスクライブし、これをデプロイすることができます。
4.3.1. OpenShift Virtualization Operator のインストール
OpenShift Container Platform Web コンソールから OpenShift Virtualization Operator をインストールできます。
前提条件
- OpenShift Container Platform 4.10 をクラスターにインストールしていること。
-
cluster-admin
パーミッションを持つユーザーとして OpenShift Container Platform Web コンソールにログインすること。
手順
- Administrator パースペクティブから、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドに OpenShift Virtualization を入力します。
- OpenShift Virtualization タイルを選択します。
- Operator についての情報を確認してから、Install をクリックします。
Install Operator ページで以下を行います。
- 選択可能な Update Channel オプションの一覧から stable を選択します。これにより、OpenShift Container Platform バージョンと互換性がある OpenShift Virtualization のバージョンをインストールすることができます。
インストールされた namespace の場合、Operator recommended namespace オプションが選択されていることを確認します。これにより、Operator が必須の
openshift-cnv
namespace にインストールされます。この namespace は存在しない場合は、自動的に作成されます。警告OpenShift Virtualization Operator を
openshift-cnv
以外の namespace にインストールしようとすると、インストールが失敗します。Approval Strategy の場合に、stable 更新チャネルで新しいバージョンが利用可能になったときに OpenShift Virtualization が自動更新されるように、デフォルト値である Automaticを選択することを強くお勧めします。
Manual 承認ストラテジーを選択することは可能ですが、クラスターのサポート容易性および機能に対応するリスクが高いため、お勧めできません。これらのリスクを完全に理解していて、Automatic を使用できない場合のみ、Manual を選択してください。
警告OpenShift Virtualization は対応する OpenShift Container Platform バージョンで使用される場合にのみサポートされるため、OpenShift Virtualization が更新されないと、クラスターがサポートされなくなる可能性があります。
-
Install をクリックし、Operator を
openshift-cnv
namespace で利用可能にします。 - Operator が正常にインストールされたら、Create HyperConverged をクリックします。
- オプション: OpenShift Virtualization コンポーネントの Infra および Workloads ノード配置オプションを設定します。
- Create をクリックして OpenShift Virtualization を起動します。
検証
- Workloads → Pods ページに移動して、OpenShift Virtualization Pod がすべて Running 状態になるまでこれらの Pod をモニターします。すべての Pod で Running 状態が表示された後に、OpenShift Virtualization を使用できます。
4.3.2. 次のステップ
以下のコンポーネントを追加で設定する必要がある場合があります。
- ホストパスプロビジョナー は、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。
4.4. CLI を使用した OpenShift Virtualization のインストール
OpenShift Virtualization をインストールし、仮想化機能を OpenShift Container Platform クラスターに追加します。コマンドラインを使用してマニフェストをクラスターに適用し、OpenShift Virtualization Operator にサブスクライブし、デプロイできます。
OpenShift Virtualization がそのコンポーネントをインストールするノードを指定するには、ノードの配置ルールを設定 します。
4.4.1. 前提条件
- OpenShift Container Platform 4.10 をクラスターにインストールしていること。
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
4.4.2. CLI を使用した OpenShift Virtualization カタログのサブスクライブ
OpenShift Virtualization をインストールする前に、OpenShift Virtualization カタログにサブスクライブする必要があります。サブスクライブにより、openshift-cnv
namespace に OpenShift Virtualization Operator へのアクセスが付与されます。
単一マニフェストをクラスターに適用して Namespace
、OperatorGroup
、および Subscription
オブジェクトをサブスクライブし、設定します。
手順
以下のマニフェストを含む 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.10.2 channel: "stable" 1
- 1
stable
チャネルを使用することで、OpenShift Container Platform バージョンと互換性のある OpenShift Virtualization のバージョンをインストールすることができます。
以下のコマンドを実行して、OpenShift Virtualization に必要な
Namespace
、OperatorGroup
、およびSubscription
オブジェクトを作成します。$ oc apply -f <file name>.yaml
YAML ファイルで 証明書のローテーションパラメーターを設定 できます。
4.4.3. CLI を使用した OpenShift Virtualization Operator のデプロイ
oc
CLI を使用して OpenShift Virtualization Operator をデプロイすることができます。
前提条件
-
openshift-cnv
namespace の OpenShift Virtualization カタログへのアクティブなサブスクリプション。
手順
以下のマニフェストを含む YAML ファイルを作成します。
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec:
以下のコマンドを実行して 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.10.2 OpenShift Virtualization 4.10.2 Succeeded
4.4.4. 次のステップ
以下のコンポーネントを追加で設定する必要がある場合があります。
- ホストパスプロビジョナー は、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。
4.5. virtctl クライアントの有効化
virtctl
クライアントは、OpenShift Virtualization リソースを管理するためのコマンドラインユーティリティーです。これは、Linux、macOS、および Windows ディストリビューションで利用できます。
4.5.1. virtctl クライアントのダウンロードおよびインストール
4.5.1.1. virtctl クライアントのダウンロード
ConsoleCLIDownload
カスタムリソース(CR)で提供されるリンクを使用して virtctl
クライアントをダウンロードします。
手順
以下のコマンドを実行して
ConsoleCLIDownload
オブジェクトを表示します。$ oc get ConsoleCLIDownload virtctl-clidownloads-kubevirt-hyperconverged -o yaml
-
お使いのディストリビューションに一覧表示されているリンクを使用して
virtctl
クライアントをダウンロードします。
4.5.1.2. virtctl クライアントのインストール
オペレーティングシステムに適した場所からダウンロードした後に、virtctl
クライアントを展開し、インストールします。
前提条件
-
virtctl
クライアントをダウンロードしている。
手順
Linux の場合
tarball を展開します。以下の CLI コマンドは、tarball と同じディレクトリーに展開します。
$ tar -xvf <virtctl-version-distribution.arch>.tar.gz
展開したフォルダー階層に移動し、以下のコマンドを実行して
virtctl
バイナリーを実行可能にします。$ chmod +x <virtctl-file-name>
-
virtctl
バイナリーをPATH 環境変数
にあるディレクトリーに移動します。 パスを確認するには、以下のコマンドを実行します。
$ echo $PATH
Windows ユーザーの場合:
- アーカイブを展開し、解凍します。
-
展開したフォルダー階層に移動し、
virtctl
実行可能ファイルをダブルクリックしてクライアントをインストールします。 -
virtctl
バイナリーをPATH 環境変数
にあるディレクトリーに移動します。 パスを確認するには、以下のコマンドを実行します。
C:\> path
macOS ユーザーの場合:
- アーカイブを展開し、解凍します。
-
virtctl
バイナリーをPATH 環境変数
にあるディレクトリーに移動します。 パスを確認するには、以下のコマンドを実行します。
echo $PATH
4.5.2. その他の設定オプション
4.5.2.1. yum ユーティリティーを使用した virtctl クライアントのインストール
kubevirt-virtctl
パッケージから virtctl
クライアントをインストールします。
手順
kubevirt-virtctl
パッケージをインストールします。# yum install kubevirt-virtctl
4.5.2.2. OpenShift Virtualization リポジトリーの有効化
Red Hat は、Red Hat Enterprise Linux 8 および Red Hat Enterprise Linux 7 向けの OpenShift Virtualization リポジトリーを提供します。
-
Red Hat Enterprise Linux 8 リポジトリー:
cnv-4.10-for-rhel-8-x86_64-rpms
-
Red Hat Enterprise Linux 7 リポジトリー:
rhel-7-server-cnv-4.10-rpms
subscription-manager
でリポジトリーを有効にするプロセスはどちらのプラットフォームでも同様です。
手順
以下のコマンドを実行して、お使いのシステムに適した OpenShift Virtualization リポジトリーを有効にします。
# subscription-manager repos --enable <repository>
4.5.3. 関連情報
- OpenShift Virtualization の CLI ツールの使用
4.6. Web コンソールを使用した OpenShift Virtualization のアンインストール
OpenShift Container Platform Web コンソール を使用して OpenShift Virtualization をアンインストールできます。
4.6.1. 前提条件
- OpenShift Virtualization 4.10 がインストールされていること。
すべての仮想マシン、 仮想マシン インスタンス、および データボリューム を削除する必要があります。
重要これらのオブジェクトを削除せずに OpenShift Virtualization のアンインストールを試みると失敗します。
4.6.2. OpenShift Virtualization Operator Deployment カスタムリソースの削除
OpenShift Virtualization をアンインストールするには、まず OpenShift Virtualization Operator Deployment カスタムリソースを削除する必要がある。
前提条件
- OpenShift Virtualization Operator Deployment カスタムリソースを作成すること。
手順
-
OpenShift Container Platform Web コンソールから、Projects 一覧より
openshift-cnv
を選択します。 - Operators → Installed Operators ページに移動します。
- OpenShift Virtualization をクリックします。
- OpenShift Virtualization Operator Deployment タブをクリックします。
-
Options メニュー
を kubevirt-hyperconverged カスタムリソースを含む行でクリックします。拡張されたメニューで、Delete HyperConverged Cluster をクリックします。
- 確認ウィンドウで Delete をクリックします。
- Workloads → Pods ページに移動し、Operator Pod のみが実行中であることを確認します。
ターミナルウィンドウを開き、以下のコマンドを実行して残りのリソースをクリーンアップします。
$ oc delete apiservices v1alpha3.subresources.kubevirt.io -n openshift-cnv
4.6.3. OpenShift Virtualization カタログサブスクリプションの削除
OpenShift Virtualization のアンインストールを終了するには、OpenShift Virtualization カタログサブスクリプションを削除します。
前提条件
- OpenShift Virtualization カタログの有効なサブスクリプション。
手順
- Operators → OperatorHub ページに移動します。
- OpenShift Virtualization を検索し、これを選択します。
- Uninstall をクリックします。
openshift-cnv
namespace を削除できるようになりました。
4.6.4. Web コンソールを使用した namespace の削除
OpenShift Container Platform Web コンソールを使用して namespace を削除できます。
namespace を削除するパーミッションがない場合、Delete Namespace オプションは選択できなくなります。
手順
- Administration → Namespaces に移動します。
- namespace の一覧で削除する必要のある namespace を見つけます。
-
namespace の一覧の右端で、Options メニュー
から Delete Namespace を選択します。
- Delete Namespace ペインが表示されたら、フィールドから削除する namespace の名前を入力します。
- Delete をクリックします。
4.7. CLI を使用した OpenShift Virtualization のアンインストール
OpenShift Container Platform CLI を使用して OpenShift Virtualization をアンインストールできます。
4.7.1. 前提条件
- OpenShift Virtualization 4.10 がインストールされていること。
すべての仮想マシン、 仮想マシン インスタンス、および データボリューム を削除する必要があります。
重要これらのオブジェクトを削除せずに OpenShift Virtualization のアンインストールを試みると失敗します。
4.7.2. OpenShift Virtualization の削除
CLI を使用して OpenShift Virtualization を削除できます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
cluster-admin
パーミッションを持つアカウントを使用して OpenShift Virtualization クラスターにアクセスできること。
CLI を使用して OLM で OpenShift Virtualization Operator のサブスクリプションを削除すると、ClusterServiceVersion
(CSV) オブジェクトはクラスターから削除されません。OpenShift Virtualization を完全にアンインストールするには、CSV を明示的に削除する必要があります。
手順
HyperConverged
カスタムリソースを削除します。$ oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnv
Operator Lifecycle Manager (OLM) で OpenShift Virtualization Operator のサブスクリプションを削除します。
$ oc delete subscription kubevirt-hyperconverged -n openshift-cnv
OpenShift Virtualization の Cluster Service Version (CSV) 名を環境変数として設定します。
$ CSV_NAME=$(oc get csv -n openshift-cnv -o=custom-columns=:metadata.name)
直前の手順で CSV 名を指定して、OpenShift Virtualization クラスターから CSV を削除します。
$ oc delete csv ${CSV_NAME} -n openshift-cnv
OpenShift Virtualization は、CSV が正常に削除されたことを示す確認メッセージが表示される際にアンインストールされます。
出力例
clusterserviceversion.operators.coreos.com "kubevirt-hyperconverged-operator.v4.10.2" deleted
第5章 OpenShift Virtualizationの更新
Operator Lifecycle Manager(OLM)が OpenShift Virtualization の z-stream およびマイナーバージョンの更新を提供する方法を確認します。
5.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.10 は OpenShift Container Platform 4.10 で実行する必要があります。
- クラスターのサポート容易性および機能が損なわれるリスクがあるので、Manual 承認ストラテジーを選択することは可能ですが、推奨していません。Manual 承認ストラテジーでは、保留中のすべての更新を手動で承認する必要があります。OpenShift Container Platform および OpenShift Virtualization の更新の同期が取れていない場合には、クラスターはサポートされなくなります。
- 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。
- Open Shift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
- データボリュームおよびその関連付けられた永続ボリューム要求 (PVC) は更新時に保持されます。
ホストパスプロビジョナーストレージを使用する仮想マシンを実行している場合、それらをライブマイグレーションすることはできず、Open Shift Container Platform クラスターの更新をブロックする可能性があります。
回避策として、仮想マシンを再設定し、クラスターの更新時にそれらの電源を自動的にオフになるようにできます。evictionStrategy: LiveMigrate
フィールドを削除し、runStrategy
フィールドを Always
に設定します。
5.2. ワークロードの自動更新の設定
5.2.1. ワークロードの更新について
OpenShift Virtualization を更新すると、ライブマイグレーションをサポートしている場合には libvirt
、virt-launcher
、および qemu
などの仮想マシンのワークロードが自動的に更新されます。
各仮想マシンには、仮想マシンインスタンス(VMI)を実行する virt-launcher
Pod があります。virt-launcher
Pod は、仮想マシン(VM)のプロセスを管理するために使用される libvirt
のインスタンスを実行します。
HyperConverged
カスタムリソース (CR)の spec.workloadUpdateStrategy
スタンザを編集して、ワークロードの更新方法を設定できます。ワークロードの更新方法として、LiveMigrate
と Evict
の 2 つが利用可能です。
Evict
メソッドは VMI ポッドをシャットダウンするため、デフォルトではLiveMigrate
更新ストラテジーのみが有効になっています。
LiveMigrate
が有効な唯一の更新ストラテジーである場合:
- ライブマイグレーションをサポートするVMIは更新プロセス時に移行されます。VM ゲストは、更新されたコンポーネントが有効になっている新しいPodに移動します。
ライブマイグレーションをサポートしない VMI は中断または更新されません。
-
VMI に
LiveMigrate
エビクションストラテジーがあるが、ライブマイグレーションをサポートしていない場合、VMI は更新されません。
-
VMI に
LiveMigrate
とEvict
の両方を有効にした場合:
-
ライブマイグレーションをサポートする VMI は、
LiveMigrate
更新ストラテジーを使用します。 -
ライブマイグレーションをサポートしない VMI は、
Evict
更新ストラテジーを使用します。VMI が、runStrategy
の値がalways
であるVirtualMachine
オブジェクトによって制御されている場合、新しい VMI は、コンポーネントが更新された新しいPodに作成されます。
移行の試行とタイムアウト
ワークロードを更新するときに、ポッドが次の期間Pending
状態の場合、ライブマイグレーションは失敗します。
- 5 分間
-
ポッドが
Unschedulable
であるために保留中の場合。 - 15 分
- 何らかの理由でポッドが保留状態のままになっている場合。
VMI が移行に失敗すると、 virt-controller
は VMI の移行を再試行します。すべての移行可能な VMI が新しいvirt-launcher
Podで実行されるまで、このプロセスが繰り返されます。ただし、VMI が不適切に設定されている場合、これらの試行は無限に繰り返される可能性があります。
各試行は、移行オブジェクトに対応します。直近の 5 回の試行のみがバッファーに保持されます。これにより、デバッグ用の情報を保持しながら、移行オブジェクトがシステムに蓄積されるのを防ぎます。
5.2.2. ワークロードの更新方法の設定
HyperConverged
カスタムリソース(CR)を編集することにより、ワークロードの更新方法を設定できます。
前提条件
ライブマイグレーションを更新方法として使用するには、まずクラスターでライブマイグレーションを有効にする必要があります。
注記VirtualMachineInstance
CR にevictionStrategy: LiveMigrate
が含まれており、仮想マシンインスタンス(VMI) がライブマイグレーションをサポートしない場合には、VMI は更新されません。
手順
デフォルトエディターで
HyperConverged
CR を作成するには、以下のコマンドを実行します。$ oc edit hco -n openshift-cnv kubevirt-hyperconverged
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
スタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。- 変更を適用するには、エディターを保存し、終了します。
5.3. 保留中の Operator 更新の承認
5.3.1. 保留中の Operator アップグレードの手動による承認
インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。
前提条件
- Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- 更新が保留中の Operator は Upgrade available のステータスを表示します。アップグレードする Operator の名前をクリックします。
- Subscription タブをクリックします。アップグレードの承認を必要とするアップグレードは、Upgrade Status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
- 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
- アップグレードに利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
- Operators → Installed Operators ページに戻り、アップグレードの進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。
5.4. 更新ステータスの監視
5.4.1. OpenShift Virtualization アップグレードステータスのモニタリング
OpenShift Virtualization Operator のアップグレードのステータスをモニターするには、クラスターサービスバージョン(CSV) PHASE
を監視します。Web コンソールを使用するか、ここに提供されているコマンドを実行して CSV の状態をモニターすることもできます。
PHASE
および状態の値は利用可能な情報に基づく近似値になります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにログインすること。 -
OpenShift CLI (
oc
) をインストールします。
手順
以下のコマンドを実行します。
$ oc get csv -n openshift-cnv
出力を確認し、
PHASE
フィールドをチェックします。以下は例になります。出力例
VERSION REPLACES PHASE 4.9.0 kubevirt-hyperconverged-operator.v4.8.2 Installing 4.9.0 kubevirt-hyperconverged-operator.v4.9.0 Replacing
オプション: 以下のコマンドを実行して、すべての 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
5.4.2. 以前の OpenShift Virtualization ワークロードの表示
CLI を使用して、以前のワークロードの一覧を表示できます。
クラスターに以前の仮想化 Pod がある場合には、OutdatedVirtualMachineInstanceWorkloads
アラートが実行されます。
手順
以前の仮想マシンインスタンス(VMI)の一覧を表示するには、以下のコマンドを実行します。
$ kubectl get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
ワークロードの更新を設定 し、VMI が自動的に更新されるようにします。
5.5. 関連情報
第6章 kubevirt-controller および virt-launcher に付与される追加のセキュリティー権限
kubevirt-controller
および virt-launcher Pod には、通常の Pod 所有者の権限に加えて一部の SELinux ポリシーおよび SCC (Security Context Constraints) 権限が付与されます。これらの権限により、仮想マシンは OpenShift Virtualization 機能を使用できます。
6.1. virt-launcher Pod の拡張 SELinux ポリシー
virt-launcher Pod の container_t
SELinux ポリシーは以下のルールで拡張されます。
-
allow process self (tun_socket (relabelfrom relabelto attach_queue))
-
allow process sysfs_t (file (write))
-
allow process hugetlbfs_t (dir (add_name create write remove_name rmdir setattr))
-
allow process hugetlbfs_t (file (create unlink))
これらのルールは、以下の仮想化機能を有効にします。
- キューを独自の TUN ソケットに再度ラベル付けし、これに割り当てます。これは、ネットワークのマルチキューをサポートするために必要です。マルチキューは、利用可能な vCPU の数が増える際にネットワークのパフォーマンスをスケーリングできます。
-
virt-launcher Pod が情報を sysfs (
/sys
) ファイルに書き込むことを許可します。これは SR-IOV (Single Root I/O Virtualization) を有効にするために必要です。 -
hugetlbfs
エントリーの読み取り/書き込みを実行します。これは、Huge Page をサポートするために必要です。Huge Page は、メモリーページサイズを増やすことで大量のメモリーを管理する方法です。
6.2. kubevirt-controller サービスアカウントの追加の OpenShift Container Platform SCC (Security Context Constraints) および Linux 機能
SCC (Security Context Constraints) は Pod のパーミッションを制御します。これらのパーミッションには、コンテナーのコレクションである Pod が実行できるアクションおよびそれがアクセスできるリソース情報が含まれます。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行についての条件の一覧を定義することができます。
kubevirt-controller
は、クラスター内の仮想マシンの virt-launcher Pod を作成するクラスターコントローラーです。これらの virt-launcher Pod には、kubevirt-controller
サービスアカウントによってパーミッションが付与されます。
6.2.1. kubevirt-controller サービスアカウントに付与される追加の SCC
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{"NET_ADMIN", "NET_RAW", "SYS_NICE"}
This provides the following additional Linux capabilitiesNET_ADMIN
,NET_RAW
, andSYS_NICE
.
6.2.2. kubevirt-controller の SCC および RBAC 定義の表示
oc
ツールを使用して kubevirt-controller
の SecurityContextConstraints
定義を表示できます。
$ oc get scc kubevirt-controller -o yaml
oc
ツールを使用して kubevirt-controller
クラスターロールの RBAC 定義を表示できます。
$ oc get clusterrole kubevirt-controller -o yaml
6.3. 関連情報
- 『Red Hat Enterprise Linux 仮想化のチューニングと最適化ガイド』には、ネットワークマルチキュー と Huge Page についての詳細情報が記載されています。
-
capabilities
man ページには、Linux 機能についての詳細情報が記載されています。 -
sysfs(5)
man ページには、sysfs についての詳細情報が記載されています。 - 『OpenShift Container Platform 認証』ガイドには、SCC( Security Context Constraints )についての詳細が記載されています。
第7章 CLI ツールの使用
クラスターでリソースを管理するために使用される 2 つの主な CLI ツールは以下の通りです。
-
OpenShift virtualization
virtctl
クライアント -
OpenShift Container Platform
oc
クライアント
7.1. 前提条件
-
virtctl
クライアントを有効にする 必要があります。
7.2. OpenShift Container Platform クライアントコマンド
OpenShift Container Platform oc
クライアントは、VirtualMachine
(vm
) および VirtualMachineInstance
(vmi
) オブジェクトタイプを含む、OpenShift Container Platform リソースを管理するためのコマンドラインユーティリティーです。
-n <namespace>
フラグを使用して、別のプロジェクトを指定できます。
表7.1 oc
コマンド
コマンド | 説明 |
---|---|
|
OpenShift Container Platform クラスターに |
| 現在のプロジェクトの指定されたオブジェクトタイプのオブジェクトの一覧を表示します。 |
| 現在のプロジェクトで特定のリソースの詳細を表示します。 |
| 現在のプロジェクトで、ファイル名または標準入力 (stdin) からリソースを作成します。 |
| 現在のプロジェクトのリソースを編集します。 |
| 現在のプロジェクトのリソースを削除します。 |
oc
client コマンドについてのより総合的な情報については、OpenShift Container Platform CLI ツール のドキュメントを参照してください。
7.3. Virtctl クライアントコマンド
virtctl
クライアントは、OpenShift Virtualization リソースを管理するためのコマンドラインユーティリティーです。
virtctl
コマンドのリストを表示するには、次のコマンドを実行します。
$ virtctl help
特定のコマンドで使用できるオプションの一覧を表示するには、これを -h
または --help
フラグを指定して実行します。以下に例を示します。
$ virtctl image-upload -h
任意のvirtctl
コマンドで使用できるグローバルコマンドオプションのリストを表示するには、次のコマンドを実行します。
$ virtctl options
以下の表には、OpenShift Virtualization のドキュメント全体で使用されている virtctl
コマンドが記載されています。
表7.2 virtctl
クライアントコマンド
コマンド | 説明 |
---|---|
|
仮想マシンを起動します。オプションで、 |
| 仮想マシンを停止します。 |
| 仮想マシンまたは仮想マシンインスタンスを一時停止します。マシンの状態がメモリーに保持されます。 |
| 仮想マシンまたは仮想マシンインスタンスの一時停止を解除します。 |
| 仮想マシンを移行します。 |
| 仮想マシンを再起動します。 |
| 仮想マシンまたは仮想マシンインスタンスの指定されたポートを転送するサービスを作成し、このサービスをノードの指定されたポートで公開します。 |
| 仮想マシンインスタンスのシリアルコンソールに接続します。 |
| VNC (仮想ネットワーククライアント) の仮想マシンインスタンスへの接続を開きます。ローカルマシンでリモートビューアーを必要とする VNC を使用して仮想マシンインスタンスのグラフィカルコンソールにアクセスします。 |
| VNC 接続からビューアーを使用してポート番号を表示し、仮想マシンインスタンスに手動で接続します。 |
| ポートが利用可能な場合、その指定されたポートでプロキシーを実行するためにポート番号を指定します。ポート番号が指定されていない場合、プロキシーはランダムポートで実行されます。 |
| 仮想マシンイメージをすでに存在するデータボリュームにアップロードします。 |
| 仮想マシンイメージを新規データボリューム にアップロードします。 |
| クライアントおよびサーバーのバージョン情報を表示します。 |
|
|
| ゲストマシンで利用可能なファイルシステムの詳細な一覧を返します。 |
| オペレーティングシステムに関するゲストエージェント情報を返します。 |
| ゲストマシンでログインしているユーザーの詳細な一覧を返します。 |
7.4. virtctl guestfs を使用したコンテナーの作成
virtctl guestfs
コマンドを使用して、libguestfs-tools
および永続ボリューム要求(PVC)がアタッチされた対話型コンテナーをデプロイできます。
手順
libguestfs-tools
でコンテナーをデプロイして PVC をマウントし、シェルを割り当てるには、以下のコマンドを実行します。$ virtctl guestfs -n <namespace> <pvc_name> 1
- 1
- PVC 名は必須の引数です。この引数を追加しないと、エラーメッセージが表示されます。
7.5. Libguestfs ツールおよび virtctl guestfs
Libguestfs
ツールは、仮想マシン(VM)のディスクイメージにアクセスして変更するのに役立ちます。libguestfs
ツールを使用して、ゲスト内のファイルの表示および編集、仮想マシンのクローンおよびビルド、およびディスクのフォーマットおよびサイズ変更を実行できます。
virtctl guestfs
コマンドおよびそのサブコマンドを使用して、PVC で仮想マシンディスクを変更して検査し、デバッグすることもできます。使用可能なサブコマンドの完全な一覧を表示するには、コマンドラインで virt-
と入力して Tab を押します。以下に例を示します。
コマンド | 説明 |
---|---|
| ターミナルでファイルを対話的に編集します。 |
| ゲストに ssh キーを挿入し、ログインを作成します。 |
| 仮想マシンによって使用されるディスク容量を確認します。 |
| 詳細の一覧を含む出力ファイルを作成して、ゲストにインストールされたすべての RPM の詳細一覧を参照してください。 |
|
ターミナルで |
| テンプレートとして使用する仮想マシンディスクイメージをシールします。 |
デフォルトでは、virtctl guestfs
は、仮想ディスク管理に必要な項目を含めてセッションを作成します。ただし、動作をカスタマイズできるように、コマンドは複数のフラグオプションもサポートしています。
フラグオプション | 説明 |
---|---|
|
|
| 特定の namespace から PVC を使用します。
|
|
|
|
デフォルトでは、
クラスターに
設定されていない場合、 |
|
|
このコマンドは、PVC が別の Pod によって使用されているかどうかを確認します。使用されている場合には、エラーメッセージが表示されます。ただし、libguestfs-tools
プロセスが開始されると、設定では同じ PVC を使用する新規 Pod を回避できません。同じ PVC にアクセスする仮想マシンを起動する前に、アクティブな virtctl guestfs
Pod がないことを確認する必要があります。
virtctl guestfs
コマンドは、インタラクティブな Pod に割り当てられている PVC 1 つだけを受け入れます。
7.6. 関連情報
第8章 仮想マシン
8.1. 仮想マシンの作成
以下のいずれかの手順を使用して、仮想マシンを作成します。
- クイックスタートのガイド付きツアー
- ウィザードの実行
- 仮想マシンウィザードによる事前に設定された YAML ファイルの貼り付け
- CLI の使用
openshift-*
namespace に仮想マシンを作成しないでください。代わりに、openshift
プレフィックスなしの新規 namespace を作成するか、または既存 namespace を使用します。
Web コンソールから仮想マシンを作成する場合、ブートソースで設定される仮想マシンテンプレートを選択します。ブートソースを含む仮想マシンテンプレートには Available boot source というラベルが付けられるか、またはそれらはカスタマイズされたラベルテキストを表示します。選択可能なブートソースでテンプレートを使用すると、仮想マシンの作成プロセスをスピードアップできます。
ブートソースのないテンプレートには、Boot source required というラベルが付けられます。ブートソースを仮想マシンに追加する手順を実行する場合、これらのテンプレートを 使用できます。
ストレージの動作の違いにより、一部の仮想マシンテンプレートは SNO と互換性がありません。互換性を確保するためには、テンプレートまたはデータボリュームまたはストレージプロファイルを使用する仮想マシンにevictionStrategy
フィールドを設定しないでください。
8.1.1. クイックスタートの使用による仮想マシンの作成
Web コンソールは、仮想マシンを作成するためのガイド付きツアーを含むクイックスタートを提供します。Administrator パースペクティブの Help メニューを選択して Quick Starts カタログにアクセスし、Quick Starts カタログを表示できます。Quick Starts タイルをクリックし、ツアーを開始すると、システムによるプロセスのガイドが開始します。
Quick Starts のタスクは、Red Hat テンプレートの選択から開始します。次に、ブートソースを追加して、オペレーティングシステムイメージをインポートできます。最後に、カスタムテンプレートを保存し、これを使用して仮想マシンを作成できます。
仮想マシンを作成するためのクイックスタートツアーには、以下が含まれます。
- Red Hat Enterprise Linux 仮想マシンの作成
- Windows 10 仮想マシンの作成
- VMware 仮想マシンのインポート
前提条件
- オペレーティングシステムイメージの URL リンクをダウンロードできる Web サイトにアクセスすること。
手順
- Web コンソールで、Help メニューから Quick Starts を選択します。
- Quick Starts カタログのタイルをクリックします。例: Red Hat Linux Enterprise Linux 仮想マシンの作成
- ガイド付きツアーの手順に従い、オペレーティングシステムイメージのインポートと仮想マシンの作成タスクを実行します。Virtual Machines タブで、仮想マシンが表示されます。
8.1.2. 仮想マシンウィザードの実行による仮想マシンの作成
Web コンソールは、仮想マシンテンプレートの選択と仮想マシンの作成プロセスをガイドするウィザードを特長としています。Red Hat 仮想マシンテンプレートは、オペレーティングシステムイメージ、オペレーティングシステム、フレーバー(CPU およびメモリー)、およびワークロードタイプ (サーバー) のデフォルト設定で事前に設定されます。テンプレートがブートソースで設定される場合、それらのテンプレートにはカスタマイズされたラベルテキストテキストまたはデフォルトのラベルテキスト (Available boot source) のラベルが付けられます。その後、これらのテンプレートは仮想マシンの作成に使用する準備が整います。
事前に設定されたテンプレートの一覧からテンプレートを選択し、設定を確認し、 Create virtual machine from template ウィザードで仮想マシンを作成できます。仮想マシンのカスタマイズを選択した場合には、ウィザードが General、Networking、Storage、Advanced、および Review の手順をガイドします。ウィザードに表示されるすべての必須フィールドには * のマークが付けられます。
ネットワークインターフェースコントローラー (NIC) およびストレージディスクを作成し、それらを仮想マシンに割り当てます。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブまたは Templates タブで、Create をクリックし、Virtual Machine with Wizard を選択します。
- ブートソースで設定したテンプレートを選択します。
- Next をクリックして Review and create ステップに移動します。
- 仮想マシンをすぐに起動する必要がない場合は、Start this virtual machine after creation チェックボックスをクリアします。
- Create virtual machine をクリックし、ウィザードを終了するか、またはウィザードを継続して使用し、仮想マシンをカスタマイズします。
Customize virtual machine をクリックして General ステップに移動します。
- オプション: Name フィールドを編集して、仮想マシンのカスタム名を指定します。
- オプション: Description フィールドに説明を追加します。
Next をクリックして Networking ステップに進みます。デフォルトで
nic0
NIC が割り当てられます。- オプション: Add Network Interface をクリックし、追加の NIC を作成します。
-
オプション: すべての NIC の削除は、Options メニュー
をクリックし、Delete を選択して実行できます。仮想マシンの作成において、NIC が割り当てられている必要はありません。NIC は仮想マシンの作成後に作成することができます。
Next をクリックして Storage ステップに進みます。
-
オプション: Add Disk をクリックして追加のディスクを作成します。これらのディスクの削除は、Options メニュー
をクリックし、Delete を選択して実行できます。
-
オプション: Options メニュー
をクリックし、ディスクを編集して変更内容を保存します。
-
オプション: Add Disk をクリックして追加のディスクを作成します。これらのディスクの削除は、Options メニュー
Next をクリックして Advanced ステップに移動し、以下のいずれかのオプションを選択します。
Linux テンプレートを選択して仮想マシンを作成した場合は、Cloud-init の詳細を確認し、SSH アクセスを設定します。
注記cloud-init またはウィザードでカスタムスクリプトを使用して、SSH キーを静的に挿入します。これにより、仮想マシンを安全に、かつリモートで管理し、情報を管理し、転送することができます。この手順は、仮想マシンのセキュリティーを保護するために実行することを強く推奨します。
- Windows テンプレートを選択して仮想マシンを作成した場合、SysPrep セクションを使用して、自動化された Windows 設定用に XML 形式で回答ファイルをアップロードします。
- Next をクリックして Review ステップに移動し、仮想マシンの設定を確認します。
- Create Virtual Machine をクリックします。
See virtual machine details をクリックして、この仮想マシンの Overview を表示します。
仮想マシンは Virtual Machines タブに一覧表示されます。
Web コンソールウィザードを実行する際は、仮想マシンウィザードのフィールドを参照します。
8.1.2.1. 仮想マシンウィザードのフィールド
名前 | パラメーター | 説明 |
---|---|---|
名前 |
この名前には、小文字 ( | |
説明 | オプションの説明フィールド。 | |
オペレーティングシステム | テンプレートで仮想マシン用に選択されるオペレーティングシステム。テンプレートから仮想マシンを作成する場合、このフィールドを編集することはできません。 | |
Boot Source | URL を使用したインポート (PVC の作成) | HTTP または S3 エンドポイントで利用できるイメージからコンテンツをインポートします。例: オペレーティングシステムイメージのある Web ページから URL リンクを取得します。 |
既存の PVC のクローン作成 (PVC の作成) | クラスターで利用可能な既存の永続ボリューム要求 (PVC) を選択し、これをクローンします。 | |
レジストリーを使用したインポート (PVC の作成) |
クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: | |
PXE (ネットワークブート: ネットワークインターフェースの追加) | ネットワークのサーバーからオペレーティングシステムを起動します。PXE ブート可能なネットワーク接続定義が必要です。 | |
永続ボリューム要求 (PVC) のプロジェクト | PVC のクローン作成に使用するプロジェクト名。 | |
永続ボリューム要求 (PVC) の名前 | 既存の PVC のクローンを作成する場合にこの仮想マシンテンプレートに適用する必要のある PVC 名。 | |
これを CD-ROM ブートソースとしてマウントする | CD-ROM には、オペレーティングシステムをインストールするための追加のディスクが必要です。チェックボックスを選択して、ディスクを追加し、後でカスタマイズします。 | |
Flavor | Tiny、Small、Medium、Large、Custom | 仮想マシンテンプレートの CPU およびメモリーの容量を、そのテンプレートに関連付けられたオペレーティングシステムに応じて、仮想マシンに割り当てられる事前に定義された値で事前設定します。
デフォルトのテンプレートを選択する場合は、カスタム値を使用して、テンプレートの |
Workload Type 注記 誤った Workload Type を選択した場合は、パフォーマンスまたはリソースの使用状況の問題が発生することがあります (UI の速度低下など)。 | デスクトップ |
デスクトップで使用するための仮想マシン設定。小規模な環境での使用に適しています。Web コンソールでの使用に推奨されます。このテンプレートクラスまたはサーバーテンプレートクラスを使用して、 |
サーバー |
パフォーマンスのバランスを図り、さまざまなサーバーのワークロードと互換性があります。このテンプレートクラスまたはデスクトップテンプレートクラスを使用して、 | |
高パフォーマンス(CPU マネージャーが必要) |
高パフォーマンスのワークロードに対して最適化された仮想マシン設定。このテンプレートクラスを使用して、仮想マシンの密度よりも | |
作成後にこの仮想マシンを起動します。 | このチェックボックスはデフォルトで選択され、仮想マシンは作成後に実行を開始します。仮想マシンの作成時に起動する必要がない場合は、チェックボックスをクリアします。 |
CPU マネージャー が高パフォーマンスのワークロードプロファイルを使用できるようにします。
8.1.2.2. ネットワークフィールド
名前 | 説明 |
---|---|
Name | ネットワークインターフェースコントローラーの名前。 |
モデル | ネットワークインターフェースコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
Network | 利用可能なネットワーク接続定義の一覧。 |
Type |
利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、 |
MAC Address | ネットワークインターフェースコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
8.1.2.3. ストレージフィールド
名前 | 選択 | 説明 |
---|---|---|
Source | 空白 (PVC の作成) | 空のディスクを作成します。 |
URL を使用したインポート (PVC の作成) | URL (HTTP または S3 エンドポイント) を使用してコンテンツをインポートします。 | |
既存 PVC の使用 | クラスターですでに利用可能な PVC を使用します。 | |
既存の PVC のクローン作成 (PVC の作成) | クラスターで利用可能な既存の PVC を選択し、このクローンを作成します。 | |
レジストリーを使用したインポート (PVC の作成) | コンテナーレジストリーを使用してコンテンツをインポートします。 | |
コンテナー (一時的) | クラスターからアクセスできるレジストリーにあるコンテナーからコンテンツをアップロードします。コンテナーディスクは、CD-ROM や一時的な仮想マシンなどの読み取り専用ファイルシステムにのみ使用する必要があります。 | |
名前 |
ディスクの名前。この名前には、小文字 ( | |
Size | ディスクのサイズ (GiB 単位)。 | |
Type | ディスクのタイプ。例: Disk または CD-ROM | |
Interface | ディスクデバイスのタイプ。サポートされるインターフェースは、virtIO、SATA、および SCSI です。 | |
Storage Class | ディスクの作成に使用されるストレージクラス。 | |
Advanced → Volume Mode 注記 デフォルト値はストレージプロファイルから使用されます。 | 永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。 |
ストレージの詳細設定
名前 | パラメーター | 説明 |
---|---|---|
ボリュームモード 注記 デフォルト値はストレージプロファイルから使用されます。 | ファイルシステム | ファイルシステムベースのボリュームで仮想ディスクを保存します。 |
Block |
ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 |
8.1.2.4. Cloud-init フィールド
名前 | 説明 |
---|---|
Hostname | 仮想マシンの特定のホスト名を設定します。 |
認可された SSH キー | 仮想マシンの ~/.ssh/authorized_keys にコピーされるユーザーの公開鍵。 |
カスタムスクリプト | 他のオプションを、カスタム cloud-init スクリプトを貼り付けるフィールドに置き換えます。 |
ストレージクラスのデフォルトを設定するには、ストレージプロファイルを使用します。詳細については、ストレージプロファイルのカスタマイズを参照してください。
8.1.2.5. 仮想マシンウィザードの作成用の事前に設定された YAML ファイルの貼り付け
YAML 設定ファイルを作成し、解析して仮想マシンを作成します。YAML 編集画面を開くと、常に有効な example
仮想マシン設定がデフォルトで提供されます。
Create をクリックする際に YAML 設定が無効な場合、エラーメッセージでエラーが発生したパラメーターが示唆されます。エラーは一度に 1 つのみ表示されます。
編集中に YAML 画面から離れると、設定に対して加えた変更が取り消されます。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- Create をクリックし、Virtual Machine With YAML を選択します。
編集可能なウィンドウで仮想マシンの設定を作成するか、またはこれを貼り付けます。
-
または、YAML 画面にデフォルトで提供される
example
仮想マシンを使用します。
-
または、YAML 画面にデフォルトで提供される
- オプション: Download をクリックして YAML 設定ファイルをその現在の状態でダウンロードします。
- Create をクリックして仮想マシンを作成します。
仮想マシンは Virtual Machines タブに一覧表示されます。
8.1.3. CLI の使用による仮想マシンの作成
仮想マシンマニフェストから仮想マシンを作成できます。
手順
仮想マシンの
VirtualMachine
マニフェストを編集します。たとえば、以下のマニフェストは Red Hat Enterprise Linux(RHEL)仮想マシンを設定します。例8.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
マニフェストファイルを使用して仮想マシンを作成します。
$ oc create -f <vm_manifest_file>.yaml
オプション: 仮想マシンを起動します。
$ virtctl start <vm_name>
8.1.4. 仮想マシンのストレージボリュームタイプ
ストレージボリュームタイプ | 説明 |
---|---|
ephemeral | ネットワークボリュームを読み取り専用のバッキングストアとして使用するローカルの copy-on-write (COW) イメージ。バッキングボリュームは PersistentVolumeClaim である必要があります。一時イメージは仮想マシンの起動時に作成され、すべての書き込みをローカルに保存します。一時イメージは、仮想マシンの停止、再起動または削除時に破棄されます。バッキングボリューム (PVC) はいずれの方法でも変更されません。 |
persistentVolumeClaim | 利用可能な PV を仮想マシンに割り当てます。PV の割り当てにより、仮想マシンデータのセッション間での永続化が可能になります。 CDI を使用して既存の仮想マシンディスクを PVC にインポートし、PVC を仮想マシンインスタンスに割り当てる方法は、既存の仮想マシンを OpenShift Container Platform にインポートするための推奨される方法です。ディスクを PVC 内で使用できるようにするためのいくつかの要件があります。 |
dataVolume |
データボリュームは、インポート、クローンまたはアップロード操作で仮想マシンディスクの準備プロセスを管理することによって
|
cloudInitNoCloud | 参照される cloud-init NoCloud データソースが含まれるディスクを割り当て、ユーザーデータおよびメタデータを仮想マシンに提供します。cloud-init インストールは仮想マシンディスク内で必要になります。 |
containerDisk | コンテナーイメージレジストリーに保存される、仮想マシンディスクなどのイメージを参照します。イメージはレジストリーからプルされ、仮想マシンの起動時にディスクとして仮想マシンに割り当てられます。
RAW および QCOW2 形式のみがコンテナーイメージレジストリーのサポートされるディスクタイプです。QCOW2 は、縮小されたイメージサイズの場合に推奨されます。 注記
|
emptyDisk | 仮想マシンインターフェースのライフサイクルに関連付けられるスパースの QCOW2 ディスクを追加で作成します。データは仮想マシンのゲストによって実行される再起動後も存続しますが、仮想マシンが Web コンソールから停止または再起動する場合には破棄されます。空のディスクは、アプリケーションの依存関係および一時ディスクの一時ファイルシステムの制限を上回るデータを保存するために使用されます。 ディスク 容量 サイズも指定する必要があります。 |
8.1.5. 仮想マシンの RunStrategy について
仮想マシンの RunStrategy
は、一連の条件に応じて仮想マシンインスタンス (VMI) の動作を判別します。spec.runStrategy
設定は、spec.running
設定の代わりに仮想マシン設定プロセスに存在します。spec.runStrategy
設定を使用すると、true
または false
の応答のみを伴う spec.running
設定とは対照的に、VMI の作成および管理をより柔軟に行えます。ただし、2 つの設定は相互排他的です。spec.running
または spec.runStrategy
のいずれかを使用できます。両方を使用する場合は、エラーが発生します。
4 つ RunStrategy が定義されています。
Always
-
VMI は仮想マシンの作成時に常に表示されます。元の VMI が何らかの理由で停止する場合に、新規の VMI が作成されます。これは
spec.running: true
と同じ動作です。 RerunOnFailure
- 前のインスタンスがエラーが原因で失敗する場合は、VMI が再作成されます。インスタンスは、仮想マシンが正常に停止する場合 (シャットダウン時など) には再作成されません。
Manual
(手動)-
start
、stop
、およびrestart
virtctl クライアントコマンドは、 VMI の状態および存在を制御するために使用できます。 Halted
-
仮想マシンが作成される際に VMI は存在しません。これは
spec.running: false
と同じ動作です。
start
、stop
、および restart
の virtctl コマンドの各種の組み合わせは、どの RunStrategy
が使用されるかに影響を与えます。
以下の表は、仮想マシンの各種の状態からの移行について示しています。最初の列には、仮想マシンの初期の RunStrategy
が表示されます。それぞれの追加の列には、virtctl コマンドと、このコマンド実行後の新規 RunStrategy
が表示されます。
初期 RunStrategy | start | stop | restart |
---|---|---|---|
Always | - | Halted | Always |
RerunOnFailure | - | Halted | RerunOnFailure |
Manual | Manual | Manual | Manual |
Halted | Always | - | - |
インストーラーでプロビジョニングされるインフラストラクチャーを使用してインストールされた OpenShift Virtualization クラスターでは、ノードで MachineHealthCheck に失敗し、クラスターで利用できなくなると、RunStrategy が Always
または RerunOnFailure
の仮想マシンが新規ノードで再スケジュールされます。
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
RunStrategy: Always 1
template:
...
- 1
- VMI の現在の
RunStrategy
設定。
8.1.6. 関連情報
KubeVirt v0.49.0 API リファレンス の
VirtualMachineSpec
定義は、仮想マシン仕様のパラメーターおよび階層のより範囲の広いコンテキストを提供します。注記KubeVirt API リファレンスはアップストリームのプロジェクトリファレンスであり、OpenShift Virtualization でサポートされていないパラメーターが含まれる場合があります。
-
「 コンテナーディスクの準備 」を参照して、これを
containerDisk
ボリュームとして仮想マシンに追加します。 - マシンヘルスチェック のデプロイおよび有効化についての詳細は、「マシンヘルスチェックのデプロイ」を参照してください。
- インストーラーで プロビジョニングされるインフラストラクチャーについての詳細は、「インストーラーでプロビジョニングされるインフラストラクチャーの概要 」を参照してください。
- SR-IOV ネットワーク Operator についての詳細は、「SR-IOV ネットワーク Operator の 設定」を参照してください。
- ストレージプロファイルのカスタマイズ
8.2. 仮想マシンの編集
Web コンソールの YAML エディターまたはコマンドラインの OpenShift CLI のいずれかを使用して、仮想マシン設定を更新できます。Virtual Machine Details 画面でパラメーターのサブセットを更新することもできます。
8.2.1. Web コンソールでの仮想マシンの編集
関連するフィールドの横にある鉛筆アイコンをクリックして、Web コンソールで仮想マシンの選択する値 (select values) を編集します。他の値は、CLI を使用して編集できます。
ラベルとアノテーションは、事前に設定された Red Hat テンプレートとカスタム仮想マシンテンプレートの両方について編集されます。その他のすべての値は、ユーザーが Red Hat テンプレートまたは Create Virtual Machine Template ウィザードを使用して作成したカスタム仮想マシンテンプレートについてのみ編集されます。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択します。
- Details タブをクリックします。
- 鉛筆アイコンをクリックして、フィールドを編集可能にします。
- 関連する変更を加え、Save をクリックします。
仮想マシンが実行されている場合、Boot Order または Flavor への変更は仮想マシンを再起動するまで反映されません。
関連するフィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。
8.2.2. Web コンソールを使用した仮想マシンの YAML 設定の編集
Web コンソールで、仮想マシンの YAML 設定を編集できます。一部のパラメーターは変更できません。無効な設定で Save をクリックすると、エラーメッセージで変更できないパラメーターが示唆されます。
仮想マシンが実行中に YAML 設定を編集する場合、変更内容は仮想マシンが再起動されるまで反映されません。
編集中に YAML 画面から離れると、設定に対して加えた変更が取り消されます。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- 仮想マシンを選択します。
- YAML タブをクリックして編集可能な設定を表示します。
- オプション: Download をクリックして YAML ファイルをその現在の状態でローカルにダウンロードできます。
- ファイルを編集し、Save をクリックします。
オブジェクトの更新されたバージョン番号を含む、変更が正常に行われたことを示す確認メッセージが表示されます。
8.2.3. CLI を使用した仮想マシン YAML 設定の編集
以下の手順を使用し、CLI を使用して仮想マシン YAML 設定を編集します。
前提条件
- YAML オブジェクト設定ファイルを使って仮想マシンを設定していること。
-
oc
CLI をインストールしていること。
手順
以下のコマンドを実行して、仮想マシン設定を更新します。
$ oc edit <object_type> <object_ID>
- オブジェクト設定を開きます。
- YAML を編集します。
実行中の仮想マシンを編集する場合は、以下のいずれかを実行する必要があります。
- 仮想マシンを再起動します。
新規の設定を有効にするために、以下のコマンドを実行します。
$ oc apply <object_type> <object_ID>
8.2.4. 仮想マシンへの仮想ディスクの追加
以下の手順を使用して仮想ディスクを仮想マシンに追加します。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Disks タブをクリックします。
Add Disk ウィンドウで、Source、Name、Size、Type、Interface、および Storage Class を指定します。
- Advanced: 空のディスクソースを使用し、データボリュームの作成時に最大の書き込みパフォーマンスが必要な場合に、事前割り当てを有効にできます。そのためには、Enable preallocation チェックボックスを選択します。
-
オプション: Advanced 一覧で、仮想ディスクの Volume Mode および Access Mode を指定します。これらのパラメーターを指定しない場合、システムは
kubevirt-storage-class-defaults
設定マップのデフォルト値を使用します。
- Add をクリックします。
仮想マシンが実行中の場合、新規ディスクは pending restart 状態にあり、仮想マシンを再起動するまで割り当てられません。
ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。
ストレージクラスのデフォルトを設定するには、ストレージプロファイルを使用します。詳細については、ストレージプロファイルのカスタマイズを参照してください。
8.2.4.1. ストレージフィールド
名前 | 選択 | 説明 |
---|---|---|
Source | 空白 (PVC の作成) | 空のディスクを作成します。 |
URL を使用したインポート (PVC の作成) | URL (HTTP または S3 エンドポイント) を使用してコンテンツをインポートします。 | |
既存 PVC の使用 | クラスターですでに利用可能な PVC を使用します。 | |
既存の PVC のクローン作成 (PVC の作成) | クラスターで利用可能な既存の PVC を選択し、このクローンを作成します。 | |
レジストリーを使用したインポート (PVC の作成) | コンテナーレジストリーを使用してコンテンツをインポートします。 | |
コンテナー (一時的) | クラスターからアクセスできるレジストリーにあるコンテナーからコンテンツをアップロードします。コンテナーディスクは、CD-ROM や一時的な仮想マシンなどの読み取り専用ファイルシステムにのみ使用する必要があります。 | |
名前 |
ディスクの名前。この名前には、小文字 ( | |
Size | ディスクのサイズ (GiB 単位)。 | |
Type | ディスクのタイプ。例: Disk または CD-ROM | |
Interface | ディスクデバイスのタイプ。サポートされるインターフェースは、virtIO、SATA、および SCSI です。 | |
Storage Class | ディスクの作成に使用されるストレージクラス。 | |
Advanced → Volume Mode 注記 デフォルト値はストレージプロファイルから使用されます。 | 永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。 |
ストレージの詳細設定
名前 | パラメーター | 説明 |
---|---|---|
ボリュームモード 注記 デフォルト値はストレージプロファイルから使用されます。 | ファイルシステム | ファイルシステムベースのボリュームで仮想ディスクを保存します。 |
Block |
ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 |
8.2.5. 仮想マシンへのネットワークインターフェースの追加
以下の手順を使用してネットワークインターフェースを仮想マシンに追加します。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Network Interfaces タブをクリックします。
- Add Network Interface をクリックします。
- Add Network Interface ウィンドウで、ネットワークインターフェースの Name、Model、Network、 Type、および MAC Address を指定します。
- Add をクリックします。
仮想マシンが実行中の場合、新規ネットワークインターフェースは pending restart 状態にあり、仮想マシンを再起動するまで変更は反映されません。
ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。
8.2.5.1. ネットワークフィールド
名前 | 説明 |
---|---|
Name | ネットワークインターフェースコントローラーの名前。 |
モデル | ネットワークインターフェースコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
Network | 利用可能なネットワーク接続定義の一覧。 |
Type |
利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、 |
MAC Address | ネットワークインターフェースコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
8.2.6. 仮想マシンの CD-ROM の編集
以下の手順を使用して、仮想マシンの CD-ROM を編集します。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Disks タブをクリックします。
-
編集する CD-ROM の Options メニュー
をクリックし、Edit を選択します。
- Edit CD-ROM ウィンドウで、Source、Persistent Volume Claim、Name、Type、および Interface フィールドを編集します。
- Save をクリックします。
8.2.7. 関連情報
8.3. ブート順序の編集
Web コンソールまたは CLI を使用して、ブート順序リストの値を更新できます。
Virtual Machine Overview ページの Boot Order で、以下を実行できます。
- ディスクまたはネットワークインターフェースコントローラー (NIC) を選択し、これをブート順序の一覧に追加します。
- ブート順序の一覧でディスクまたは NIC の順序を編集します。
- ブート順序の一覧からディスクまたは NIC を削除して、起動可能なソースのインベントリーに戻します。
8.3.1. Web コンソールでのブート順序一覧への項目の追加
Web コンソールを使用して、ブート順序一覧に項目を追加します。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Details タブをクリックします。
- Boot Order の右側にある鉛筆アイコンをクリックします。YAML 設定が存在しない場合や、これがブート順序一覧の初回作成時の場合、以下のメッセージが表示されます。No resource selected.仮想マシンは、YAML ファイルでの出現順にディスクからの起動を試行します。
- Add Source をクリックして、仮想マシンのブート可能なディスクまたはネットワークインターフェースコントローラー (NIC) を選択します。
- 追加のディスクまたは NIC をブート順序一覧に追加します。
- Save をクリックします。
仮想マシンが実行されている場合、Boot Order への変更は仮想マシンを再起動するまで反映されません。
Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。
8.3.2. Web コンソールでのブート順序一覧の編集
Web コンソールで起動順序一覧を編集します。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Details タブをクリックします。
- Boot Order の右側にある鉛筆アイコンをクリックします。
ブート順序一覧で項目を移動するのに適した方法を選択します。
- スクリーンリーダーを使用しない場合、移動する項目の横にある矢印アイコンにカーソルを合わせ、項目を上下にドラッグし、選択した場所にドロップします。
- スクリーンリーダーを使用する場合は、上矢印キーまたは下矢印を押して、ブート順序一覧で項目を移動します。次に Tab キーを押して、選択した場所に項目をドロップします。
- Save をクリックします。
仮想マシンが実行されている場合、ブート順序の変更は仮想マシンが再起動されるまで反映されません。
Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。
8.3.3. YAML 設定ファイルでのブート順序一覧の編集
CLI を使用して、YAML 設定ファイルのブート順序の一覧を編集します。
手順
以下のコマンドを実行して、仮想マシンの YAML 設定ファイルを開きます。
$ oc edit vm example
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
- YAML ファイルを保存します。
- reload the content をクリックして、Web コンソールで YAML ファイルの更新されたブート順序の値をブート順序一覧に適用します。
8.3.4. Web コンソールでのブート順序一覧からの項目の削除
Web コンソールを使用して、ブート順序の一覧から項目を削除します。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Details タブをクリックします。
- Boot Order の右側にある鉛筆アイコンをクリックします。
-
項目の横にある Remove アイコン
をクリックします。この項目はブート順序の一覧から削除され、利用可能なブートソースの一覧に保存されます。ブート順序一覧からすべての項目を削除する場合、以下のメッセージが表示されます。No resource selected.仮想マシンは、YAML ファイルでの出現順にディスクからの起動を試行します。
仮想マシンが実行されている場合、Boot Order への変更は仮想マシンを再起動するまで反映されません。
Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。
8.4. 仮想マシンの削除
Web コンソールまたは oc
コマンドラインインターフェースを使用して、仮想マシンを削除できます。
8.4.1. Web コンソールの使用による仮想マシンの削除
仮想マシンを削除すると、仮想マシンはクラスターから永続的に削除されます。
仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。
手順
- OpenShift Virtualization コンソールのサイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
削除する仮想マシンの Options メニュー
をクリックして Delete Virtual Machine を選択します。
- または、仮想マシン名をクリックして Virtual Machine Overview 画面を開き、Actions → Delete Virtual Machine をクリックします。
- 確認のポップアップウィンドウで、Delete をクリックし、仮想マシンを永続的に削除します。
8.4.2. CLI の使用による仮想マシンの削除
oc
コマンドラインインターフェース (CLI) を使用して仮想マシンを削除できます。oc
クライアントを使用すると、複数の仮想マシンで各種のアクションを実行できます。
仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。
前提条件
- 削除する仮想マシンの名前を特定すること。
手順
以下のコマンドを実行し、仮想マシンを削除します。
$ oc delete vm <vm_name>
注記このコマンドは、現在のプロジェクトに存在するオブジェクトのみを削除します。削除する必要のあるオブジェクトが別のプロジェクトまたは namespace にある場合、
-n <project_name>
オプションを指定します。
8.5. 仮想マシンインスタンスの管理
OpenShift Virtualization 環境外に独立して作成されたスタンドアロンの仮想マシンインスタンス(VMI) がある場合、Web コンソールまたはコマンドラインインターフェース (CLI) を使用してこれらを管理できます。
8.5.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 を削除します。
8.5.2. CLI を使用した仮想マシンインスタンスの一覧表示
oc
コマンドラインインターフェース (CLI) を使用して、スタンドアロンおよび仮想マシンによって所有されている VMI を含むすべての仮想マシンの一覧を表示できます。
手順
以下のコマンドを実行して、すべての VMI の一覧を表示します。
$ oc get vmis
8.5.3. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの一覧表示
Web コンソールを使用して、仮想マシンによって所有されていないクラスター内のスタンドアロンの仮想マシンインスタンス (VMI) の一覧を表示できます。
仮想マシンまたは他のオブジェクトが所有する VMI は、Web コンソールには表示されません。Web コンソールは、スタンドアロンの VMI のみを表示します。クラスター内のすべての VMI を一覧表示するには、CLI を使用する必要があります。
手順
- サイドメニューから Workloads → Virtualization をクリックします。仮想マシンおよびスタンドアロン VMI の一覧が表示されます。スタンドアロン VMI は、仮想マシンインスタンス名の横に表示される暗い配色のバッジで特定できます。
8.5.4. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの編集
Web コンソールを使用して、スタンドアロン仮想マシンインスタンスのアノテーションおよびラベルを編集できます。スタンドアロン VMI の Details ページに表示される他の項目は編集できません。
手順
- サイドメニューから Workloads → Virtualization をクリックします。仮想マシン (VM) およびスタンドアロン VMI の一覧が表示されます。
- スタンドアロン VMI の名前をクリックして、 Virtual Machine Instance Overview 画面を開きます。
- Details タブをクリックします。
- Annotations の右側にある鉛筆アイコンをクリックします。
- 関連する変更を加え、Save をクリックします。
スタンドアロン VMI のラベルを編集するには、Actions をクリックして、Edit Labels を選択します。関連する変更を加え、Save をクリックします。
8.5.5. CLI を使用したスタンドアロン仮想マシンインスタンスの削除
oc
コマンドラインインターフェース (CLI) を使用してスタンドアロン仮想マシンインスタンス (VMI) を削除できます。
前提条件
- 削除する必要のある VMI の名前を特定すること。
手順
以下のコマンドを実行して VMI を削除します。
$ oc delete vmi <vmi_name>
8.5.6. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの削除
Web コンソールからスタンドアロン仮想マシンインスタンス (VMI) を削除します。
手順
- OpenShift Container Platform Web コンソールで、サイドメニューから Workloads → Virtualization をクリックします。
削除する必要のあるスタンドアロン仮想マシンインスタンス (VMI) の ⋮ ボタンをクリックし、 Delete Virtual Machine Instance を選択します。
- または、スタンドアロン VMI の名前をクリックします。Virtual Machine Instance Overview ページが表示されます。
- Actions → Delete Virtual Machine Instance を選択します。
- 確認のポップアップウィンドウで、Delete をクリックし、スタンドアロン VMI を永続的に削除します。
8.6. 仮想マシンの状態の制御
Web コンソールから仮想マシンを停止し、起動し、再起動し、一時停止を解除することができます。
コマンドラインインターフェース(CLI)から仮想マシンを制御するには、virtctl
クライアント を使用します。
8.6.1. 仮想マシンの起動
Web コンソールから仮想マシンを起動できます。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 起動する仮想マシンが含まれる行を見つけます。
ユースケースに適したメニューに移動します。
複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。
-
行の右端にある Options メニュー
をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、Virtual Machine Overview ページにアクセスします。
- Actions をクリックします。
- Start Virtual Machine を選択します。
- 確認ウィンドウで Start をクリックし、仮想マシンを起動します。
URL
ソースからプロビジョニングされる仮想マシンの初回起動時に、OpenShift Virtualization が URL エンドポイントからコンテナーをインポートする間、仮想マシンの状態は Importing になります。このプロセスは、イメージのサイズによって数分の時間がかかる可能性があります。
8.6.2. 仮想マシンの再起動
Web コンソールから実行中の仮想マシンを再起動できます。
エラーを回避するには、ステータスが Importing の仮想マシンは再起動しないでください。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 再起動する仮想マシンが含まれる行を見つけます。
ユースケースに適したメニューに移動します。
複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。
-
行の右端にある Options メニュー
をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを再起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、Virtual Machine Overview ページにアクセスします。
- Actions をクリックします。
- Restart Virtual Machine を選択します。
- 確認ウィンドウで Restart をクリックし、仮想マシンを再起動します。
8.6.3. 仮想マシンの停止
Web コンソールから仮想マシンを停止できます。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 停止する仮想マシンが含まれる行を見つけます。
ユースケースに適したメニューに移動します。
複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。
-
行の右端にある Options メニュー
をクリックします。
-
行の右端にある Options メニュー
選択した仮想マシンを停止する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、Virtual Machine Overview ページにアクセスします。
- Actions をクリックします。
- Stop Virtual Machine を選択します。
- 確認ウィンドウで Stop をクリックし、仮想マシンを停止します。
8.6.4. 仮想マシンの一時停止の解除
Web コンソールから仮想マシンの一時停止を解除できます。
前提条件
1 つ以上の仮想マシンのステータスが Paused である必要がある。
注記virtctl
クライアントを使用して仮想マシンを一時停止することができます。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 一時停止を解除する仮想マシンが含まれる行を見つけます。
ユースケースに適したメニューに移動します。
複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。
- Status 列で、Paused をクリックします。
選択した仮想マシンの一時停止を解除する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。
- 仮想マシンの名前をクリックして、Virtual Machine Overview ページにアクセスします。
- Status の右側にある鉛筆アイコンをクリックします。
- 確認ウィンドウで Stop をクリックし、仮想マシンの一時停止を解除します。
8.7. 仮想マシンコンソールへのアクセス
OpenShift Virtualization は、異なる製品タスクを実現するために使用できる異なる仮想マシンコンソールを提供します。Web コンソールおよび CLI コマンドを使用してこれらのコンソールにアクセスできます。
8.7.1. 仮想マシンコンソールのセッション
Web コンソールの Virtual Machine Details ページの Console タブから、実行中の仮想マシンの VNC およびシリアルコンソールに接続することができます。
VNC コンソール は、Consoles タブに移動する際には常にデフォルトで開きます。VNC Console ドロップダウンリストをクリックし、Serial Console を選択して、シリアルコンソールへの接続を開くことができます。
コンソールのセッションは切断しない限り、バックグラウンドでアクティブな状態のままになります。コンソールセッションが一度に 1 つだけ開かれていることを確認するには、コンソールを切り換える前に、 Disconnect before switching チェックボックスをクリックします。
Open Console in New Window をクリックするか、または Actions → Open Console をクリックして、切り離されたウィンドウのアクティブなコンソールセッションを開くことができます。
VNC コンソール のオプション
- Send Key をクリックして、キーの組み合わせを仮想マシンに送信します。
シリアルコンソール のオプション
- Disconnect をクリックして、仮想マシンから Serial Console セッションを手動で切断します。
- Reconnect ボタンを使用して Serial Console セッションを仮想マシンに対して手動で開きます。
8.7.2. Web コンソールの使用による仮想マシンへの接続
8.7.2.1. ターミナルへの接続
Web コンソールを使用して仮想マシンに接続することができます。
手順
- 正しいプロジェクトを指定していることを確認します。そうでない場合は、Project 一覧をクリックして適切なプロジェクトを選択します。
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
-
Details タブで、
virt-launcher-<vm-name>
Pod をクリックします。 - Terminal タブをクリックします。ターミナルが空白の場合、ターミナルをクリックし、任意のキーを押して接続を開始します。
8.7.2.2. シリアルコンソールへの接続
Web コンソールの Virtual Machine Overview 画面の Consoles タブから、実行中の仮想マシンの Serial Console に接続します。
手順
- OpenShift Virtualization コンソールのサイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview ページを開きます。
- Consoles をクリックします。VNC コンソールがデフォルトで開きます。
- VNC Console ドロップダウンリストをクリックし、Serial Console を選択します。
- オプション: Open Console in New Window をクリックして、別のウィンドウでシリアルコンソールを開きます。
8.7.2.3. VNC コンソールへの接続
Web コンソールの Virtual Machine Overview 画面の Console タブから実行中の仮想マシンの VNC コンソールに接続します。
手順
- OpenShift Virtualization コンソールのサイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview ページを開きます。
- Console タブをクリックします。VNC コンソールがデフォルトで開きます。
- オプション: Open Console in New Window をクリックして、別のウィンドウで VNC コンソールを開きます。
8.7.2.4. RDP コンソールへの接続
Remote Desktop Protocol (RDP) を使用するデスクトップビューアーコンソールは、Windows 仮想マシンに接続するためのより使いやすいコンソールを提供します。
RDP を使用して Windows 仮想マシンに接続するには、Web コンソールの Virtual Machine Details 画面の Consoles タブから仮想マシンの console.rdp
ファイルをダウンロードし、これを優先する RDP クライアントに指定します。
前提条件
-
QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。
qemu-guest-agent
は VirtIO ドライバーに含まれています。 - 仮想マシンに接続された layer-2 NIC。
- Windows 仮想マシンと同じネットワーク上のマシンにインストールされた RDP クライアント。
手順
- OpenShift Virtualization コンソールのサイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- Windows 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Console タブをクリックします。
- Console 一覧で、Desktop Viewer を選択します。
- Network Interface 一覧で、 layer-2 NIC を選択します。
-
Launch Remote Desktop をクリックし、
console.rdp
ファイルをダウンロードします。 RDP クライアントを開き、
console.rdp
ファイルを参照します。たとえば、remmina を使用します。$ remmina --connect /path/to/console.rdp
- Administrator ユーザー名およびパスワードを入力して、Windows 仮想マシンに接続します。
8.7.3. CLI コマンドの使用による仮想マシンコンソールへのアクセス
8.7.3.1. SSH 経由での仮想マシンインスタンスへのアクセス
仮想マシン (仮想マシン) にポート 22 を公開した後に、SSH を使用して仮想マシンにアクセスできます。
virtctl expose
コマンドは、仮想マシンインスタンス (VMI) のポートをノードポートに転送し、有効にされたアクセスのサービスを作成します。以下の例では、fedora-vm-ssh
サービスを作成します。このサービスは、クラスターノードの特定のポートから <fedora-vm>
仮想マシンのポート 22 にトラフィックを転送します。
前提条件
- VMI と同じプロジェクトを使用する。
-
アクセスする VMI は、
masquerade
バインディング方法を使用してデフォルトの Pod ネットワークに接続されている。 - アクセスする VMI が実行中であること。
-
OpenShift CLI (
oc
) をインストールします。
手順
以下のコマンドを実行して
fedora-vm-ssh
サービスを作成します。$ virtctl expose vm <fedora-vm> --port=22 --name=fedora-vm-ssh --type=NodePort 1
- 1
<fedora-vm>
は、fedora-vm-ssh
サービスを実行する仮想マシンの名前です。
サービスをチェックし、サービスが取得したポートを見つけます。
$ oc get svc
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE fedora-vm-ssh NodePort 127.0.0.1 <none> 22:32551/TCP 6s
この例では、サービスは
32551
ポートを取得しています。SSH 経由で VMI にログインします。クラスターノードの
ipAddress
および直前の手順で確認したポートを使用します。$ ssh username@<node_IP_address> -p 32551
8.7.3.2. YAML 設定を使用した SSH での仮想マシンへのアクセス
virtctl expose
コマンドを実行する必要なしに、仮想マシン (VM) への SSH 接続を有効にすることができます。仮想マシンの YAML ファイルおよびサービスの YAML ファイルが設定され、適用されると、サービスは SSH トラフィックを仮想マシンに転送します。
以下の例は、仮想マシンの YAML ファイルおよびサービス YAML ファイルの設定を示しています。
前提条件
-
OpenShift CLI (
oc
) をインストールします。 -
oc create namespace
コマンドを使用し、namespace の名前を指定して仮想マシンの YAML ファイルの namespace を作成します。
手順
仮想マシンの YAML ファイルで、SSH 接続のサービスを公開するためのラベルおよび値を追加します。インターフェースの
masquerade
機能を有効にします。VirtualMachine
定義の例... apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: namespace: ssh-ns 1 name: vm-ssh spec: running: false template: metadata: labels: kubevirt.io/vm: vm-ssh special: vm-ssh 2 spec: domain: devices: disks: - disk: bus: virtio name: containerdisk - disk: bus: virtio name: cloudinitdisk interfaces: - masquerade: {} 3 name: testmasquerade 4 rng: {} machine: type: "" resources: requests: memory: 1024M networks: - name: testmasquerade pod: {} volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-container-disk-demo - name: cloudinitdisk cloudInitNoCloud: userData: | #!/bin/bash echo "fedora" | passwd fedora --stdin ...
仮想マシンを作成します。
$ oc create -f <path_for_the_VM_YAML_file>
仮想マシンを起動します。
$ virtctl start vm-ssh
サービスの YAML ファイルで、サービス名、ポート番号、およびターゲットポートを指定します。
Service
定義の例。... apiVersion: v1 kind: Service metadata: name: svc-ssh 1 namespace: ssh-ns 2 spec: ports: - targetPort: 22 3 protocol: TCP port: 27017 selector: special: vm-ssh 4 type: NodePort ...
サービスを作成します。
$ oc create -f <path_for_the_service_YAML_file>
仮想マシンが実行されていることを確認します。
$ oc get vmi
出力例
NAME AGE PHASE IP NODENAME vm-ssh 6s Running 10.244.196.152 node01
サービスをチェックし、サービスが取得したポートを見つけます。
$ oc get svc
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc-ssh NodePort 10.106.236.208 <none> 27017:30093/TCP 22s
この例では、サービスはポート番号 30093 を取得しています。
以下のコマンドを実行して、ノードの IP アドレスを取得します。
$ oc get node <node_name> -o wide
出力例
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP node01 Ready worker 6d22h v1.23.0 192.168.55.101 <none>
仮想マシンが実行されているノードの IP アドレスとポート番号を指定して、SSH 経由で仮想マシンにログインします。
oc get svc
コマンドで表示されるポート番号およびoc get node
コマンドで表示されるノードの IP アドレスを使用します。以下の例は、ユーザー名、ノードの IP アドレス、およびポート番号を指定したssh
コマンドを示しています。$ ssh fedora@192.168.55.101 -p 30093
8.7.3.3. 仮想マシンインスタンスのシリアルコンソールへのアクセス
virtctl console
コマンドは、指定された仮想マシンインスタンスへのシリアルコンソールを開きます。
前提条件
-
virt-viewer
パッケージがインストールされていること。 - アクセスする仮想マシンインスタンスが実行中であること。
手順
virtctl
でシリアルコンソールに接続します。$ virtctl console <VMI>
8.7.3.4. VNC を使用した仮想マシンインスタンスのグラフィカルコンソールへのアクセス
virtctl
クライアントユーティリティーは remote-viewer
機能を使用し、実行中の仮想マシンインスタンスに対してグラフィカルコンソールを開くことができます。この機能は virt-viewer
パッケージに組み込まれています。
前提条件
-
virt-viewer
パッケージがインストールされていること。 - アクセスする仮想マシンインスタンスが実行中であること。
リモートマシンで SSH 経由で virtctl
を使用する場合、X セッションをマシンに転送する必要があります。
手順
virtctl
ユーティリティーを使用してグラフィカルインターフェースに接続します。$ virtctl vnc <VMI>
コマンドが失敗した場合には、トラブルシューティング情報を収集するために
-v
フラグの使用を試行します。$ virtctl vnc <VMI> -v 4
8.7.3.5. RDP コンソールの使用による Windows 仮想マシンへの接続
Remote Desktop Protocol (RDP) は、Windows 仮想マシンに接続するためのより使いやすいコンソールを提供します。
RDP を使用して Windows 仮想マシンに接続するには、割り当てられた L2 NIC の IP アドレスを RDP クライアントに対して指定します。
前提条件
-
QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。
qemu-guest-agent
は VirtIO ドライバーに含まれています。 - 仮想マシンに接続された layer-2 NIC。
- Windows 仮想マシンと同じネットワーク上のマシンにインストールされた RDP クライアント。
手順
アクセストークンを持つユーザーとして、
oc
CLI ツールを使って OpenShift Virtualization クラスターにログインします。$ oc login -u <user> https://<cluster.example.com>:8443
oc describe vmi
を使用して、実行中の Windows 仮想マシンの設定を表示します。$ oc describe vmi <windows-vmi-name>
出力例
... spec: networks: - name: default pod: {} - multus: networkName: cnv-bridge name: bridge-net ... status: interfaces: - interfaceName: eth0 ipAddress: 198.51.100.0/24 ipAddresses: 198.51.100.0/24 mac: a0:36:9f:0f:b1:70 name: default - interfaceName: eth1 ipAddress: 192.0.2.0/24 ipAddresses: 192.0.2.0/24 2001:db8::/32 mac: 00:17:a4:77:77:25 name: bridge-net ...
-
レイヤー 2 ネットワークインターフェースの IP アドレスを特定し、これをコピーします。これは直前の例では
192.0.2.0
であり、IPv6 を選択する場合は2001:db8::
になります。 - RDP クライアントを開き、接続用に直前の手順でコピーした IP アドレスを使用します。
- Administrator ユーザー名およびパスワードを入力して、Windows 仮想マシンに接続します。
8.8. sysprep を使用した Windows のインストールの自動化
Microsoft DVD イメージとsysprep
を使用して、Windows 仮想マシンのインストール、セットアップ、およびソフトウェアプロビジョニングを自動化できます。
8.8.1. Windows DVD を使用した VM ディスクイメージの作成
Microsoft はダウンロード用のディスクイメージを提供していませんが、Windows DVD を使用してディスクイメージを作成できます。このディスクイメージを使用して、仮想マシンを作成できます。
手順
- Open Shift Virtualization Web コンソールで、Storage → PersistentVolumeClaims → Create PersistentVolumeClaim With Data upload formをクリックします。
- 目的のプロジェクトを選択します。
- 永続ボリューム要求の名前を設定します。
- Windows DVD から仮想マシンディスクイメージをアップロードします。これで、イメージをブートソースとして使用して、新しい Windows 仮想マシンを作成できます。
8.8.2. ディスクイメージを使用した Windows のインストール
Windows DVD を使用してディスクイメージを作成した後、そのディスクイメージを使用して仮想マシンに Windows をインストールできます。
手順
- Open Shift Virtualization Web コンソール仮想マシンウィザードを使用して、希望のバージョンの Windows で使用可能なテンプレートを使用して新しい Windows 仮想マシンを作成します。
- ブートソースとして DVD イメージを選択します。
- Clone available operating system source to this Virtual Machineのチェックを外します。
- Start this virtual machine after creationのチェックボックスをオフにします。
- Customize virtual machine → Advancedをクリックします。
-
Sysprepで、 Microsoft のガイドラインに従って
autounattend.xml
応答ファイルの設定を指定します。 -
YAML で、
running:false
をrunStrategy: RerunOnFailure
に置き換えて、保存します。仮想マシンが自動的に起動します。これで、autounattend.xml
応答ファイルが含まれるsysprep
ディスクが仮想マシンに接続されました。
8.8.3. sysprep を使用した Windows 仮想マシンの一般化
イメージを一般化すると、イメージが仮想マシンにデプロイされる際に、システム固有の設定データがすべて削除されます。
仮想マシンを一般化する前に、Windows の無人インストール後にsysprep
ツールが応答ファイルを検出できないことを確認する必要があります。
手順
sysprep
ディスクを削除します。- Web コンソールで、Virtualization → Virtual Machinesを選択し、関連する仮想マシンを選択します。
- ディスク をクリックします。
-
sysprep
ディスクのオプションメニューをクリックし、続いてDeleteをクリックします。
- Detach sysprep diskダイアログでDetachをクリックします。
-
sysprep
ツールによる検出を回避するために、C:\Windows\Panther\unattend.xml
の名前を変更します。 次のコマンドを実行して、
sysprep
プログラムを開始します。%WINDIR%\System32\Sysprep\sysprep.exe /generalize /shutdown /oobe /mode:vm
-
sysprep
ツールが完了すると、Windows 仮想マシンがシャットダウンします。これで、仮想マシンのディスクイメージを Windows 仮想マシンのインストールイメージとして使用できるようになりました。
これで、仮想マシンを特殊化できます。
8.8.4. Windows 仮想マシンの特殊化
仮想マシンを特殊化すると、コンピューター固有の情報がイメージから仮想マシンに設定されます。
仮想マシンを特殊化する前に、ルートディスクを一般化する必要があります。
手順
- Open Shift Virtualization Web コンソール仮想マシンウィザードを使用して、新しい Windows 仮想マシンを作成します。
-
Boot Source
を選択するときは、Clone existing PVC
を選択し、初期の仮想マシンルートディスクから PVC のクローンを作成します。 - Customize virtual machine → Advancedをクリックします
-
Sysprepで、Microsoft のガイドラインに従って
unattend.xml
応答ファイルの設定を指定します。 -
autounattend.xml
応答ファイル設定にフィラー情報を追加します。 -
仮想マシンを起動します。最初の起動時に、Windows は
unattend.xml
応答ファイルを使用して仮想マシンを特殊化します。これで、仮想マシンを使用する準備が整いました。
8.8.5. 関連情報
8.9. 障害が発生したノードの解決による仮想マシンのフェイルオーバーのトリガー
ノードに障害が発生し、マシンのヘルスチェック がクラスターにデプロイされていない場合、RunStrategy: Always
が設定された仮想マシン(VM)は正常なノードに自動的に移動しません。仮想マシンのフェイルオーバーをトリガーするには、Node
オブジェクトを手動で削除する必要があります。
インストーラーでプロビジョニングされるインフラストラクチャー を使用してクラスターをインストールし、マシンのヘルスチェックを適切に設定している場合は、以下を実行します。
- 障害が発生したノードは自動的に再利用されます。
-
RunStrategy
がAlways
またはRerunOnFailure
に設定された仮想マシンは正常なノードで自動的にスケジュールされます。
8.9.1. 前提条件
-
仮想マシンが実行されているノードには
NotReady
状態 が設定されている。 -
障害のあるノードで実行されていた仮想マシンでは、
RunStrategy
がAlways
に設定されている。 -
OpenShift CLI (
oc
) がインストールされている。
8.9.2. ベアメタルクラスターからのノードの削除
CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーで管理されないベア Pod は、OpenShift Container Platform からはアクセスできなくなります。レプリケーションコントローラーで管理されるベア Pod は、他の利用可能なノードに再スケジュールされます。ローカルのマニフェスト Pod は削除する必要があります。
手順
以下の手順を実行して、ベアメタルで実行されている OpenShift Container Platform クラスターからノードを削除します。
ノードにスケジュール対象外 (unschedulable) のマークを付けます。
$ oc adm cordon <node_name>
ノード上のすべての Pod をドレイン (解放) します。
$ oc adm drain <node_name> --force=true
このステップは、ノードがオフラインまたは応答しない場合に失敗する可能性があります。ノードが応答しない場合でも、共有ストレージに書き込むワークロードを実行している可能性があります。データの破損を防ぐには、続行する前に物理ハードウェアの電源を切ります。
クラスターからノードを削除します。
$ oc delete node <node_name>
ノードオブジェクトはクラスターから削除されていますが、これは再起動後や kubelet サービスが再起動される場合にクラスターに再び参加することができます。ノードとそのすべてのデータを永続的に削除するには、ノードの使用を停止する必要があります。
- 物理ハードウェアを電源を切っている場合は、ノードがクラスターに再度加わるように、そのハードウェアを再びオンに切り替えます。
8.9.3. 仮想マシンのフェイルオーバーの確認
すべてのリソースが正常でないノードで終了すると、移行した仮想マシンのそれぞれについて、新しい仮想マシンインスタンス (VMI) が正常なノードに自動的に作成されます。VMI が作成されていることを確認するには、oc
CLI を使用してすべての VMI を表示します。
8.9.3.1. CLI を使用した仮想マシンインスタンスの一覧表示
oc
コマンドラインインターフェース (CLI) を使用して、スタンドアロンおよび仮想マシンによって所有されている VMI を含むすべての仮想マシンの一覧を表示できます。
手順
以下のコマンドを実行して、すべての VMI の一覧を表示します。
$ oc get vmis
8.10. QEMU ゲストエージェントの仮想マシンへのインストール
QEMU ゲストエージェント は仮想マシンで実行され、仮想マシン、ユーザー、ファイルシステム、およびセカンダリーネットワークに関する情報をホストに渡すデーモンです。
8.10.1. QEMU ゲストエージェントの Linux 仮想マシンへのインストール
qemu-guest-agent
は広く利用されており、Red Hat 仮想マシンでデフォルトで利用できます。このエージェントをインストールし、サービスを起動します。
仮想マシン(VM)に QEMU ゲストエージェントがインストールされ、実行されているかどうかを確認するには、AgentConnected
が VM 仕様に表示されていることを確認します。
整合性が最も高いオンライン(実行状態)の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。
QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。
手順
- コンソールのいずれか、または SSH を使用して仮想マシンのコマンドラインにアクセスします。
QEMU ゲストエージェントを仮想マシンにインストールすること。
$ yum install -y qemu-guest-agent
サービスに永続性があることを確認し、これを起動します。
$ systemctl enable --now qemu-guest-agent
Web コンソールで仮想マシンまたは仮想マシンテンプレートのいずれかを作成する際に、ウィザードの cloud-init セクションの custom script フィールドを使用して QEMU ゲストエージェントをインストールし、起動することもできます。
8.10.2. QEMU ゲストエージェントの Windows 仮想マシンへのインストール
Windows 仮想マシンの場合には、QEMU ゲストエージェントは VirtIO ドライバーに含まれます。既存の Windows システムまたは新しい Windows システムにドライバーをインストールします。
仮想マシン(VM)に QEMU ゲストエージェントがインストールされ、実行されているかどうかを確認するには、AgentConnected
が VM 仕様に表示されていることを確認します。
整合性が最も高いオンライン(実行状態)の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。
QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。
8.10.2.1. VirtIO ドライバーの既存 Windows 仮想マシンへのインストール
VirtIO ドライバーを、割り当てられた SATA CD ドライブから既存の Windows 仮想マシンにインストールします。
この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。このプロセスは Windows のバージョンごとに若干異なる可能性があります。特定のインストール手順については、お使いの Windows バージョンについてのインストールドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- Windows ユーザーセッションにログインします。
Device Manager を開き、Other devices を拡張して、Unknown device を一覧表示します。
-
Device Properties
を開いて、不明なデバイスを特定します。デバイスを右クリックし、Properties を選択します。 - Details タブをクリックし、Property リストで Hardware Ids を選択します。
- Hardware Ids の Value をサポートされる VirtIO ドライバーと比較します。
-
- デバイスを右クリックし、Update Driver Software を選択します。
- Browse my computer for driver software をクリックし、VirtIO ドライバーが置かれている割り当て済みの SATA CD ドライブの場所に移動します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
- Next をクリックしてドライバーをインストールします。
- 必要なすべての VirtIO ドライバーに対してこのプロセスを繰り返します。
- ドライバーのインストール後に、Close をクリックしてウィンドウを閉じます。
- 仮想マシンを再起動してドライバーのインストールを完了します。
8.10.2.2. Windows インストール時の VirtIO ドライバーのインストール
Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。
この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- Windows インストールプロセスを開始します。
- Advanced インストールを選択します。
-
ストレージの宛先は、ドライバーがロードされるまで認識されません。
Load driver
をクリックします。 - ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
- 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
- Windows インストールを完了します。
8.11. 仮想マシンの QEMU ゲストエージェント情報の表示
QEMU ゲストエージェントが仮想マシンで実行されている場合は、Web コンソールを使用して、仮想マシン、ユーザー、ファイルシステム、およびセカンダリーネットワークに関する情報を表示できます。
8.11.1. 前提条件
- QEMU ゲストエージェント を仮想マシンにインストールします。
8.11.2. Web コンソールでの QEMU ゲストエージェント情報について
QEMU ゲストエージェントがインストールされると、Virtual Machine Overview タブの Details ペインと、Details タブにホスト名、オペレーティングシステム、タイムゾーン、およびログインユーザーに関する情報が表示されます。
Virtual Machine Overview には、仮想マシンにインストールされたゲストオペレーティングシステムについての情報が表示されます。Details タブには、ログインユーザーの情報が含まれる表が表示されます。Disks タブには、ファイルシステムの情報が含まれる表が表示されます。
QEMU ゲストエージェントがインストールされていない場合、Virtual Machine Overview タブおよび Details タブには、仮想マシンの作成時に指定したオペレーティングシステムについての情報が表示されます。
8.11.3. Web コンソールでの QEMU ゲストエージェント情報の表示
Web コンソールを使用して、QEMU ゲストエージェントによってホストに渡される仮想マシンの情報を表示できます。
手順
- サイドメニューから Workloads → Virtual Machines をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシン名を選択して Virtual Machine Overview 画面を開き、Details ペインを表示します。
- Logged in users をクリックして、ユーザーについての情報を表示する Details タブを表示します。
- Disks タブをクリックして、ファイルシステムについての情報を表示します。
8.12. 仮想マシンでの設定マップ、シークレット、およびサービスアカウントの管理
シークレット、設定マップ、およびサービスアカウントを使用して設定データを仮想マシンに渡すことができます。たとえば、以下を実行できます。
- シークレットを仮想マシンに追加して認証情報を必要とするサービスに仮想マシンのアクセスを付与します。
- Pod または別のオブジェクトがデータを使用できるように、機密データではない設定データを設定マップに保存します。
- サービスアカウントをそのコンポーネントに関連付けることにより、コンポーネントが API サーバーにアクセスできるようにします。
OpenShift Virtualization はシークレット、設定マップ、およびサービスアカウントを仮想マシンディスクとして公開し、追加のオーバーヘッドなしにプラットフォーム全体でそれらを使用できるようにします。
8.12.1. シークレット、設定マップ、またはサービスアカウントの仮想マシンへの追加
OpenShift Container Platform Web コンソールを使用して、シークレット、設定マップ、またはサービスアカウントを仮想マシンに追加します。
前提条件
- 追加するシークレット、設定マップ、またはサービスアカウントは、ターゲット仮想マシンと同じ namespace に存在する必要がある。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Environment タブをクリックします。
- Select a resource をクリックし、一覧からシークレット、設定マップ、またはサービスアカウントを選択します。6 文字のシリアル番号が、選択したリソースについて自動的に生成されます。
- Save をクリックします。
- オプション。Add Config Map, Secret or Service Account をクリックして別のオブジェクトを追加します。
- Reload をクリックし、最後に保存された状態にフォームをリセットできます。
- Environment リソースが仮想マシンにディスクとして追加されます。他のディスクをマウントするように、シークレット、設定マップ、またはサービスアカウントをマウントできます。
- 仮想マシンが実行中の場合、変更内容は仮想マシンが再起動されるまで反映されません。新規に追加されたリソースは、ページ上部の Pending Changes バナーの Environment および Disks タブの両方に保留中のリソースとしてマークされます。
検証
- Virtual Machine Overview ページから、Disks タブをクリックします。
- シークレット、設定マップ、またはサービスアカウントがディスクの一覧に含まれていることを確認します。
オプション。変更を適用する適切な方法を選択します。
- 仮想マシンが実行されている場合、Actions → Restart Virtual Machine をクリックして仮想マシンを再起動します。
- 仮想マシンが停止している場合は、Actions → Start Virtual Machine をクリックして仮想マシンを起動します。
他のディスクをマウントするように、シークレット、設定マップ、またはサービスアカウントをマウントできるようになりました。
8.12.2. 仮想マシンからのシークレット、設定マップ、またはサービスアカウントの削除
OpenShift Container Platform Web コンソールを使用して、シークレット、設定マップ、またはサービスアカウントを仮想マシンから削除します。
前提条件
- 仮想マシンに割り当てられるシークレット、設定マップ、またはサービスアカウントが少なくとも 1 つ必要である。
手順
- サイドメニューから Workloads → Virtualization をクリックします。
- Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Environment タブをクリックします。
-
一覧で削除する項目を見つけ、項目の右上にある Remove
をクリックします。
- Save をクリックします。
Reload をクリックし、最後に保存された状態にフォームをリセットできます。
検証
- Virtual Machine Overview ページから、Disks タブをクリックします。
- 削除したシークレット、設定マップ、またはサービスアカウントがディスクの一覧に含まれていないことを確認します。
8.12.3. 関連情報
8.13. VirtIO ドライバーの既存の Windows 仮想マシンへのインストール
8.13.1. VirtIO ドライバーについて
VirtIO ドライバーは、Microsoft Windows 仮想マシンが OpenShift Virtualization で実行されるために必要な準仮想化デバイスドライバーです。サポートされるドライバーは、Red Hat Ecosystem Catalog の container-native-virtualization/virtio-win
コンテナーディスクで利用できます。
container-native-virtualization/virtio-win
コンテナーディスクは、ドライバーのインストールを有効にするために SATA CD ドライブとして仮想マシンに割り当てられる必要があります。仮想マシン上での Windows のインストール時に VirtIO ドライバーをインストールすることも、既存の Windows インストールに追加することもできます。
ドライバーのインストール後に、container-native-virtualization/virtio-win
コンテナーディスクは仮想マシンから削除できます。
「 Installing Virtio drivers on a new Windows virtual machine 」も参照してください。
8.13.2. Microsoft Windows 仮想マシンのサポートされる VirtIO ドライバー
表8.1 サポートされるドライバー
ドライバー名 | ハードウェア ID | 説明 |
---|---|---|
viostor |
VEN_1AF4&DEV_1001 | ブロックドライバー。Other devices グループの SCSI Controller として表示される場合があります。 |
viorng |
VEN_1AF4&DEV_1005 | エントロピーソースドライバー。Other devices グループの PCI Device として表示される場合があります。 |
NetKVM |
VEN_1AF4&DEV_1000 | ネットワークドライバー。Other devices グループの Ethernet Controller として表示される場合があります。VirtIO NIC が設定されている場合にのみ利用できます。 |
8.13.3. VirtIO ドライバーコンテナーディスクの仮想マシンへの追加
OpenShift Virtualization は、Red Hat Ecosystem Catalog で利用できる Microsoft Windows の VirtIO ドライバーをコンテナーディスクとして配布します。これらのドライバーを Windows 仮想マシンにインストールするには、仮想マシン設定ファイルで container-native-virtualization/virtio-win
コンテナーディスクを SATA CD ドライブとして仮想マシンに割り当てます。
前提条件
-
container-native-virtualization/virtio-win
コンテナーディスクを Red Hat Ecosystem Catalog からダウンロードすること。コンテナーディスクがクラスターにない場合は Red Hat レジストリーからダウンロードされるため、これは必須ではありません。
手順
container-native-virtualization/virtio-win
コンテナーディスクをcdrom
ディスクとして Windows 仮想マシン設定ファイルに追加します。コンテナーディスクは、クラスターにない場合はレジストリーからダウンロードされます。spec: domain: devices: disks: - name: virtiocontainerdisk bootOrder: 2 1 cdrom: bus: sata volumes: - containerDisk: image: container-native-virtualization/virtio-win name: virtiocontainerdisk
- 1
- OpenShift Virtualization は、
VirtualMachine
設定ファイルに定義される順序で仮想マシンディスクを起動します。container-native-virtualization/virtio-win
コンテナーディスクの前に仮想マシンの他のディスクを定義するか、またはオプションのbootOrder
パラメーターを使用して仮想マシンが正しいディスクから起動するようにできます。ディスクにbootOrder
を指定する場合、これは設定のすべてのディスクに指定される必要があります。
ディスクは、仮想マシンが起動すると利用可能になります。
-
コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で
oc apply -f <vm.yaml>
を使用するか、または仮想マシンを再起動します。 -
仮想マシンが実行されていない場合、
virtctl start <vm>
を使用します。
-
コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で
仮想マシンが起動したら、VirtIO ドライバーを割り当てられた SATA CD ドライブからインストールできます。
8.13.4. VirtIO ドライバーの既存 Windows 仮想マシンへのインストール
VirtIO ドライバーを、割り当てられた SATA CD ドライブから既存の Windows 仮想マシンにインストールします。
この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。このプロセスは Windows のバージョンごとに若干異なる可能性があります。特定のインストール手順については、お使いの Windows バージョンについてのインストールドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- Windows ユーザーセッションにログインします。
Device Manager を開き、Other devices を拡張して、Unknown device を一覧表示します。
-
Device Properties
を開いて、不明なデバイスを特定します。デバイスを右クリックし、Properties を選択します。 - Details タブをクリックし、Property リストで Hardware Ids を選択します。
- Hardware Ids の Value をサポートされる VirtIO ドライバーと比較します。
-
- デバイスを右クリックし、Update Driver Software を選択します。
- Browse my computer for driver software をクリックし、VirtIO ドライバーが置かれている割り当て済みの SATA CD ドライブの場所に移動します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
- Next をクリックしてドライバーをインストールします。
- 必要なすべての VirtIO ドライバーに対してこのプロセスを繰り返します。
- ドライバーのインストール後に、Close をクリックしてウィンドウを閉じます。
- 仮想マシンを再起動してドライバーのインストールを完了します。
8.13.5. 仮想マシンからの VirtIO コンテナーディスクの削除
必要なすべての VirtIO ドライバーを仮想マシンにインストールした後は、container-native-virtualization/virtio-win
コンテナーディスクを仮想マシンに割り当てる必要はなくなります。container-native-virtualization/virtio-win
コンテナーディスクを仮想マシン設定ファイルから削除します。
手順
設定ファイルを編集し、
disk
およびvolume
を削除します。$ oc edit vm <vm-name>
spec: domain: devices: disks: - name: virtiocontainerdisk bootOrder: 2 cdrom: bus: sata volumes: - containerDisk: image: container-native-virtualization/virtio-win name: virtiocontainerdisk
- 変更を有効にするために仮想マシンを再起動します。
8.14. VirtIO ドライバーの新規 Windows 仮想マシンへのインストール
8.14.1. 前提条件
- 仮想マシンからアクセスできる Windows インストールメディア( ISO のデータボリュームへのインポート および仮想マシンへの割り当てなど)。
8.14.2. VirtIO ドライバーについて
VirtIO ドライバーは、Microsoft Windows 仮想マシンが OpenShift Virtualization で実行されるために必要な準仮想化デバイスドライバーです。サポートされるドライバーは、Red Hat Ecosystem Catalog の container-native-virtualization/virtio-win
コンテナーディスクで利用できます。
container-native-virtualization/virtio-win
コンテナーディスクは、ドライバーのインストールを有効にするために SATA CD ドライブとして仮想マシンに割り当てられる必要があります。仮想マシン上での Windows のインストール時に VirtIO ドライバーをインストールすることも、既存の Windows インストールに追加することもできます。
ドライバーのインストール後に、container-native-virtualization/virtio-win
コンテナーディスクは仮想マシンから削除できます。
8.14.3. Microsoft Windows 仮想マシンのサポートされる VirtIO ドライバー
表8.2 サポートされるドライバー
ドライバー名 | ハードウェア ID | 説明 |
---|---|---|
viostor |
VEN_1AF4&DEV_1001 | ブロックドライバー。Other devices グループの SCSI Controller として表示される場合があります。 |
viorng |
VEN_1AF4&DEV_1005 | エントロピーソースドライバー。Other devices グループの PCI Device として表示される場合があります。 |
NetKVM |
VEN_1AF4&DEV_1000 | ネットワークドライバー。Other devices グループの Ethernet Controller として表示される場合があります。VirtIO NIC が設定されている場合にのみ利用できます。 |
8.14.4. VirtIO ドライバーコンテナーディスクの仮想マシンへの追加
OpenShift Virtualization は、Red Hat Ecosystem Catalog で利用できる Microsoft Windows の VirtIO ドライバーをコンテナーディスクとして配布します。これらのドライバーを Windows 仮想マシンにインストールするには、仮想マシン設定ファイルで container-native-virtualization/virtio-win
コンテナーディスクを SATA CD ドライブとして仮想マシンに割り当てます。
前提条件
-
container-native-virtualization/virtio-win
コンテナーディスクを Red Hat Ecosystem Catalog からダウンロードすること。コンテナーディスクがクラスターにない場合は Red Hat レジストリーからダウンロードされるため、これは必須ではありません。
手順
container-native-virtualization/virtio-win
コンテナーディスクをcdrom
ディスクとして Windows 仮想マシン設定ファイルに追加します。コンテナーディスクは、クラスターにない場合はレジストリーからダウンロードされます。spec: domain: devices: disks: - name: virtiocontainerdisk bootOrder: 2 1 cdrom: bus: sata volumes: - containerDisk: image: container-native-virtualization/virtio-win name: virtiocontainerdisk
- 1
- OpenShift Virtualization は、
VirtualMachine
設定ファイルに定義される順序で仮想マシンディスクを起動します。container-native-virtualization/virtio-win
コンテナーディスクの前に仮想マシンの他のディスクを定義するか、またはオプションのbootOrder
パラメーターを使用して仮想マシンが正しいディスクから起動するようにできます。ディスクにbootOrder
を指定する場合、これは設定のすべてのディスクに指定される必要があります。
ディスクは、仮想マシンが起動すると利用可能になります。
-
コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で
oc apply -f <vm.yaml>
を使用するか、または仮想マシンを再起動します。 -
仮想マシンが実行されていない場合、
virtctl start <vm>
を使用します。
-
コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で
仮想マシンが起動したら、VirtIO ドライバーを割り当てられた SATA CD ドライブからインストールできます。
8.14.5. Windows インストール時の VirtIO ドライバーのインストール
Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。
この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。
手順
- 仮想マシンを起動し、グラフィカルコンソールに接続します。
- Windows インストールプロセスを開始します。
- Advanced インストールを選択します。
-
ストレージの宛先は、ドライバーがロードされるまで認識されません。
Load driver
をクリックします。 - ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
- 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
- Windows インストールを完了します。
8.14.6. 仮想マシンからの VirtIO コンテナーディスクの削除
必要なすべての VirtIO ドライバーを仮想マシンにインストールした後は、container-native-virtualization/virtio-win
コンテナーディスクを仮想マシンに割り当てる必要はなくなります。container-native-virtualization/virtio-win
コンテナーディスクを仮想マシン設定ファイルから削除します。
手順
設定ファイルを編集し、
disk
およびvolume
を削除します。$ oc edit vm <vm-name>
spec: domain: devices: disks: - name: virtiocontainerdisk bootOrder: 2 cdrom: bus: sata volumes: - containerDisk: image: container-native-virtualization/virtio-win name: virtiocontainerdisk
- 変更を有効にするために仮想マシンを再起動します。
8.15. 高度な仮想マシン管理
8.15.1. 仮想マシンのノードの指定
ノードの配置ルールを使用して、仮想マシン (VM) を特定のノードに配置することができます。
8.15.1.1. 仮想マシンのノード配置について
仮想マシン (VM) が適切なノードで実行されるようにするには、ノードの配置ルールを設定できます。以下の場合にこれを行うことができます。
- 仮想マシンが複数ある。フォールトトレランスを確保するために、これらを異なるノードで実行する必要がある。
- 2 つの相互間のネットワークトラフィックの多い chatty VM がある。冗長なノード間のルーティングを回避するには、仮想マシンを同じノードで実行します。
- 仮想マシンには、利用可能なすべてのノードにない特定のハードウェア機能が必要です。
- 機能をノードに追加する Pod があり、それらの機能を使用できるように仮想マシンをそのノードに配置する必要があります。
仮想マシンの配置は、ワークロードの既存のノードの配置ルールに基づきます。ワークロードがコンポーネントレベルの特定のノードから除外される場合、仮想マシンはそれらのノードに配置できません。
以下のルールタイプは、VirtualMachine
マニフェストの spec
フィールドで使用できます。
nodeSelector
- 仮想マシンは、キーと値のペアまたはこのフィールドで指定したペアを使用してラベルが付けられたノードに Pod をスケジュールできます。ノードには、一覧表示されたすべてのペアに一致するラベルがなければなりません。
affinity
より表現的な構文を使用して、ノードと仮想マシンに一致するルールを設定できます。たとえば、ルールがハード要件ではなく基本設定になるように指定し、ルールの条件が満たされない場合も仮想マシンがスケジュールされるようにすることができます。Pod のアフィニティー、Pod の非アフィニティー、およびノードのアフィニティーは仮想マシンの配置でサポートされます。Pod のアフィニティーは仮想マシンに対して動作します。
VirtualMachine
ワークロードタイプはPod
オブジェクトに基づくためです。注記アフィニティールールは、スケジューリング時にのみ適用されます。OpenShift Container Platform は、制約を満たさなくなった場合に実行中のワークロードを再スケジューリングしません。
tolerations
- 一致するテイントを持つノードで仮想マシンをスケジュールできます。テイントがノードに適用される場合、そのノードはテイントを容認する仮想マシンのみを受け入れます。
8.15.1.2. ノード配置の例
以下の YAML スニペットの例では、nodePlacement
、affinity
、および tolerations
フィールドを使用して仮想マシンのノード配置をカスタマイズします。
8.15.1.2.1. 例: nodeSelector を使用した仮想マシンノードの配置
この例では、仮想マシンに example-key-1 = example-value-1
および example-key-2 = example-value-2
ラベルの両方が含まれるメタデータのあるノードが必要です。
この説明に該当するノードがない場合、仮想マシンはスケジュールされません。
仮想マシンマニフェストの例
metadata: name: example-vm-node-selector apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: template: spec: nodeSelector: example-key-1: example-value-1 example-key-2: example-value-2 ...
8.15.1.2.2. 例: Pod のアフィニティーおよび Pod の非アフィニティーによる仮想マシンノードの配置
この例では、仮想マシンはラベル example-key-1 = example-value-1
を持つ実行中の Pod のあるノードでスケジュールされる必要があります。このようなノードで実行中の Pod がない場合、仮想マシンはスケジュールされません。
可能な場合に限り、仮想マシンはラベル example-key-2 = example-value-2
を持つ Pod のあるノードではスケジュールされません。ただし、すべての候補となるノードにこのラベルを持つ Pod がある場合、スケジューラーはこの制約を無視します。
仮想マシンマニフェストの例
metadata: name: example-vm-pod-affinity apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: 1 - labelSelector: matchExpressions: - key: example-key-1 operator: In values: - example-value-1 topologyKey: kubernetes.io/hostname podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: 2 - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: example-key-2 operator: In values: - example-value-2 topologyKey: kubernetes.io/hostname ...
8.15.1.2.3. 例: ノードのアフィニティーによる仮想マシンノードの配置
この例では、仮想マシンはラベル example.io/example-key = example-value-1
またはラベル example.io/example-key = example-value-2
を持つノードでスケジュールされる必要があります。この制約は、ラベルのいずれかがノードに存在する場合に満たされます。いずれのラベルも存在しない場合、仮想マシンはスケジュールされません。
可能な場合、スケジューラーはラベル example-node-label-key = example-node-label-value
を持つノードを回避します。ただし、すべての候補となるノードにこのラベルがある場合、スケジューラーはこの制約を無視します。
仮想マシンマニフェストの例
metadata: name: example-vm-node-affinity apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: 1 nodeSelectorTerms: - matchExpressions: - key: example.io/example-key operator: In values: - example-value-1 - example-value-2 preferredDuringSchedulingIgnoredDuringExecution: 2 - weight: 1 preference: matchExpressions: - key: example-node-label-key operator: In values: - example-node-label-value ...
8.15.1.2.4. 例: 容認 (toleration) を使用した仮想マシンノードの配置
この例では、仮想マシン用に予約されるノードには、すでに key=virtualization:NoSchedule
テイントのラベルが付けられています。この仮想マシンには一致する tolerations
があるため、これをテイントが付けられたノードにスケジュールできます。
テイントを容認する仮想マシンは、そのテイントを持つノードにスケジュールする必要はありません。
仮想マシンマニフェストの例
metadata: name: example-vm-tolerations apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: tolerations: - key: "key" operator: "Equal" value: "virtualization" effect: "NoSchedule" ...
8.15.1.3. 関連情報
8.15.2. 証明書ローテーションの設定
証明書ローテーションパラメーターを設定して、既存の証明書を置き換えます。
8.15.2.1. 証明書ローテーションの設定
これは、Web コンソールでの OpenShift Virtualization のインストール時に、または HyperConverged
カスタムリソース (CR) でインストール後に実行することができます。
手順
以下のコマンドを実行して
HyperConverged
CR を開きます。$ oc edit hco -n openshift-cnv kubevirt-hyperconverged
以下の例のように
spec.certConfig
フィールドを編集します。システムのオーバーロードを避けるには、すべての値が 10 分以上であることを確認します。golangParseDuration
形式 に準拠する文字列として、すべての値を表現します。apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: certConfig: ca: duration: 48h0m0s renewBefore: 24h0m0s 1 server: duration: 24h0m0s 2 renewBefore: 12h0m0s 3
- YAML ファイルをクラスターに適用します。
8.15.2.2. 証明書ローテーションパラメーターのトラブルシューティング
1 つ以上の certConfig
値を削除すると、デフォルト値が以下のいずれかの条件と競合する場合を除き、デフォルト値に戻ります。
-
ca.renewBefore
の値はca.duration
の値以下である必要があります。 -
server.duration
の値はca.duration
の値以下である必要があります。 -
server.renewBefore
の値はserver.duration
の値以下である必要があります。
デフォルト値がこれらの条件と競合すると、エラーが発生します。
以下の例で server.duration
値を削除すると、デフォルト値の 24h0m0s
は ca.duration
の値よりも大きくなり、指定された条件と競合します。
例
certConfig: ca: duration: 4h0m0s renewBefore: 1h0m0s server: duration: 4h0m0s renewBefore: 4h0m0s
これにより、以下のエラーメッセージが表示されます。
error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission webhook "validate-hco.kubevirt.io" denied the request: spec.certConfig: ca.duration is smaller than server.duration
エラーメッセージには、最初の競合のみが記載されます。続行する前に、すべての certConfig の値を確認します。
8.15.3. 管理タスクの自動化
Red Hat Ansible Automation Platform を使用すると、OpenShift Virtualization 管理タスクを自動化できます。Ansible Playbook を使用して新規の仮想マシンを作成する際の基本事項を確認します。
8.15.3.1. Red Hat Ansible Automation について
Ansible は、システムの設定、ソフトウェアのデプロイ、およびローリングアップデートの実行に使用する自動化ツールです。Ansible には OpenShift Virtualization のサポートが含まれ、Ansible モジュールを使用すると、テンプレート、永続ボリューム要求 (PVC) および仮想マシンの操作などのクラスター管理タスクを自動化できます。
Ansible は、oc
CLI ツールや API を使用しても実行できる OpenShift Virtualization の管理を自動化する方法を提供します。Ansible は、KubeVirt モジュールを他の Ansible モジュールと統合できる点でユニークであると言えます。
8.15.3.2. 仮想マシン作成の自動化
kubevirt_vm
Ansible Playbook を使用し、Red Hat Ansible Automation Platform を使用して OpenShift Container Platform クラスターに仮想マシンを作成できます。
前提条件
- Red Hat Ansible Engine バージョン 2.8 以降。
手順
kubevirt_vm
タスクを含むように Ansible Playbook YAML ファイルを編集します。kubevirt_vm: namespace: name: cpu_cores: memory: disks: - name: volume: containerDisk: image: disk: bus:
注記このスニペットには Playbook の
kubevirt_vm
部分のみが含まれます。namespace
、cpu_cores
の数、memory
、およびdisks
を含む、作成する必要のある仮想マシンを反映させるように値を編集します。以下は例になります。kubevirt_vm: namespace: default name: vm1 cpu_cores: 1 memory: 64Mi disks: - name: containerdisk volume: containerDisk: image: kubevirt/cirros-container-disk-demo:latest disk: bus: virtio
仮想マシンを作成後すぐに起動する必要がある場合には、
state: running
を YAML ファイルに追加します。以下は例になります。kubevirt_vm: namespace: default name: vm1 state: running 1 cpu_cores: 1
- 1
- この値を
state: absent
に変更すると、すでに存在する場合に仮想マシンは削除されます。
Playbook のファイル名を引数としてのみ使用して、
ansible-playbook
コマンドを実行します。$ ansible-playbook create-vm.yaml
出力を確認し、プレイが正常に実行されたかどうかを確認します。
出力例
(...) TASK [Create my first VM] ************************************************************************ changed: [localhost] PLAY RECAP ******************************************************************************************************** localhost : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Playbook ファイルに
state: running
を含めず、すぐに仮想マシンを起動する必要がある場合には、state: running
を含めるようにファイルを編集し、Playbook を再度実行します。$ ansible-playbook create-vm.yaml
仮想マシンが作成されたことを確認するには、仮想 マシンコンソールへのアクセスを 試行します。
8.15.3.3. 例: 仮想マシンを作成するための Ansible Playbook
kubevirt_vm
Ansible Playbook を使用して仮想マシン作成を自動化できます。
以下の YAML ファイルは kubevirt_vm
Playbook の例です。これには、Playbook を実行する際に独自の情報を置き換える必要のあるサンプルの値が含まれます。
--- - name: Ansible Playbook 1 hosts: localhost connection: local tasks: - name: Create my first VM kubevirt_vm: namespace: default name: vm1 cpu_cores: 1 memory: 64Mi disks: - name: containerdisk volume: containerDisk: image: kubevirt/cirros-container-disk-demo:latest disk: bus: virtio
8.15.4. 仮想マシンの EFI モードの使用
Extensible Firmware Interface (EFI) モードで仮想マシンを起動できます。
8.15.4.1. 仮想マシンの EFI モードについて
レガシー BIOS などの Extensible Firmware Interface (EFI) は、コンピューターの起動時にハードウェアコンポーネントやオペレーティングシステムのイメージファイルを初期化します。EFI は BIOS よりも最新の機能とカスタマイズオプションをサポートするため、起動時間を短縮できます。
これは、.efi
拡張子を持つファイルに初期化と起動に関する情報をすべて保存します。このファイルは、EFI System Partition (ESP) と呼ばれる特別なパーティションに保管されます。ESP には、コンピューターにインストールされるオペレーティングシステムのブートローダープログラムも含まれます。
8.15.4.2. EFI モードでの仮想マシンのブート
仮想マシンマニフェストを編集して、仮想マシンを EFI モードで起動するように設定できます。
前提条件
-
OpenShift CLI (
oc
) をインストールします。
手順
仮想マシンオブジェクトを定義する YAML ファイルを作成します。サンプル YAML ファイルのファームウェアの スタンザを使用します。
セキュアブートがアクティブな状態の EFI モードでのブート
apiversion: kubevirt.io/v1 kind: VirtualMachine metadata: labels: special: vm-secureboot name: vm-secureboot spec: template: metadata: labels: special: vm-secureboot spec: domain: devices: disks: - disk: bus: virtio name: containerdisk features: acpi: {} smm: enabled: true 1 firmware: bootloader: efi: secureBoot: true 2 #...
以下のコマンドを実行して、マニフェストをクラスターに適用します。
$ oc create -f <file_name>.yaml
8.15.5. 仮想マシンの PXE ブートの設定
PXE ブートまたはネットワークブートは OpenShift Virtualization で利用できます。ネットワークブートにより、ローカルに割り当てられたストレージデバイスなしにコンピューターを起動し、オペレーティングシステムまたは他のプログラムを起動し、ロードすることができます。たとえば、これにより、新規ホストのデプロイ時に PXE サーバーから必要な OS イメージを選択できます。
8.15.5.1. 前提条件
- Linux ブリッジが 接続されている こと。
- PXE サーバーがブリッジとして同じ VLAN に接続されていること。
8.15.5.2. MAC アドレスを指定した PXE ブート
まず、管理者は PXE ネットワークの NetworkAttachmentDefinition
オブジェクトを作成し、ネットワーク経由でクライアントを起動できます。次に、仮想マシンインスタンスの設定ファイルでネットワーク接続定義を参照して仮想マシンインスタンスを起動します。また PXE サーバーで必要な場合には、仮想マシンインスタンスの設定ファイルで MAC アドレスを指定することもできます。
前提条件
- Linux ブリッジが接続されていること。
- PXE サーバーがブリッジとして同じ VLAN に接続されていること。
手順
クラスターに PXE ネットワークを設定します。
PXE ネットワーク
pxe-net-conf
のネットワーク接続定義ファイルを作成します。apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: pxe-net-conf spec: config: '{ "cniVersion": "0.3.1", "name": "pxe-net-conf", "plugins": [ { "type": "cnv-bridge", "bridge": "br1", "vlan": 1 1 }, { "type": "cnv-tuning" 2 } ] }'
注記仮想マシンインスタンスは、必要な VLAN のアクセスポートでブリッジ
br1
に割り当てられます。
直前の手順で作成したファイルを使用してネットワーク接続定義を作成します。
$ oc create -f pxe-net-conf.yaml
仮想マシンインスタンス設定ファイルを、インターフェースおよびネットワークの詳細を含めるように編集します。
PXE サーバーで必要な場合には、ネットワークおよび MAC アドレスを指定します。MAC アドレスが指定されていない場合、値は自動的に割り当てられます。
bootOrder
が1
に設定されており、インターフェースが最初に起動することを確認します。この例では、インターフェースは<pxe-net>
というネットワークに接続されています。interfaces: - masquerade: {} name: default - bridge: {} name: pxe-net macAddress: de:00:00:00:00:de bootOrder: 1
注記複数のインターフェースおよびディスクのブートの順序はグローバル順序になります。
オペレーティングシステムのプロビジョニング後に起動が適切に実行されるよう、ブートデバイス番号をディスクに割り当てます。
ディスク
bootOrder
の値を2
に設定します。devices: disks: - disk: bus: virtio name: containerdisk bootOrder: 2
直前に作成されたネットワーク接続定義に接続されるネットワークを指定します。このシナリオでは、
<pxe-net>
は<pxe-net-conf>
というネットワーク接続定義に接続されます。networks: - name: default pod: {} - name: pxe-net multus: networkName: pxe-net-conf
仮想マシンインスタンスを作成します。
$ oc create -f vmi-pxe-boot.yaml
出力例
virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created
仮想マシンインスタンスの実行を待機します。
$ oc get vmi vmi-pxe-boot -o yaml | grep -i phase phase: Running
VNC を使用して仮想マシンインスタンスを表示します。
$ virtctl vnc vmi-pxe-boot
- ブート画面で、PXE ブートが正常に実行されていることを確認します。
仮想マシンインスタンスにログインします。
$ virtctl console vmi-pxe-boot
仮想マシンのインターフェースおよび MAC アドレスを確認し、ブリッジに接続されたインターフェースに MAC アドレスが指定されていることを確認します。この場合、PXE ブートには IP アドレスなしに
eth1
を使用しています。他のインターフェースeth0
は OpenShift Container Platform から IP アドレスを取得しています。$ ip addr
出力例
... 3. eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether de:00:00:00:00:de brd ff:ff:ff:ff:ff:ff
8.15.5.3. テンプレート: PXE ブートの仮想マシン設定ファイル
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: creationTimestamp: null labels: special: vm-pxe-boot name: vm-pxe-boot spec: template: metadata: labels: special: vm-pxe-boot spec: domain: devices: disks: - disk: bus: virtio name: containerdisk bootOrder: 2 - disk: bus: virtio name: cloudinitdisk interfaces: - masquerade: {} name: default - bridge: {} name: pxe-net macAddress: de:00:00:00:00:de bootOrder: 1 machine: type: "" resources: requests: memory: 1024M networks: - name: default pod: {} - multus: networkName: pxe-net-conf name: pxe-net terminationGracePeriodSeconds: 180 volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-container-disk-demo - cloudInitNoCloud: userData: | #!/bin/bash echo "fedora" | passwd fedora --stdin name: cloudinitdisk status: {}
8.15.5.4. OpenShift Virtualization ネットワークの用語集
OpenShift Virtualization は、カスタムリソースおよびプラグインを使用して高度なネットワーク機能を提供します。
以下の用語は、OpenShift Virtualization ドキュメント全体で使用されています。
- Container Network Interface (CNI)
- コンテナーのネットワーク接続に重点を置く Cloud Native Computing Foundation プロジェクト。OpenShift Virtualization は CNI プラグインを使用して基本的な Kubernetes ネットワーク機能を強化します。
- Multus
- 複数の CNI の存在を可能にし、Pod または仮想マシンが必要なインターフェースを使用できるようにする「メタ」 CNI プラグイン。
- カスタムリソース定義 (CRD、Custom Resource Definition)
- カスタムリソースの定義を可能にする Kubernetes API リソース、または CRD API リソースを使用して定義されるオブジェクト。
- ネットワーク接続定義 (NAD)
- Pod、仮想マシン、および仮想マシンインスタンスを 1 つ以上のネットワークに割り当てることを可能にする Multus プロジェクトによって導入される CRD。
- ノードネットワーク設定ポリシー (NNCP)
-
ノードで要求されるネットワーク設定の説明。
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用して、インターフェースの追加および削除など、ノードネットワーク設定を更新します。 - PXE (Preboot eXecution Environment)
- 管理者がネットワーク経由でサーバーからクライアントマシンを起動できるようにするインターフェース。ネットワークのブートにより、オペレーティングシステムおよび他のソフトウェアをクライアントにリモートでロードできます。
8.15.6. ゲストメモリーの管理
ゲストメモリー設定を特定のユースケースに合わせて調整する必要がある場合、ゲストの YAML 設定ファイルを編集してこれを実行できます。OpenShift Virtualization は、ゲストメモリーのオーバーコミットの設定と、ゲストメモリーのオーバーコミットアカウンティングの無効化を許可します。
以下の手順では、メモリー不足により仮想マシンのプロセスが強制終了される可能性を高めます。リスクを理解している場合にのみ続行してください。
8.15.6.1. ゲストメモリーのオーバーコミットの設定
仮想ワークロードに利用可能な量を上回るメモリーが必要な場合、メモリーのオーバーコミットを使用してホストのメモリーのすべてまたはそのほとんどを仮想マシンインスタンス (VMI) に割り当てることができます。メモリーのオーバーコミットを有効にすることは、通常ホストに予約されるリソースを最大化できることを意味します。
たとえば、ホストに 32 GB RAM がある場合、メモリーのオーバーコミットを使用してそれぞれ 4 GB RAM を持つ 8 つの仮想マシン (VM) に対応できます。これは、仮想マシンがそれらのメモリーのすべてを同時に使用しないという前提で機能します。
メモリーのオーバーコミットにより、メモリー不足(OOM による強制終了) が原因で仮想マシンプロセスが強制終了される可能性が高くなります。
仮想マシンが OOM で強制終了される可能性は、特定の設定、ノードメモリー、利用可能な swap 領域、仮想マシンのメモリー消費、カーネルの same-page merging (KSM) の使用その他の要因によって変わります。
手順
仮想マシンインスタンスに対し、クラスターから要求された以上のメモリーが利用可能であることを明示的に示すために、仮想マシン設定ファイルを編集し、
spec.domain.memory.guest
をspec.domain.resources.requests.memory
よりも高い値に設定します。このプロセスはメモリーのオーバーコミットと呼ばれています。以下の例では、
1024M
がクラスターから要求されますが、仮想マシンインスタンスには2048M
が利用可能であると通知されます。ノードに利用可能な空のメモリーが十分にある限り、仮想マシンインスタンスは最大 2048M を消費します。kind: VirtualMachine spec: template: domain: resources: requests: memory: 1024M memory: guest: 2048M
注記ノードがメモリー不足の状態になると、Pod のエビクションルールと同じルールが仮想マシンインスタンスに適用されます。
仮想マシンを作成します。
$ oc create -f <file_name>.yaml
8.15.6.2. ゲストメモリーオーバーヘッドアカウンティングの無効化
要求する量に加えて、少量のメモリーが各仮想マシンインスタンスによって要求されます。追加のメモリーは、それぞれの VirtualMachineInstance
プロセスをラップするインフラストラクチャーに使用されます。
通常は推奨される方法ではありませんが、ゲストメモリーオーバーヘッドアカウンティングを無効にすることでノード上の仮想マシンインスタンスの密度を増やすことは可能です。
ゲストメモリーのオーバーヘッドアカウンティングを無効にすると、メモリー不足 (OOM による強制終了) による仮想マシンプロセスが強制終了の可能性が高くなります。
仮想マシンが OOM で強制終了される可能性は、特定の設定、ノードメモリー、利用可能な swap 領域、仮想マシンのメモリー消費、カーネルの same-page merging (KSM) の使用その他の要因によって変わります。
手順
ゲストメモリーオーバーヘッドアカウンティングを無効にするには、YAML 設定ファイルを編集し、
overcommitGuestOverhead
の値をtrue
に設定します。このパラメーターはデフォルトで無効にされています。kind: VirtualMachine spec: template: domain: resources: overcommitGuestOverhead: true requests: memory: 1024M
注記overcommitGuestOverhead
が有効にされている場合、これはゲストのオーバーヘッドをメモリー制限 (ある場合) に追加します。仮想マシンを作成します。
$ oc create -f <file_name>.yaml
8.15.7. 仮想マシンでの Huge Page の使用
Huge Page は、クラスター内の仮想マシンのバッキングメモリーとして使用できます。
8.15.7.1. 前提条件
- ノードには、事前に割り当てられた Huge Page が設定され ている必要があります。
8.15.7.2. Huge Page の機能
メモリーは Page と呼ばれるブロックで管理されます。多くのシステムでは、1 ページは 4Ki です。メモリー 1Mi は 256 ページに、メモリー 1Gi は 256,000 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) は、仮想から物理へのページマッピングの小規模なハードウェアキャッシュのことです。ハードウェアの指示で渡された仮想アドレスが TLB にあれば、マッピングをすばやく決定できます。そうでない場合には、TLB ミスが発生し、システムは速度が遅く、ソフトウェアベースのアドレス変換にフォールバックされ、パフォーマンスの問題が発生します。TLB のサイズは固定されているので、TLB ミスの発生率を減らすには Page サイズを大きくする必要があります。
Huge Page とは、4Ki より大きいメモリーページのことです。x86_64 アーキテクチャーでは、2Mi と 1Gi の 2 つが一般的な Huge Page サイズです。別のアーキテクチャーではサイズは異なります。Huge Page を使用するには、アプリケーションが認識できるようにコードを書き込む必要があります。Transparent Huge Pages (THP) は、アプリケーションによる認識なしに、Huge Page の管理を自動化しようとしますが、制約があります。特に、ページサイズは 2Mi に制限されます。THP では、THP のデフラグが原因で、メモリー使用率が高くなり、断片化が起こり、パフォーマンスの低下につながり、メモリーページがロックされてしまう可能性があります。このような理由から、アプリケーションは THP ではなく、事前割り当て済みの Huge Page を使用するように設計 (また推奨) される場合があります。
OpenShift Virtualization では、事前に割り当てられた Huge Page を使用できるように仮想マシンを設定できます。
8.15.7.3. 仮想マシンの Huge Page の設定
memory.hugepages.pageSize
および resources.requests.memory
パラメーターを仮想マシン設定に組み込み、仮想マシンを事前に割り当てられた Huge Page を使用するように設定できます。
メモリー要求はページサイズ別に分ける必要があります。たとえば、ページサイズ 1Gi
の場合に 500Mi
メモリーを要求することはできません。
ホストおよびゲスト OS のメモリーレイアウトには関連性がありません。仮想マシンマニフェストで要求される Huge Page が QEMU に適用されます。ゲスト内の Huge Page は、仮想マシンインスタンスの利用可能なメモリー量に基づいてのみ設定できます。
実行中の仮想マシンを編集する場合は、変更を有効にするために仮想マシンを再起動する必要があります。
前提条件
- ノードには、事前に割り当てられた Huge Page が設定されている必要がある。
手順
仮想マシン設定で、
resources.requests.memory
およびmemory.hugepages.pageSize
パラメーターをspec.domain
に追加します。以下の設定スニペットは、ページサイズが1Gi
の合計4Gi
メモリーを要求する仮想マシンについてのものです。kind: VirtualMachine ... spec: domain: resources: requests: memory: "4Gi" 1 memory: hugepages: pageSize: "1Gi" 2 ...
仮想マシン設定を適用します。
$ oc apply -f <virtual_machine>.yaml
8.15.8. 仮想マシン用の専用リソースの有効化
パフォーマンスを向上させるために、CPU などのノードリソースを仮想マシン専用に確保できます。
8.15.8.1. 専用リソースについて
仮想マシンの専用リソースを有効にする場合、仮想マシンのワークロードは他のプロセスで使用されない CPU でスケジュールされます。専用リソースを使用することで、仮想マシンのパフォーマンスとレイテンシーの予測の精度を向上させることができます。
8.15.8.2. 前提条件
-
CPU マネージャー はノードに設定される必要があります。仮想マシンのワークロードをスケジュールする前に、ノードに
cpumanager = true
ラベルが設定されていることを確認します。 - 仮想マシンの電源がオフになっていること。
8.15.8.3. 仮想マシンの専用リソースの有効化
Details タブで仮想マシンの専用リソースを有効にすることができます。Red Hat テンプレートまたはウィザードを使用して作成された仮想マシンは、専用のリソースで有効にできます。
手順
- サイドメニューから Workloads → Virtual Machines をクリックします。
- 仮想マシンを選択して、Virtual Machine タブを開きます。
- Details タブをクリックします。
- Dedicated Resources フィールドの右側にある鉛筆アイコンをクリックして、Dedicated Resources ウィンドウを開きます。
- Schedule this workload with dedicated resources (guaranteed policy) を選択します。
- Save をクリックします。
8.15.9. 仮想マシンのスケジュール
仮想マシンの CPU モデルとポリシー属性が、ノードがサポートする CPU モデルおよびポリシー属性との互換性について一致することを確認して、ノードで仮想マシン (VM) をスケジュールできます。
8.15.9.1. ポリシー属性
仮想マシン (VM) をスケジュールするには、ポリシー属性と、仮想マシンがノードでスケジュールされる際の互換性について一致する CPU 機能を指定します。仮想マシンに指定されるポリシー属性は、その仮想マシンをノードにスケジュールする方法を決定します。
ポリシー属性 | 説明 |
---|---|
force | 仮想マシンは強制的にノードでスケジュールされます。これは、ホストの CPU が仮想マシンの CPU に対応していない場合でも該当します。 |
require | 仮想マシンが特定の CPU モデルおよび機能仕様で設定されていない場合に仮想マシンに適用されるデフォルトのポリシー。このデフォルトポリシー属性または他のポリシー属性のいずれかを持つ CPU ノードの検出をサポートするようにノードが設定されていない場合、仮想マシンはそのノードでスケジュールされません。ホストの CPU が仮想マシンの CPU をサポートしているか、ハイパーバイザーが対応している CPU モデルをエミュレートできる必要があります。 |
optional | 仮想マシンがホストの物理マシンの CPU でサポートされている場合は、仮想マシンがノードに追加されます。 |
disable | 仮想マシンは CPU ノードの検出機能と共にスケジュールすることはできません。 |
forbid | この機能がホストの CPU でサポートされ、CPU ノード検出が有効になっている場合でも、仮想マシンはスケジュールされません。 |
8.15.9.2. ポリシー属性および CPU 機能の設定
それぞれの仮想マシン (VM) にポリシー属性および CPU 機能を設定して、これがポリシーおよび機能に従ってノードでスケジュールされるようにすることができます。設定する CPU 機能は、ホストの CPU によってサポートされ、またはハイパーバイザーがエミュレートされることを確認するために検証されます。
8.15.9.3. サポートされている CPU モデルでの仮想マシンのスケジューリング
仮想マシン(VM)の CPU モデルを設定して、CPU モデルがサポートされるノードにこれをスケジュールできます。
手順
仮想マシン設定ファイルの
domain
仕様を編集します。以下の例は、VM 向けに定義された特定の CPU モデルを示しています。apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: myvm spec: template: spec: domain: cpu: model: Conroe 1
- 1
- VM の CPU モデル。
8.15.9.4. ホストモデルでの仮想マシンのスケジューリング
仮想マシン (VM) の CPU モデルが host-model
に設定されている場合、仮想マシンはスケジュールされているノードの CPU モデルを継承します。
手順
仮想マシン設定ファイルの
domain
仕様を編集します。以下の例は、仮想マシン (VM) に指定されるhost-model
を示しています。apiVersion: kubevirt/v1alpha3 kind: VirtualMachine metadata: name: myvm spec: template: spec: domain: cpu: model: host-model 1
- 1
- スケジュールされるノードの CPU モデルを継承する仮想マシン。
8.15.10. PCI パススルーの設定
PCI (Peripheral Component Interconnect) パススルー機能を使用すると、仮想マシンからハードウェアデバイスにアクセスし、管理できます。PCI パススルーが設定されると、PCI デバイスはゲストオペレーティングシステムに物理的に接続されているかのように機能します。
クラスター管理者は、oc
コマンドラインインターフェース (CLI) を使用して、クラスターでの使用が許可されているホストデバイスを公開および管理できます。
8.15.10.1. PCI パススルー用ホストデバイスの準備について
CLI を使用して PCI パススルー用にホストデバイスを準備するには、MachineConfig
オブジェクトを作成し、カーネル引数を追加して、Input-Output Memory Management Unit (IOMMU) を有効にします。PCI デバイスを Virtual Function I/O (VFIO) ドライバーにバインドしてから、HyperConverged
カスタムリソース (CR) の permittedHostDevices
フィールドを編集してクラスター内で公開します。OpenShift Virtualization Operator を最初にインストールする場合、permittedHostDevices
の一覧は空になります。
CLI を使用してクラスターから PCI ホストデバイスを削除するには、HyperConverged
CR から PCI デバイス情報を削除します。
8.15.10.1.1. IOMMU ドライバーを有効にするためのカーネル引数の追加
カーネルの IOMMU (Input-Output Memory Management Unit) ドライバーを有効にするには、MachineConfig
オブジェクトを作成し、カーネル引数を追加します。
前提条件
- 作業用の OpenShift Container Platform クラスターに対する管理者権限が必要です。
- Intel または AMD CPU ハードウェア。
- Intel Virtualization Technology for Directed I/O 拡張または BIOS (Basic Input/Output System) の AMD IOMMU が有効にされている。
手順
カーネル引数を識別する
MachineConfig
オブジェクトを作成します。以下の例は、Intel CPU のカーネル引数を示しています。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker 1 name: 100-worker-iommu 2 spec: config: ignition: version: 3.2.0 kernelArguments: - intel_iommu=on 3 ...
新規
MachineConfig
オブジェクトを作成します。$ oc create -f 100-worker-kernel-arg-iommu.yaml
検証
新規
MachineConfig
オブジェクトが追加されていることを確認します。$ oc get MachineConfig
8.15.10.1.2. PCI デバイスの VFIO ドライバーへのバインディング
PCI デバイスを VFIO (Virtual Function I/O) ドライバーにバインドするには、各デバイスから vendor-ID
および device-ID
の値を取得し、これらの値で一覧を作成します。一覧を MachineConfig
オブジェクトに追加します。MachineConfig
Operator は、PCI デバイスを持つノードで /etc/modprobe.d/vfio.conf
を生成し、PCI デバイスを VFIO ドライバーにバインドします。
前提条件
- カーネル引数を CPU の IOMMU を有効にするために追加している。
手順
lspci
コマンドを実行して、PCI デバイスのvendor-ID
およびdevice-ID
を取得します。$ lspci -nnv | grep -i nvidia
出力例
02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)
Butane 設定ファイル
100-worker-vfiopci.bu
を作成し、PCI デバイスを VFIO ドライバーにバインドします。注記Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。
例
variant: openshift version: 4.10.0 metadata: name: 100-worker-vfiopci labels: machineconfiguration.openshift.io/role: worker 1 storage: files: - path: /etc/modprobe.d/vfio.conf mode: 0644 overwrite: true contents: inline: | options vfio-pci ids=10de:1eb8 2 - path: /etc/modules-load.d/vfio-pci.conf 3 mode: 0644 overwrite: true contents: inline: vfio-pci
Butane を使用して、ワーカーノードに配信される設定を含む
MachineConfig
オブジェクトファイル (100-worker-vfiopci.yaml
) を生成します。$ butane 100-worker-vfiopci.bu -o 100-worker-vfiopci.yaml
MachineConfig
オブジェクトをワーカーノードに適用します。$ oc apply -f 100-worker-vfiopci.yaml
MachineConfig
オブジェクトが追加されていることを確認します。$ oc get MachineConfig
出力例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.2.0 25h 00-worker d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.2.0 25h 01-master-container-runtime d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.2.0 25h 01-master-kubelet d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.2.0 25h 01-worker-container-runtime d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.2.0 25h 01-worker-kubelet d3da910bfa9f4b599af4ed7f5ac270d55950a3a1 3.2.0 25h 100-worker-iommu 3.2.0 30s 100-worker-vfiopci-configuration 3.2.0 30s
検証
VFIO ドライバーがロードされていることを確認します。
$ lspci -nnk -d 10de:
この出力では、VFIO ドライバーが使用されていることを確認します。
出力例
04:00.0 3D controller [0302]: NVIDIA Corporation GP102GL [Tesla P40] [10de:1eb8] (rev a1) Subsystem: NVIDIA Corporation Device [10de:1eb8] Kernel driver in use: vfio-pci Kernel modules: nouveau
8.15.10.1.3. CLI を使用したクラスターでの PCI ホストデバイスの公開
クラスターで PCI ホストデバイスを公開するには、PCI デバイスの詳細を HyperConverged
カスタムリソース (CR) の spec.permittedHostDevices.pciHostDevices
配列に追加します。
手順
以下のコマンドを実行して、デフォルトエディターで
HyperConverged
CR を編集します。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
PCI デバイス情報を
spec.permittedHostDevices.pciHostDevices
配列に追加します。以下に例を示します。設定ファイルのサンプル
apiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: permittedHostDevices: 1 pciHostDevices: 2 - pciDeviceSelector: "10DE:1DB6" 3 resourceName: "nvidia.com/GV100GL_Tesla_V100" 4 - pciDeviceSelector: "10DE:1EB8" resourceName: "nvidia.com/TU104GL_Tesla_T4" - pciDeviceSelector: "8086:6F54" resourceName: "intel.com/qat" externalResourceProvider: true 5 ...
注記上記のスニペットの例は、
nvidia.com/GV100GL_Tesla_V100
およびnvidia.com/TU104GL_Tesla_T4
という名前の 2 つの PCI ホストデバイスが、HyperConverged
CR の許可されたホストデバイスの一覧に追加されたことを示しています。これらのデバイスは、OpenShift Virtualization と動作することがテストおよび検証されています。- 変更を保存し、エディターを終了します。
検証
以下のコマンドを実行して、PCI ホストデバイスがノードに追加されたことを確認します。この出力例は、各デバイスが
nvidia.com/GV100GL_Tesla_V100
、nvidia.com/TU104GL_Tesla_T4
、およびintel.com/qat
のリソース名にそれぞれ関連付けられたデバイスが 1 つあることを示しています。$ oc describe node <node_name>
出力例
Capacity: cpu: 64 devices.kubevirt.io/kvm: 110 devices.kubevirt.io/tun: 110 devices.kubevirt.io/vhost-net: 110 ephemeral-storage: 915128Mi hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 131395264Ki nvidia.com/GV100GL_Tesla_V100 1 nvidia.com/TU104GL_Tesla_T4 1 intel.com/qat: 1 pods: 250 Allocatable: cpu: 63500m devices.kubevirt.io/kvm: 110 devices.kubevirt.io/tun: 110 devices.kubevirt.io/vhost-net: 110 ephemeral-storage: 863623130526 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 130244288Ki nvidia.com/GV100GL_Tesla_V100 1 nvidia.com/TU104GL_Tesla_T4 1 intel.com/qat: 1 pods: 250
8.15.10.1.4. CLI を使用したクラスターからの PCI ホストデバイスの削除
クラスターから PCI ホストデバイスを削除するには、HyperConverged
カスタムリソース (CR) からそのデバイスの情報を削除します。
手順
以下のコマンドを実行して、デフォルトエディターで
HyperConverged
CR を編集します。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
適切なデバイスの
pciDeviceSelector
、resourceName
、およびexternalResourceProvider
(該当する場合) のフィールドを削除して、spec.permittedHostDevices.pciHostDevices
配列から PCI デバイス情報を削除します。この例では、intel.com/qat
リソースが削除されました。設定ファイルのサンプル
apiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: permittedHostDevices: pciHostDevices: - pciDeviceSelector: "10DE:1DB6" resourceName: "nvidia.com/GV100GL_Tesla_V100" - pciDeviceSelector: "10DE:1EB8" resourceName: "nvidia.com/TU104GL_Tesla_T4" ...
- 変更を保存し、エディターを終了します。
検証
以下のコマンドを実行して、PCI ホストデバイスがノードから削除されたことを確認します。この出力例は、
intel.com/qat
リソース名に関連付けられているデバイスがゼロであることを示しています。$ oc describe node <node_name>
出力例
Capacity: cpu: 64 devices.kubevirt.io/kvm: 110 devices.kubevirt.io/tun: 110 devices.kubevirt.io/vhost-net: 110 ephemeral-storage: 915128Mi hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 131395264Ki nvidia.com/GV100GL_Tesla_V100 1 nvidia.com/TU104GL_Tesla_T4 1 intel.com/qat: 0 pods: 250 Allocatable: cpu: 63500m devices.kubevirt.io/kvm: 110 devices.kubevirt.io/tun: 110 devices.kubevirt.io/vhost-net: 110 ephemeral-storage: 863623130526 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 130244288Ki nvidia.com/GV100GL_Tesla_V100 1 nvidia.com/TU104GL_Tesla_T4 1 intel.com/qat: 0 pods: 250
8.15.10.2. PCI パススルー用の仮想マシンの設定
PCI デバイスがクラスターに追加された後に、それらを仮想マシンに割り当てることができます。PCI デバイスが仮想マシンに物理的に接続されているかのような状態で利用できるようになりました。
8.15.10.2.1. PCI デバイスの仮想マシンへの割り当て
PCI デバイスがクラスターで利用可能な場合、これを仮想マシンに割り当て、PCI パススルーを有効にすることができます。
手順
PCI デバイスをホストデバイスとして仮想マシンに割り当てます。
例
apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: domain: devices: hostDevices: - deviceName: nvidia.com/TU104GL_Tesla_T4 1 name: hostdevices1
- 1
- クラスターでホストデバイスとして許可される PCI デバイスの名前。仮想マシンがこのホストデバイスにアクセスできます。
検証
以下のコマンドを使用して、ホストデバイスが仮想マシンから利用可能であることを確認します。
$ lspci -nnk | grep NVIDIA
出力例
$ 02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)
8.15.10.3. 関連情報
8.15.11. 仮想 GPU パススルーの設定
仮想マシンは仮想 GPU (vGPU)ハードウェアにアクセスできます。仮想マシンに仮想 GPU を割り当てると、次のことが可能になります。
- 基盤となるハードウェアの GPU の一部にアクセスして、仮想マシンで高いパフォーマンスのメリットを実現する。
- リソースを大量に消費する I/O 操作を合理化する。
仮想 GPU パススルーは、ベアメタル環境で実行されているクラスターに接続されているデバイスにのみ割り当てることができます。
8.15.11.1. 仮想 GPU パススルーの仮想マシンへの割り当て
Open Shift Container Platform Web コンソールを使用して、仮想 GPU デバイスを仮想マシンに割り当てます。
前提条件
- クラスターと仮想マシンがベアメタル環境にデプロイされていることを確認します。現時点では、他の環境はサポートされていません。
手順
仮想 GPU デバイスを仮想マシンに割り当てます。
- Open Shift Container Platform Web コンソールで、サイドメニューからVirtualization → Virtual Machinesをクリックします。
- デバイスを割り当てる仮想マシンを選択します。
Detailsタブをクリックします。
- Hardware Devicesフィールドには、GPU デバイスとホストデバイスを追加または削除するためのリンクが含まれています。
- GPU デバイスを使用して仮想 GPU を割り当てると、接続されている仮想 GPU の VNC コンソールアクセスが有効になります。ホストデバイスを使用して仮想 GPU を割り当てても、VNC コンソールアクセスは有効になりません。
- マイナスアイコンを使用して、既存のハードウェアデバイスを削除します。
- 仮想マシンが停止している場合にのみ、仮想マシンにデバイスを追加または削除できます。
- 鉛筆アイコンをクリックし、ポップアップウィンドウを使用して、適切なハードウェアリソース名を選択してデバイスを追加または削除します。
- Save をクリックします。
-
YAMLタブをクリックして、クラスター設定の
hostDevices
セクションに新しいデバイスが追加されていることを確認します。
仮想マシンを作成するとき、またはカスタマイズするテンプレートを使用して仮想マシンを作成するときに、Open Shift Container Platform Web コンソールを使用してハードウェアデバイスを仮想マシンに追加できます。Windows 10 や RHEL 7 などの特定のオペレーティングシステム用に事前に提供されているブートソーステンプレートにデバイスを追加することはできません。
作成するカスタムテンプレートにハードウェアデバイスを追加または削除するには、Create Virtual MachineウィザードのAdvancedタブをクリックし、Hardware devicesをクリックします。マイナスアイコンを使用して、既存のハードウェアデバイスを削除します。仮想マシンが停止している場合にのみ、仮想マシンにデバイスを追加または削除できます。
クラスターに接続されているリソースを表示するには、サイドメニューからCompute → Hardware Devicesをクリックします。
8.15.11.2. 関連情報
8.15.12. 仲介デバイスの設定
HyperConverged
カスタムリソース(CR)でデバイスのリストを提供すると、Open Shift Virtualization は仮想 GPU (vGPU)などの仲介デバイスを自動的に作成します。
仲介デバイスの宣言型設定は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat テクノロジープレビュー機能のサポート範囲に関する情報は、「https://access.redhat.com/ja/support/offerings/techpreview」を参照してください。
8.15.12.1. 前提条件
ハードウェアベンダーがドライバーを提供している場合は、仲介デバイスを作成するノードにドライバーをインストールしている。
- NVIDIA カードを使用する場合は、NVIDIAGRID ドライバーをインストールしている。
8.15.12.2. OpenShift Virtualizationでの仮想 GPU の使用について
一部のグラフィックス処理ユニット(GPU)カードは、仮想 GPU (vGPU)の作成をサポートしています。管理者がHyperConverged
カスタムリソース(CR)で設定の詳細を提供すると、Open Shift Virtualization は仮想 GPU およびその他の仲介デバイスを自動的に作成できます。この自動化は、大規模なクラスターで特に役立ちます。
機能とサポートの詳細については、ハードウェアベンダーのドキュメントを参照してください。
- 仲介デバイス
- 1 つまたは複数の仮想デバイスに分割された物理デバイス。仮想 GPU は、仲介デバイス(mdev)の一種です。物理 GPU のパフォーマンスが、仮想デバイス間で分割されます。仲介デバイスを 1 つまたは複数の仮想マシン(VM)に割り当てることができますが、ゲストの数は GPU と互換性がある必要があります。一部の GPU は複数のゲストをサポートしていません。
8.15.12.2.1. 設定の概要
仲介デバイスを設定する場合、管理者は次のことを行う必要があります。
- 仲介デバイスを作成する。
- 仲介デバイスをクラスターに公開する。
HyperConverged
CR には、両方のタスクを実行する API が含まれています。
仲介デバイスの作成
... spec: mediatedDevicesConfiguration: mediatedDevicesTypes: 1 - <device_type> nodeMediatedDeviceTypes: 2 - mediatedDevicesTypes: 3 - <device_type> nodeSelector: 4 <node_selector_key>: <node_selector_value> ...
仲介デバイスのクラスターへの公開
...
permittedHostDevices:
mediatedDevices:
- mdevNameSelector: GRID T4-2Q 1
resourceName: nvidia.com/GRID_T4-2Q
...
- 1
- この値にマッピングする仲介デバイスをホスト上に公開します。注記
実際のシステムの正しい値に置き換えて、
/sys/bus/pci/devices/<slot>:<bus>:<domain>.<function>/mdev_supported_types/<type>/name
の内容を表示し、デバイスがサポートする仲介デバイスのタイプを確認できます。たとえば、
nvidia-231
タイプの name ファイルには、セレクター文字列GRID T4-2Q
が含まれます。GRID T4-2Q
をmdevNameSelector
値として使用することで、ノードはnvidia-231
タイプを使用できます。
8.15.12.2.2. 仮想 GPU がノードに割り当てられる方法
それぞれの物理デバイスについて、OpenShift Virtualization は以下の項目を設定します。
- 1 つのmdev タイプ。
- 選択した mdev タイプのインスタンスの最大数。
クラスターのアーキテクチャーは、デバイスの作成およびノードへの割り当て方法に影響します。
- ノードごとに複数のカードを持つ大規模なクラスター
同様の仮想 GPU タイプに対応する複数のカードを持つノードでは、関連するデバイス種別がラウンドロビン方式で作成されます。以下に例を示します。
... mediatedDevicesConfiguration: mediatedDevicesTypes: - nvidia-222 - nvidia-228 - nvidia-105 - nvidia-108 ...
このシナリオでは、各ノードに以下の仮想 GPU 種別に対応するカードが 2 つあります。
nvidia-105 ... nvidia-108 nvidia-217 nvidia-299 ...
各ノードで、OpenShift Virtualization は以下の項目を作成します。
- 最初のカード上に nvidia-105 タイプの 16 の仮想GPU
- 2 番目のカード上に nvidia-108 タイプの 2 つの仮想GPU
- 1 つのノードに、要求された複数の仮想 GPU タイプをサポートするカードが 1 つある
OpenShift Virtualization は、
mediatedDevicesTypes
一覧の最初のサポートされるタイプを使用します。たとえば、ノードのカードが
nvidia-223
およびnvidia-224
をサポートします。以下のmediatedDevicesTypes
一覧が設定されます。... mediatedDevicesConfiguration: mediatedDevicesTypes: - nvidia-22 - nvidia-223 - nvidia-224 ...
この例では、OpenShift Virtualization は
nvidia-223
タイプを使用します。
8.15.12.2.3. 仲介デバイスの変更および削除について
以下の場合に、OpenShift Virtualization はクラスターの仲介デバイス設定を更新します。
-
HyperConverged
CR を編集し、mediatedDevicesTypes
スタンザの内容を変更した。 -
nodeMediatedDeviceTypes
ノードセレクターに一致するノードラベルを変更した。 HyperConverged
CR のspec.mediatedDevicesConfiguration
およびspec.permittedHostDevices
スタンザからデバイス情報を削除した。注記spec.permittedHostDevices
スタンザからデバイス情報を削除したが、spec.mediatedDevicesConfiguration
スタンザからは削除しなかった場合、同じノードで新規の仲介デバイスタイプを作成することはできません。仲介デバイスを適切に削除するには、両方のスタンザからデバイス情報を削除します。
具体的な変更に応じて、これらのアクションにより、OpenShift Virtualization は仲介デバイスを再設定するか、クラスターノードからそれらを削除します。
8.15.12.3. 仲介デバイス用のホストの準備
仲介デバイスを設定する前に、IOMMU (Input-Output Memory Management Unit)ドライバーを有効にする必要があります。
8.15.12.3.1. IOMMU ドライバーを有効にするためのカーネル引数の追加
カーネルの IOMMU (Input-Output Memory Management Unit) ドライバーを有効にするには、MachineConfig
オブジェクトを作成し、カーネル引数を追加します。
前提条件
- 作業用の OpenShift Container Platform クラスターに対する管理者権限が必要です。
- Intel または AMD CPU ハードウェア。
- Intel Virtualization Technology for Directed I/O 拡張または BIOS (Basic Input/Output System) の AMD IOMMU が有効にされている。
手順
カーネル引数を識別する
MachineConfig
オブジェクトを作成します。以下の例は、Intel CPU のカーネル引数を示しています。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker 1 name: 100-worker-iommu 2 spec: config: ignition: version: 3.2.0 kernelArguments: - intel_iommu=on 3 ...
新規
MachineConfig
オブジェクトを作成します。$ oc create -f 100-worker-kernel-arg-iommu.yaml
検証
新規
MachineConfig
オブジェクトが追加されていることを確認します。$ oc get MachineConfig
8.15.12.4. 仲介デバイスの追加および削除
8.15.12.4.1. 仲介デバイスの作成および公開
HyperConverged
カスタムリソース(CR)を編集して、仮想 GPU (vGPU)などの仲介デバイスを公開し、作成できます。
前提条件
- IOMMU (Input-Output Memory Management Unit)ドライバーを有効にしている。
手順
以下のコマンドを実行して、デフォルトエディターで
HyperConverged
CR を編集します。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
仲介デバイス情報を
HyperConverged
CR のspec
に追加し、mediatedDevicesConfiguration
およびpermittedHostDevices
スタンザが含まれるようにします。以下に例を示します。設定ファイルのサンプル
apiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: mediatedDevicesConfiguration: 1 mediatedDevicesTypes: 2 - nvidia-231 nodeMediatedDeviceTypes: 3 - mediatedDevicesTypes: 4 - nvidia-233 nodeSelector: kubernetes.io/hostname: node-11.redhat.com permittedHostDevices: 5 mediatedDevices: - mdevNameSelector: GRID T4-2Q resourceName: nvidia.com/GRID_T4-2Q - mdevNameSelector: GRID T4-8Q resourceName: nvidia.com/GRID_T4-8Q ...
- 変更を保存し、エディターを終了します。
検証
以下のコマンドを実行して、デバイスが特定のノードに追加されたことを確認できます。
$ oc describe node <node_name>
8.15.12.4.2. CLI を使用したクラスターからの仲介デバイスの削除
クラスターから仲介デバイスを削除するには、HyperConverged
カスタムリソース (CR) からそのデバイスの情報を削除します。
手順
以下のコマンドを実行して、デフォルトエディターで
HyperConverged
CR を編集します。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
HyperConverged
CR のspec.mediatedDevicesConfiguration
およびspec.permittedHostDevices
スタンザからデバイス情報を削除します。両方のエントリーを削除すると、後で同じノードで新しい仲介デバイスタイプを作成できます。以下に例を示します。設定ファイルのサンプル
apiVersion: hco.kubevirt.io/v1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: mediatedDevicesConfiguration: mediatedDevicesTypes: 1 - nvidia-231 permittedHostDevices: mediatedDevices: 2 - mdevNameSelector: GRID T4-2Q resourceName: nvidia.com/GRID_T4-2Q
- 変更を保存し、エディターを終了します。
8.15.12.5. 仮想マシンへの仲介デバイスの割り当て
仮想 GPU (vGPU)などの仲介デバイスを仮想マシンに割り当てます。
前提条件
-
仲介デバイスが
HyperConverged
カスタムリソースで設定されている。
手順
VirtualMachine
マニフェストのspec.domain.devices.gpus
スタンザを編集して、仲介デバイスを仮想マシン(VM)に割り当てます。仮想マシンマニフェストの例
apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: domain: devices: gpus: - deviceName: nvidia.com/TU104GL_Tesla_T4 1 name: gpu1 2 - deviceName: nvidia.com/GRID_T4-1Q name: gpu2
検証
デバイスが仮想マシンで利用できることを確認するには、
<device_name>
をVirtualMachine
マニフェストのdeviceName
の値に置き換えて以下のコマンドを実行します。$ lspci -nnk | grep <device_name>
8.15.12.6. 関連情報
8.15.13. ウォッチドッグの設定
ウォッチドッグデバイスに仮想マシン (VM) を設定し、ウォッチドッグをインストールして、ウォッチドッグサービスを開始することで、ウォッチドッグを公開します。
8.15.13.1. 前提条件
-
仮想マシンで
i6300esb
ウォッチドッグデバイスのカーネルサポートが含まれている。Red Hat Enterprise Linux(RHEL)イメージが、i6300esb
をサポートしている。
8.15.13.2. ウォッチドッグデバイスの定義
オペレーティングシステム (OS) が応答しなくなるときにウォッチドッグがどのように進行するかを定義します。
表8.3 利用可能なアクション
|
仮想マシン (VM) の電源がすぐにオフになります。 |
| VM はその場で再起動し、ゲスト OS は反応できません。ゲスト OS の再起動に必要な時間の長さにより liveness プローブのタイムアウトが生じる可能性があるため、このオプションの使用は推奨されません。このタイムアウトにより、クラスターレベルの保護が liveness プローブの失敗に気づき、強制的に再スケジュールした場合に、VM の再起動にかかる時間が長くなる可能性があります。 |
| VM は、すべてのサービスを停止することにより、正常に電源を切ります。 |
手順
以下の内容を含む YAML ファイルを作成します。
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: labels: kubevirt.io/vm: vm2-rhel84-watchdog name: <vm-name> spec: running: false template: metadata: labels: kubevirt.io/vm: vm2-rhel84-watchdog spec: domain: devices: watchdog: name: <watchdog> i6300esb: action: "poweroff" 1 ...
- 1
watchdog
アクション (poweroff
、reset
、またはshutdown
) を指定します。
上記の例では、電源オフアクションを使用して、RHEL8 VM で
i6300esb
ウォッチドッグデバイスを設定し、デバイスを/dev/watchdog
として公開します。このデバイスは、ウォッチドッグバイナリーで使用できるようになりました。
以下のコマンドを実行して、YAML ファイルをクラスターに適用します。
$ oc apply -f <file_name>.yaml
検証
この手順は、ウォッチドッグ機能をテストするためにのみ提供されており、実稼働マシンでは実行しないでください。
以下のコマンドを実行して、VM がウォッチドッグデバイスに接続されていることを確認します。
$ lspci | grep watchdog -i
以下のコマンドのいずれかを実行して、ウォッチドッグがアクティブであることを確認します。
カーネルパニックをトリガーします。
# echo c > /proc/sysrq-trigger
ウォッチドッグサービスを終了します。
# pkill -9 watchdog
8.15.13.3. ウォッチドッグデバイスのインストール
仮想マシンに watchdog
パッケージをインストールして、ウォッチドッグサービスを起動します。
手順
root ユーザーとして、
watchdog
パッケージおよび依存関係をインストールします。# yum install watchdog
/etc/watchdog.conf
ファイルの以下の行のコメントを解除して、変更を保存します。#watchdog-device = /dev/watchdog
ウォッチドッグサービスが起動時に開始できるように有効化します。
# systemctl enable --now watchdog.service
8.15.13.4. 関連情報
8.15.14. 事前定義済みのブートソースの自動インポートおよび更新
バージョン 4.10 の時点で、手動で解除しない限り、OpenShift Virtualization は事前に定義されたブートソースを自動的にインポートおよび更新します。バージョン 4.9 以前の OpenShift Virtualization から4.10 にアップグレードし、以前のバージョンからの事前定義済みのブートソースがある場合、これらの事前定義済みのブートソースの自動インポートおよび更新を手動で選択する必要があります。
8.15.14.1. ブートソースの自動更新の有効化
OpenShift Virtualization 4.9 からの事前定義済みのブートソースがある場合は、手動でブートソースの自動更新を選択する必要があります。OpenShift Virtualization 4.10 以降からのすべての事前定義済みブートソースは、デフォルトで自動的に更新されます。
手順
以下のコマンドを使用して
dataImportCron
ラベルをデータソースに適用します。$ oc label --overwrite DataSource rhel8 -n openshift-virtualization-os-images cdi.kubevirt.io/dataImportCron=true
8.15.14.2. ブートソースの自動更新の無効化
非接続環境のログ数を減らしたり、リソースの使用量を減らしたりできます。そのためには、事前定義済みブートソースの自動インポートと更新を無効にします。HyperConverged
カスタムリソース(CR)の spec.featureGates.enableCommonBootImageImport
フィールドを false
に設定します。
カスタムブートソースは、この設定の影響を受けません。
手順
以下のコマンドを使用して自動更新を無効にします。
$ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", "value": false}]'
8.15.14.3. ブートソースの自動更新の再有効化
以前にブートソースの自動更新を無効にしている場合は、この機能を手動で再度有効にする必要があります。HyperConverged
カスタムリソース(CR)の spec.featureGates.enableCommonBootImageImport
フィールドを true
に設定します。
手順
以下のコマンドを使用して自動更新を再度有効にします。
$ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", "value": true}]'
8.15.14.4. カスタムブートソースでの自動更新の有効化
OpenShift Virtualization はデフォルトで事前に定義されたブートソースを自動的に更新しますが、カスタムブートソースは自動的に更新しません。HyperConverged
カスタムリソース(CR)を編集して、カスタムブートソースで自動インポートおよび更新を手動で有効にする必要があります。
手順
以下のコマンドを使用して、編集するために
HyperConverged
CR を開きます。$ oc edit -n openshift-cnv HyperConverged
適切なテンプレートおよびブートソースを
dataImportCronTemplates
セクションで指定して、HyperConverged
CR を編集します。以下に例を示します。CentOS 7 の例
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: dataImportCronTemplates: - metadata: name: centos7-image-cron annotations: cdi.kubevirt.io/storage.bind.immediate.requested: "true" 1 spec: schedule: "0 */12 * * *" 2 template: spec: source: registry: 3 url: docker://quay.io/containerdisks/centos:7-2009 storage: resources: requests: storage: 10Gi managedDataSource: centos7 4 retentionPolicy: "None" 5
- 1
- このアノテーションは、
volumeBindingMode
がWaitForFirstConsumer
に設定されたストレージクラスに必要です。 - 2
- cron 形式で指定されるジョブのスケジュール。
- 3
- レジストリーソースからデータボリュームを作成するのに使用します。
node
docker キャッシュに基づくデフォルトのnode
pullMethod
ではなく、デフォルトのpod
pullMethod
を使用します。node
docker キャッシュはレジストリーイメージがContainer.Image
で利用可能な場合に便利ですが、CDI インポーターはこれにアクセスすることは許可されていません。 - 4
- 利用可能なブートソースとして検出するカスタムイメージの場合、イメージの
managedDataSource
の名前が、仮想マシンテンプレート YAML ファイルのspec.dataVolumeTemplates.spec.sourceRef.name
にあるテンプレートのDataSource
の名前に一致する必要があります。 - 5
- cron ジョブが削除されたときにデータボリュームおよびデータソースを保持するには、
All
を使用します。cron ジョブが削除されたときにデータボリュームおよびデータソースを削除するには、None
を使用します。
8.15.15. 仮想マシンでの Descheduler エビクションの有効化
Descheduler を使用して Pod をエビクトし、Pod がより適切なノードに再スケジュールされるようにできます。Pod が仮想マシンである場合、Pod のエビクションにより、仮想マシンが別のノードにライブマイグレーションされます。
仮想マシンの Descheduler エビクションはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
8.15.15.1. Descheduler プロファイル
テクノロジープレビューの DevPreviewLongLifecycle
プロファイルを使用して、仮想マシンで Descheduler を有効にします。これは、現在 OpenShift Virtualization で利用可能な唯一の Descheduler プロファイルです。適切なスケジューリングを確保するには、予想される負荷に応じた CPU およびメモリー要求で仮想マシンを作成します。
DevPreviewLongLifecycle
このプロファイルは、ノード間のリソース使用状況のバランスを取り、以下のストラテジーを有効にします。
-
RemovePodsHavingTooManyRestarts
: コンテナが何度も再起動された Pod、およびすべてのコンテナー(Init コンテナーを含む)の再起動の合計が 100 を超える Pod を削除します。仮想マシンのゲストオペレーティングシステムを再起動しても、この数は増えません。 LowNodeUtilization
: 使用率の低いノードがある場合に、使用率の高いノードから Pod をエビクトします。エビクトされた Pod の宛先ノードはスケジューラーによって決定されます。- ノードは、使用率がすべてしきい値 (CPU、メモリー、Pod の数) について 20% 未満の場合に使用率が低いと見なされます。
- ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) について 50% を超える場合に過剰に使用されていると見なされます。
-
8.15.15.2. Descheduler のインストール
Descheduler はデフォルトで利用できません。Descheduler を有効にするには、Kube Descheduler Operator を OperatorHub からインストールし、1 つ以上の Descheduler プロファイルを有効にする必要があります。
前提条件
- クラスター管理者の権限。
- OpenShift Container Platform Web コンソールへのアクセス。
手順
- OpenShift Container Platform Web コンソールにログインします。
Kube Descheduler Operator に必要な namespace を作成します。
- Administration → Namespaces に移動し、Create Namespace をクリックします。
-
Name フィールドに
openshift-kube-descheduler-operator
を入力し、Labels フィールドにopenshift.io/cluster-monitoring=true
を入力して Descheduler メトリクスを有効にし、Create をクリックします。
Kube Descheduler Operator をインストールします。
- Operators → OperatorHub に移動します。
- Kube Descheduler Operator をフィルターボックスに入力します。
- Kube Descheduler Operator を選択し、Install をクリックします。
- Install Operator ページで、A specific namespace on the cluster を選択します。ドロップダウンメニューから openshift-kube-descheduler-operator を選択します。
- Update Channel および Approval Strategy の値を必要な値に調整します。
- Install をクリックします。
Descheduler インスタンスを作成します。
- Operators → Installed Operators ページから、 Kube Descheduler Operator をクリックします。
- Kube Descheduler タブを選択し、Create KubeDescheduler をクリックします。
必要に応じて設定を編集します。
Profiles セクションを展開し、
DevPreviewLongLifecycle
を選択します。AffinityAndTaints
プロファイルがデフォルトで有効になっています。重要OpenShift Virtualization で現在利用できるプロファイルは
DevPreviewLongLifecycle
のみです。
また、後で OpenShift CLI (oc
)を使用して、Descheduler のプロファイルおよび設定を設定することもできます。
8.15.15.3. 仮想マシン(VM)での Descheduler エビクションの有効化
Descheduler のインストール後に、アノテーションを VirtualMachine
カスタムリソース(CR)に追加して Descheduler エビクションを仮想マシンで有効にできます。
前提条件
-
Descheduler を OpenShift Container Platform Web コンソールまたは OpenShift CLI (
oc
)にインストールしている。 - 仮想マシンが実行されていないことを確認します。
手順
仮想マシンを起動する前に、
Descheduler.alpha.kubernetes.io/evict
アノテーションをVirtualMachine
CR に追加します。apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: template: metadata: annotations: descheduler.alpha.kubernetes.io/evict: "true"
インストール時に Web コンソールで
DevPreviewLongLifecycle
プロファイルをまだ設定していない場合は、KubeDescheduler
オブジェクトのspec.profile
セクションにDevPreviewLongLifecycle
を指定します。apiVersion: operator.openshift.io/v1 kind: KubeDescheduler metadata: name: cluster namespace: openshift-kube-descheduler-operator spec: deschedulingIntervalSeconds: 3600 profiles: - DevPreviewLongLifecycle
Descheduler が仮想マシンで有効になりました。
8.15.15.4. 関連情報
8.16. 仮想マシンのインポート
8.16.1. データボリュームインポートの TLS 証明書
8.16.1.1. データボリュームインポートの認証に使用する TLS 証明書の追加
ソースからデータをインポートするには、レジストリーまたは HTTPS エンドポイントの TLS 証明書を設定マップに追加する必要があります。この設定マップは、宛先データボリュームの namespace に存在する必要があります。
TLS 証明書の相対パスを参照して設定マップ を作成します。
手順
正しい namespace にあることを確認します。設定マップは、同じ namespace にある場合にデータボリュームによってのみ参照されます。
$ oc get ns
設定マップを作成します。
$ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>
8.16.1.2. 例: TLS 証明書から作成される設定マップ
以下は、ca.pem
TLS 証明書で作成される設定マップの例です。
apiVersion: v1 kind: ConfigMap metadata: name: tls-certs data: ca.pem: | -----BEGIN CERTIFICATE----- ... <base64 encoded cert> ... -----END CERTIFICATE-----
8.16.2. データボリュームの使用による仮想マシンイメージのインポート
Containerized Data Importer (CDI) を使用し、データボリュームを使用して仮想マシンイメージを永続ボリューム要求 (PVC) にインポートします。次に、データボリュームを永続ストレージの仮想マシンに割り当てることができます。
仮想マシンイメージは、HTTP または HTTPS エンドポイントでホストするか、またはコンテナーディスクに組み込み、コンテナーレジストリーで保存できます。
ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。
サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムによって異なります。詳細は、該当するオペレーティングシステムのドキュメントを参照してください。
8.16.2.1. 前提条件
- エンドポイントに TLS 証明書が必要な場合、証明書はデータボリュームと同じ namespace の設定 マップに組み込む必要があり、これはデータボリューム設定で参照され ます。
コンテナーディスクをインポートするには、以下を実行すること。
- 仮想マシンイメージからコンテナーディスクを準備 し、これをコンテナーレジストリーに保存してからインポートする必要がある場合があります。
-
コンテナーレジストリーに TLS がない場合、レジストリーを
HyperConverged
カスタムリソースのinsecureRegistries
フィールドに追加し、ここからコンテナーディスクをインポートする必要があります。
- この操作を正常に実行するため には、ストレージクラスを定義するか、CDI スクラッチ領域を用意 する必要がある場合があります。
8.16.2.2. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
CDI は OpenShift Container Platform の クラスター全体のプロキシー設定 を使用するようになりました。
8.16.2.3. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
8.16.2.4. データボリュームの使用による永続ボリューム要求 (PVC) への仮想マシンイメージのインポート
データボリュームを使用して、仮想マシンイメージを永続ボリューム要求 (PVC) にインポートすることができます。
仮想マシンイメージは、HTTP または HTTPS エンドポイントでホストするか、またはイメージをコンテナーディスクに組み込み、コンテナーレジストリーで保存できます。
インポートされたイメージから仮想マシンを作成するには、仮想マシンを作成する前にイメージまたはコンテナーディスクのエンドポイントを VirtualMachine
設定ファイルに指定します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - クラスターには、少なくとも 1 つの利用可能な永続ボリュームがあること。
仮想マシンイメージをインポートするには、以下が必要である。
-
RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで
xz
またはgz
を使用して圧縮される)。 -
イメージがデータソースにアクセスするために必要な認証情報と共にホストされる HTTP エンドポイント。例:
http://www.example.com/path/to/data
-
RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで
コンテナーディスクをインポートするには、以下が必要である。
-
データソースにアクセスするために必要な認証情報と共に、コンテナーイメージレジストリーに保存されている仮想マシンイメージからビルドされたコンテナーディスク。例:
docker://registry.example.com/container-image
-
データソースにアクセスするために必要な認証情報と共に、コンテナーイメージレジストリーに保存されている仮想マシンイメージからビルドされたコンテナーディスク。例:
手順
オプション: データソースに認証情報が必要な場合、
endpoint-secret.yaml
ファイルを編集し、更新された設定をクラスターに適用します。apiVersion: v1 kind: Secret metadata: name: <endpoint-secret> labels: app: containerized-data-importer type: Opaque data: accessKeyId: "" 1 secretKey: "" 2
$ oc apply -f endpoint-secret.yaml
仮想マシン設定ファイルを編集し、インポートする必要のある仮想マシンイメージのデータソースを指定します。この例では、
http
ソースから Fedora イメージがインポートされます。apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: creationTimestamp: null labels: kubevirt.io/vm: vm-fedora-datavolume name: vm-fedora-datavolume spec: dataVolumeTemplates: - metadata: creationTimestamp: null name: fedora-dv spec: pvc: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: local source: http: 1 url: "https://download.fedoraproject.org/pub/fedora/linux/releases/33/Cloud/x86_64/images/Fedora-Cloud-Base-33-1.2.x86_64.qcow2" 2 secretRef: "" 3 certConfigMap: "" 4 status: {} running: true template: metadata: creationTimestamp: null labels: kubevirt.io/vm: vm-fedora-datavolume spec: domain: devices: disks: - disk: bus: virtio name: datavolumedisk1 machine: type: "" 5 resources: requests: memory: 1.5Gi terminationGracePeriodSeconds: 180 volumes: - dataVolume: name: fedora-dv name: datavolumedisk1 status: {}
- 1
- イメージのインポート元となるソースタイプ。この例では、HTTP エンドポイントを使用します。レジストリーからコンテナーディスクをインポートするには、
http
をregistry
に置き換えます。 - 2
- インポートする必要のある仮想マシンイメージのソース。この例では、HTTP エンドポイントで仮想マシンイメージを参照します。コンテナーレジストリーエンドポイントのサンプルは
url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest"
です。 - 3
secretRef
パラメーターはオプションです。- 4
certConfigMap
は、自己署名証明書またはシステム CA バンドルで署名されていない証明書を使用するサーバーと通信するために必要です。参照される設定マップはデータボリュームと同じ namespace にある必要があります。- 5
type: dataVolume
またはtype: ""
を指定します。persistentVolumeClaim
などのtype
に他の値を指定すると、警告が表示され、仮想マシンは起動しません。
仮想マシンを作成します。
$ oc create -f vm-<name>-datavolume.yaml
注記oc create
コマンドは、データボリュームおよび仮想マシンを作成します。CDI コントローラーは適切なアノテーションを使って基礎となる PVC を作成し、インポートプロセスが開始されます。インポートが完了すると、データボリュームのステータスはSucceeded
に変更され、仮想マシンの起動が可能になります。データボリュームのプロビジョニングはバックグランドで実行されるため、これをモニターする必要はありません。仮想マシンは起動できますが、これはインポートが完了するまで実行されません。
検証
インポーター Pod は指定された URL から仮想マシンイメージまたはコンテナーディスクをダウンロードし、これをプロビジョニングされた PV に保存します。以下のコマンドを実行してインポーター Pod のステータスを確認します。
$ oc get pods
以下のコマンドを実行し、
Succeeded
が表示されるまでデータボリュームのステータスをモニターします。$ oc describe dv <datavolume-name> 1
- 1
- 仮想マシン設定ファイルの
dataVolumeTemplates.metadata.name
で指定されるデータボリュームの名前。上記の設定例では、これはfedora-dv
です。
プロビジョニングが完了し、VMI が起動したことを検証するには、以下のコマンドを実行してそのシリアルコンソールへのアクセスを試行します。
$ virtctl console <vm-fedora-datavolume>
8.16.2.5. 関連情報
- 事前割り当てモードを設定 して、データボリューム操作の書き込みパフォーマンスを向上します。
8.16.3. データボリュームの使用による仮想マシンイメージのブロックストレージへのインポート
既存の仮想マシンイメージは OpenShift Container Platform クラスターにインポートできます。OpenShift Virtualization はデータボリュームを使用してデータのインポートおよび基礎となる永続ボリューム要求 (PVC) の作成を自動化します。
ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。
サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムに