Container-native Virtualization

OpenShift Container Platform 4.1

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

Red Hat OpenShift Documentation Team

概要

本書では、OpenShift Container Platform 4.1 で Container-native Virtualization を使用する方法についての情報を提供します。

第1章 Container-native Virtualization インストール

1.1. Container-native Virtualization について

Container-native Virtualization の機能およびサポート範囲について確認します。

1.1.1. Container-native Virtualization の機能

Container-native Virtualization は OpenShift Container Platform のアドオンであり、仮想マシンのワークロードを実行し、このワークロードをコンテナーのワークロードと共に管理することを可能にします。

Container-native Virtualization は、Kubernetes カスタムリソースを使って新規オブジェクトを OpenShift Container Platform クラスターに追加し、仮想化タスクを有効にします。これらのタスクには、以下が含まれます。

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

機能強化された Web コンソールは、これらの仮想化されたリソースを OpenShift Container Platform クラスターコンテナーおよびインフラストラクチャーと共に管理するためのグラフィカルポータルを提供します。

1.1.2. Container-native Virtualization のサポート

重要

Container-native Virtualization はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

1.2. Container-native Virtualization のクラスターの準備

Container-native Virtualization 2.0 はデフォルトで OpenShift Container Platform と連携しますが、以下のインストール設定が推奨されます。

  • OpenShift Container Platform クラスターを ベアメタルにインストールします。コンピュートノードを、クラスター内でホストする仮想マシンの数およびサイズに応じて管理します。
  • モニタリングをクラスターに設定します。

1.3. Container-native Virtualization のインストール

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

Container-native Virtualization をデプロイする前に、カスタムリソース定義 (CRD) オブジェクトを作成する必要があります。

  • kind: OperatorGroup
  • kind: CatalogSource

1 つのコマンドを実行して両方のオブジェクトを作成できます。

Container-native Virtualization のインストールを終了するには、OpenShift Container Platform 4.1 Web コンソールを使用して、Container-native Virtualization Operator にサブスクライブし、これをデプロイすることができます。

重要

Container-native Virtualization はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

1.3.1. Container-native Virtualization のインストールの準備

Container-native Virtualization をデプロイする前に、以下を実行します。

  • kubevirt-hyperconverged という名前の namespace を作成します。
  • OperatorGroup および CatalogSource カスタムリソース定義オブジェクト (CRD) を kubevirt-hyperconverged namespace に作成します。

前提条件

  • OpenShift Container Platform 4.1
  • cluster-admin 権限を持つユーザー
  • oc として知られる OpenShift Container Platform コマンドラインインターフェース (CLI)

手順

  1. 以下のコマンドを実行して kubevirt-hyperconverged namespace を作成します。

    $ oc new-project kubevirt-hyperconverged
  2. 以下のコマンドを実行して kubevirt-hyperconverged namespace に OperatorGroup および CatalogSource を作成します。

    cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1alpha2
    kind: OperatorGroup
    metadata:
      name: hco-operatorgroup
      namespace: kubevirt-hyperconverged
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: hco-catalogsource
      namespace: openshift-operator-lifecycle-manager
      imagePullPolicy: Always
    spec:
      sourceType: grpc
      image: registry.redhat.io/container-native-virtualization/hco-bundle-registry:v2.0.0
      displayName: KubeVirt HyperConverged
      publisher: Red Hat
    EOF

1.3.2. KubeVirt HyperConverged Cluster Operator カタログへのサブスクライブ

Container-native Virtualization をインストールする前に、OpenShift Container Platform Web コンソールから KubeVirt HyperConverged Cluster Operator カタログにサブスクライブします。サブスクライブにより、kubevirt-hyperconverged namespace に Container-native Virtualization Operator へのアクセスが付与されます。

前提条件

  • OperatorGroup および CatalogSource カスタムリソース定義オブジェクト (CRD) の両方が kubevirt-hyperconverged namespace に作成されている。

手順

  1. ブラウザーウィンドウを開き、OpenShift Container Platform Web コンソールに移動します。
  2. kubevirt-hyperconverged プロジェクトを Projects 一覧から選択します。
  3. CatalogOperator Management ページに移動します。
  4. Operator Catalogs タブで、KubeVirt HyperConverged Cluster Operator を見つけ、Create Subscription をクリックします。
  5. Create をクリックして Container-native Virtualization Operator を起動します。

1.3.3. Container-native Virtualization のデプロイ

KubeVirt HyperConverged Cluster Operator カタログにサブスクライブした後に、KubeVirt HyperConverged Cluster Operator Deployment カスタムリソースを作成し、Container-native Virtualization をデプロイします。

前提条件

  • kubevirt-hyperconverged namespace での KubeVirt HyperConverged Cluster Operator カタログへのアクティブなサブスクリプション

手順

  1. CatalogInstalled Operators ページに移動します。
  2. KubeVirt HyperConverged Cluster Operator をクリックします。
  3. KubeVirt HyperConverged Cluster Operator Deployment タブをクリックし、Create HyperConverged をクリックします。
  4. Create をクリックして Container-native Virtualization を起動します。
  5. WorkloadsPods ページに移動して、Container-native Virtualization Pod がすべて Running 状態になるまでこれらの Pod をモニターします。すべての Pod で Running 状態が表示された後に、Container-native Virtualization にアクセスできます。
注記

kubevirt-web-ui.your.app.subdomain.host.com にある Web コンソールに移動してインストールを確認できます。OpenShift Container Platform の認証情報を使用してログインします。

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

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

Container-native Virtualization リポジトリーを有効にし、kubevirt-virtctl パッケージをインストールしてクライアントをシステムにインストールします。

1.4.1. Container-native Virtualization リポジトリーの有効化

Red Hat は、Red Hat Enterprise Linux 8 および Red Hat Enterprise Linux 7 向けの Container-native Virtualization リポジトリーを提供します。

  • Red Hat Enterprise Linux 8 リポジトリー: cnv-2.0-for-rhel-8-x86_64-rpms
  • Red Hat Enterprise Linux 7 リポジトリー: rhel-7-server-cnv-2.0-rpms

subscription-manager でリポジトリーを有効にするプロセスはどちらのプラットフォームでも同様です。

手順

  • subscription manager を使用して、お使いのシステムに適した Container-native Virtualization リポジトリーを有効にします。

    # subscription-manager repos --enable <repository>

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

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

手順

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

    # yum install kubevirt-virtctl

Container-native Virtualization の「CLI ツールの使用」も参照してください。

1.5. Container-native Virtualization のアンインストール

OpenShift Container Platform 4.1 の Web コンソールを使用して、Container-native Virtualization をアンインストールできます。まず、デプロイ時に作成したカスタムリソースを削除します。次に、KubeVirt HyperConverged Cluster Operator カタログサブスクリプションを削除します。

前提条件

  • Container-native Virtualization 2.0

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

Container-native Virtualization をアンインストールするには、デプロイ時に作成したカスタムリソースを削除する必要があります。

前提条件

  • アクティブな KubeVirt HyperConverged Cluster Operator Deployment カスタムリソース

手順

  1. OpenShift Container Platform Web コンソールで、kubevirt-hyperconvergedProjects 一覧から選択します。
  2. CatalogInstalled Operators ページに移動します。
  3. KubeVirt HyperConverged Cluster Operator をクリックします。
  4. KubeVirt HyperConverged Cluster Operator Deployment タブをクリックします。
  5. Options メニュー kebab を kubevirt-hyperconverged カスタムリソースを含む行でクリックします。拡張されたメニューで、Delete HyperConverged をクリックします。
  6. 確認ウィンドウで Delete をクリックします。
  7. WorkloadsPods ページに移動し、Operator Pod のみが実行中であることを確認します。
  8. ターミナルウィンドウを開き、以下のコマンドを実行して残りの KubeVirt リソースをクリーンアップします。

    $ oc delete apiservices v1alpha3.subresources.kubevirt.io -n kubevirt-hyperconverged
    注記

    現時点で、一部の KubeVirt リソースが不適切に保持される状態が確認されるため、それらを手動で削除する必要があります。これらのリソースは、(BZ1712429) の解決後に自動的に削除されます。

1.5.2. KubeVirt HyperConverged Cluster Operator カタログサブスクリプションの削除

Container-native Virtualization のアンインストールを終了するには、KubeVirt HyperConverged Cluster Operator カタログサブスクリプションを削除します。

前提条件

  • アクティブな KubeVirt HyperConverged Cluster Operator カタログサブスクリプション

手順

  1. OpenShift Container Platform Web コンソールで、kubevirt-hyperconvergedProjects 一覧から選択します。
  2. CatalogOperator Management ページに移動します。
  3. Operator Subscriptions タブをクリックします。
  4. 仮想マシンの末尾の Options メニュー kebab を hco-subscription サブスクリプションを含む行でクリックします。拡張されたメニューで、 Remove Subscription をクリックします。
  5. Also completely remove the Operator from the selected namespace」チェックボックスが選択されていることを確認します。これが選択されていない場合、サブスクリプションが削除されると Operator Pod は WorkloadsPods に残ります。
  6. Remove を再度クリックしてサブスクリプションを削除することを確定します。
注記

kubevirt-hyperconverged namespace を削除できるようになります。

1.5.3. Web コンソールを使用したプロジェクトの削除

手順

  1. HomeProjects に移動します。
  2. プロジェクトの一覧から削除するプロジェクトを見つけます。
  3. プロジェクト一覧の右端にあるメニューから Delete Project を選択します。プロジェクトを削除するパーミッションがない場合は、Delete Project オプションがグレーアウトされるため、オプションをクリックすることができません。

第2章 Container-native Virtualization ユーザーガイド

2.1. 仮想マシンの作成

以下のいずれかの手順を使用して、仮想マシンを作成します。

  • 仮想マシンウィザードの実行
  • 仮想マシンウィザードによる事前に設定された YAML ファイルの貼り付け
  • CLI の使用
  • 仮想マシンウィザードによる VMware 仮想マシンまたはテンプレートのインポート

2.1.1. 仮想マシンウィザードの実行による仮想マシンの作成

Web コンソールは、Basic SettingsNetworking、および Storage 画面にナビゲートし、仮想マシンの作成プロセスを単純化するインタラクティブなウィザードを特長としています。すべての必須フィールドには * のマークが付けられます。ウィザードは必須フィールドの入力が完了するまで次の画面に移動することを防ぎます。

NIC およびストレージディスクを作成し、それらの作成後に仮想マシンに割り当てることができます。

ブート可能なディスク

Basic Settings 画面で URL または Container のいずれかが Provision Source として選択されている場合、 rootdisk ディスクが Bootable Disk として作成され、仮想マシンに割り当てられます。rootdisk を変更できますが、これを削除することはできません。

Bootable Disk は、仮想マシンにディスクが割り当てられていない場合、PXE ソースからプロビジョニングされる仮想マシンには不要です。1 つ以上のディスクが仮想マシンに割り当てられている場合、Bootable Disk を 1 つを選択する必要があります。

前提条件

  • ウィザードを使用して仮想マシンを作成する場合、仮想マシンのストレージメディアは Read-Write-Many(RWM)PVC をサポートする必要があります。

手順

  1. サイドメニューから WorkloadsVirtual Machines をクリックします。
  2. Create Virtual Machine をクリックし、Create with Wizard を選択します。
  3. すべての必須の Basic Settings を入力します。Template を選択すると、これらのフィールドへの入力が自動的に行われます。
  4. Next をクリックして Networking 画面に進みます。デフォルトで nic0 NIC が割り当てられます。

    1. (オプション) Create NIC をクリックして追加の NIC を作成します。
    2. (オプション) ⋮ ボタンをクリックし、Remove NIC を選択して、NICS のいずれかまたはすべてを削除できます。仮想マシンの作成において、NIC が割り当てられている必要はありません。NIC は仮想マシンの作成後に作成することができます。
  5. Next をクリックして Storage 画面に進みます。

    1. (オプション) Create Disk をクリックして追加のディスクを作成します。これらのディスクは、⋮ ボタンをクリックし、 Remove Disk を選択して削除できます。
    2. (オプション) ディスクをクリックして選択可能なフィールドを変更します。✓ ボタンをクリックして更新を保存します。
    3. (オプション) Attach Disk をクリックして、Select Storage ドロップダウンリストから利用可能なディスクを選択します。
  6. Create Virtual Machine > をクリックします。Results 画面には、仮想マシンの JSON 設定ファイルが表示されます。

仮想マシンは WorkloadsVirtual Machines に一覧表示されます。

Web コンソールウィザードを実行する際は、仮想マシンウィザードのフィールドを参照します。

2.1.1.1. 仮想マシンウィザードのフィールド

名前パラメーター説明

名前

 

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

説明

 

オプションの説明フィールド。

Template

 

仮想マシンの作成に使用するテンプレート。テンプレートを選択すると、他のフィールドが自動的に入力されます。

Provision Source

PXE

PXE メニューから仮想マシンをプロビジョニングします。クラスターに PXE 対応の NIC が必要になります。

URL

HTTP または S3 エンドポイントで利用できるイメージから仮想マシンをプロビジョニングします。

Container

クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: kubevirt/cirros-registry-disk-demo

Cloned Disk

プロビジョニングソースはクローン作成されるディスクです。

Import

サポートされているプロバイダーから仮想マシンをインポートします。

Operating System

 

クラスターで利用可能なオペレーティングシステムの一覧。これは、仮想マシンの主なオペレーティングシステムになります。ImportProvider Source として選択する場合、オペレーティングシステムはインポートされる VMware 仮想マシンのオペレーティングシステムに基づいて自動的に入力されます。

Flavor

small、medium、large、tiny、Custom

仮想マシンに割り当てられる CPU およびメモリーの量を決定するプリセット。

Workload Profile

desktop

デスクトップで使用するための仮想マシン設定。

generic

各種ワークロードについてのパフォーマンスと互換性のバランスを取るための仮想マシン設定。

high performance

高パフォーマンスの負荷に対して最適化された仮想マシン設定。

Start virtual machine on creation

 

これを選択すると、作成時に仮想マシンが自動的に起動します。

Use cloud-init

 

これを選択すると cloud-init フィールドが有効になります。

2.1.1.2. Cloud-init フィールド

名前説明

Hostname

仮想マシンの特定のホスト名を設定します。

Authenticated SSH Keys

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

Use custom script

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

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

名前説明

Create NIC

仮想マシンの新規 NIC を作成します。

NIC NAME

NIC の名前。

MAC ADDRESS

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

NETWORK CONFIGURATION

利用可能な NetworkAttachmentDefinition オブジェクトの一覧。

BINDING METHOD

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

PXE NIC

PXE 対応ネットワークの一覧。PXEProvision Source として選択されている場合にのみ表示されます。

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

名前説明

Create Disk

仮想マシンの新規ディスクを作成します。

Attach Disk

利用可能な PVC の一覧から、仮想マシンに割り当てる既存のディスクを選択します。

DISK NAME

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

SIZE (GB)

ディスクのサイズ (GB)。

STORAGE CLASS

基礎となる StorageClass の名前。

Bootable Disk

仮想マシンの起動に利用できるディスクの一覧。仮想マシンの Provision SourceURL または Container の場合に rootdisk に固定されます。

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

Web コンソールの WorkloadsVirtual Machines 画面で YAML 設定ファイルを作成するか、またはこれを貼り付けて仮想マシンを作成します。YAML 編集画面を開くと、常に有効な example 仮想マシン設定がデフォルトで提供されます。

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

注記

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

手順

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

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

仮想マシンは WorkloadsVirtual Machines に一覧表示されます。

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

手順

VirtualMachine 設定ファイルの spec オブジェクトは、コア数やメモリーの量、ディスクタイプおよび使用するボリュームなどの仮想マシン設定を参照します。

  1. 関連する PVC claimName をボリュームとして参照し、仮想マシンディスクを仮想マシンに割り当てます。
  2. OpenShift Container Platform クライアントで仮想マシンを作成するには、以下のコマンドを実行します。

    $ oc create -f <vm.yaml>
  3. 仮想マシンは Stopped 状態で作成されるため、これを起動して仮想マシンインスタンスを実行します。
