トップ > Red Hat OpenShift Virtualization > OpenShift Virtualization ( Kubevirt ) でVM管理もCloud Nativeに (2)

OpenShift Virtualization ( Kubevirt ) でVM管理もCloud Nativeに (2)

Red Hat OpenShift Virtualization

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。

前回に引き続き、今回もOpenShift Virtualization(OCP Virt)について紹介していきたいと思います。
環境の構築やインストールに関しては前回の記事を参照下さい。 rheb.hatenablog.com

この記事ではWindows ServerをOCP Virt上でVMとして構築し、関連してContainerized Data Importer(CDI)やDataVolumeについて紹介したいと思います。

Windows Serverの構築

Red HatはWindows Serverを実行する仮想化ソフトウェアについてMicrosoftとパートナーであり、OCP Virtも複数バージョンのWindows Serverの実行をサポートしています。
access.redhat.com

今回はWindows Server 2022をOCP Virtで実行したいと思います。 まずはOCPコンソールのカタログから対象のバージョンを選び、設定のカスタマイズを行なっていきます。

前回の記事でRHEL9のVMを起動した際はOCP Virtをインストールした時点でOSのイメージがOCP環境上に準備されていましたが、Windows Serverを利用する場合はOSのISOファイルを準備する必要があります。 まず以下のサイトからISOをダウンロードするためのURLをコピーしておきます。 www.microsoft.com

画像のように"Boot from CD"にチェックを入れ、CD sourceとして"URL"を選択、そして"Image URL"にコピーしておいたURLを貼り付けます。

あとはそのままの設定でVMを作成しましょう。 しばらくするとVMが起動しOSのセットアップが開始されます。

OCP VirtではVNCコンソールを利用できるためここから設定を進めていきます。
設定が完了すると無事にWindows Serverを起動することができました。

QEMU Guest Agentのインストール

Windows Server起動後、VMの管理を円滑に行うためQEMU Guest Agentをインストールしたいと思います。 ドキュメントに関しては以下を参照下さい。 access.redhat.com

ファイルエクスプローラーを開き画面左側から"virtio-win" CDドライブを選択します。

"guest-agent"フォルダを開き、中にあるインストーラーを実行するとQEMU Guest Agentをインストールすることができます。

PowerShellからnet startコマンドを実行するとQEMU Guest Agentの実行を確認できます。

リモートデスクトップ接続

起動したVMに対し、手元の環境(Mac)からRDPで接続してみたいと思います。 まずはVNCコンソールからサーバーマネージャーを開き、リモートデスクトップを有効化しておきます。

その後コンソールをVNCコンソールから"Desktop viewer"に切り替え、"Create RDP Service"を実行します。 これによりtype: NodePortのServiceが新たに作成され、VMが起動するベアメタルNodeのIPを通じてクラスター外部からのRDP接続が可能となりました。

ただし今回も前回同様にAWS上のベアメタルサーバーを利用しているため、手元の環境から上記のアドレスに直接のアクセスはできません。 そのためPublic Subnet上で踏み台サーバーを構築し、ポートフォワードを行うことで手元の環境からアクセスを可能としました。またAWSのSGについても適宜設定変更をしておきます。

ssh -i ~/.ssh/cluster-key ec2-user@{踏み台のパブリックIP} -L 3389:10.0.68.1:31183

無事手元の環境からアクセスすることができました。

Containerized Data Importer(CDI) / DataVolume について

今回はVMを作成するタイミングでコンソールからISOファイルのURLを指定しましたが、実際のファイルのダウンロードや、ダウンロード先としてのPVの作成などはDataVolumeと呼ばれるCRや、それを管理するContainerized Data Importer(CDI) Operatorにより行われます。 CDI OperatorはOCP VirtのOperatorをインストールし、HyperConverged CRを作成するとOpenShift環境にインストールされます。

DataVolume CRを作成すると、OSイメージをダウンロードするためのImporter Podと保存用のPVが作成されます。

指定したURLからOSイメージのダウンロードが完了するとImporter Pod等のリソースは削除され、VMを起動するためのVirt Launcher Podに先ほどのPVがアタッチされ、そこからOSの起動を可能としています。

