Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第1章 Container-native Virtualization リリースノート

1.1. 製品概要

1.1.1. Container-native Virtualization の導入

Container-native Virtualization は OpenShift Container Platform のアドオンであり、仮想マシンのワークロードを実行し、このワークロードをコンテナーのワークロードと共に管理することを可能にします。仮想マシンは、Containerized Data Importer (CDI) コントローラーを使用してインポートされるディスクイメージから作成することも、OpenShift Container Platform 内でゼロから作成することもできます。

Container-native Virtualization は 2 つの新たなオブジェクトを OpenShift Container Platform に導入します。

  • Virtual Machine (仮想マシン): OpenShift Container Platform の仮想マシンです。
  • Virtual Machine Instance (仮想マシンインスタンス): 実行される仮想マシンのインスタンスです。

Container-native Virtualization アドオンを使用すると、仮想マシンは Pod で実行され、仮想マシンに標準的な Pod と同じネットワークおよびストレージ機能を持たせることができます。

既存の仮想マシンディスクは永続ボリューム (PV) にインポートされます。この永続ボリューム (PV) は、Persistent Volume Claim (永続ボリューム要求、PVC) を使用して Container-native Virtualization 仮想マシンからアクセスできるようになります。OpenShift Container Platform では、仮想マシンオブジェクトは、PV に保存される永続データに影響を与えることなく、変更したり、置き換えたりすることができます。

重要

現時点で Container-native Virtualization はテクノロジープレビュー機能です。Container-native Virtualization についての Red Hat サポートの詳細は、「Container-native Virtualization - Technology Preview Support Policy」を参照してください。

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

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

1.2. 新機能および変更された機能

1.2.1. Operator の導入

  • Operator は KubeVirt、Containerized Data Importer、および Container-native Virtualization 1.4 の Web UI のインストールをサポートします。

1.2.2. KubeVirt API の更新

  • 新規バージョンの KubeVirt API が Container-native Virtualization 1.4 に組み込まれています。いくつかの重要な変更点が最新の設定ファイルテンプレートに反映されています。

    • apiVersionkubevirt.io/v1alpha2 から kubevirt.io/v1alpha3 に更新されています。
    • volumeName 属性がなくなりました。それぞれのディスク名がすべての設定ファイルの対応するボリューム名と一致することを確認してください。
    • registryDisk のすべてのインスタンスは、設定ファイルの containerDisk に対して更新される必要があります。