注記

ReplicaSetは、一定数の同一 Pod の可用性を保証することを目的としています。現時点で、ReplicaSet は Container-native Virtualization でサポートされていません。

表2.1 ドメイン設定

設定説明

Cores

仮想マシン内のコア数。1 以上の値である必要があります。

Memory

ノードによって仮想マシンに割り当てられる RAM の量。M (メガバイト) または Gi (ギガバイト) で値を指定します。

Disks: name

参照されるボリュームの名前。ボリュームの名前に一致する必要があります。

表2.2 ボリューム設定

設定説明

名前

ボリュームの名前。 DNS ラベルであり、仮想マシン内で一意である必要があります。

PersistentVolumeClaim

仮想マシンに割り当てる PVC。PVC の claimName は仮想マシンと同じプロジェクトになければなりません。

仮想マシンのストレージボリュームタイプがドメインおよびボリューム設定と共に一覧表示されます。仮想マシン設定の具体的な一覧については、「 kubevirt API Reference 」を参照してください。

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

ephemeral

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

persistentVolumeClaim

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

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

dataVolume

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

cloudInitNoCloud

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

containerDisk

コンテナーイメージレジストリーに保存される、仮想マシンディスクなどのイメージを参照します。イメージはレジストリーからプルされ、仮想マシンの作成時にボリュームに組み込まれます。containerDisk ボリュームは一時的なボリュームです。これは、仮想マシンが停止されるか、再起動するか、または削除される際に破棄されます。

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

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

emptyDisk

仮想マシンインターフェースのライフサイクルに関連付けられるスパースの QCOW2 ディスクを追加で作成します。データは仮想マシンのゲストによって実行される再起動後も存続しますが、仮想マシンが Web コンソールから停止または再起動する場合には破棄されます。空のディスクは、アプリケーションの依存関係および一時ディスクの一時ファイルシステムの制限を上回るデータを保存するために使用されます。

ディスク 容量 サイズも指定する必要があります。

2.2. DataVolume インポートの TLS 証明書

2.2.1. DataVolume インポートの認証に使用する TLS 証明書の追加

ソースからデータをインポートするには、レジストリーまたは HTTPS エンドポイントの TLS 証明書を ConfigMap に追加する必要があります。この ConfigMap は、宛先 DataVolume の namespace に存在する必要があります。

TLS 証明書の相対パスを参照して ConfigMap を作成します。

手順

  1. 正しい namespace にあることを確認します。ConfigMap は、同じ namespace にある場合に DataVolume によってのみ参照されます。

    $ oc get ns
  2. ConfigMap を作成します。

    $ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>

2.2.2. 例: TLS 証明書から作成される ConfigMap

以下は、ca.pem TLS 証明書で作成される ConfigMap の例です。

apiVersion: v1
kind: ConfigMap
metadata:
  name: tls-certs
data:
  ca.pem: |
    -----BEGIN CERTIFICATE-----
    ... <base64 encoded cert> ...
    -----END CERTIFICATE-----

2.3. 仮想マシンウィザードによる VMware 仮想マシンまたはテンプレートのインポート

VMware 仮想マシンまたはテンプレートをインポートできます。テンプレートをインポートする場合、テンプレートをベースとする仮想マシンが作成されます。

重要

VMware 仮想マシンまたはテンプレートのインポートはテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

前提条件

  • VMware 仮想マシンの電源がオフになっていること。
  • VMware Virtual Disk Development Kit (VDDK) が仮想マシンをインポートする namespace にアップロードされていること。

2.3.1. VMware Virtual Disk Development Kit のアップロード

手順

  1. ブラウザーで VMware ドキュメントに移動し、ログインします。
  2. VMware SDK & API Product Documentation をクリックして拡張します。
  3. VMware Virtual Disk Development Kit (VDDK) をクリックします。
  4. Latest Releases をクリックして、最新の VDDK リリースを選択します。
  5. Download SDKs をクリックして VDDK アーカイブファイルをダウンロードします。
  6. VDDK アーカイブを HTTP でアクセス可能な場所に保存します。
  7. 仮想マシンをインポートする namespace に切り替えます。

    $ oc project <namespace>
  8. VDDK を namespace にアップロードします。

    $ cat <<EOF | oc apply -f -
    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: "vddk-pvc"
    spec:
      source:
        http:
          url: "<http://www.example.com/VDDK_archive_file>" 1
      contentType: "archive"
      pvc:
        storageClassName: nfs-sc
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: "200Mi"
    EOF
    1
    <url> は VDDK アーカイブファイルのパスです。

2.3.2. VMware 仮想マシンまたはテンプレートのインポート

手順

  1. サイドメニューから WorkloadsVirtual Machines をクリックします。
  2. Create Virtual Machine をクリックし、Create with Wizard を選択します。
  3. Basic Settings 画面で以下の手順を実行します。

    1. Provision Source をクリックし、Import を選択します。
    2. Provider をクリックし、VMware を選択します。
    3. vCenter Instance をクリックし、Connect to New Instance または保存された vCenter インスタンスを選択します。

      • Connect to New Instance を選択する場合、以下のフィールドに値を指定し、Check and Save をクリックします。

        • vCenter Hostname
        • vCenter User Name
        • vCenter Password

          ウィザードは vCenter インスタンスに接続し、認証情報を保存します。

          Save as New vCenter Instance チェックボックスをクリアし、Check をクリックする場合、ウィザードは認証情報を保存せずに vCenter インスタンスに接続します。

      • 保存された vCenter インスタンスを選択する場合、ウィザードは保存された認証情報を使用してこれに接続します。
    4. VM to import をクリックし、仮想マシンまたはテンプレートを選択します。

      Name および Operating System には、選択された仮想マシンまたはテンプレートの属性が自動的に入力されます。

    5. デフォルトのフレーバー Custom を使用する場合、Memory (GB) および CPUs の数を指定します。

      オプションで、既存の Flavor を選択できます。

    6. Workload Profile を選択します。
    7. Next をクリックします。
  4. Networking 画面で以下の手順を実行します。

    1. NETWORK CONFIGURATION をクリックし、Pod Networking を選択します。
    2. BINDING METHOD を選択します。
    3. ✓ ボタンをクリックして更新を保存します。
    4. Next をクリックします。
  5. Storage 画面で以下の手順を実行します。

    1. 各ディスクをクリックし、STORAGE CLASS を選択します。ストレージクラスを選択しない場合、Container-native Virtualization はデフォルトストレージクラスを使用して仮想マシンを作成します。
    2. ✓ ボタンをクリックして更新を保存します。
    3. 複数のブート可能なディスクがある場合は、Bootable Disk を選択します。
    4. Create Virtual Machine > をクリックします。

      Result 画面に、仮想マシン用に作成されたリソースが表示されます。

  6. Close をクリックします。

インポートの進捗を表示するには、以下を実行します。

  1. サイドメニューから WorkloadsPods をクリックします。
  2. 変換 Pod kubevirt-v2v-conversion-<id> をクリックし、Pod の詳細を表示します。
  3. Overview タブで、v2vConversionProgress 値の ANNOTATIONS をクリックします。

エラーが発生した場合は、変換 Pod ログを確認できます。

  1. サイドメニューから WorkloadsPods をクリックします。
  2. 変換 Pod kubevirt-v2v-conversion-<id> をクリックし、Pod の詳細を表示します。
  3. Logs をクリックし、変換 Pod ログを表示します。

ウィザードのフィールドについては、「virtual machine wizard fields」のセクションを参照してください。

2.3.3. インポートされた仮想マシンの NIC 名の更新

インポートされた仮想マシンの NIC 名を、Container-native Virtualization の命名規則に適合するように更新します。

手順

  1. インポートされた仮想マシンにログインします。
  2. /etc/sysconfig/network-scripts ディレクトリーに移動します。
  3. ネットワーク設定ファイルの名前を新規 NIC 名に変更します (単一 NIC は eth0 と呼ばれます)。

    $ mv original_NIC ifcfg-ethx
  4. ネットワーク設定ファイルで以下のパラメーターを更新します。

    NAME=ethx
    DEVICE=ethx
  5. ネットワークを再起動します。

    $ systemctl restart network

2.3.4. 仮想マシンウィザードのフィールド

2.3.4.1. 仮想マシンウィザードのフィールド

名前パラメーター説明

名前

 

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

説明

 

オプションの説明フィールド。

Template

 

仮想マシンの作成に使用するテンプレート。テンプレートを選択すると、他のフィールドが自動的に入力されます。

Provision Source

PXE

PXE メニューから仮想マシンをプロビジョニングします。クラスターに PXE 対応の NIC が必要になります。

URL

HTTP または S3 エンドポイントで利用できるイメージから仮想マシンをプロビジョニングします。

Container

クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: kubevirt/cirros-registry-disk-demo

Cloned Disk

プロビジョニングソースはクローン作成されるディスクです。

Import

サポートされているプロバイダーから仮想マシンをインポートします。

Operating System

 

クラスターで利用可能なオペレーティングシステムの一覧。これは、仮想マシンの主なオペレーティングシステムになります。ImportProvider Source として選択する場合、オペレーティングシステムはインポートされる VMware 仮想マシンのオペレーティングシステムに基づいて自動的に入力されます。

Flavor

small、medium、large、tiny、Custom

仮想マシンに割り当てられる CPU およびメモリーの量を決定するプリセット。

Workload Profile

desktop

デスクトップで使用するための仮想マシン設定。

generic

各種ワークロードについてのパフォーマンスと互換性のバランスを取るための仮想マシン設定。

high performance

高パフォーマンスの負荷に対して最適化された仮想マシン設定。

Start virtual machine on creation

 

これを選択すると、作成時に仮想マシンが自動的に起動します。

Use cloud-init

 

これを選択すると cloud-init フィールドが有効になります。

2.3.4.2. Cloud-init フィールド

名前説明

Hostname

仮想マシンの特定のホスト名を設定します。

Authenticated SSH Keys

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

Use custom script

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

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

名前説明

Create NIC

仮想マシンの新規 NIC を作成します。

NIC NAME

NIC の名前。

MAC ADDRESS

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

NETWORK CONFIGURATION

利用可能な NetworkAttachmentDefinition オブジェクトの一覧。

BINDING METHOD

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

PXE NIC

PXE 対応ネットワークの一覧。PXEProvision Source として選択されている場合にのみ表示されます。

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

名前説明

Create Disk

仮想マシンの新規ディスクを作成します。

Attach Disk

利用可能な PVC の一覧から、仮想マシンに割り当てる既存のディスクを選択します。

DISK NAME

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

SIZE (GB)

ディスクのサイズ (GB)。

STORAGE CLASS

基礎となる StorageClass の名前。

Bootable Disk

仮想マシンの起動に利用できるディスクの一覧。仮想マシンの Provision SourceURL または Container である場合、rootdisk に固定されます。

2.4. DataVolume の使用による仮想マシンイメージのインポート

既存の仮想マシンイメージは OpenShift Container Platform クラスターにインポートできます。Container-native Virtualization は DataVolume を使用してデータのインポートおよび基礎となる PersistentVolumeClaim (PVC) の作成を自動化します。

注意

ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。

サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムによって異なります。詳細は、該当するオペレーティングシステムのドキュメントを参照してください。

前提条件

2.4.1. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーS3 バケットアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
✓ GZ*
✓ XZ*

Archive+

✓ TAR

✓ TAR

✓ TAR

□ TAR

□ TAR

□ TAR

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

+ アーカイブはブロックモード DV をサポートしません。

2.4.2. DataVolume について

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。DataVolume は、基礎となる PersistentVolumeClaim (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。DataVolume は KubeVirt に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

2.4.3. DataVolume の使用による仮想マシンイメージの Container-native Virtualization オブジェクトへのインポート

インポートされたイメージから仮想マシンを作成するには、仮想マシンを作成する前にイメージの場所を VirtualMachine 設定ファイルに指定します。

前提条件

  • oc として知られる OpenShift Container Platform コマンドラインインターフェース (CLI) のインストール
  • RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで xz または gz を使用して圧縮される)
  • イメージがデータソースにアクセスするために必要な認証情報と共にホストされる HTTP エンドポイント
  • 1 つ以上の利用可能な PersistentVolume

手順

  1. インポートする必要のある仮想ディスクイメージをホストする HTTP ファイルサーバーを特定します。正しい形式での完全な URL が必要になります。

  2. データソースに認証情報が必要な場合、endpoint-secret.yaml ファイルを編集し、更新された設定をクラスターに適用します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <endpoint-secret>
      labels:
        app: containerized-data-importer
    type: Opaque
    data:
      accessKeyId: "" 1
      secretKey:   "" 2
    1
    オプション: キーまたはユーザー名 (base64 エンコード)
    2
    オプション: シークレットまたはパスワード、base64 エンコード
    $ oc apply -f endpoint-secret.yaml
  3. 仮想マシン設定ファイルを編集し、インポートする必要のあるイメージのデータソースを指定します。この例では、Fedora イメージがインポートされます。

    apiVersion: kubevirt.io/v1alpha3
    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: 2Gi
            storageClassName: local
          source:
            http:
              url: https://download.fedoraproject.org/pub/fedora/linux/releases/28/Cloud/x86_64/images/Fedora-Cloud-Base-28-1.1.x86_64.qcow2 1
              secretRef: "" 2
              certConfigMap: "" 3
        status: {}
      running: false
      template:
        metadata:
          creationTimestamp: null
          labels:
            kubevirt.io/vm: vm-fedora-datavolume
        spec:
          domain:
            devices:
              disks:
              - disk:
                  bus: virtio
                name: datavolumedisk1
            machine:
              type: ""
            resources:
              requests:
                memory: 64M
          terminationGracePeriodSeconds: 0
          volumes:
          - dataVolume:
              name: fedora-dv
            name: datavolumedisk1
    status: {}
    1
    インポートする必要のあるイメージの HTTP ソース。
    2
    secretRef パラメーターはオプションです。
    3
    certConfigMap はエンドポイントが認証を必要とする場合のみ必要になります。参照される ConfigMap は DataVolume と同じ namespace にある必要があります。
  4. 仮想マシンを作成します。

    $ oc create -f vm-<name>-datavolume.yaml
    注記

    oc create コマンドは、DataVolume および仮想マシンを作成します。CDI コントローラーは適切なアノテーションを使って基礎となる PVC を作成し、インポートプロセスが開始されます。インポートが完了すると、DataVolume のステータスは Succeeded に変更され、仮想マシンの起動が可能になります。

    DataVolume のプロビジョニングはバックグランドで実行されるため、これをモニターする必要はありません。仮想マシンは起動できますが、これはインポートが完了するまで実行されません。

オプションの検証手順

  1. oc get pods を実行し、インポーター Pod を見つけます。この Pod は指定された URL からイメージをダウンロードし、これをプロビジョニングされた PV に保存します。
  2. Succeeded が表示されるまで DataVolume のステータスをモニターします。

    $ oc describe dv <data-label> 1
    1
    仮想マシン設定ファイルに指定された DataVolume のデータラベル。
  3. プロビジョニングが完了し、VMI が起動したことを検証するには、そのシリアルコンソールへのアクセスを試行します。

    $ virtctl console <vm-fedora-datavolume>

2.4.4. テンプレート: DataVolume 仮想マシン設定ファイル

example-dv-vm.yaml

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: example-vm
  name: example-vm
spec:
  dataVolumeTemplates:
  - metadata:
      name: example-dv
    spec:
      pvc:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1G
      source:
          http:
             url: "" 1
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/vm: example-vm
    spec:
      domain:
        cpu:
          cores: 1
        devices:
          disks:
          - disk:
              bus: virtio
            name: example-dv-disk
        machine:
          type: q35
        resources:
          requests:
            memory: 1G
      terminationGracePeriodSeconds: 0
      volumes:
      - dataVolume:
          name: example-dv
        name: example-dv-disk
1
インポートする必要のあるイメージの HTTP ソース (該当する場合)。

