第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)。