Container-native Virtualization リリースノート

OpenShift Container Platform 3.11

Container-native Virtualization リリースノート

概要

本リリースの CNV の既知の問題および修正された問題

第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 のテクノロジープレビュー機能のサポートについての詳細は、テクノロジープレビュー機能のサポート範囲を参照してください。

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 に組み込まれています。いくつかの重要な変更点が最新の設定ファイルテンプレートに反映されています。
- apiVersion が kubevirt.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 マネージャーは物理 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)

Container-native Virtualization リリースノート