2.4.5. テンプレート: DataVolume インポート設定ファイル

example-import-dv.yaml

apiVersion: cdi.kubevirt.io/v1alpha1
kind: DataVolume
metadata:
  name: "example-import-dv"
spec:
  source:
      http:
         url: "" 1
         secretRef: "" 2
  pvc:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: "1G"
1
インポートする必要のあるイメージの HTTP ソース。
2
secretRef パラメーターはオプションです。

2.5. 仮想マシンの編集

以下のタスクのいずれかを実行して仮想マシンを編集します。

  • Web コンソールの使用
  • 仮想マシン YAML 設定の編集
  • CLI の使用

2.5.1. Web コンソールの使用による仮想マシンの編集

Web コンソールの Virtual Machine Overview 画面で仮想マシンの選択する値 (select values) を編集します。他の値は、CLI を使用して編集できます。変更内容は、仮想マシンを再起動するまで表示されません。

前提条件

  • Virtual Machine Overview 画面から編集する場合、仮想マシンは オフ である必要があります。

手順

  1. サイドメニューから WorkloadsVirtual Machines をクリックします。
  2. 仮想マシンを選択します。
  3. Edit をクリックして、編集可能なフィールドを選択可能にします。
  4. FlavorCustom のみに変更できます。 これにより、CPU および Memory の追加フィールドが提供されます。
  5. Save をクリックします。

    値と仮想マシンは、操作の処理後に更新されます。

    仮想マシンが実行中の場合、変更内容は仮想マシンが再起動されるまで表示されません。

2.5.2. 仮想マシン YAML 設定の編集

Web コンソールで仮想マシンの YAML 設定を編集します。

すべてのパラメーターを更新できる訳ではありません。変更不可の値を編集し、Save をクリックすると、更新できなかったパラメーターを示すエラーメッセージが出されます。

YAML 設定は、仮想マシンが Running の場合に編集できますが、変更は仮想マシンが停止され、再度起動された後にのみ有効になります。

注記

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

手順

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

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

2.5.3. CLI の使用による仮想マシンの編集

前提条件

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

手順

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

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

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

      oc apply

2.6. 仮想マシンの削除

以下のいずれかの手順を使用して、仮想マシンを削除します。

  • Web コンソールの使用
  • CLI の使用

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

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

WorkloadsVirtual Machines 一覧で仮想マシンの ⋮ ボタンを使用するか、または Virtual Machine Details 画面の Actions コントロールを使用して仮想マシンを削除します。

手順

  1. Container-native Virtualization コンソールのサイドメニューから WorkloadsVirtual Machines をクリックします。
  2. 削除する仮想マシンの ⋮ ボタンをクリックして Delete Virtual Machine を選択します。

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

2.6.2. CLI の使用による仮想マシンおよび PVC の削除

仮想マシンを削除すると、その仮想マシンが使用する PVC のバインドは解除されます。

この PVC を異なる仮想マシンにバインドする予定がない場合、クリーンな環境を維持し、混乱の生じる可能性を未然防ぐべくこれを削除することが推奨されます。

手順

これらのコマンドを実行して、仮想マシンと PVC を削除します。

注記

プロジェクト名について -n <project_name> オプションを指定しない限り、使用しているプロジェクトのオブジェクトしか削除することができません。

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

    $ oc delete vm <fedora-vm>
  2. 以下のコマンドを実行し、仮想マシンに関連付けられた PVC を削除します。

    $ oc delete pvc <fedora-vm-pvc>

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

Container-native Virtualization を使用すると、Web コンソールおよびコマンドラインインターフェース (CLI) から仮想マシンを停止し、起動し、再起動できます。

2.7.1. Web コンソールからの仮想マシンの制御

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

2.7.1.1. 仮想マシンの起動

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

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. この画面から仮想マシンを起動します。 これにより、1 つの画面で複数のマシンに対してアクションを実行することがより容易になります。 または、Virtual Machine Details 画面から仮想マシンを起動することもできます。 この場合、選択された仮想マシンの総合的な詳細情報を確認できます。

    • ディスクの Options メニュー kebab を を仮想マシンの末尾でクリックし、Start Virtual Machine を選択します。
    • 仮想マシン名をクリックして Virtual Machine Details 画面を開き、Actions をクリックして Start Virtual Machine を選択します。
  3. 確認ウィンドウで Start をクリックし、仮想マシンを起動します。
注記

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

2.7.1.2. 仮想マシンの再起動

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

重要

ステータスが Importing の仮想マシンは再起動しないでください。この仮想マシンを再起動すると、エラーが発生します。

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. この画面から仮想マシンを再起動します。 これにより、1 つの画面で複数のマシンに対してアクションを実行することがより容易になります。 または、Virtual Machine Details 画面から仮想マシンを起動することもできます。 この場合、選択された仮想マシンの総合的な詳細情報を確認できます。

    • ディスクの Options メニュー kebab を を仮想マシンの末尾でクリックし、Restart Virtual Machineを選択します。
    • 仮想マシン名をクリックして Virtual Machine Details 画面を開き、Actions クリックして Restart Virtual Machine を選択します。
  3. 確認ウィンドウで Restart をクリックし、仮想マシンを再起動します。

2.7.1.3. 仮想マシンの停止

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

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. この画面から仮想マシンを停止します。 これにより、1 つの画面で複数のマシンに対してアクションを実行することがより容易になります。 または、Virtual Machine Details 画面から仮想マシンを停止することもできます。 この場合、選択された仮想マシンの総合的な詳細情報を確認できます。

    • ディスクの Options メニュー kebab を を仮想マシンの末尾でクリックし、Stop Virtual Machineを選択します。
    • 仮想マシン名をクリックして Virtual Machine Details 画面を開き、Actions クリックして Stop Virtual Machine を選択します。
  3. 確認ウィンドウで Stop をクリックし、仮想マシンを停止します。

2.7.2. 仮想マシンを制御するための CLI リファレンス

以下の virtctl クライアントユーティリティーおよび oc コマンドを使用して仮想マシンの状態を変更し、仮想マシンおよびそれらを表す仮想マシンインスタンスの一覧を表示します。

注記

virtctl コマンドを実行する場合、Web コンソールで仮想マシンを表す仮想マシンインスタンスではなく、仮想マシン自体を変更します。

2.7.2.1. start

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

例: 現行プロジェクトでの仮想マシンの起動

$ virtctl start <example-vm>

例: 特定プロジェクトでの仮想マシンの起動

$ virtctl start <example-vm> -n <project_name>

2.7.2.2. restart

実行中の仮想マシンを再起動します。

例: 現行プロジェクトでの仮想マシンの再起動

$ virtctl restart <example-vm>

例: 特定のプロジェクトでの仮想マシンの再起動

$ virtctl restart <example-vm> -n <project_name>

2.7.2.3. stop

実行中の仮想マシンを停止します。

例: 現行プロジェクトでの仮想マシンの停止

$ virtctl stop <example-vm>

例: 特定のプロジェクトでの仮想マシンの停止

$ virtctl stop <example-vm> -n <project_name>

2.7.2.4. list

プロジェクトに仮想マシンまたは仮想マシンインスタンスを一覧表示します。仮想マシンインスタンスは仮想マシン自体を抽象化したものです。

例: 現行プロジェクトでの仮想マシンの一覧表示

$ oc get vm

例: 特定プロジェクトでの仮想マシンの一覧表示

$ oc get vm -n <project_name>

例: 現行プロジェクトでの実行中の仮想マシンインスタンスの一覧表示

$ oc get vmi

例: 特定プロジェクトでの実行中の仮想マシンインスタンスの一覧表示

$ oc get vmi -n <project_name>

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

Container-native Virtualization は、異なる製品タスクを実現するために使用できる異なる仮想マシンコンソールを提供します。Web コンソールおよび CLI コマンドを使用してこれらのコンソールにアクセスできます。

2.8.1. 仮想マシンコンソールのセッション

Web コンソールの Virtual Machine Details 画面の Consoles タブから、実行中の仮想マシンの VNC およびシリアルコンソールに接続することができます。

グラフィカルな VNC コンソールシリアルコンソール の 2 つのコンソールを使用できます。VNC コンソール は、Consoles タブに移動する際には常にデフォルトで開きます。VNC ConsoleSerial Console リストを使用してコンソールを切り換えることができます。

コンソールのセッションは切断しない限り、バックグラウンドでアクティブな状態のままになります。Disconnect before switching チェックボックスがアクティブな場合にコンソールを切り替えると、現在のコンソールセッションは切断され、選択したコンソールの新規セッションが仮想マシンに接続されます。これにより、一度に 1 つのコンソールセッションのみが開かれます。

VNC コンソール のオプション

Send Key ボタンでは、仮想マシンに送信するキーの組み合わせを一覧表示します。

シリアルコンソール のオプション

Disconnect ボタンを使用して、仮想マシンから Serial Console セッションを手動で切断します。
Reconnect ボタンを使用して Serial Console セッションを仮想マシンに対して手動で開きます。

2.8.1.1. Webコンソールの使用による仮想マシンへの接続

Web コンソールを使用して仮想マシンに接続することができます。

手順

  1. 正しいプロジェクトを指定していることを確認します。そうでない場合は、Project 一覧をクリックして適切なプロジェクトを選択します。
  2. ApplicationsVirtual Machines をクリックして、プロジェクトに仮想マシンを表示します。
  3. 仮想マシンを選択します。
  4. Overview タブで、virt-launcher-<vm-name> Pod をクリックします。
  5. Terminal タブをクリックします。ターミナルが空白の場合、ターミナルをクリックし、任意のキーを押して接続を開始します。

2.8.1.2. シリアルコンソールへの接続

Web コンソールの Virtual Machine Details 画面の Consoles タブから、実行中の仮想マシンの Serial Console に接続します。

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. 仮想マシンを選択します。
  3. Consoles をクリックします。VNC コンソールがデフォルトで開きます。
  4. VNC Console ドロップダウンリストをクリックし、Serial Console を選択します。

2.8.1.3. VNC コンソールへの接続

Web コンソールの Virtual Machine Details 画面の Consoles タブから、実行中の仮想マシンの VNC コンソールに接続します。

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. 仮想マシンを選択します。
  3. Consoles をクリックします。VNC コンソールがデフォルトで開きます。

2.8.1.4. RDP コンソールへの接続

Remote Desktop Protocol (RDP) を使用するデスクトップビューアーコンソールは、Windows 仮想マシンに接続するためのより使いやすいコンソールを提供します。

RDP を使用して Windows 仮想マシンに接続するには、Web コンソールの Virtual Machine Details 画面の Consoles タブから仮想マシンの console.rdp ファイルをダウンロードし、これを優先する RDP クライアントに指定します。

前提条件

  • QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。qemu-guest-agent は VirtIO ドライバーに含まれています。
  • 仮想マシンに接続されたレイヤー2 vNIC。
  • Windows 仮想マシンと同じネットワーク上のマシンにインストールされた RDP クライアント。

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. Windows 仮想マシンを選択します。
  3. Consoles タブをクリックします。
  4. Consoles 一覧をクリックし、Desktop Viewer を選択します。
  5. Network Interface 一覧で、レイヤー 2 vNIC を選択します。
  6. Launch Remote Desktop をクリックし、 console.rdp ファイルをダウンロードします。
  7. RDP クライアントを開き、console.rdp ファイルを参照します。たとえば、remmina を使用します。

    $ remmina --connect /path/to/console.rdp
  8. Administrator ユーザー名およびパスワードを入力して、Windows 仮想マシンに接続します。

2.8.2. CLI コマンドの使用による仮想マシンコンソールへのアクセス

2.8.2.1. SSH 経由での仮想マシンインスタンスへのアクセス

仮想マシンにポート 22 を公開した後に、SSH を使用して仮想マシンにアクセスできます。

virtctl expose コマンドは、仮想マシンインスタンスのポートをノードポートに転送し、有効にされたアクセスのサービスを作成します。以下の例では、fedora-vm-ssh サービスを作成します。 このサービスは、<fedora-vm> 仮想マシンのポート 22 をノード上のポートに転送します。

前提条件

  • アクセスする仮想マシンインスタンスが実行中であること。
  • oc として知られる OpenShift コマンドラインインターフェース (CLI) のインストール。

手順

  1. 以下のコマンドを実行して fedora-vm-ssh サービスを作成します。

    $ virtctl expose vm <fedora-vm> --port=20022 --target-port=22 --name=fedora-vm-ssh --type=NodePort 1
    1
    <fedora-vm> は、fedora-vm-ssh サービスを実行する仮想マシンの名前です。
  2. サービスをチェックし、サービスが取得したポートを見つけます。

    $ oc get svc
    NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
    fedora-vm-ssh   NodePort   127.0.0.1      <none>        20022:32551/TCP   6s

    この例では、サービスは 32551 ポートを取得しています。

  3. SSH 経由で仮想マシンインスタンスにログインします。ノードの ipAddress および直前の手順で確認したポートを使用します。

    $ ssh username@<node_IP_address> -p 32551

2.8.2.2. 仮想マシンインスタンスのシリアルコンソールへのアクセス

virtctl console コマンドは、指定された仮想マシンインスタンスへのシリアルコンソールを開きます。

前提条件

  • virt-viewer パッケージがインストールされていること。
  • アクセスする仮想マシンインスタンスが実行中であること。

手順

  • virtctl でシリアルコンソールに接続します。

    $ virtctl console <VMI>

2.8.2.3. VNC を使用した仮想マシンインスタンスのグラフィカルコンソールへのアクセス

virtctl クライアントユーティリティーは remote-viewer 機能を使用し、実行中の仮想マシンインスタンスに対してグラフィカルコンソールを開くことができます。この機能は virt-viewer パッケージに組み込まれています。

前提条件

  • virt-viewer パッケージがインストールされていること。
  • アクセスする仮想マシンインスタンスが実行中であること。
注記

リモートマシンで SSH 経由で virtctl を使用する場合、X セッションをマシンに転送する必要があります。

手順

  1. virtctl ユーティリティーを使用してグラフィカルインターフェースに接続します。

    $ virtctl vnc <VMI>
  2. コマンドが失敗した場合には、トラブルシューティング情報を収集するために -v フラグの使用を試行します。

    $ virtctl vnc <VMI> -v 4

2.8.2.4. RDP コンソールの使用による Windows 仮想マシンへの接続

Remote Desktop Protocol (RDP) は、Windows 仮想マシンに接続するためのより使いやすいコンソールを提供します。

RDP を使用して Windows 仮想マシンに接続するには、割り当てられた L2 vNIC の IP アドレスを RDP クライアントに対して指定します。

前提条件

  • QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。qemu-guest-agent は VirtIO ドライバーに含まれています。
  • 仮想マシンに接続されたレイヤー2 vNIC。
  • Windows 仮想マシンと同じネットワーク上のマシンにインストールされた RDP クライアント。

手順

  1. アクセストークンを持つユーザーとして、oc CLI ツールを使って Container-native Virtualization クラスターにログインします。

    $ oc login -u <user> https://<cluster.example.com>:8443
  2. 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
    ...
  3. レイヤー 2 ネットワークインターフェースの IP アドレスを特定し、これをコピーします。これは直前の例では 192.0.2.0 であり、IPv6 を選択する場合は 2001:db8:: になります。
  4. RDP クライアントを開き、接続用に直前の手順でコピーした IP アドレスを使用します。
  5. Administrator ユーザー名およびパスワードを入力して、Windows 仮想マシンに接続します。

2.9. CLI ツールの使用

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

  • Container-native Virtualization virtctl クライアント
  • OpenShift Container Platform oc クライアント

2.9.1. Virtctl クライアントコマンド

virtctl クライアントは、Container-native Virtualization リソースを管理するためのコマンドラインユーティリティーです。以下の表には、Container-native Virtualization のドキュメント全体で使用されている virtctl コマンドが記載されています。

表2.3 virtctl クライアントコマンド

コマンド説明

virtctl start <vm>

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

virtctl stop <vm>

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