1.3. 解決済みの問題

  • runc パッケージバージョン runc-1.0.0-54 には、FIPS が無効にされている場合に virt-launcher をクラッシュさせるバグが含まれていました。この修正が含まれる runc のバージョンは Red Hat Enterprise Linux 7 Extras に同梱されるようになりました (BZ1650512)。
  • 「Create Virtual Machine」ウィザードで Start virtual machine on creation オプションを指定して PXE ソースオプションを使用すると、仮想マシンの停止および起動後にブートの順序を変更できなくなりました。この問題は解決されています (BZ#1648245) (BZ#1647447)。

1.4. 既知の問題

  • 現時点で、CPU Manager (OpenShift Container Platform で CPU ピニングを提供する機能) は、パフォーマンスが低下する問題のために Container-native Virtualization で無効にされています。CPU Manager では物理的な CPU トポロジーを考慮しないため、ハイパースレッディングが有効にされている場合ピニングが最適に実行されません (BZ#1667854)。
  • 3.11 よりも前の Red Hat OpenShift Container Storage バージョンには Container-native Virtualization との互換性がありません。互換性のないバージョンでは、 Gluster ノードをコンテナーランタイムとしての CRI-O と共にデプロイできません (BZ#1651270)。
  • Container-native Virtualization 1.4 のインストール時に、ansible-playbook コマンドは、multus イメージおよびその基礎となるレイヤーがタイムアウト期間にプルされない場合に失敗します。回避策として、数分の間待機し、コマンドの実行を再度試行します (BZ#1664274)。
  • virtctl image-upload コマンドは、--uploadproxy-url の値が末尾のスラッシュで終了する場合に失敗します。カスタム URL を使用する場合、コマンドを実行する前に値が末尾のスラッシュで終了していないことを確認してください (BZ#1660888)。
  • 現時点でコンピュートノードデバイスの制限値は 110 です。この制限を設定することはできませんが、今後のリリースでは 110 を超えるデバイスへのスケールアップがサポートされます (BZ#1673438)。
  • ディスクイメージを PVC にアップロードするか、またはインポートする場合に、PVC に割り当てられる領域は 2 * 実際のイメージのサイズ + 仮想イメージのサイズ以上である必要があります。それ以外の場合には、仮想マシンは正常に起動しません (BZ#1676824)。

    注記

    コマンド $ ls -sh <image_file> は実際のサイズを報告します。圧縮されていない raw イメージの場合、コマンド $ ls -lh <image_file> は仮想サイズを報告します。QCOW2 イメージの場合は、両方の値を取得するために $ qemu-img info <image_file> を使用します。

  • 新規 DataVolume を作成する際に 同じ名前を持つ PVC がすでに存在する場合、DataVolume は修復不能な状態になります。この DataVolume が仮想マシンに関連付けられるか、またはこれが仮想マシン設定ファイルの dataVolumeTemplates セクションを使って作成されている場合、仮想マシンの起動は失敗します。この場合、根本的な DataVolume のエラーは仮想マシンに伝播しません (BZ#1669163)。
  • CDI の PVC へのインポートが失敗する場合、PVC を削除する要求はすぐに機能しない可能性があります。代わりに、Importer Pod が CrashLoopBackOff 状態になり、PVC は Terminating フェーズに入ります。この問題を解決するには、PVC に関連付けられた Importer Pod を見つけ、これを削除します。その後 PVC は削除されます (BZ#1673683)。
  • virtctl image-upload を使用して QCOW2 イメージを PVC にアップロードする場合、この操作はエラー Unexpected return value 500 を出して失敗し、PVC が使用できなくなる可能性があります。この問題は、アップロード操作時の特定の QCOW2 イメージの変換が事前定義のプロセス制限を超えるバグによって生じる可能性があります (BZ#1679134)。

    失敗がこのバグによるものかを確認するには、関連する uploadserver Pod のログで以下のようなメッセージの有無を確認します。

    1 uploadserver.go:203] Saving stream failed: data stream copy failed: Local qcow to raw conversion failed: could not convert local qcow2 image to raw: qemu-img execution failed: signal: killed

    回避策として、ファイルを圧縮された Raw 形式に変換し、その結果をアップロードします。

    $ qemu-img convert -f qcow2 -O raw <failing-image.qcow2> image.raw
    $ gzip image.raw
    $ virtctl image-upload ... image.raw.gz
  • URL ソースからプロビジョニングされる仮想マシンが最初に起動される際に、Container-native Virtualization がエンドポイント URL からコンテナーをインポートする間、仮想マシンの状態は Importing になります。
    Importing 状態の仮想マシンを再起動すると、エラーが生じます (BZ#1673921)。
  • ノード上の kubelet がクラッシュするか、または再起動する場合、kubelet が誤って 0 KVM デバイスと報告します。仮想マシンは影響を受けるノードで適切にスケジュールされません。

    以下を実行して kubelet が報告するデバイス数を確認します。

    $ oc get node $NODE | grep devices.kubevirt

    影響を受けるノードの出力には、devices.kubevirt.io/kvm: 0 が表示されます (BZ#1681175)。

    注記

    回避策として、影響を受けるノードで関連のある virt-handler Pod を強制終了します。Pod は自動的に再起動し、 kubelet は利用可能な KVM デバイスの正確な数を報告します。

  • bridge モードを使用して仮想マシンが Pod ネットワークに接続される場合、kubelet が再起動すると、仮想マシンは停止する可能性があります (BZ#1685118)。