DataVolumeによるOSイメージを含むPVの作成はURLを指定してダウンロードする以外にも、 利用者の端末からのアップロードや、既存のPVからのコピー、PVのSnapshotsからの作成、さらにはコンテナ化されたOSイメージの利用と複数の方法を取ることができます。

例えば、前回の記事ではRHEL9のVMを起動しましたが、この場合はOSイメージがVolumeSnapshotsとして保存されており、そこからPVが作成されVirt Launcher Podにアタッチされていました。

openshift-virtualization-os-imagesNameSpaceを見るとVolumeSnapshotsとしてCentOS StreamやFedora、そしてRHELのイメージが存在しているのがわかります。

# oc get volumesnapshots -n openshift-virtualization-os-images
NAME                          READYTOUSE   SOURCEPVC                     SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS                            SNAPSHOTCONTENT                                    CREATIONTIME   AGE
centos-stream8-c323729af4d6   true         centos-stream8-c323729af4d6                           30Gi          ocs-storagecluster-rbdplugin-snapclass   snapcontent-a71a0072-a2e9-42f3-a54b-e480b3a2fe2d   20h            20h
centos-stream9-e5a8aee22808   true         centos-stream9-e5a8aee22808                           30Gi          ocs-storagecluster-rbdplugin-snapclass   snapcontent-2f4aea79-e29e-44c1-8fc5-a1e13babf7d4   20h            20h
centos7-680e9b4e0fba          true         centos7-680e9b4e0fba                                  30Gi          ocs-storagecluster-rbdplugin-snapclass   snapcontent-2126c3be-bb95-43d0-ad77-b9fee8486a4c   20h            20h
fedora-498bd939ff7a           true         fedora-498bd939ff7a                                   30Gi          ocs-storagecluster-rbdplugin-snapclass   snapcontent-d774d73a-1c11-4572-bb84-024fb8770bd4   20h            20h
rhel8-3d8ef774e232            true         rhel8-3d8ef774e232                                    30Gi          ocs-storagecluster-rbdplugin-snapclass   snapcontent-d74e8c7d-f401-4bee-a14f-17e99c33d413   20h            20h
rhel9-1467c655829b            true         rhel9-1467c655829b                                    30Gi          ocs-storagecluster-rbdplugin-snapclass   snapcontent-08727a8b-75f4-4b0b-b0d8-0b073e30cfc3   20h            20h

さて、ではこのDataVolumeがいつ定義され作成されるのかというと、実はVirtualMachine CRを作成する際にDataVolumeTemplateとして設定が行われています。先ほどWindows Severを起動したyamlを見てみると以下のような記載となっています。

apiVersion: kubevirt.io/v1
kind: VirtualMachine
---snip---
spec:
  dataVolumeTemplates:
    - apiVersion: cdi.kubevirt.io/v1beta1
      kind: DataVolume
      metadata:
        annotations:
          cdi.kubevirt.io/storage.bind.immediate.requested: 'true'
        creationTimestamp: null
        name: win2k22-kvirt
      spec:
        source:
          blank: {}
        storage:
          resources:
            requests:
              storage: 30Gi
    - metadata:
        creationTimestamp: null
        name: win2k22-kvirt-installation-cdrom
      spec:
        source:
          http:
            url: >-
              https://go.microsoft.com/fwlink/p/?LinkID=2195280&clcid=0x411&culture=ja-jp&country=JP
        storage:
          resources:
            requests:
              storage: 30Gi

.spec.dataVolumeTemplatesの中に二つのDataVolume設定があり、一つは空のボリュームとして、もう一つがOSイメージをインストールするボリュームとしてGUIで入力したURLが記載されているのがわかります。 最初にVirtualMachine CRを作成するタイミングでこれらのDataVolumeも作成され一連のPVが準備されたのでした。

まとめ

今回はOCP Virt上でWindows Serverを起動し、そこへのアクセスや、OSイメージをPVとして準備する仕組みについてご紹介しました。また別の記事にてOCP Virtに関する別のトピックについて紹介していきたいと思います。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。