virtctl restart <vm>

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

virtctl expose <vm>

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

virtctl console <vmi>

仮想マシンインスタンスのシリアルコンソールに接続します。

virtctl vnc <vmi>

仮想マシンインスタンスへの VNC 接続を開きます。

virtctl image-upload <…​>

仮想マシンイメージを PersistentVolumeClaim にアップロードします。

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

OpenShift Container Platform oc クライアントは、OpenShift Container Platform リソースを管理するためのコマンドラインユーティリティーです。以下の表には、Container-native Virtualization のドキュメント全体で使用される oc コマンドが記載されています。

表2.4 oc コマンド

コマンド説明

oc login -u <user_name>

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

oc get <object_type>

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

oc describe <object_type> <resource_name>

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

oc create -f <object_config>

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

oc edit <object_type> <resource_name>

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

oc delete <object_type> <resource_name>

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

oc クライアントコマンドのより総合的な情報については、『OpenShift Container Platform CLI リファレンス』を参照してください。

2.10. 管理タスクの自動化

Container-native Virtualization の管理タスクは、Red Hat Ansible Automation を使用して自動化できます。Ansible Playbook を使用して新規の仮想マシンを作成する際の基本事項を確認します。

2.10.1. Red Hat Ansible Automation について

Ansible は、システムの設定、ソフトウェアのデプロイ、およびローリングアップデートの実行に使用する自動化ツールです。Ansible には Container-native Virtualization のサポートが含まれ、Ansible モジュールを使用すると、テンプレート、Persistent Volume Claim (PVC、永続ボリューム要求) および仮想マシンの操作などのクラスター管理タスクを自動化できます。

Ansible は、oc CLI ツールや API を使用しても実行できるContainer-native Virtualization の管理を自動化する方法を提供します。Ansible は、KubeVirt モジュールを他の Ansible モジュールと統合できる点でユニークであると言えます。

2.10.2. Red Hat Ansible Automation による仮想マシン作成の自動化

kubevirt_vm Ansible Playbook を使用して、OpenShift Container Platform クラスターに仮想マシンを作成できます。

前提条件

手順

  1. kubevirt_vm タスクを含むように Ansible Playbook YAML ファイルを編集します。

      kubevirt_vm:
        namespace:
        name:
        cpu_cores:
        memory:
        disks:
          - name:
            volume:
              containerDisk:
                image:
            disk:
              bus:
    注記

    このスニペットには Playbook の kubevirt_vm 部分のみが含まれます。

  2. namespacecpu_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
  3. 仮想マシンを作成後すぐに起動する必要がある場合には、state: running を YAML ファイルに追加します。例:

      kubevirt_vm:
        namespace: default
        name: vm1
        state: running 1
        cpu_cores: 1
    1
    この値を state: absent に変更すると、すでに存在する場合に仮想マシンは削除されます。
  4. Playbook のファイル名を引数としてのみ使用して、 ansible-playbook コマンドを実行します。

    $ ansible-playbook create-vm.yaml
  5. 出力を確認し、プレイが正常に実行されたかどうかを確認します。

    (...)
    TASK [Create my first VM] ************************************************************************
    changed: [localhost]
    
    PLAY RECAP ********************************************************************************************************
    localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
  6. Playbook ファイルに state: running を含めず、すぐに仮想マシンを起動する必要がある場合には、 state: running を含めるようにファイルを編集し、Playbook を再度実行します。

    $ ansible-playbook create-vm.yaml

仮想マシンが作成されたことを確認するには、仮想マシンコンソールへのアクセスを試行します。

2.10.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

2.11. Container-native Virtualization でのデフォルト Pod ネットワークの使用

Container-native Virtualization でデフォルトの Pod ネットワークを使用できます。これを実行するには、masquerade バインディングメソッドを使用する必要があります。これは、デフォルトの Pod ネットワークを使用する場合にのみ推奨されるバインディングメソッドです。デフォルト以外のネットワークには、masquerade モードを使用しないでください。

注記

セカンダリーネットワークの場合は、bridge バインディングメソッドを使用します。

2.11.1. コマンドラインでのマスカレードモードの設定

マスカレードモードを使用し、仮想マシンの送信トラフィックを Pod IP アドレスの背後で非表示にすることができます。マスカレードモードは、ネットワークアドレス変換 (NAT) を使用して仮想マシンを Linux ブリッジ経由で Pod ネットワークバックエンドに接続します。

仮想マシンの設定ファイルを編集して、マスカレードモードを有効にし、トラフィックが仮想マシンに到達できるようにします。

前提条件

  • 仮想マシンは、IPv4 アドレスを取得するために DHCP を使用できるように設定される必要があります。以下の例では、DHCP を使用するように設定されます。

手順

  1. 仮想マシン設定ファイルの interfaces 仕様を編集します。

    kind: VirtualMachine
    spec:
      domain:
        devices:
          interfaces:
            - name: red
              masquerade: {} 1
              ports:
                - port: 80 2
      networks:
      - name: red
        pod: {}
    1
    マスカレードモードを使用した接続
    2
    ポート 80 での受信トラフィックの許可
  2. 仮想マシンを作成します。

    $ oc create -f <vm-name>.yaml

2.11.2. Web コンソール

Container-native Virtualization Web コンソールウィザードから仮想マシンを作成する場合、Networking 画面で必要なバインディングメソッドを選択します。

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

名前説明

Create NIC

仮想マシンの新規 NIC を作成します。

NIC NAME

NIC の名前。

MAC ADDRESS

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

NETWORK CONFIGURATION

利用可能な NetworkAttachmentDefinition オブジェクトの一覧。

BINDING METHOD

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

PXE NIC

PXE 対応ネットワークの一覧。PXEProvision Source として選択されている場合にのみ表示されます。

2.11.3. 設定ファイルのサンプル

2.11.3.1. テンプレート: 仮想マシンの設定ファイル

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  name: example-vm
  namespace: default
spec:
  running: false
  template:
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - masquerade: {}
            name: default
        resources:
          requests:
            memory: 1024M
      networks:
        - name: default
          pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: kubevirt/fedora-cloud-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userData: |
              #!/bin/bash
              echo "fedora" | passwd fedora --stdin

2.11.3.2. テンプレート: Windows 仮想マシンインスタンスの設定ファイル

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstance
metadata:
  labels:
    special: vmi-windows
  name: vmi-windows
spec:
  domain:
    clock:
      timer:
        hpet:
          present: false
        hyperv: {}
        pit:
          tickPolicy: delay
        rtc:
          tickPolicy: catchup
      utc: {}
    cpu:
      cores: 2
    devices:
      disks:
      - disk:
          bus: sata
        name: pvcdisk
      interfaces:
      - masquerade: {}
        model: e1000
        name: default
    features:
      acpi: {}
      apic: {}
      hyperv:
        relaxed: {}
        spinlocks:
          spinlocks: 8191
        vapic: {}
    firmware:
      uuid: 5d307ca9-b3ef-428c-8861-06e72d69f223
    machine:
      type: q35
    resources:
      requests:
        memory: 2Gi
  networks:
  - name: default
    pod: {}
  terminationGracePeriodSeconds: 0
  volumes:
  - name: pvcdisk
    persistentVolumeClaim:
      claimName: disk-windows

2.12. 仮想マシンの複数ネットワークへの割り当て

Container-native Virtualization は、仮想マシンの複数ネットワークへの接続を可能にするレイヤー 2 ネットワーク機能を提供します。複数インターフェースへのアクセスによって異なる既存のワークロードを持つ仮想マシンをインポートできます。また、仮想マシンをネットワーク経由で起動できるように PXE ネットワークを設定することもできます。

最初に、ネットワーク管理者はタイプ cnv-bridge の NetworkAttachmentDefinition を設定します。次に、ユーザーは Pod、仮想マシンインスタンス、および仮想マシンをブリッジネットワークに割り当てることができます。Container-native Virtualization Web コンソールから、ブリッジネットワークを参照する vNIC を作成できます。

2.12.1. Container-native Virtualization ネットワークの用語集

Container-native Virtualization は、カスタムリソースおよびプラグインを使用して高度なネットワーク機能を提供します。

以下の用語は、Container-native Virtualization ドキュメント全体で使用されています。

Container Network Interface (CNI)
コンテナーのネットワーク接続に重点を置く Cloud Native Computing Foundation プロジェクト。Container-native Virtualization は CNI プラグインを使用して基本的な Kubernetes ネットワーク機能を強化します。
Multus
複数の CNI の存在を可能にし、Pod または仮想マシンが必要なインターフェースを使用できるようにする「メタ」 CNI プラグイン。
カスタムリソース定義 (CRD、Customer Resource Definition)
カスタムリソースの定義を可能にする Kubernetes API リソース、または CRD API リソースを使用して定義されるオブジェクト。
NetworkAttachmentDefinition
Pod、仮想マシン、および仮想マシンインスタンスを 1 つ以上のネットワークに割り当てることを可能にする Multus プロジェクトによって導入される CRD。
PXE (Preboot eXecution Environment)
管理者がネットワーク経由でサーバーからクライアントマシンを起動できるようにするインターフェース。ネットワークのブートにより、オペレーティングシステムおよび他のソフトウェアをクライアントにリモートでロードできます。

2.12.2. リソースのブリッジベースのネットワークへの接続

ネットワーク管理者は、タイプ cnv-bridge の NetworkAttachmentDefinition をレイヤー 2 ネットワークを Pod および仮想マシンに提供するように設定できます。

前提条件

  • Container-native Virtualization 2.0 以降
  • Linux ブリッジはすべてのノードで設定され、適切な Network Interface Card に割り当てられる必要があります。
  • VLAN を使用する場合、vlan_filtering はブリッジで有効にされる必要があります。
  • NIC はすべての関連する VLAN に対してタグ付けされる必要があります。

    • 例: bridge vlan add dev bond0 vid 1-4095 master

手順

  1. 任意のローカルディレクトリーで NetworkAttachmentDefinition の新規ファイルを作成します。このファイルには、お使いの設定に合わせて変更された以下の内容が含まれる必要があります。

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: a-bridge-network
      annotations:
        k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/br0 1
    spec:
      config: '{
        "cniVersion": "0.3.0",
        "name": "a-bridge-network", 2
        "type": "cnv-bridge", 3
        "bridge": "br0", 4
        "isGateway": true,
        "ipam": {}
    }'
    1
    このアノテーションを NetworkAttachmentDefinition に追加する場合、仮想マシンインスタンスは br0 ブリッジが接続されているノードでのみ実行されます。
    2
    name 値は、次の手順で使用するアノテーションの一部を構成します。
    3
    この NetworkAttachmentDefinition のネットワークを提供する Container Network Interface (CNI) プラグインの実際の名前。異なる CNI を使用するのでない限り、このフィールドは変更しないでください。
    4
    ブリッジの名前が br0 でない場合、ブリッジの実際の名前に置き換える必要があります。
    $ oc create -f <resource_spec.yaml>
  2. ブリッジネットワークに接続する必要のある仮想マシンまたは仮想マシンインスタンスの設定を編集します。

    apiVersion: v1
    kind: VirtualMachine
    metadata:
      name: example-vm
      annotations:
        k8s.v1.cni.cncf.io/networks: a-bridge-network 1
    spec:
    ...
    1
    NetworkAttachmentDefinition の実際の name 値に置き換える必要があります。

    この例では、NetworkAttachmentDefinition および Pod が同じ namespace に置かれています。

    異なる namespace を指定するには、以下の構文を使用します。

    ...
      annotations:
        k8s.v1.cni.cncf.io/networks: <namespace>/a-bridge-network
    ...
  3. 設定ファイルをリソースに適用します。

    $ oc create -f <local/path/to/network-attachment-definition.yaml>
注記

次のセクションで vNIC を定義する際に、NETWORK の値が直前のセクションで作成した NetworkAttachmentDefinition のブリッジネットワーク名であることを確認します。

2.12.3. 仮想マシンの NIC の作成

Web コンソールから追加の NIC を作成し、これを仮想マシンに割り当てます。

手順

  1. Container-native Virtualization コンソールの適切なプロジェクトで、WorkloadsVirtual Machines をクリックします。
  2. 仮想マシンテンプレートを選択します。
  3. Network Interfaces をクリックし、仮想マシンにすでに割り当てられている NIC を表示します。
  4. Create NIC をクリックして、新規スロットを一覧に作成します。
  5. 新規 NIC の NAMENETWORKMAC ADDRESS、および BINDING METHOD に入力します。
  6. ボタンをクリックして NIC を保存し、これを仮想マシンに割り当てます。

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

名前説明

Create NIC

仮想マシンの新規 NIC を作成します。

NIC NAME

NIC の名前。

MAC ADDRESS

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

NETWORK CONFIGURATION

利用可能な NetworkAttachmentDefinition オブジェクトの一覧。

BINDING METHOD

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

PXE NIC

PXE 対応ネットワークの一覧。PXEProvision Source として選択されている場合にのみ表示されます。

仮想マシンにオプションの QEMU ゲストエージェントをインストールし、ホストが追加のネットワークについての関連情報を表示できるようにします。

2.13. QEMU ゲストエージェントの仮想マシンへのインストール

QEMU ゲストエージェントは仮想マシンで実行されるデーモンです。エージェントは仮想マシン上で、追加ネットワークの IP アドレスなどのネットワーク情報をホストに渡します。

2.13.1. QEMU ゲストエージェントの Linux 仮想マシンへのインストール

qemu-guest-agent は広く利用されており、Red Hat 仮想マシンでデフォルトで利用できます。このエージェントをインストールし、サービスを起動します。

手順

  1. コンソールのいずれか、または SSH を使用して仮想マシンのコマンドラインにアクセスします。
  2. QEMU ゲストエージェントを仮想マシンにインストールします。

    $ yum install -y qemu-guest-agent
  3. QEMU ゲストエージェントサービスを起動します。

    $ systemctl start qemu-guest-agent
  4. サービスに永続性があることを確認します。

    $ systemctl enable qemu-guest-agent

Web コンソールで仮想マシンまたは仮想マシンテンプレートのいずれかを作成する際に、ウィザードの cloud-init:*Use custom script* フィールドを使用して QEMU ゲストエージェントをインストールし、起動することもできます。

Windows 仮想マシンの場合、QEMU ゲストエージェントは、既存の Windows 仮想マシンに、または仮想マシンへの Windows のインストール時にインストールできる VirtIO ドライバーに組み込まれます。

2.14. vNIC の IP アドレスの仮想マシンへの表示

QEMU ゲストエージェントは仮想マシンで実行され、割り当てられた vNIC の IP アドレスをホストに渡します。 これにより、Web コンソールおよび oc クライアントの両方から IP アドレスを表示できます。

前提条件

2.14.1. CLI での仮想マシンインターフェースの IP アドレスの表示

ネットワークインターフェース設定は oc describe vmi <vmi_name> コマンドに含まれます。

IP アドレス情報は、仮想マシン上で ip addr を実行するか、または oc get vmi <vmi_name> -o yaml を実行して表示することもできます。

手順

  • oc describe コマンドを使用して、仮想マシンインターフェース設定を表示します。

    $ oc describe vmi <vmi_name>
    
    ...
    Interfaces:
       Interface Name:  eth0
       Ip Address:      10.244.0.37/24
       Ip Addresses:
         10.244.0.37/24
         fe80::858:aff:fef4:25/64
       Mac:             0a:58:0a:f4:00:25
       Name:            default
       Interface Name:  v2
       Ip Address:      1.1.1.7/24
       Ip Addresses:
         1.1.1.7/24
         fe80::f4d9:70ff:fe13:9089/64
       Mac:             f6:d9:70:13:90:89
       Interface Name:  v1
       Ip Address:      1.1.1.1/24
       Ip Addresses:
         1.1.1.1/24
         1.1.1.2/24
         1.1.1.4/24
         2001:de7:0:f101::1/64
         2001:db8:0:f101::1/64
         fe80::1420:84ff:fe10:17aa/64
       Mac:             16:20:84:10:17:aa

