Red Hatでソリューションアーキテクトをしている田中司恩(@tnk4on)です。 この連載はvSphere環境上にOpenShift Container Platform（以下、OpenShift）およびOpenShift Virtualizationの環境を構築する方法を解説するシリーズです。
第4回はOpenShift Virtualizationのインストールと実行方法について解説します。今後の連載予定は下記の通りです。
- 第1回：OpenShiftのインストール
- 第2回：OpenShiftインストール後の作業
- 第3回：共有ストレージの作成（NFS CSIドライバーの構築）
- 第4回：OpenShift Virtualizationのインストールと実行（←本記事）
- 第5回：vSphere仮想マシンの移行
- 【番外編】：共有ストレージの作成（NFSプロビジョナーの構築）
-目次-
- OpenShift Virtualizationのインストールと実行方法
- 前提条件
- 1. OpenShift Virtualizationのインストール
- 2. 追加のOpenShiftの設定変更
- 3. CLIツール（virtctl）のインストール
- 4. 仮想マシンの作成（インスタンスタイプから作成）
- 5. 仮想マシンの作成（テンプレートから作成）
- 6. 仮想マシンの起動と停止
- 7. 仮想マシンのライブマイグレーション
- まとめ
OpenShift Virtualizationのインストールと実行方法
本記事では OpenShift Virtualizationのインストールと実行方法について、下記の内容を紹介します。
- OpenShift Virtualizationのインストール
- 追加のOpenShiftの設定変更
- CLIツール（virtctl）のインストール
- 仮想マシンの作成（インスタンスタイプから作成）
- 仮想マシンの作成（テンプレートから作成）
- 仮想マシンの起動と停止
- 仮想マシンのライブマイグレーション
OpenShift Virtualizationではインスタンスタイプから作成する方法とテンプレートカタログから作成する方法の2種類の仮想マシンの作成方法があります。 本記事において、インスタンスタイプから作成する方法ではRHEL 9の仮想マシンの作成方法を、テンプレートカタログから作成する方法ではWindows Server 2022の仮想マシンの作成方法を紹介します。
リファレンス実装ガイド
OpenShift Virtualizationの構成のための参考情報として、リファレンス実装ガイド（英語）が公開されています。 最小構成の3ノード構成から大規模構成まで、ハードウェアの構成のための参考となる情報が記載されています。 実稼働環境でのサイジングの参考にしてください。
OpenShift Virtualization - リファレンス実装ガイド - Red Hat Customer Portal
サポート対象のゲストオペレーティングシステム
OpenShift VirtualizationがサポートするゲストOSのリストは下記のページに記載があります。
RHELとWindows（クライアントOSおよびServer OS）について記載があり、それ以外のOSについては、Red Hatのサードパーティのソフトウェアサポートポリシー*1に従ってサポートされます。
Windows Server OSのサポートはMicrosoft SVVPにて認定されています。 なお、Microsoft SVVPではクライアントOSの認定はないため、たとえばWindows 11はWindows Server 2022と同様にサポートされます。
前提条件
- 連載第3回の作業を完了していることとします
- 全体の構成や各パラメーターなどは第1回を参照してください
- 作業用端末のプロンプトは
%とします - 踏み台サーバーのプロンプトは
$とします - 踏み台サーバーの作業は明示的に記載がある場合を除いて、作業ディレクトリ
${HOME}/workで作業することとします
1. OpenShift Virtualizationのインストール
1-1 インストールの概要
OpenShift Virtualizationのインストールは、Operatorを使用して行います。Operatorとは、Kubernetes上でアプリケーションやサービスのライフサイクル管理を自動化するためのカスタムリソースです。
Operatorを使ったインストールは、OpenShift上のOperator Hubメニューから実施します。Operator HubはOpenShiftに統合された機能のひとつで、リストされたOperatorの中から選択したものを簡単にOpenShift上に追加できるカタログ機能です。これにより、OpenShift自体の機能追加や、その他のミドルウェアアプリケーションの導入が容易になります。
Operatorを使ったOpenShift Virtualizationのインストールの流れは下記の通りです。
- OpenShift Virtualization Operatorのインストール
- HyperConvergedの作成*2
OpenShift Virtualization OperatorおよびHyperConverged Operatorを構成する各コンポーネントの詳細は、下記のドキュメントを参照してください。
1.3. OpenShift Virtualization アーキテクチャー | Red Hat Product Documentation
1-2 インストールの前提条件
OpenShift Virtualizationを実行するためには、仮想マシンの実行元となるコンピュートノードには物理（ベアメタル）サーバーが必要です。 オンプレ以外のクラウド環境では、AWSまたはIBM Cloud（Tech Preview）がサポートプラットフォームです。 OpenShift Virtualizationのサポート対象のプラットフォームについては下記のドキュメントを参照してください。
なお、本連載ではvSphere仮想環境を使った最小構成での検証環境構築を目的としています。 そのため本来必要な物理サーバーではなく、仮想マシン上のコンピュートノード（今回は3ノード構成のためコントロールプレーンと兼用）上で実行します。 物理サーバーを用意できる場合は、実稼働環境と同様に物理サーバー上に直接OpenShiftをインストールしてご利用ください。
1-3 OpenShift Virtualization Operatorのインストール
ここからOpenShift Virtualizationの具体的なインストール作業を開始します。 対象のドキュメントは下記を参照してください。
4.2. OpenShift virtualization のインストール | Red Hat Product Documentation
OpenShiftのWebコンソールから「Operator>Operator Hub」メニューを選択します。 Operator Hubの一覧画面が表示されます。ここではRed Hatの提供Operatorだけでなく、Red Hatパートナーやコミュニティ提供のOperatorも表示されます。
キーワードの入力欄にopenshift virtと入力するとフィルタリングされて「OpenShift Virtualization」と「Migration Toolkit for Virtualization Operator」の2つが表示されます。
ここでは「OpenShift Virtualization」を選択します。なお、Migration Toolkit for Virtualization Operatorは連載第5回でインストールを行います。
チャネルとバージョンはデフォルト表示のままで「インストール」を押します。
インストールの詳細入力画面が開きます。ここでもデフォルト表示のままインストールを押します。 なお、（HC）OpenShift Virtualization Deploymentが必須となっていますが、これは後ほどインストールするのでそのまま無視します。
- 更新チャネル：stable（stable以外にはdev-perviewがある）
- バージョン：4.16.0（本記事執筆時点では「4.16.0」が最新）
- インストールモード：クラスターの特定のnamespace
- インストール済みのnamespace：Operator推奨のnamespace:openshift-cnv*3
- 更新の承認：自動
OpenShift Virtualization Operatorのインストールが開始します。環境にもよりますが、インストールの完了まで3分半から4分程度かかります。インストールの完了までそのままでお待ちください。なお、インストール自体はバックグラウンドで継続されるため、他の画面に遷移しても問題ありません。
インストールが完了すると「HyperConvergedの作成」ボタンが表示されます。これを押して次のステップに進みます。
1-4 HyperConvergedの作成
先のステップで「HyperConvergedの作成」ボタンを押すと、「HyperConvergedの作成画面」が表示されます。
この「HyperConvergedの作成画面」は、Webコンソールのメニューから「Operator>インストール済みのOperator>OpenShift Virtualization」を選択して表示される画面上の、「HyperConvergedの作成」ボタンを押した後に出る画面と同じものです。別の画面に遷移した場合はここから作業を継続してください。
「HyperConvergedの作成画面」でフォームビューのまま一番下にスクロールし、すべてのパラメーターはデフォルトのままで「作成」を押します。
「作成」ボタンを押した後は自動で「インストール済みのOperator>Operatorの詳細画面」から、OpenShift Virtualization Deploymentのタブが選択された状態の画面に遷移します。
インストールが進むにつれステータスの表示が変わります。ここも環境によりますが、完了まで4分ほどかかりますのでまでそのまま待機します。
インストールの完了後、画面上部にポップアップ画面が表示されます。ポップアップ画面内の「Webコンソールの更新」のリンクを押す、またはブラウザをリロードします。
画面の更新後、Webコンソールのメニュー内に「Virtualization」の項目が追加されています。
Webコンソールのメニューから「Virtualization>Overview」を選択します。初回アクセス時は「Welcome to OpenShift Virtualization」の画面が表示されます。「Do not show this again」のチェックボックスを選択すると次回からは表示されません。
1-5 インストール後の確認
OpenShift Virtuzalizationのインストールの確認を行います。
（1）カタログ画面の確認
Webコンソールのメニューから「Virtualization>Catalog」を選択します。
ここでは仮想マシンの作成時に使用する起動ボリュームやテンプレートカタログが選択できます。 カタログ画面のデフォルトは「InstanceTypes」のタブが選択されており、ここでは起動ボリュームからOSを作成できます。 初期状態では「CentOS Stream 8、CentOS Stream 9、CentOS 7、Fedora、RHEL 8、RHEL 9」が用意されています。
なお、これらの起動ボリュームはHyperConvergedの作成直後は登録されておらず、バックグラウンドで追加の処理が自動で行われます。
この自動追加処理は起動ボリュームの元になる「コンテナーディスク」をインターネット上からダウンロードし、PVCおよびPVとして追加が行われます。
コンテナーディスクとは、OpenShift Virtualizationの仮想マシンの作成元となるOSのインストール済みのイメージのことです。コンテナーディスクは初期で登録されたもの以外に、ユーザーが任意でカスタムイメージを作成できます。作成手順は下記のドキュメントを参照ください。
なお、このコンテナーディスクはコンテナイメージとして作成、配布を行いますが、「bootc（Image mode for RHELの基礎技術）」とは異なるイメージ形式です。混同しないようにご注意ください。
（2）コンテナーディスクの確認
Webコンソールのメニューから「ストレージ>PersistentVolumeClaims」を選択します。 プロジェクトの選択から「openshift-virtualization-os-images」を選択することで表示をフィルタリングできます。 カタログ画面で確認した起動ボリュームに対応するPVCおよびPVが登録されているのが確認できます。
踏み台サーバー上で下記のコマンドを実行すると、作成されたPVの実ディレクトリの中身を確認できます。
起動ボリュームのPVはディレクトリ配下にdisk.imgを持つ形式で保存されていることがわかります。
$ tree /mnt/nfs/ | grep -E 'disk.img|pvc-'
├── pvc-7843e9b5-03d2-41b2-a7b8-2fd95399dde3
│ └── disk.img
├── pvc-8899284c-25c4-4dd9-8a90-47875bbc9cf5
│ └── disk.img
├── pvc-b3c88568-404c-40c1-a4c8-d252b804a9fc
├── pvc-ba1e3638-e52b-45f9-aa10-3c89a34536b8
│ └── disk.img
├── pvc-e141698e-886e-4eee-a89c-40acf0813b4a
│ └── disk.img
├── pvc-e21e08d2-9621-4d54-895b-07059f1a0942
│ └── disk.img
└── pvc-f72ca6c3-39ec-46bf-9900-6f2e95ba5c74
└── disk.img
OpenShift Virtualizationのインストールが確認できたので、次のステップ以降では仮想マシンのインストールを行います。
2. 追加のOpenShiftの設定変更
本連載で構築する環境では、追加でいくつかの設定変更を行います。
2-1 クローンストラテジーの変更
OpenShift Virtualizationのデフォルト設定では、仮想マシンの作成時にスナップショットを使った起動ボリュームのクローンを行います。 ストレージのCSIドライバーがスナップショットに対応している場合はその機能が使われます。 連載第3回で導入したNFS CSIドライバーはスナップショットに対応していますが、そのバックエンドはLinuxで構築した汎用的なNFSサーバーをしています。そのためデフォルトの設定のままでは仮想マシンの作成に非常に時間がかかり、また仮想マシンの作成に失敗することが分かりました。
クローンストラテジーの設定は下記のコマンドで確認できます。
specの設定は空ですが、デフォルトではcloneStrategy: snapshotが設定されていることがstatusの内容から分かります。
確認コマンド
$ oc get storageprofiles nfs-csi -o yaml
確認コマンドと結果（一部省略）
$ oc get storageprofiles nfs-csi -o yaml
apiVersion: cdi.kubevirt.io/v1beta1
kind: StorageProfile
...
spec: {}
status:
claimPropertySets:
- accessModes:
- ReadWriteMany
volumeMode: Filesystem
cloneStrategy: snapshot
dataImportCronSourceFormat: pvc
provisioner: nfs.csi.k8s.io
snapshotClass: csi-nfs-snapclass
storageClass: nfs-csi
...
本連載ではこの設定をsnaphostからcopyに変更します。これにより、仮想マシンの作成時に起動ボリュームを元に、単純なファイルコピーによるクローンが実行されます。
なお、この変更は本連載の環境で確実に動作させることを目的としており実稼働環境で必ずしも推奨するものではありません。実稼働環境におけるクローンストラテジーの設定は、お使いのストレージやストレージ用CSIドライバーで最適なものを採用ください。詳細は各ストレージベンダーにお問い合わせください。
クローンストラテジーの設定変更コマンドは下記です。
実行コマンド
$ oc patch storageprofile nfs-csi --type=merge -p '{"spec": {"cloneStrategy": "copy"}}'
実行コマンドと結果
$ oc patch storageprofile nfs-csi --type=merge -p '{"spec": {"cloneStrategy": "copy"}}'
storageprofile.cdi.kubevirt.io/nfs-csi patched
コマンド実行後は下記のように設定内容が変更されます。
確認コマンド
$ oc get storageprofiles nfs-csi -o yaml
確認コマンドと結果（一部省略）
$ oc get storageprofiles nfs-csi -o yaml
apiVersion: cdi.kubevirt.io/v1beta1
kind: StorageProfile
...
spec:
cloneStrategy: copy
status:
claimPropertySets:
- accessModes:
- ReadWriteMany
volumeMode: Filesystem
cloneStrategy: copy
dataImportCronSourceFormat: pvc
provisioner: nfs.csi.k8s.io
snapshotClass: csi-nfs-snapclass
storageClass: nfs-csi
...
2-2（OpenShift v4.16.0-v4.16.3限定）Console Operatorが再起動を繰り返すバグの修正
OpenShift v4.16.0からv4.16.3にはConsole OperatorのPodが頻繁に再起動を繰り返すバグがあります。
このバグのKCSは下記です。
Console keeps deploying frequently in OpenShift 4.16 - Red Hat Customer Portal
このバグの影響により、OpenShift Virtualizationのコンソール画面が頻繁に切れるという現象が発生します。 すでにOpenShift v4.16.4で修正リリースが行われていますが、v4.16.0からv4.16.3のバージョンを使っている場合は下記のワークアラウンドのコマンドを実行してください。 なお、該当バージョン以外（たとえばv4.15.x）では実行は不要です。
実行コマンド
$ oc create configmap cluster-monitoring-config -n openshift-monitoring --from-literal=config.yaml='telemeterClient: enabled: false'
実行コマンドと結果
$ oc create configmap cluster-monitoring-config -n openshift-monitoring --from-literal=config.yaml='telemeterClient: enabled: false' configmap/cluster-monitoring-config created
確認コマンド
$ oc get configmap -n openshift-monitoring cluster-monitoring-config -o yaml
apiVersion: v1
data:
config.yaml: |-
telemeterClient:
enabled: false
kind: ConfigMap
metadata:
creationTimestamp: "2024-07-25T18:49:01Z"
name: cluster-monitoring-config
namespace: openshift-monitoring
resourceVersion: "3138283"
uid: 1f475c16-42b0-4dfb-baa1-5040f8d9ab07
2-3 ライブマイグレーション用ワークアラウンドの実施
OpenShift v4.16でOpenShift Virtualizationをインストールする際、デフォルトではOpenShift Virtualization v4.16.0が選択されます（本記事執筆時点）。 OpenShift Virtualization v4.16.0で使用されるlibvirtに問題があり、特定の環境でライブマイグレーションに失敗します。 今回の検証環境ではNested環境でOpenShift Virtualizationの仮想マシンを実行しているためか、この問題が発生します。
バグの特定とアップストリームでの修正は行われていますが、OpenShiftとしての修正リリースはまだです。
そこで、本記事ではCPUモデルにhost-passthroughを指定することでワークアラウンドを実施しこの問題に対応します。
このワークアラウンドはRed Hatが公式に出しているものではありません。ご注意ください。
このワークアラウンドは同一ホスト上の仮想マシン同士であれば同じCPUを利用するので、host-passthroughの設定でも問題なくライブマイグレーションできることを利用しています。*4
この設定はkubevirt-hyperconvergedカスタムリソースに設定するため、グローバル設定となります。
個別の仮想マシンごとに設定を行いたい場合は、VirtualMachineカスタムリソースに個別に設定してください。
まず、既存の設定を確認します。デフォルトでは設定はないためnullになります。
$ oc get -n openshift-cnv hco kubevirt-hyperconverged -o json | jq .spec.defaultCPUModel null
ワークアラウンドの追加は下記のコマンドを実行します。
実行コマンド
$ oc patch -n openshift-cnv hco kubevirt-hyperconverged --type=json -p '[{"op": "add", "path": "/spec/defaultCPUModel", "value": "host-passthrough"}]'
実行コマンドと結果
$ oc patch -n openshift-cnv hco kubevirt-hyperconverged --type=json -p '[{"op": "add", "path": "/spec/defaultCPUModel", "value": "host-passthrough"}]'
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched
設定が反映されたか確認します。
実行コマンド
$ oc get -n openshift-cnv hco kubevirt-hyperconverged -o json | jq .spec.defaultCPUModel
実行コマンドと結果
$ oc get -n openshift-cnv hco kubevirt-hyperconverged -o json | jq .spec.defaultCPUModel "host-passthrough"
このグローバル設定は、各仮想マシンの起動時に読み込まれて仮想マシンに設定が反映されます。仮想マシンの起動時に設定変更した場合は、仮想マシンを再起動して反映してください。
仮想マシンの設定状況を確認するには、VirtualMachineInstanceカスタムリソースの設定を確認します。
仮想マシン名：rhel-9-salmon-parrotfish-27の設定を確認するコマンドは下記になります。
実行コマンド
$ oc get vmi -n ocp-virt rhel-9-salmon-parrotfish-27 -o json | jq .spec.domain.cpu.model
デフォルトの設定値の場合（host-modelが設定されている）
$ oc get vmi -n ocp-virt rhel-9-salmon-parrotfish-27 -o json | jq .spec.domain.cpu.model "host-model"
ワークアラウンドの設定後（host-passthroughが設定されている）
$ oc get vmi -n ocp-virt rhel-9-salmon-parrotfish-27 -o json | jq .spec.domain.cpu.model "host-passthrough"
3. CLIツール（virtctl）のインストール
仮想マシンの作成の前に、作業で利用するCLIツール「virtctl」をインストールします。 virtctlを使うことでOpenShift Virtualizationの操作をCLIで行うことができます。 virtctlのインストール方法や対応しているコマンドは下記のドキュメントを参照してください。
3-1 virtctlのインストール
Webコンソールのメニューから「Virtualization>Overview」を選択します。 Overview画面の右上に「Download the virtctl command-line utility」のリンクがあります。
リンクを選択すると各コマンドラインツールの入手先一覧が表示されます。
virtctlの一覧から「Download virtctl for Linux for x86_64」のリンクをコピーします。 リンク先は下記のような形式になります。
https://hyperconverged-cluster-cli-download-openshift-cnv.apps.ocp.home.lab/amd64/linux/virtctl.tar.gz
このリンクはOpenShiftクラスター上に作成されています。なお、virtctl以外のツールはインターネット上のリンク先からダウンロードすることになります。
踏み台サーバー上でコピーしたリンクをペーストし、下記のコマンドを実行します。
$ curl -L -o - https://hyperconverged-cluster-cli-download-openshift-cnv.apps.ocp.home.lab/amd64/linux/virtctl.tar.gz | sudo tar -C /usr/local/bin -xvzf - virtctl
virtctlコマンドが実行できることを確認します。
$ virtctl Available Commands: addvolume add a volume to a running VM adm Administrate KubeVirt configuration. completion Generate the autocompletion script for the specified shell ...
virtctlコマンドの自動補完を有効化します。
$ virtctl completion bash > virtctl_bash_completion $ sudo cp virtctl_bash_completion /etc/bash_completion.d/ $ exec bash $ virtctl (<--スペースに続けてTABキーを押す) addvolume (add a volume to a running VM) pause (Pause a virtual machine) adm (Administrate KubeVirt configuration.) permitted-devices (List the permitted devices for vmis.) completion (Generate the autocompletion script for the specified shell) port-forward (Forward local ports to a virtualmachine or virtualmachineinstance.) ...
4. 仮想マシンの作成（インスタンスタイプから作成）
起動ボリュームとインスタンスタイプを選択し、RHEL 9仮想マシンを作成する方法を紹介します。
4-1 インスタンスタイプから作成する
Webコンソールのメニューから「Virtualization>Catalog」を選択します。 カタログ画面のデフォルトでは「InstanceTypes」のタブが選択されます。
インスタンスタイプから作成する方法では、3つのステップを経て仮想マシンを作成します。
- 起動ボリュームの選択（Select volume to boot from）
- インスタンスタイプの選択（Select InstanceType）
- 仮想マシンの詳細設定（VirtualMachine details）
ステップ1「起動ボリュームの選択」は、本記事「1-5 インストール後の確認」で解説済みですのでここでは省略します。 ステップ2「インスタンスタイプの選択」では、作成する仮想マシンに適用するリソースと特性を事前に用意された定義済みのインスタンスタイプから選択します（詳細は後述）。 ステップ3「仮想マシンの詳細設定」では、仮想マシン名やストレージクラス、SSH公開鍵の事前設定などを行います。
4-2 定義済みのインスタンスタイプとは
OpenShift Virualizationではデフォルトで5つのインスタンスタイプのシリーズ（N、CX、U、GN、M）が用意されています。
標準的なリソースのものから特定のワークロードに特化したもの（たとえばGPUを搭載したものなど）をここから選択できます。
各インスタンスタイプはさらにnanoから8xlargeのサイズまでの雛形が用意されています。
インスタンスタイプの各シリーズの上にマウスオーバーするとそのシリーズの詳細が表示されます。
また、インスタンスタイプの各シリーズ上で選択するとそのシリーズが対応しているサイズの一覧が表示されます。 仮想マシンを作成する時はここから任意のサイズを選択します。
インスタンスタイプの各サイズの内容がどのように定義されているかはoc get vmcfコマンドを使って表示できます。
たとえば、u1.mediumのサイズのスペックの定義は下記のコマンドで表示できます。
$ oc get vmcf u1.medium -o json | jq '.spec'
{
"cpu": {
"guest": 1
},
"memory": {
"guest": "4Gi"
}
}
なお、本連載の環境ではUシリーズまたはMシリーズのみ利用可能です。他のシリーズを選択した場合は必要なリソースが提供できないため仮想マシンの作成が失敗します。ご注意ください。
参考に、各シリーズの最小サイズのスペックの定義を載せておきます。どのような内容が定義されているかご確認ください。
u1.microのspecの出力結果を開く
$ oc get vmcf u1.micro -o json | jq '.spec'
{
"cpu": {
"guest": 1
},
"memory": {
"guest": "1Gi"
}
}
gn1.xlargeのspecの出力結果を開く
$ oc get vmcf gn1.xlarge -o json | jq '.spec'
{
"cpu": {
"guest": 4
},
"gpus": [
{
"deviceName": "nvidia.com/A400",
"name": "gpu1"
}
],
"memory": {
"guest": "16Gi"
}
}
cx1.mediumのspecの出力結果を開く
$ oc get vmcf cx1.medium -o json | jq '.spec'
{
"cpu": {
"dedicatedCPUPlacement": true,
"guest": 1,
"isolateEmulatorThread": true,
"numa": {
"guestMappingPassthrough": {}
}
},
"ioThreadsPolicy": "auto",
"memory": {
"guest": "2Gi",
"hugepages": {
"pageSize": "2Mi"
}
}
}
m1.largeのspecの出力結果を開く
$ oc get vmcf m1.large -o json | jq '.spec'
{
"cpu": {
"guest": 2
},
"memory": {
"guest": "16Gi",
"hugepages": {
"pageSize": "2Mi"
}
}
}
n1.mediumのspecの出力結果を開く
$ oc get vmcf n1.medium -o json | jq '.spec'
{
"annotations": {
"cpu-load-balancing.crio.io": "disable",
"cpu-quota.crio.io": "disable",
"irq-load-balancing.crio.io": "disable"
},
"cpu": {
"dedicatedCPUPlacement": true,
"guest": 4,
"isolateEmulatorThread": true
},
"memory": {
"guest": "4Gi",
"hugepages": {
"pageSize": "1Gi"
}
}
}
定義済みのインスタンスタイプに関する詳細は下記ドキュメントを参照ください。
4-3 仮想マシンの作成
Webコンソールから「Virtualization>Catalog」を選択します。
仮想マシンを実行するためのプロジェクトを新規作成します。「プロジェクトの作成」を選択します。
プロジェクト名は任意の名前で構いませんが、ここでは「ocp-virt」とします。プロジェクト名の入力後、「作成」を押します。
先ほど作成したプロジェクト名が選択されていることを確認し、起動ボリュームを選択します。「① Select volume to boot from」から「rhel9」を選択します
次に、インスタンスタイプを選択します。「② Select InstanceType」からU seriesの「small: 1 CPUs, 2 GiB Memory」を選択します。
起動ボリュームの各OSには必要リソース要求が定義されています。たとえば、RHEL 9の場合はCPU1、メモリー1536Miが必要リソース要求として定義されています。
$ oc get vmcp rhel.9 -o json | jq .spec.requirements
{
"cpu": {
"guest": 1
},
"memory": {
"guest": "1536Mi"
}
}
そのため、必要リソース要求を下回るサイズを選んだ場合はエラーになり、仮想マシンの作成ができません。
最後に仮想マシンの詳細設定を行います。「③ VirtualMachine details」のNameは自動で作成されます。変更する場合は任意の名前を指定します。さらに、ここではSSH公開鍵の設定を行うため「Not contifured」のリンクを選択します。
Public SSH Keyの設定画面内の「None」「Use existing」「Add new」から「Add new」を選択します。キーの入力欄にSSH公開鍵をペーストします。 「Secret name」に任意の名前を指定します。ここでは「my-sshkey」とします。 「Automatically apply this key to any new VirtualMachine you create in this project.」のチェックを入れると、今後同じプロジェクトで作成される仮想マシンに自動で同じSSHキーを使用します。 最後に「Save」を押します。 このSSHキーの設定はcloud-iniの機能を使用しており、cloud-initに対応したOSの場合は自動的にSSHキーが登録されます。
「Public SSH key」の欄に先ほど作成した「my-sshkey」が登録されています。また、RHEL 9の場合は「Dynamic SSH key injection」に対応していますのでチェックを有効にします（無効のままでも問題ありません）。
すべての設定の完了後、「Create VirtualMachine」を押して仮想マシンの作成を行います。その際に「Start this VirtualMachine after creation」にチェックが入っていると、仮想マシンの作成完了と同時に起動が行われます。
作成したSSHキーは、仮想マシンの作成後「Virtualization>Overview>Settings>User>Manage SSH keys」で管理が行えます。
仮想マシンの作成後、詳細画面に遷移します。Statusが「Provisioning」となり、起動ボリュームからクローンが行われます。
起動ボリュームのクローンが完了すると、Statusが「Running」に変わり、OSが起動します。
4-4 仮想マシンへコンソールでアクセス
仮想マシンの起動後、Consoleタブから仮想マシンのコンソール画面へアクセスできます。
また、Overview画面から「Open web console」のリンクを選択すると別ウィンドウでコンソール画面を開くことができます。
コンソール画面には「Guest login credentials」のリンクがあり、選択するとその仮想マシンにログイン可能なユーザー名とパスワードが表示されます。 ユーザー名やパスワードをコピーし、「Paste」リンクを選択すると自動でコンソールの内部にコピーした内容がペーストされます。
この初期ユーザーはsudoコマンドの実行が可能です。たとえばsudo -iコマンドを実行し、その後passwdコマンドでルートユーザーのパスワードを変更できます。
4-5 仮想マシンへvirtctlでリモートアクセス
仮想マシンの詳細画面の右側にある「Actions」ドロップダウンメニューから「Copy SSH command」を選択します。
下記のようなコマンドがコピーされます。
virtctl -n ocp-virt ssh cloud-user@rhel-9-salmon-parrotfish-27 --identity-file=<path_to_sshkey>
virtctlコマンドで仮想マシン内へSSHのリモートアクセスができます。
踏み台サーバーに秘密鍵をコピーしていない場合は連載第1回を参考に、SSHエージェント転送を利用してください。
（作業用端末で実行） % ssh -A bastion
SSHエージェント転送を利用して踏み台サーバーにログイン後、OpenShiftにログインします。 ログイン方法は「kubeconfigを使ったログイン」または「oc login」のどちらでも構いません。 ログイン方法の詳細は連載第2回を参考にしてください。
$ export KUBECONFIG=${HOME}/work/auth/kubeconfig
$ oc whoami
system:admin
OpenShiftにログイン後、先ほどコピーしたvirtctlコマンドから、秘密鍵の指定の部分を除いて実行します。
初回のフィンガープリントの確認の後、仮想マシンにリモートアクセスができます。
$ virtctl -n ocp-virt ssh cloud-user@rhel-9-salmon-parrotfish-27 The authenticity of host 'vmi/rhel-9-salmon-parrotfish-27.ocp-virt (<no hostip for proxy command>)' can't be established. ED25519 key fingerprint is SHA256:pIksu6TcU4ShB3tptNic3M25cU5Sx0gGJzmnHOj8DCc. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'vmi/rhel-9-salmon-parrotfish-27.ocp-virt' (ED25519) to the list of known hosts. Register this system with Red Hat Insights: insights-client --register Create an account or view all your systems at https://red.ht/insights-dashboard Last login: Thu Jul 25 15:23:10 2024 [cloud-user@rhel-9-salmon-parrotfish-27 ~]$
5. 仮想マシンの作成（テンプレートから作成）
テンプレートカタログから仮想マシンの元となるテンプレートを選択し、Windows Server 2022をインストールする方法を紹介します。
5-1 テンプレートから作成する
テンプレートから作成する方法では、インストールの準備を除き2つのステップを経て仮想マシンを作成します。
- テンプレートの選択
- テンプレートの詳細設定
OpenShift Virtualizationのテンプレートとは、起動ボリュームと事前に定義済みのリソースを組み合わせた雛形のことです。 よく使う組み合わせを事前に定義しておくことで、繰り返し行う仮想マシンの作成作業を軽減できます。 また、OpenShift Virtualizationのインストール時に自動追加される起動ボリュームを使ったテンプレートが複数用意されているので、これを積極的に使うのも良いでしょう。
5-2 インストールの準備
MicrosoftのEvaluation CenterからWindows Server 2022の評価版をダウンロードします。 本記事ではダウンロード手順の詳細は割愛します。
Windows Server 2022 評価版のISOファイルをファイルを踏み台サーバーへコピーします。
作業用端末のカレントディレクトリにISOファイル（SERVER_EVAL_x64FRE_ja-jp.iso）が存在することとします。
% scp SERVER_EVAL_x64FRE_ja-jp.iso bastion:work
ISOファイルをvirtctlコマンドでOpenShiftへアップロード（PVCの作成）します。
virtctlコマンドによるファイルのアップロード方法は下記のドキュメントを参照してください。
ocp-virtプロジェクトを選択し、virtctl image-uploadコマンドでISOファイルをアップロードします。
実行コマンド
$ oc project ocp-virt $ virtctl image-upload dv win2022-ja-iso \ --size=10G \ --image-path=SERVER_EVAL_x64FRE_ja-jp.iso
win2022-ja-iso：PVCの名前。ここではwin2022-ja-isoとします。--size=10G：新規作成の場合はサイズの指定が必要です。ISOファイルが十分に収まるサイズを指定ください。--image-path=SERVER_EVAL_x64FRE_ja-jp.iso：アップロード元のファイルを指定します。
実行コマンドと結果
$ oc project ocp-virt Now using project "ocp-virt" on server "https://api.ocp.home.lab:6443". $ virtctl image-upload dv win2022-ja-iso \ --size=10G \ --image-path=SERVER_EVAL_x64FRE_ja-jp.iso PVC ocp-virt/win2022-ja-iso not found DataVolume ocp-virt/win2022-ja-iso created Waiting for PVC win2022-ja-iso upload pod to be ready... Pod now ready Uploading data to https://cdi-uploadproxy-openshift-cnv.apps.ocp.home.lab 4.85 GiB / 4.85 GiB [=============================================================================================================================================================================================================================================] 100.00% 54s Uploading data completed successfully, waiting for processing to complete, you can hit ctrl-c without interrupting the progress Processing completed successfully Uploading SERVER_EVAL_x64FRE_ja-jp.iso completed successfully
Webコンソールのメニューから「ストレージ>PersistentVolumeClaims」を選択します。 ISOファイルアップロード時に作成したPVCと対応するPVが作成されています。
5-3 仮想マシンの作成
Webコンソールのメニューから「Virtualization>Overview」を開き、「Template catalog」タブを選択します。
テンプレートカタログはインスタンスタイプとは異なり、OSとリソース（CPU、メモリー）がセットになった状態のテンプレートとして選択ができるようになっています。 「Source available」の表示があるものは起動ボリュームが存在し、そのまま仮想マシンの作成が可能になっているものです。 「Source available」の表示がないものは起動ボリュームが存在せず、起動ボリュームを別途用意したりISOファイルからインストールを行う必要があります。 Windows Serverはどれも「Source available」の表示がなく、ISOファイルからインストールが必要です。
まず「Microsoft Windows Server 2022 VM」を選択します。
仮想マシンの詳細設定画面が表示されたら、下記の通りに設定を行います。
Boot from CD：有効化CD source：PVC（clone PVC）PVC project：ocp-virtPVC name：win2022-ja-isoDisk source：Blank
Disk size、VirtualMachine nameは任意で変更してください。 「Start this VirtualMachine after creation」のチェックはそのままで、仮想マシンの作成と同時に起動を行います。 すべてのパラメーターが設定できたら、「Quick create VirtualMachine」を選択します。
仮想マシンの作成後、詳細画面に遷移します。Statusが「Provisioning」となり、ISOのPVのクローンが行われます。
Statusが「Running」に変わり、ISOから起動が開始します。「Press any key to boot from CD or DVD・・・・ 」 の表示が出たらタイミングよくエンターを押します。
あとは通常通りWindows Serverのインストールを続行します（本記事では詳細は割愛）。インストールの途中でドライバの追加なども不要です。
OSのインストール完了後、「Send Key」のプルダウンメニューから「Ctrl + Alt +Delete」を選択してログインします。
OSのインストール中に適用されなかった不明なデバイスドライバは、Windows Updateの機能によりバックグラウンドで自動適用されます。環境によっては適用完了までに少し時間がかかりますので、しばらく待ってから確認ください。
6. 仮想マシンの起動と停止
6-1 仮想マシンの停止
起動中の仮想マシンを停止するには、仮想マシンの詳細画面内の「Actions」メニューからStopを選択します（またはStopのアイコンを押します）。
この際、仮想マシン内のOSはシャットダウン操作が行われます（ハードオフではない）。
OSのシャットダウン完了後、自動的に仮想マシンが停止します。Statusは「Stopped」に変わります。
6-2 仮想マシンの起動
仮想マシンを起動するには、仮想マシンの詳細画面内の「Actions」メニューからStartを選択します（またはStartのアイコンを押します）。
仮想マシンの起動後、Statusは「Running」に変わります。
6-3 OS内でシャットダウンした時の動作の変更
OpenShift Virtualizationのデフォルト設定では、仮想マシンのOS内でシャットダウンしても自動的に仮想マシンが再起動してしまいます。 この件に関してはドキュメントに記載があります。
spec.running: true で設定された仮想マシンはすぐに再起動されます。spec.runStrategy キーを使用すると、特定の条件下で仮想マシンがどのように動作するかを決定するための柔軟性が高まります。
デフォルトの設定を確認するには下記のコマンドを実行します。
$ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}'
{
"running": true,
"runStrategy": null
}
このspec.runningキーの設定を無効化し、spec.runStrategyキーの設定を行うことでデフォルトの動作を変更できます。なお、ドキュメントに下記の注意点が記載されています。
spec.runStrategy キーと spec.running キーは相互に排他的です。いずれか 1 つだけを 使用できます。両方のキーを含む仮想マシン設定は無効です。
これはspec.runningキーとspec.runStrategyキーが相互に影響し合うため、別々に設定を変更できないことを意味します。そのためspec.runningキーとspec.runStrategyキーを同時に変更する方法で設定を行います。
（1）OS内からのシャットダウンで仮想マシンの停止を有効化する
OS内でのシャットダウンで仮想マシンを停止するには下記のコマンドで設定を変更します。
なお、この設定は仮想マシンごとの設定になります。oc patch vmに続けて設定変更したい仮想マシン名を指定します。仮想マシンの作成時に設定を適用したい場合は
また、この設定を反映するためには仮想マシンの再起動が必要です。仮想マシンを停止した後にコマンドを実行するか、仮想マシンを実行中に行った場合は仮想マシンの再起動を行なってください。
実行コマンド
$ oc patch vm win2k22-moccasin-elk-82 -n ocp-virt --type json -p '[{"op": "remove", "path": "/spec/running"},{"op": "add", "path": "/spec/runStrategy", "value": "Manual"}]'
実行コマンドと結果
$ oc patch vm win2k22-moccasin-elk-82 -n ocp-virt --type json -p '[{"op": "remove", "path": "/spec/running"},{"op": "add", "path": "/spec/runStrategy", "value": "Manual"}]'
virtualmachine.kubevirt.io/win2k22-moccasin-elk-82 patched
確認コマンド
$ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}'
確認コマンドと結果
$ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}'
{
"running": null,
"runStrategy": "Manual"
}
設定変更後はOS内のシャットダウンで仮想マシンの停止ができるようになります。
（2）元の設定に戻す方法
元の設定に戻す場合は下記のコマンドを実行します。
実行コマンド
$ oc patch vm win2k22-moccasin-elk-82 -n ocp-virt --type json -p '[{"op": "remove", "path": "/spec/runStrategy"},{"op": "add", "path": "/spec/running", "value": true}]'
実行コマンドと結果
$ oc patch vm win2k22-moccasin-elk-82 -n ocp-virt --type json -p '[{"op": "remove", "path": "/spec/runStrategy"},{"op": "add", "path": "/spec/running", "value": true}]'
virtualmachine.kubevirt.io/win2k22-moccasin-elk-82 patched
確認コマンド
$ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}'
確認コマンドと結果
$ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}'
{
"running": true,
"runStrategy": null
}
7. 仮想マシンのライブマイグレーション
7-1 ライブマイグレーションについて
ライブマイグレーションは、メンテナンスなどの目的で仮想マシンを停止せずに稼働中のホストから別のホストに仮想マシンを移行する機能です。 VMware vSphereのvMotionと同等の機能です。 vMotionは実行時に移行先のホストを明示的に指定しますが、OpenShift Virtualizationのライブマイグレーションではホストの指定はありません。 ライブマイグレーションの実行を指定するのみで、リソースの空きのある移行可能なホストに自動で移行が行われます。 この辺りの挙動はベース技術がコンテナオーケストレーションのKubernetesならではです。
なお、本連載における構成ではOpenShift Virtualization v4.16.0でライブマイグレーションできない不具合があるため、本記事「2-3 ライブマイグレーション用ワークアラウンドの実施」を行ってください。 該当バージョン以外や、不具合が発生しない場合はワークアラウンドの実施は不要です。
7-2 ライブマイグレーションの実行
ライブマイグレーションを実行するには、実行中の仮想マシンの詳細画面内の「Actions」メニューからMigrateを選択します。 操作はこれだけです。
仮想マシンのライブマイグレーション中は、各仮想マシンのStatusがRunningからMigratingに変わります。「Node」欄を確認すると、現在はnode-01上で実行していることが確認できます。
しばらく待って、ライブマイグレーションが完了するとRunningに戻ります。「Node」欄を確認すると、完了後はnode-02上で実行していることが確認できます。
ライブマイグレーションの進捗は、仮想マシンの詳細設定のMetricsタブを押し、画面を一番下にスクロールして「Migration>LiveMigration progress」を確認します。
まとめ
OpenShift Virtualizationのインストールと実行方法について解説しました。 OpenShift Virtualizationのインストールは、OpenShiftクラスターとストレージの環境さえ整っていればWebコンソールのOperator Hubから選んでインストールするだけですのでとても簡単に行えます。 仮想マシンの作成や起動、停止、さらにはライブマイグレーションもGUIの操作で行うことができ、vSphereの操作に慣れた方であればそれほど違和感なく使い始められます。 仮想マシン作成のライフサイクルの中心になるのがPVCやPVといったストレージが重要なのは特徴かもしれません。 その代わりにインスタンスタイプやテンプレートを駆使することで、セルフサービスを前提とした仮想マシン運用に変化できるのは大きなメリットです。
（次回予告） 次回はMigration Toolkit for Virtualizationを使って、vSphere/ESXi上の仮想マシンを移行する方法を解説します。
*1:サードパーティーコンポーネントを使用しているお客様に対して Red Hat はどのようなサポートを提供していますか? - Red Hat Customer Portal
*2:実際には自動的にHyperConverged Operatorがインストールされます
*3:CNVはOpenShift Virtualizationの以前の名前「Container Native Virtualizationに由来
*4:同一ホスト上でなくても、同じハードウェア構成のノード間であれば同様に問題なくライブマイグレーションできる可能性があります