2.14.2. Web コンソールでの仮想マシンインターフェースの IP アドレスの表示

IP 情報は、仮想マシンの Virtual Machine Overview 画面に表示されます。

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. 仮想マシンの名前をクリックして、Virtual Machine Overview 画面を開きます。

それぞれの割り当てられた vNIC の情報は IP ADDRESSES の下に表示されます。

2.15. 仮想マシンの PXE ブートの設定

PXE ブートまたはネットワークブートは Container-native Virtualization で利用できます。ネットワークブートにより、ローカルに割り当てられたストレージデバイスなしにコンピューターを起動し、オペレーティングシステムまたは他のプログラムを起動し、ロードすることができます。たとえば、これにより、新規ホストのデプロイ時に PXE サーバーから必要な OS イメージを選択できます。

前提条件

  • Linux ブリッジが接続されていること
  • PXE サーバーがブリッジとして同じ VLAN に接続されていること。

2.15.1. Container-native Virtualization ネットワークの用語集

Container-native Virtualization は、カスタムリソースおよびプラグインを使用して高度なネットワーク機能を提供します。

以下の用語は、Container-native Virtualization ドキュメント全体で使用されています。

Container Network Interface (CNI)
コンテナーのネットワーク接続に重点を置く Cloud Native Computing Foundation プロジェクト。Container-native Virtualization は CNI プラグインを使用して基本的な Kubernetes ネットワーク機能を強化します。
Multus
複数の CNI の存在を可能にし、Pod または仮想マシンが必要なインターフェースを使用できるようにする「メタ」 CNI プラグイン。
カスタムリソース定義 (CRD、Customer Resource Definition)
カスタムリソースの定義を可能にする Kubernetes API リソース、または CRD API リソースを使用して定義されるオブジェクト。
NetworkAttachmentDefinition
Pod、仮想マシン、および仮想マシンインスタンスを 1 つ以上のネットワークに割り当てることを可能にする Multus プロジェクトによって導入される CRD。
PXE (Preboot eXecution Environment)
管理者がネットワーク経由でサーバーからクライアントマシンを起動できるようにするインターフェース。ネットワークのブートにより、オペレーティングシステムおよび他のソフトウェアをクライアントにリモートでロードできます。

2.15.2. MAC アドレスを指定した PXE ブート

まず、管理者は PXE ネットワークの NetworkAttachmentDefinition オブジェクトを作成し、ネットワーク経由でクライアントを起動できます。次に、仮想マシンインスタンスの設定ファイルで NetworkAttachmentDefinition を参照して仮想マシンインスタンスを起動します。また PXE サーバーで必要な場合には、仮想マシンインスタンスの設定ファイルで MAC アドレスを指定することもできます。

前提条件

  • Linux ブリッジが接続されていること。
  • PXE サーバーがブリッジとして同じ VLAN に接続されていること。

手順

  1. クラスターに PXE ネットワークを設定します。

    1. PXE ネットワーク pxe-net-conf の NetworkAttachmentDefinition ファイルを作成します。

      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",
                "ipam": {}
              },
              {
                "type": "cnv-tuning" 1
              }
            ]
          }'
      1
      cnv-tuning プラグインは、カスタム MAC アドレスのサポートを提供します。
      注記

      仮想マシンインスタンスは、必要な VLAN のアクセスポートでブリッジ br1 に割り当てられます。

  2. 直前の手順で作成したファイルを使用して NetworkAttachmentDefinition オブジェクトを作成します。

    $ oc create -f pxe-net-conf.yaml
  3. 仮想マシンインスタンス設定ファイルを、インターフェースおよびネットワークの詳細を含めるように編集します。

    1. PXE サーバーで必要な場合には、ネットワークおよび MAC アドレスを指定します。MAC アドレスが指定されていない場合、値は自動的に割り当てられます。ただし、この時点で自動的に割り当てられる MAC アドレスは永続しないことに注意してください。

      bootOrder1 に設定されており、インターフェースが最初に起動することを確認します。この例では、インターフェースは <pxe-net> というネットワークに接続されています。

      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1
      注記

      複数のインターフェースおよびディスクのブートの順序はグローバル順序になります。

    2. オペレーティングシステムのプロビジョニング後に起動が適切に実行されるよう、ブートデバイス番号をディスクに割り当てます。

      ディスク bootOrder の値を 2 に設定します。

      devices:
        disks:
        - disk:
            bus: virtio
          name: containerdisk
          bootOrder: 2
    3. 直前に作成された NetworkAttachmentDefinition に接続されるネットワークを指定します。このシナリオでは、<pxe-net><pxe-net-conf> という NetworkAttachmentDefinition に接続されます。

      networks:
      - name: default
        pod: {}
      - name: pxe-net
        multus:
          networkName: pxe-net-conf
  4. 仮想マシンインスタンスを作成します。

    $ oc create -f vmi-pxe-boot.yaml
      virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created
  5. 仮想マシンインスタンスの実行を待機します。

    $ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
      phase: Running
  6. VNC を使用して仮想マシンインスタンスを表示します。

    $ virtctl vnc vmi-pxe-boot
  7. ブート画面で、PXE ブートが正常に実行されていることを確認します。
  8. 仮想マシンインスタンスにログインします。

    $ virtctl console vmi-pxe-boot
  9. 仮想マシンのインターフェースおよび 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

2.15.3. テンプレート: PXE ブートの仮想マシンインスタンス設定ファイル

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstance
metadata:
  creationTimestamp: null
  labels:
    special: vmi-pxe-boot
  name: vmi-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: 0
  volumes:
  - name: containerdisk
    containerDisk:
      image: kubevirt/fedora-cloud-container-disk-demo
  - cloudInitNoCloud:
      userData: |
        #!/bin/bash
        echo "fedora" | passwd fedora --stdin
    name: cloudinitdisk
status: {}

2.16. ゲストメモリーの管理

ゲストメモリー設定を特定のユースケースに合わせて調整する必要がある場合、ゲストの YAML 設定ファイルを編集してこれを実行できます。Container-native Virtualization は、ゲストメモリーのオーバーコミットの設定と、ゲストメモリーのオーバーコミットアカウンティングの無効化を許可します。

この手順にはどちらの場合もリスクが伴います。そのため、経験のある管理者のみが対応するようにしてください。

2.16.1. ゲストメモリーのオーバーコミットの設定

仮想ワークロードに利用可能な量を上回るメモリーが必要な場合、メモリーのオーバーコミットを使用してホストのメモリーのすべてまたはそのほとんどを仮想マシンインスタンスに割り当てることができます。メモリーのオーバーコミットを有効にすることは、通常ホストに予約されるリソースを最大化できることを意味します。

たとえば、ホストに 32 GB RAM がある場合、メモリーのオーバーコミットを使用してそれぞれ 4 GB RAM を持つ 8 つの仮想マシンに対応できます。これは、仮想マシンがそれらのメモリーのすべてを同時に使用しないという前提で機能します。

手順

  1. 仮想マシンインスタンスに対し、クラスターから要求された以上のメモリーが利用可能であることを明示的に示すために、仮想マシン設定ファイルを編集し、spec.domain.memory.guestspec.domain.resources.requests.memory よりも高い値に設定します。このプロセスはメモリーのオーバーコミットと呼ばれています。

    以下の例では、1024M がクラスターから要求されますが、仮想マシンインスタンスには 2048M が利用可能であると通知されます。ノードに利用可能な空のメモリーが十分にある限り、仮想マシンインスタンスは最大 2048M を消費します。

    kind: VirtualMachine
    spec:
      template:
        domain:
        resources:
            requests:
              memory: 1024M
        memory:
            guest: 2048M
    注記

    ノードがメモリー不足の状態になると、Pod のエビクションルールと同じルールが仮想マシンインスタンスに適用されます。

  2. 仮想マシンを作成します。

    $ oc create -f <file name>.yaml

2.16.2. ゲストメモリーオーバーヘッドアカウンティングの無効化

警告

この手順は、特定のユースケースでのみ有効であり、上級ユーザーのみが試行するようにしてください。

要求する量に加えて、少量のメモリーが各仮想マシンインスタンスによって要求されます。追加のメモリーは、それぞれの VirtualMachineInstance プロセスをラップするインフラストラクチャーに使用されます。

通常は推奨される方法ではありませんが、ゲストメモリーオーバーヘッドアカウンティングを無効にすることでノード上の仮想マシンインスタンスの密度を増やすことは可能です。

手順

  1. ゲストメモリーオーバーヘッドアカウンティングを無効にするには、YAML 設定ファイルを編集し、overcommitGuestOverhead の値を true に設定します。このパラメーターはデフォルトで無効にされています。

    kind: VirtualMachine
    spec:
      template:
        domain:
        resources:
            overcommitGuestOverhead: true
            requests:
              memory: 1024M
    注記

    overcommitGuestOverhead が有効にされている場合、これはゲストのオーバーヘッドをメモリー制限 (ある場合) に追加します。

  2. 仮想マシンを作成します。

    $ oc create -f <file name>.yaml

2.17. 仮想マシンテンプレートの作成

仮想マシンテンプレートの使用は、同様の設定を持つ複数の仮想マシンを作成するための簡単な方法です。テンプレートの作成後、仮想マシンの作成時にテンプレートを参照できます。

2.17.1. Web コンソールでのインタラクティブなウィザードを使用した仮想マシンテンプレートの作成

Web コンソールは、Basic SettingsNetworking、および Storage 画面にナビゲートし、仮想マシンテンプレートの作成プロセスを単純化するインタラクティブなウィザードを特長としています。すべての必須フィールドには * のマークが付けられます。ウィザードは必須フィールドの入力が完了するまで次の画面に移動することを防ぎます。

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machine Templates をクリックします。
  2. Create Template をクリックし、Create with Wizard を選択します。
  3. すべての必須の Basic Settings を入力します。
  4. Next をクリックして Networking 画面に進みます。デフォルトで nic0 という名前の NIC が割り当てられます。

    1. オプション: Create NIC をクリックして追加の NIC を作成します。
    2. オプション: Options メニュー kebab をクリックし、Remove NIC を選択していずれか、またはすべての NIC を削除できます。テンプレートから作成される仮想マシンには、割り当てられている NIC は不要です。NIC は仮想マシンの作成後に作成できます。
  5. Next をクリックして Storage 画面に進みます。

    1. オプション: Create Disk をクリックして追加のディスクを作成します。
    2. オプション: ディスクをクリックして選択可能なフィールドを変更します。✓ ボタンをクリックして変更を保存します。
    3. オプション: Attach Disk をクリックして、Select Storage リストから利用可能なディスクを選択します。

      注記

      URL または Container のいずれかが Basic Settings 画面で Provision Source として選択されてる場合、rootdisk ディスクが作成され、Bootable Disk として仮想マシンに割り当てられます。rootdisk を変更できますが、これを削除することはできません。

      Bootable Disk は、仮想マシンにディスクが割り当てられていない場合、PXE ソースからプロビジョニングされる仮想マシンには不要です。1 つ以上のディスクが仮想マシンに割り当てられている場合、Bootable Disk を 1 つを選択する必要があります。

  6. Create Virtual Machine Template > をクリックします。Results 画面には、仮想マシンテンプレートの JSON 設定ファイルが表示されます。

    テンプレートは WorkloadsVirtual Machine Templates に一覧表示されます。

2.17.2. 仮想マシンテンプレートのインタラクティブなウィザードのフィールド

以下の表は、Create Virtual Machine Template のインタラクティブなウィザードの Basic SettingsNetworking、および Storage ペインのフィールドを説明しています。

2.17.2.1. 仮想マシンテンプレートウィザードのフィールド

名前パラメーター説明

名前

 

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

説明

 

オプションの説明フィールド。

Provision Source

PXE

PXE メニューから仮想マシンをプロビジョニングします。クラスターに PXE 対応の NIC が必要になります。

URL

HTTP または S3 エンドポイントで利用できるイメージから仮想マシンをプロビジョニングします。

Container

クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: kubevirt/cirros-registry-disk-demo

Cloned Disk

プロビジョニングソースはクローン作成されるディスクです。

Import

サポートされているプロバイダーから仮想マシンをインポートします。

Operating System

 

クラスターで利用可能なオペレーティングシステムの一覧。これは、仮想マシンの主なオペレーティングシステムになります。ImportProvider Source として選択する場合、オペレーティングシステムはインポートされる VMware 仮想マシンのオペレーティングシステムに基づいて自動的に入力されます。

Flavor

small、medium、large、tiny、Custom

仮想マシンに割り当てられる CPU およびメモリーの量を決定するプリセット。

Workload Profile

desktop

デスクトップで使用するための仮想マシン設定。

generic

各種ワークロードについてのパフォーマンスと互換性のバランスを取るための仮想マシン設定。

high performance

高パフォーマンスの負荷に対して最適化された仮想マシン設定。

Use cloud-init

 

これを選択すると cloud-init フィールドが有効になります。

2.17.2.2. Cloud-init フィールド

名前説明

Hostname

仮想マシンの特定のホスト名を設定します。

Authenticated SSH Keys

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

Use custom script

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

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

名前説明

Create NIC

仮想マシンの新規 NIC を作成します。

NIC NAME

NIC の名前。

MAC ADDRESS

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

NETWORK CONFIGURATION

利用可能な NetworkAttachmentDefinition オブジェクトの一覧。

BINDING METHOD

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

PXE NIC

PXE 対応ネットワークの一覧。PXEProvision Source として選択されている場合にのみ表示されます。

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

名前説明

Create Disk

仮想マシンの新規ディスクを作成します。

Attach Disk

利用可能な PVC の一覧から、仮想マシンに割り当てる既存のディスクを選択します。

DISK NAME

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

SIZE (GB)

ディスクのサイズ (GB)。

STORAGE CLASS

基礎となる StorageClass の名前。

Bootable Disk

仮想マシンの起動に利用できるディスクの一覧。仮想マシンの Provision SourceURL または Container の場合に rootdisk に固定されます。

2.18. 仮想マシンテンプレートの編集

Web コンソールで仮想マシンテンプレートを編集できます。

2.18.1. Web コンソールでの仮想マシンテンプレートの編集

Web コンソールで仮想マシンテンプレートの YAML 設定を編集できます。

すべてのパラメーターが変更可能である訳ではありません。無効な設定で Save をクリックすると、エラーメッセージで変更できないパラメーターが示唆されます。

注記

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

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machine Templates をクリックします。
  2. テンプレートを選択します。
  3. YAML タブをクリックして編集可能な設定を表示します。
  4. ファイルを編集し、Save をクリックします。

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

2.19. 仮想マシンテンプレートの削除

Web コンソールで仮想マシンテンプレートを削除できます。

2.19.1. Web コンソールでの仮想マシンテンプレートの削除

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

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machine Templates をクリックします。
  2. このペインから仮想マシンテンプレートを削除できます。 これにより、1 つのペインで複数のマシンに対してアクションを実行することがより容易になります。 または、Virtual Machine Template Details ペインから仮想マシンテンプレートを削除することもできます。 この場合、選択されたテンプレートの総合的な詳細情報を確認できます。

    • Options メニュー kebab をクリックし、Delete Template を選択します。
    • テンプレート名をクリックして Virtual Machine Template Details ペインを開き、ActionsDelete Template をクリックします。
  3. 確認のポップアップウィンドウで、Delete をクリックし、テンプレートを永続的に削除します。

2.20. 新規 DataVolume への仮想マシンディスクのクローン作成

DataVolume 設定ファイルでソース PVC を参照し、新規 DataVolume に仮想マシンディスクの PersistentVolumeClaim (PVC) のクローンを作成できます。

前提条件

2.20.1. DataVolume について

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。DataVolume は、基礎となる PersistentVolumeClaim (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。DataVolume は KubeVirt に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

2.20.2. 新規 DataVolume への仮想マシンディスクの PersistentVolumeClaim のクローン作成

既存の仮想マシンディスクの PersistentVolumeClaim (PVC) のクローンを新規 DataVolume に作成できます。その後、新規 DataVolume は新規の仮想マシンに使用できます。

注記

Volume が仮想マシンとは別に作成される場合、DataVolume のライフサイクルは仮想マシンから切り離されます。仮想マシンが削除されても、DataVolume もその関連付けられた PVC も削除されません。

前提条件

  • 使用する既存の仮想マシンディスクの PVC を判別します。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
  • oc として知られる OpenShift コマンドラインインターフェース (CLI) のインストール。

手順

  1. 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンディスクを確認します。
  2. 新規 DataVolume の名前、ソース PVC の名前および namespace、および新規 DataVolume のサイズを指定する DataVolume オブジェクトの YAML ファイルを作成します。

    例:

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: cloner-datavolume 1
    spec:
      source:
        pvc:
          namespace: "<source-namespace>" 2
          name: "<my-favorite-vm-disk>" 3
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi 4
    1
    新規 DataVolume の名前。
    2
    ソース PVC が存在する namespace。
    3
    ソース PVC の名前。
    4
    新規 DataVolume のサイズ。十分な領域を割り当てる必要があります。そうでない場合には、クローン操作は失敗します。そうでない場合には、クローン操作は失敗します。 サイズはソース PVC と同じか、またはそれよりも大きくなければなりません。
  3. DataVolume を作成して PVC のクローン作成を開始します。

    $ oc create -f <cloner-datavolume>.yaml
    注記

    DataVolume は仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規 DataVolume を参照する仮想マシンを作成できます。

2.20.3. テンプレート: DataVolume クローン設定ファイル

example-clone-dv.yaml

apiVersion: cdi.kubevirt.io/v1alpha1
kind: DataVolume
metadata:
  name: "example-clone-dv"
spec:
  source:
      pvc:
        name: source-pvc
        namespace: example-ns
  pvc:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: "1G"

2.20.4. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーS3 バケットアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
✓ GZ*
✓ XZ*

Archive+

✓ TAR

✓ TAR

✓ TAR

□ TAR

□ TAR

□ TAR

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

+ アーカイブはブロックモード DV をサポートしません。

2.21. DataVolumeTemplate の使用による仮想マシンのクローン作成

既存の仮想マシンの PersistentVolumeClaim (PVC) のクローン作成により、新規の仮想マシンを作成できます。dataVolumeTemplate を仮想マシン設定ファイルに含めることにより、元の PVC から新規の DataVolume を作成します。

前提条件

2.21.1. DataVolume について

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。DataVolume は、基礎となる PersistentVolumeClaim (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。DataVolume は KubeVirt に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

2.21.2. DataVolumeTemplate の使用による、クローン作成された PersistentVolumeClaim からの仮想マシンの新規作成

既存の仮想マシンの PersistentVolumeClaim (PVC) のクローンを DataVolume に作成する仮想マシンを作成できます。仮想マシン specdataVolumeTemplate を参照することにより、source PVC のクローンが DataVolume に作成され、これは次に仮想マシンを作成するために自動的に使用されます。

注記

DataVolume が仮想マシンの DataVolumeTemplate の一部として作成されると、DataVolume のライフサイクルは仮想マシンに依存します。つまり、仮想マシンが削除されると、DataVolume および関連付けられた PVC も削除されます。

前提条件

  • 使用する既存の仮想マシンディスクの PVC を判別します。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
  • oc として知られる OpenShift コマンドラインインターフェース (CLI) のインストール。

手順

  1. 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンを確認します。
  2. VirtualMachine オブジェクトの YAML ファイルを作成します。以下の仮想マシンのサンプルでは、source-namespace namespace にある my-favorite-vm-disk のクローンを作成します。favorite-clone という 2Gi DataVolume が my-favorite-vm-disk から作成されます。

    例:

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      labels:
        kubevirt.io/vm: vm-dv-clone
      name: vm-dv-clone 1
    spec:
      running: false
      template:
        metadata:
          labels:
            kubevirt.io/vm: vm-dv-clone
        spec:
          domain:
            devices:
              disks:
              - disk:
                  bus: virtio
                name: root-disk
            resources:
              requests:
                memory: 64M
          volumes:
          - dataVolume:
              name: favorite-clone
            name: root-disk
      dataVolumeTemplates:
      - metadata:
          name: favorite-clone
        spec:
          pvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 2Gi
          source:
            pvc:
              namespace: "source-namespace"
              name: "my-favorite-vm-disk"
    1
    作成する仮想マシン。
  3. PVC のクローンが作成された DataVolume で仮想マシンを作成します。

    $ oc create -f <vm-clone-datavolumetemplate>.yaml

2.21.3. テンプレート: DataVolume 仮想マシン設定ファイル

example-dv-vm.yaml

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: example-vm
  name: example-vm
spec:
  dataVolumeTemplates:
  - metadata:
      name: example-dv
    spec:
      pvc:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1G
      source:
          http:
             url: "" 1
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/vm: example-vm
    spec:
      domain:
        cpu:
          cores: 1
        devices:
          disks:
          - disk:
              bus: virtio
            name: example-dv-disk
        machine:
          type: q35
        resources:
          requests:
            memory: 1G
      terminationGracePeriodSeconds: 0
      volumes:
      - dataVolume:
          name: example-dv
        name: example-dv-disk
1
インポートする必要のあるイメージの HTTP ソース (該当する場合)。

2.21.4. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーS3 バケットアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
✓ GZ*
✓ XZ*

Archive+

✓ TAR

✓ TAR

✓ TAR

□ TAR

□ TAR

□ TAR

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

+ アーカイブはブロックモード DV をサポートしません。

2.22. virtctl ツールの使用によるローカルディスクイメージのアップロード

virtctl コマンドラインユーティリティーを使用して、ローカルに保存されるディスクイメージをアップロードできます。

前提条件

2.22.1. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーS3 バケットアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
✓ GZ*
✓ XZ*

Archive+

✓ TAR

✓ TAR

✓ TAR

□ TAR

□ TAR

□ TAR

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

+ アーカイブはブロックモード DV をサポートしません。

2.22.2. ローカルディスクイメージの新規 PersistentVolumeClaim へのアップロード

virtctl CLI ユーティリティーを使用し、仮想マシンディスクイメージをクライアントマシンからクラスターにアップロードできます。ディスクイメージをアップロードすることにより、仮想マシンに関連付けることのできる PersistentVolumeClaim (PVC) が作成されます。

前提条件

  • RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで xz または gz を使用して圧縮される)
  • kubevirt-virtctl パッケージがクライアントマシンにインストールされていること。
  • クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されていること。

手順

  1. 以下を特定します。

    • アップロードする VM ディスクイメージのファイルの場所
    • 結果として生成される PVC の名前およびこれに必要なサイズ
  2. virtctl image-upload コマンドを実行して仮想マシンイメージをアップロードします。PVC 名、PVC サイズ、およびファイルの場所を指定する必要があります。以下は例になります。

    $ virtctl image-upload --pvc-name=upload-fedora-pvc --pvc-size=10Gi --image-path=/images/fedora28.qcow2
    注意

    HTTPS を使用したセキュアでないサーバー接続を許可するには、--insecure パラメーターを使用します。--insecure フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。

  3. PVC が作成されていることを確認するには、すべての PVC オブジェクトを表示します。

    $ oc get pvc

2.23. 空のディスクイメージを追加して仮想ストレージを拡張する

空のディスクイメージを Container-native Virtualization に追加することによって、ストレージ容量を拡張したり、新規のデータパーティションを作成したりできます。

2.23.1. DataVolume について

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。DataVolume は、基礎となる PersistentVolumeClaim (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。DataVolume は KubeVirt に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

2.23.2. DataVolume を使用した空のディスクイメージの作成

DataVolume 設定ファイルをカスタマイズし、デプロイすることにより、新規の空のディスクイメージを PersistentVolumeClaim に作成することができます。

前提条件

  • 1 つ以上の利用可能な PersistentVolume
  • oc として知られる OpenShift コマンドラインインターフェース (CLI) をダウンロードします。

手順

  1. DataVolume 設定ファイルを編集します。

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: blank-image-datavolume
    spec:
      source:
          blank: {}
      pvc:
        # Optional: Set the storage class or omit to accept the default
        # storageClassName: "hostpath"
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi
  2. 以下のコマンドを実行して、空のディスクイメージを作成します。

    $ oc create -f <blank-image-datavolume>.yaml

2.23.3. テンプレート: 空のディスクイメージの DataVolume 設定ファイル

blank-image-datavolume.yaml

apiVersion: cdi.kubevirt.io/v1alpha1
kind: DataVolume
metadata:
  name: blank-image-datavolume
spec:
  source:
      blank: {}
  pvc:
    # Optional: Set the storage class or omit to accept the default
    # storageClassName: "hostpath"
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 500Mi

2.24. CDI のスクラッチ領域の用意

2.24.1. DataVolume について

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。DataVolume は、基礎となる PersistentVolumeClaim (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。DataVolume は KubeVirt に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

2.24.2. スクラッチ領域について

Containerized Data Importer (CDI) では、仮想マシンイメージのインポートやアップロードなどの、一部の操作を実行するためにスクラッチ領域 (一時ストレージ) が必要になります。このプロセスで、CDI は、宛先 DataVolume (DV) をサポートする PVC のサイズと同じサイズのスクラッチ領域 PVC をプロビジョニングします。スクラッチ領域 PVC は操作の完了または中止後に削除されます。

CDIConfig オブジェクトにより、 scratchSpaceStorageClass を CDIConfig オブジェクトの spec: セクションに指定して、スクラッチ領域 PVC をバインドするために使用する StorageClass を定義することができます。

定義された StorageClass がクラスターの StorageClass に一致しない場合、クラスターに定義されたデフォルト StorageClass が使用されます。クラスターで定義されたデフォルトの StorageClass がない場合、元の DV または PVC のプロビジョニングに使用される StorageClass が使用されます。

注記

CDI では、元の DataVolume をサポートする PVC の種類を問わず、file ボリュームモードが設定されているスクラッチ領域が必要です。元の PVC が block ボリュームモードでサポートされる場合、file ボリュームモード PVC をプロビジョニングできる StorageClass を定義する必要があります。

手動プロビジョニング

ストレージクラスがない場合、CDI はイメージのサイズ要件に一致するプロジェクトの PVC を使用します。これらの要件に一致する PVC がない場合、CDI インポート Pod は適切な PVC が利用可能になるまで、またはタイムアウト機能が Pod を強制終了するまで Pending 状態になります。

2.24.3. CDI 設定での StorageClass の定義

CDI 設定で StorageClass を定義し、CDI 操作のスクラッチ領域を動的にプロビジョニングします。

手順

  • oc クライアントを使用して cdiconfig/config を編集し、spec: scratchSpaceStorageClass を追加または編集してクラスターの StorageClass に一致させます。

    $ oc edit cdiconfig/config
    API Version:  cdi.kubevirt.io/v1alpha1
    kind: CDIConfig
    metadata:
      name: config
    ...
    spec:
      scratchSpaceStorageClass: "<storage_class>"
    ...

2.24.4. スクラッチ領域を必要とする CDI 操作

タイプ理由

レジストリーのインポート

CDI はイメージをスクラッチ領域にダウンロードし、イメージファイルを見つけるためにレイヤーを抽出する必要があります。その後、raw ディスクに変換するためにイメージファイルが QEMU-img に渡されます。

イメージのアップロード

QEMU-IMG は STDIN の入力を受け入れません。代わりに、アップロードするイメージは、変換のために QEMU-IMG に渡される前にスクラッチ領域に保存されます。

アーカイブされたイメージの HTTP インポート

QEMU-IMG は、CDI がサポートするアーカイブ形式の処理方法を認識しません。イメージが QEMU-IMG に渡される前にアーカイブは解除され、スクラッチ領域に保存されます。

認証されたイメージの HTTP インポート

QEMU-IMG が認証を適切に処理しません。イメージが QEMU-IMG に渡される前にスクラッチ領域に保存され、認証されます。

カスタム証明書の HTTP インポート

QEMU-IMG は HTTPS エンドポイントのカスタム証明書を適切に処理しません。代わりに CDI は、ファイルを QEMU-IMG に渡す前にイメージをスクラッチ領域にダウンロードします。

2.24.5. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーS3 バケットアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
✓ GZ*
✓ XZ*

Archive+

✓ TAR

✓ TAR

✓ TAR

□ TAR

□ TAR

□ TAR

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

+ アーカイブはブロックモード DV をサポートしません。

追加リソース

  • StorageClass およびこれらがクラスターで定義される方法についての詳細は、「Dynamic provisioning」セクションを参照してください。

2.25. 仮想マシンのライブマイグレーション

2.25.1. ライブマイグレーションについて

ライブマイグレーションは、仮想ワークロードまたはアクセスに支障を与えることなく、実行中の仮想マシンインスタンスをクラスター内の別のノードに移行するプロセスです。これは、他のノードに移行する仮想マシンインスタンスを選択する場合は手動プロセスで実行でき、仮想マシンインスタンスに LiveMigrate エビクションストラテジーがあり、これが実行されるノードがメンテナンス状態の場合には自動プロセスで実行できます。

注記

NFS 共有ボリュームは、Container-native Virtualization 2.0 のライブマイグレーションでサポートされる唯一の共有データボリュームタイプです。

2.26. ライブマイグレーションの制限およびタイムアウト

ライブマイグレーションの制限およびタイムアウトは、移行プロセスがクラスターに負担をかけないようにするために適用されます。kubevirt-config 設定ファイルを編集してこれらの設定を行います。

2.26.1. ライブマイグレーションの制限およびタイムアウトの設定

更新された key:value フィールドを、kubevirt-hyperconverged namespace にある kubevirt-config 設定ファイルに追加することによって、クラスターのライブマイグレーションの制限およびタイムアウトを設定します。

手順

  • kubevirt-config 設定ファイルを編集し、必要なライブマイグレーションパラメーターを追加します。以下の例は、デフォルト値を示しています。

    $ oc edit configmap kubevirt-config -n kubevirt-hyperconverged
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: kubevirt-config
      namespace: kubevirt
      labels:
        kubevirt.io: ""
    data:
      feature-gates: "LiveMigration"
      migrations: |-
        parallelMigrationsPerCluster: 5
        parallelOutboundMigrationsPerNode: 2
        bandwidthPerMigration: 64Mi
        completionTimeoutPerGiB: 800
        progressTimeout: 150

2.26.2. クラスター全体のライブマイグレーションの制限およびタイムアウト

表2.5 マイグレーションパラメーター

パラメーター説明デフォルト

parallelMigrationsPerCluster

クラスターで並行して実行されるマイグレーションの数。

5

parallelOutboundMigrationsPerNode

ノードごとのアウトバウンドマイグレーションの最大数。

2

bandwidthPerMigration

各マイグレーションの帯域幅 (MiB/s)。

64Mi

completionTimeoutPerGiB

マイグレーションが (メモリー GiB あたりの秒単位の) この時間内に終了しなかった場合、マイグレーションは取り消されます。たとえば、6GiB メモリーを持つ仮想マシンインスタンスは、4800 秒内にマイグレーションを完了しない場合にタイムアウトします。Migration MethodBlockMigration の場合、移行するディスクのサイズは計算に含められます。

800

progressTimeout

マイグレーションは、メモリーコピーの進展が (秒単位の) この時間内に見られない場合に取り消されます。

150

2.27. 仮想マシンインスタンスの別のノードへの移行

Web コンソールまたは CLI のいずれかで仮想マシンインスタンスのライブマイグレーションを手動で開始します。

2.27.1. Web コンソールでの仮想マシンインスタンスのライブマイグレーションの開始

実行中の仮想マシンインスタンスをクラスター内の別のノードに移行します。

注記

Migrate Virtual Machine アクションはすべてのユーザーに対して表示されますが、仮想マシンの移行を開始できるのは管理者ユーザーのみとなります。

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. この画面からマイグレーションを開始できます。 これにより、1 つの画面で複数のマシンに対してアクションを実行することがより容易になります。 または、Virtual Machine Details 画面から仮想マシンを停止することもできます。 この場合、選択された仮想マシンの総合的な詳細情報を確認できます。

    • Options メニュー kebab をクリックし、Migrate Virtual Machine を選択します。
    • 仮想マシン名をクリックし、Virtual Machine Details 画面を開き、ActionsMigrate Virtual Machine をクリックします。
  3. Migrate をクリックして、仮想マシンを別のノードに移行します。

2.27.2. CLI での仮想マシンインスタンスのライブマイグレーションの開始

クラスターに VirtualMachineInstanceMigration オブジェクトを作成し、仮想マシンインスタンスの名前を参照して、実行中の仮想マシンインスタンスのライブマイグレーションを開始します。

手順

  1. 移行する仮想マシンインスタンスの VirtualMachineInstanceMigration 設定ファイルを作成します。vmi-migrate.yaml はこの例になります。

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachineInstanceMigration
    metadata:
      name: migration-job
    spec:
      vmiName: vmi-fedora
  2. クラスターにオブジェクトを作成します。

    $ oc create -f vmi-migrate.yaml

VirtualMachineInstanceMigration オブジェクトは、仮想マシンインスタンスのライブマイグレーションをトリガーします。このオブジェクトは、手動で削除されない場合、仮想マシンインスタンスが実行中である限りクラスターに存在します。

2.28. 仮想マシンインスタンスのライブマイグレーションのモニター

Web コンソールまたは CLI のいずれかで仮想マシンインスタンスのライブマイグレーションの進捗をモニターできます。

2.28.1. Web コンソールでの仮想マシンインスタンスのライブマイグレーションのモニター

移行期間中、仮想マシンのステータスは Migrating になります。このステータスは Virtual Machines 一覧に表示されるか、または移行中の仮想マシンの Virtual Machine Details 画面に表示されます。

手順

  • Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。

2.28.2. CLI での仮想マシンインスタンスのライブマイグレーションのモニター

仮想マシンの移行のステータスは、VirtualMachineInstance 設定の Status コンポーネントに保存されます。

手順

  • 移行中の仮想マシンインスタンスで oc describe コマンドを使用します。
$ oc describe vmi vmi-fedora

+

...
Status:
  Conditions:
    Last Probe Time:       <nil>
    Last Transition Time:  <nil>
    Status:                True
    Type:                  LiveMigratable
  Migration Method:  LiveMigration
  Migration State:
    Completed:                    true
    End Timestamp:                2018-12-24T06:19:42Z
    Migration UID:                d78c8962-0743-11e9-a540-fa163e0c69f1
    Source Node:                  node2.example.com
    Start Timestamp:              2018-12-24T06:19:35Z
    Target Node:                  node1.example.com
    Target Node Address:          10.9.0.18:43891
    Target Node Domain Detected:  true

2.29. 仮想マシンインスタンスのライブマイグレーションの取り消し

仮想マシンインスタンスを元のノードに残すためにライブマイグレーションを取り消すことができます。

Web コンソールまたは CLI のいずれかでライブマイグレーションを取り消します。

2.29.1. Web コンソールでの仮想マシンインスタンスのライブマイグレーションの取り消し

仮想マシンインスタンスのライブマイグレーションは、Options メニュー kebabWorkloadsVirtual Machines 画面の各仮想マシンで使用するか、または Virtual Machine Details 画面の Actions メニューから取り消すことができます。

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. この画面から移行を取り消すことができます。 これにより、1 つの画面で複数のマシンに対してアクションを実行することがより容易になります。 または、Virtual Machine Details 画面から仮想マシンを停止することもできます。 この場合、選択された仮想マシンの総合的な詳細情報を確認できます。

    • Options メニュー kebab をクリックして、Cancel Virtual Machine Migrationを選択します。
    • 仮想マシン名をクリックして Virtual Machine Details 画面を開き、ActionsCancel Virtual Machine Migration をクリックします。
  3. Cancel Migration をクリックして仮想マシンのライブマイグレーションを取り消します。

2.29.2. CLI での仮想マシンインスタンスのライブマイグレーションの取り消し

マイグレーションに関連付けられた VirtualMachineInstanceMigration オブジェクトを削除して、仮想マシンインスタンスのライブマイグレーションを取り消します。

手順

  • ライブマイグレーションをトリガーした VirtualMachineInstanceMigration オブジェクトを削除します。 この例では、migration-job が使用されています。

    $ oc delete vmim migration-job

2.30. ノードのメンテナンスモード

2.30.1. ノードのメンテナンスモードについて

ノードがメンテナンス状態になると、ノードにはスケジュール対象外のマークが付けられ、ノードからすべての仮想マシンおよび Pod がドレイン (解放) されます。LiveMigrate エビクションストラテジーを持つ仮想マシンインスタンスのライブマイグレーションは、サービスが失われることなく実行されます。このエビクションストラテジーはデフォルトで共通テンプレートから作成される仮想マシンで設定されますが、カスタム仮想マシンの場合には手動で設定される必要があります。

エビクションストラテジーのない仮想マシンインスタンスは、ノードで削除され、別のノードで再作成されます。

注記

NFS 共有ボリュームは、Container-native Virtualization 2.0 のライブマイグレーションでサポートされる唯一の共有データボリュームタイプです。

2.31. 仮想マシンのエビクションストラテジーの設定

LiveMigrate エビクションストラテジーは、ノードがメンテナンス状態になるか、ドレイン (解放) される場合に仮想マシンインスタンスが中断されないようにします。このエビクションストラテジーを持つ仮想マシンインスタンスのライブマイグレーションが別のノードに対して行われます。

2.31.1. LiveMigration エビクションストラテジーでのカスタム仮想マシンの設定

LiveMigration エビクションストラテジーはカスタム仮想マシンでのみ設定する必要があります。共通テンプレートには、デフォルトでこのエビクションストラテジーが設定されています。

手順

  1. evictionStrategy: LiveMigrate オプションを、仮想マシン設定ファイルの spec セクションに追加します。この例では、oc edit を使用して VirtualMachine 設定ファイルの関連するスニペットを更新します。

    $ oc edit vm <custom-vm> -n <my-namespace>
    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      name: custom-vm
    spec:
      terminationGracePeriodSeconds: 30
      evictionStrategy: LiveMigrate
      domain:
        resources:
          requests:
    ...
  2. 更新を有効にするために仮想マシンを再起動します。

    $ virtctl restart <custom-vm> -n <my-namespace>

2.32. ノードのメンテナンスモードへの設定

2.32.1. ノードのメンテナンスモードについて

ノードがメンテナンス状態になると、ノードにはスケジュール対象外のマークが付けられ、ノードからすべての仮想マシンおよび Pod がドレイン (解放) されます。LiveMigrate エビクションストラテジーを持つ仮想マシンインスタンスのライブマイグレーションは、サービスが失われることなく実行されます。このエビクションストラテジーはデフォルトで共通テンプレートから作成される仮想マシンで設定されますが、カスタム仮想マシンの場合には手動で設定される必要があります。

エビクションストラテジーのない仮想マシンインスタンスは、ノードで削除され、別のノードで再作成されます。

注記

NFS 共有ボリュームは、Container-native Virtualization 2.0 のライブマイグレーションでサポートされる唯一の共有データボリュームタイプです。

Web コンソールまたは CLI のいずれかでノードをメンテナンス状態にします。

2.32.2. Web コンソールでのノードのメンテナンスモードへの設定

Options メニュー kebab (ComputeNodes 一覧にある各ノードにある) を使用するか、または Node Details 外面の Actions コントロールを使用してノードをメンテナンスモードから再開します。

手順

  1. Container-native Virtualization コンソールで ComputeNodes をクリックします。
  2. この画面からノードをメンテナンスモードに設定できます。 これにより、1 つの画面で複数のノードに対してアクションを実行することがより容易になります。 または、Node Details 画面からノードをメンテナンスモードに設定することもできます。 この場合、選択されたノードの総合的な詳細情報を確認できます。

    • Options メニュー kebab をクリックし、Start Maintenance を選択します。
    • ノード名をクリックし、Node Details 画面を開いて ActionsStat Maintenance をクリックします。
  3. 確認ウィンドウで Start Maintenance をクリックします。

ノードは liveMigration エビクションストラテジーを持つ仮想マシンインスタンスのライブマイグレーションを行い、このノードはスケジュール対象外となります。このノードの他のすべての Pod および仮想マシンは削除され、別のノードで再作成されます。

2.32.3. CLI でのノードのメンテナンスモードへの設定

ノード名、およびこれをメンテナンスモードに設定する理由を参照する NodeMaintenance カスタムリソース (CR) オブジェクトを作成し、ノードをメンテナンスモードに設定します。

手順

  1. ノードメンテナンス CR 設定を作成します。この例では、node02-maintenance.yaml という CR を使用します。

    apiVersion: kubevirt.io/v1alpha1
    kind: NodeMaintenance
    metadata:
      name: node02-maintenance
    spec:
      nodeName: node02
      reason: "Replacing node02"
  2. NodeMaintenance オブジェクトをクラスターに作成します。

    $ oc apply -f <node02-maintenance.yaml>

ノードは liveMigration エビクションストラテジーを持つ仮想マシンインスタンスのライブマイグレーションを実行し、これがスケジュール対象外になるようにノードにテイントを設定します。このノードの他のすべての Pod および仮想マシンは削除され、別のノードで再作成されます。

2.33. メンテナンスモードからのノードの再開

ノードを再開することにより、ノードをメンテナンスモードから切り替え、再度スケジュール可能な状態にします。

Web コンソールまたは CLI のいずれかでノードをメンテナンスモードから再開します。

2.33.1. Web コンソールでのメンテナンスモードからのノードの再開

Options メニュー kebab (ComputeNodes 一覧にある各ノードにある) を使用するか、または Node Details 外面の Actions コントロールを使用してノードをメンテナンスモードから再開します。

手順

  1. Container-native Virtualization コンソールで ComputeNodes をクリックします。
  2. この画面からノードを再開できます。 これにより、1 つの画面で複数のノードに対してアクションを実行することがより容易になります。 または、Node Details 画面からノードを再開することもできます。 この場合、選択されたノードの総合的な詳細情報を確認できます。

    • Options メニュー kebab をクリックし、Stop Maintenanceを選択します。
    • ノード名をクリックし、Node Details 画面を開いて ActionsStop Maintenance をクリックします。
  3. 確認ウィンドウで Stop Maintenance をクリックします。

ノードはスケジュール可能な状態になりますが、メンテナンス前にノード上で実行されていた仮想マシンインスタンスはこのノードに自動的に戻されません。

2.33.2. CLI でのメンテナンスモードからのノードの再開

ノードの NodeMaintenance オブジェクトを削除することによって、メンテナンスモードからノードを再開し、これを再度スケジュール可能な状態にします。

手順

  1. NodeMaintenance オブジェクトを見つけます。

    $ oc get nodemaintenance
  2. オプション: NodeMaintenance オブジェクトを検査し、これが正しいノードに関連付けられていることを確認します。

    $ oc describe nodemaintenance <node02-maintenance>
    Name:         node02-maintenance
    Namespace:
    Labels:
    Annotations:
    API Version:  kubevirt.io/v1alpha1
    Kind:         NodeMaintenance
    ...
    Spec:
      Node Name:  node02
      Reason:     Replacing node02
  3. NodeMaintenance オブジェクトを削除します。

    $ oc delete nodemaintenance <node02-maintenance>

2.34. VirtIO ドライバーの既存の Windows 仮想マシンへのインストール

2.34.1. VirtIO ドライバーについて

VirtIO ドライバーは、Microsoft Windows 仮想マシンが Container-native Virtualization で実行されるために必要な準仮想化デバイスドライバーです。サポートされるドライバーは cnv-tech-preview/virtio-win container disk of the Red Hat Container Catalog で利用できます。

cnv-tech-preview/virtio-win コンテナーディスクは、ドライバーのインストールを有効にするために SATA CD ドライブとして仮想マシンに割り当てられる必要があります。仮想マシン上での Windows のインストール時に VirtIO ドライバーをインストールすることも、既存の Windows インストールに追加することもできます。

ドライバーのインストール後に、cnv-tech-preview/virtio-win コンテナーディスクは仮想マシンから削除できます。

Installing Virtio drivers on a new Windows virtual machine」も参照してください。

2.34.2. Microsoft Windows 仮想マシンのサポートされる VirtIO ドライバー

表2.6 サポートされるドライバー

ドライバー名ハードウェア ID説明

viostor

VEN_1AF4&DEV_1001
VEN_1AF4&DEV_1042

ブロックドライバー。Other devices グループの SCSI Controller として表示される場合があります。

viorng

VEN_1AF4&DEV_1005
VEN_1AF4&DEV_1044

エントロピーソースドライバー。Other devices グループの PCI Device として表示される場合があります。

NetKVM

VEN_1AF4&DEV_1000
VEN_1AF4&DEV_1041

ネットワークドライバー。Other devices グループの Ethernet Controller として表示される場合があります。VirtIO NIC が設定されている場合にのみ利用できます。

2.34.3. VirtIO ドライバーコンテナーディスクの仮想マシンへの追加

Container-native Virtualization は、Red Hat Container Catalogで利用できる Microsoft Windows の VirtIO ドライバーをコンテナーディスクとして配布します。これらのドライバーを Windows 仮想マシンにインストールするには、仮想マシン設定ファイルで cnv-tech-preview/virtio-win コンテナーディスクを SATA CD ドライブとして仮想マシンに割り当てます。

前提条件

  • cnv-tech-preview/virtio-win コンテナーディスクを Red Hat Container Catalogからダウンロードします。コンテナーディスクがクラスターにない場合は Red Hat レジストリーからダウンロードされるため、これは必須ではありません。

手順

  1. cnv-tech-preview/virtio-win コンテナーディスクを cdrom ディスクとして Windows 仮想マシン設定ファイルに追加します。コンテナーディスクは、クラスターにない場合はレジストリーからダウンロードされます。

    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2 1
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: cnv-tech-preview/virtio-win
        name: virtiocontainerdisk
    1
    Container-native Virtualization は、VirtualMachine 設定ファイルに定義される順序で仮想マシンディスクを起動します。cnv-tech-preview/virtio-win コンテナーディスクの前に仮想マシンの他のディスクを定義するか、またはオプションの bootOrder パラメーターを使用して仮想マシンが正しいディスクから起動するようにできます。ディスクに bootOrder を指定する場合、これは設定のすべてのディスクに指定される必要があります。
  2. ディスクは、仮想マシンが起動すると利用可能になります。

    • コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で oc apply -f <vm.yaml> を使用するか、または仮想マシンを再起動します。
    • 仮想マシンが実行されていない場合、virtctl start <vm> を使用します。

仮想マシンが起動したら、VirtIO ドライバーを割り当てられた SATA CD ドライブからインストールできます。

2.34.4. VirtIO ドライバーの既存 Windows 仮想マシンへのインストール

VirtIO ドライバーを、割り当てられた SATA CD ドライブから既存の Windows 仮想マシンにインストールします。

注記

この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。このプロセスは Windows のバージョンごとに若干異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows ユーザーセッションにログインします。
  3. Device Manager を開き、Other devices を拡張して、Unknown device を一覧表示します。

    1. Device Properties を開いて不明なデバイスを特定する必要がある場合があります。デバイスを右クリックし、Properties を選択します。
    2. Details タブをクリックし、Property リストで Hardware Ids を選択します。
    3. Hardware IdsValue をサポートされる VirtIO ドライバーと比較します。
  4. デバイスを右クリックし、Update Driver Software を選択します。
  5. Browse my computer for driver software をクリックし、VirtIO ドライバーが置かれている割り当て済みの SATA CD ドライブの場所に移動します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. Next をクリックしてドライバーをインストールします。
  7. 必要なすべての VirtIO ドライバーに対してこのプロセスを繰り返します。
  8. ドライバーのインストール後に、Close をクリックしてウィンドウを閉じます。
  9. 仮想マシンを再起動してドライバーのインストールを完了します。

2.34.5. 仮想マシンからの VirtIO コンテナーディスクの削除

必要なすべての VirtIO ドライバーを仮想マシンにインストールした後は、cnv-tech-preview/virtio-win コンテナーディスクを仮想マシンに割り当てる必要はなくなります。cnv-tech-preview/virtio-win コンテナーディスクを仮想マシン設定ファイルから削除します。

手順

  1. 設定ファイルを編集し、disk および volume を削除します。

    $ oc edit vm <vm-name>
    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: cnv-tech-preview/virtio-win
        name: virtiocontainerdisk
  2. 変更を有効にするために仮想マシンを再起動します。

2.35. VirtIO ドライバーの新規 Windows 仮想マシンへのインストール

前提条件

2.35.1. VirtIO ドライバーについて

VirtIO ドライバーは、Microsoft Windows 仮想マシンが Container-native Virtualization で実行されるために必要な準仮想化デバイスドライバーです。サポートされるドライバーは cnv-tech-preview/virtio-win container disk of the Red Hat Container Catalog で利用できます。

cnv-tech-preview/virtio-win コンテナーディスクは、ドライバーのインストールを有効にするために SATA CD ドライブとして仮想マシンに割り当てられる必要があります。仮想マシン上での Windows のインストール時に VirtIO ドライバーをインストールすることも、既存の Windows インストールに追加することもできます。

ドライバーのインストール後に、cnv-tech-preview/virtio-win コンテナーディスクは仮想マシンから削除できます。

VirtIO ドライバーの既存の Windows 仮想マシンへのインストール」も参照してください。

2.35.2. Microsoft Windows 仮想マシンのサポートされる VirtIO ドライバー

表2.7 サポートされるドライバー

ドライバー名ハードウェア ID説明

viostor

VEN_1AF4&DEV_1001
VEN_1AF4&DEV_1042

ブロックドライバー。Other devices グループの SCSI Controller として表示される場合があります。

viorng

VEN_1AF4&DEV_1005
VEN_1AF4&DEV_1044

エントロピーソースドライバー。Other devices グループの PCI Device として表示される場合があります。

NetKVM

VEN_1AF4&DEV_1000
VEN_1AF4&DEV_1041

ネットワークドライバー。Other devices グループの Ethernet Controller として表示される場合があります。VirtIO NIC が設定されている場合にのみ利用できます。

2.35.3. VirtIO ドライバーコンテナーディスクの仮想マシンへの追加

Container-native Virtualization は、Red Hat Container Catalogで利用できる Microsoft Windows の VirtIO ドライバーをコンテナーディスクとして配布します。これらのドライバーを Windows 仮想マシンにインストールするには、仮想マシン設定ファイルで cnv-tech-preview/virtio-win コンテナーディスクを SATA CD ドライブとして仮想マシンに割り当てます。

前提条件

  • cnv-tech-preview/virtio-win コンテナーディスクを Red Hat Container Catalogからダウンロードします。コンテナーディスクがクラスターにない場合は Red Hat レジストリーからダウンロードされるため、これは必須ではありません。

手順

  1. cnv-tech-preview/virtio-win コンテナーディスクを cdrom ディスクとして Windows 仮想マシン設定ファイルに追加します。コンテナーディスクは、クラスターにない場合はレジストリーからダウンロードされます。

    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2 1
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: cnv-tech-preview/virtio-win
        name: virtiocontainerdisk
    1
    Container-native Virtualization は、VirtualMachine 設定ファイルに定義される順序で仮想マシンディスクを起動します。cnv-tech-preview/virtio-win コンテナーディスクの前に仮想マシンの他のディスクを定義するか、またはオプションの bootOrder パラメーターを使用して仮想マシンが正しいディスクから起動するようにできます。ディスクに bootOrder を指定する場合、これは設定のすべてのディスクに指定される必要があります。
  2. ディスクは、仮想マシンが起動すると利用可能になります。

    • コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で oc apply -f <vm.yaml> を使用するか、または仮想マシンを再起動します。
    • 仮想マシンが実行されていない場合、virtctl start <vm> を使用します。

仮想マシンが起動したら、VirtIO ドライバーを割り当てられた SATA CD ドライブからインストールできます。

2.35.4. Windows インストール時の VirtIO ドライバーのインストール

Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。

注記

この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows インストールプロセスを開始します。
  3. Advanced インストールを選択します。
  4. ストレージの宛先は、ドライバーがロードされるまで認識されません。Load driver をクリックします。
  5. ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
  7. Windows インストールを完了します。

2.35.5. 仮想マシンからの VirtIO コンテナーディスクの削除

必要なすべての VirtIO ドライバーを仮想マシンにインストールした後は、cnv-tech-preview/virtio-win コンテナーディスクを仮想マシンに割り当てる必要はなくなります。cnv-tech-preview/virtio-win コンテナーディスクを仮想マシン設定ファイルから削除します。

手順

  1. 設定ファイルを編集し、disk および volume を削除します。

    $ oc edit vm <vm-name>
    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: cnv-tech-preview/virtio-win
        name: virtiocontainerdisk
  2. 変更を有効にするために仮想マシンを再起動します。

2.36. ログの表示

2.36.1. ログについて

ログは、OpenShift Container Platform ビルド、デプロイメントおよび Pod について収集されます。Container-native Virtualization では、仮想マシンのログは Web コンソールまたは CLI のいずれかで仮想マシンランチャー Pod から取得されます。

-f オプションは、リアルタイムでログ出力をフォローします。 これは進捗のモニターおよびエラーの確認に役立ちます。

ランチャー Pod の起動が失敗する場合、--previous オプションを使用して最後の試行時のログを確認します。

警告

ErrImagePull および ImagePullBackOff エラーは、誤ったデプロイメント設定または参照されるイメージに関する問題によって引き起こされる可能性があります。

2.36.2. CLI での仮想マシンログの表示

仮想マシンランチャー Pod から仮想マシンログを取得します。

手順

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

    $ oc logs <virt-launcher-name>

2.36.3. Web コンソールでの仮想マシンログの表示

関連付けられた仮想マシンランチャー Pod から仮想マシンログを取得します。

手順

  1. Container-native Virtualization コンソールで WorkloadsVirtual Machinesをクリックします。
  2. 仮想マシンをクリックし、Virtual Machine Details パネルを開きます。
  3. Overview タブで、POD セクションの virt-launcher-<name> Pod をクリックします。
  4. Logs をクリックします。

2.37. イベントの表示

2.37.1. イベントについて

OpenShift Container Platform イベントは、namespace 内の重要なライフサイクル情報のレコードであり、リソースのスケジュール、作成、および削除に関する問題のモニターおよびトラブルシューティングに役立ちます。

Container-native Virtualization は、仮想マシンおよび仮想マシンインスタンスについてのイベントを追加します。これらは Web コンソールまたは CLI のいずれかで表示できます。

OpenShift Container Platform クラスター内のシステムイベント情報の表示」も参照してください。

2.37.2. Web コンソールでの仮想マシンのイベントの表示

実行中の仮想マシンのストリームイベントは、Web コンソールの Virtual Machine Details パネルから確認できます。

▮▮ ボタンはイベントストリームを一時停止します。
▶ ボタンは一時停止されたイベントストリームを継続します。

手順

  1. サイドメニューから WorkloadsVirtual Machines をクリックします。
  2. 仮想マシンを選択します。
  3. Events をクリックして、仮想マシンのすべてのイベントを表示します。

2.37.3. CLI での namespace イベントの表示

OpenShift Container Platform クライアントを使用して namespace のイベントを取得します。

手順

  • namespace で、oc get コマンドを使用します。

    $ oc get events

2.37.4. CLI でのリソースイベントの表示

イベントはリソース説明に組み込むこともできます。 これは OpenShift Container Platform クライアントを使用して取得できます。

手順

  • namespace で、oc describe コマンドを使用します。以下の例は、仮想マシン、仮想マシンインスタンス、および仮想マシンの virt-launcher Pod のイベント取得する方法を示しています。

    $ oc describe vm <vm>
    $ oc describe vmi <vmi>
    $ oc describe pod virt-launcher-<name>

2.38. OpenShift Container Platform クラスターモニタリング、ロギング、および Telemetry

OpenShift Container Platform は、クラスターレベルでモニターするための各種のリソースを提供します。

2.38.1. OpenShift Container Platform クラスターモニタリングについて

OpenShift Container Platform には、Prometheus オープンソースプロジェクトおよびその幅広いエコシステムをベースとする事前に設定され、事前にインストールされた自己更新型のモニタリングスタックが同梱されます。これはクラスターのモニタリング機能を提供し、クラスター管理者に問題の発生を即時に通知するアラートのセットと Grafana ダッシュボードのセットを提供します。クラスターモニタリングスタックは、OpenShift Container Platform クラスターのモニタリング用のみにサポートされています。

重要

今後の OpenShift Container Platform の更新との互換性を確保するために、指定されたモニタリングスタックのオプションのみを設定することがサポートされます。

2.38.2. クラスターロギングについて

クラスターロギングコンポーネントは Elasticsearch、Fluentd、Kibana (EFK) に基づいています。コレクターの Fluentd は、OpenShift Container Platform クラスターの各ノードにデプロイされます。これはすべてのノードおよびコンテナーのログを収集し、それらを Elasticsearch (ES) に書き込みます。Kibana は、ユーザーおよび管理者が集計されたデータを使って高度なビジュアライゼーションおよびダッシュボードを作成できる中央の Web UI です。

クラスターロギングについての詳細は、「OpenShift Container Platform クラスターロギング」のドキュメントを参照してください。

2.38.3. Telemetry について

Telemetry は、以下についての匿名化され、集計された情報を収集します。

  • OpenShift Container Platform クラスターのサイズ
  • OpenShift Container Platform コンポーネントの健全性およびステータス
  • OpenShift Container Platform コンポーネントの使用
  • 使用中の機能

この情報は、OpenShift Container Platform をより使用しやすく、より直感的に使用できるようにするために Red Hat によって使用されます。この情報のいずれもサードパーティーと共有されることはありません。

2.38.3.1. 収集される情報

Telemetry は、ユーザー名、パスワード、またはユーザーリソースの名前またはアドレスなどの識別情報を収集せず、今後も収集することはありません。

収集される主要な情報には、以下が含まれます。

  • クラスターごとに利用可能な更新の数
  • 更新に使用されるチャネルとイメージリポジトリー
  • 更新時に発生したエラーの数
  • 実行中の更新の進捗情報
  • クラスターごとのマシン数
  • CPU コアの数およびマシンの RAM のサイズ
  • etcd クラスターのメンバー数、および現在 etcd クラスターに保存されているオブジェクトの数
  • マシンタイプ (インフラまたはマスター) ごとに使用される CPU コアおよび RAM の数
  • クラスターごとに使用される CPU コアおよび RAM の数
  • クラスターごとの OpenShift Container Platform フレームワークコンポーネントの使用
  • OpenShift Container Platform クラスターのバージョン
  • クラスターにインストールされている OpenShift Container Platform フレームワークコンポーネントの健全性、状態、およびステータス。たとえば、クラスターバージョン Operator、クラスターモニタリング、イメージレジストリー、およびロギング用の Elasticsearch がこれらのコンポーネントに含まれます。
  • インストール時に生成される一意でランダムな識別子
  • Amazon Web Services などの OpenShift Container Platform がデプロイされているプラットフォームの名前

2.38.4. CLI のトラブルシューティングおよびデバッグコマンド

oc クライアントのトラブルシューティングおよびデバッグコマンドの一覧については、「OpenShift Container Platform CLI リファレンス」ドキュメントを参照してください。

第3章 Container-native Virtualization 2.0 リリースノート

3.1. Container-native Virtualization 2.0 リリースノート

3.1.1. Container-native Virtualization について

3.1.1.1. Container-native Virtualization の機能

Container-native Virtualization は OpenShift Container Platform のアドオンであり、仮想マシンのワークロードを実行し、このワークロードをコンテナーのワークロードと共に管理することを可能にします。

Container-native Virtualization は、Kubernetes カスタムリソースを使って新規オブジェクトを OpenShift Container Platform クラスターに追加し、仮想化タスクを有効にします。これらのタスクには、以下が含まれます。

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

機能強化された Web コンソールは、これらの仮想化されたリソースを OpenShift Container Platform クラスターコンテナーおよびインフラストラクチャーと共に管理するためのグラフィカルポータルを提供します。

3.1.1.2. Container-native Virtualization のサポート

重要

Container-native Virtualization はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

3.1.2. 新機能および変更された機能

3.1.2.1. サポートされているバインディングメソッド

  • Open vSwitch (OVS) は非推奨となったため、Container-native Virtualization 2.0 で使用することはできません。
  • デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。これはデフォルト以外のネットワークではサポートされません。
  • セカンダリーネットワークの場合は、bridge バインディングメソッドを使用します。

3.1.2.2. Web コンソールの強化

  • Virtual Machine Details 画面で、仮想マシンに関連付けられたすべてのサービスを表示できるようになりました。

3.1.3. 解決済みの問題

  • CDI インポートの失敗後に PVC を削除しても、インポーター Pod が CrashLoopBackOff 状態のままになることがなくなりました。PVC が正常に削除されるようになりました(BZ#1673683)。

3.1.4. 既知の問題

  • 一部の KubeVirt リソースは、Container-native Virtualization の削除時に不適切に保持される状態が生じます。回避策として、コマンド oc delete apiservices v1alpha3.subresources.kubevirt.io -n kubevirt-hyperconverged を実行してそれらを手動で削除する必要があります。これらのリソースは (BZ#1712429) の解決後に自動的に削除されます。
  • 古いバージョンの virtctl を Container-native Virtualization 2.0 で使用すると、virtctl は要求された仮想マシンに接続できなくなります。クライアントで virtctl RPM パッケージを最新バージョンに更新し、この問題を解決します(BZ#1706108)。
  • デフォルトの Pod ネットワークに接続されるインターフェースはライブマイグレーションの後に接続を失います。回避策として、追加の multus 対応のネットワークを使用します(BZ#1693532)。
  • Container-native Virtualization は、oc adm drain または kubectl drain のいずれかを実行してトリガーされるノードのドレイン (解放) を確実に特定することができません。これらのコマンドは、Container-native Virtualization がデプロイされているクラスターのノードでは実行しないでください。ノードは、それらの上部で実行されている仮想マシンがある場合にドレイン (解放) を実行しない可能性があります。現時点の解決策として、ノードをメンテナンス状態にする方法があります(BZ#1707427)。
  • 仮想マシンを bridge モードで接続された Pod ネットワークで接続し、cloud-init ディスクを使用する場合、仮想マシンは起動後にそのネットワーク接続を失います。回避策として、/etc/sysconfig/network-scripts/ifcfg-eth0ファイルの HWADDR 行を削除します(BZ#1708680)。
  • 現在、マスカレードは CNV では機能しません。アップストリームの問題のため、マスカレードモードでは仮想マシンをデフォルトの Pod ネットワークに接続できません(BZ#1725848)。
  • ウィザードでマスカレードが設定された NIC を作成しても、port オプションを指定できません(BZ#1725848)。
  • 仮想マシンが Guaranteed CPU を使用する場合、ラベル cpumanager=true がノードに自動的に設定されないためにスケジュールされません。回避策として、CPUManager エントリーを kubevirt-config ConfigMap から削除します。次に、ノードに cpumanager=true のラベルを手動で付けてからクラスター上で Guaranteed CPU を持つ仮想マシンを実行します(BZ#1718944)。
  • Web コンソールを使用して、既存の仮想マシンと同じ名前を持つ仮想マシンテンプレートを作成する場合、操作は失敗し、メッセージ Name is already used by another virtual machine が表示されます。回避策として、コマンドラインからテンプレートを作成します(BZ#1717930)。
  • ReadWriteMany (RWX) はライブマイグレーションでサポートされる唯一のストレージアクセスモードであり、VMware 仮想マシンをインポートし、ウィザードを使用して仮想マシンを作成します(BZ#1724654)。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.