第2章 Container-native Virtualization リリースノート
2.1. Container-native Virtualization リリースノート
2.1.1. Container-native Virtualization 2.2 について
2.1.1.1. Container-native Virtualization の機能
Container-native Virtualization は OpenShift Container Platform のアドオンであり、仮想マシンのワークロードを実行し、このワークロードをコンテナーのワークロードと共に管理することを可能にします。
Container-native Virtualization は、Kubernetes カスタムリソースを使って新規オブジェクトを OpenShift Container Platform クラスターに追加し、仮想化タスクを有効にします。これらのタスクには、以下が含まれます。
- Linux および Windows 仮想マシンの作成と管理
- 各種コンソールおよび CLI ツールの使用による仮想マシンへの接続
- 既存の仮想マシンのインポートおよびクローン作成
- ネットワークインターフェースコントローラーおよび仮想マシンに割り当てられたストレージディスクの管理
- 仮想マシンのノード間でのライブマイグレーション
機能強化された Web コンソールは、これらの仮想化されたリソースを OpenShift Container Platform クラスターコンテナーおよびインフラストラクチャーと共に管理するためのグラフィカルポータルを提供します。
2.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/ を参照してください。
2.1.2. 新機能および変更された機能
設計とワークフローの向上により、仮想マシンの管理がシンプルかつより効率的になります。以下を実行することができます。
- 仮想マシンウィザードをナビゲーションの回数を少なくして実行できます。ウィザードは、包括的な in-page (ページ内) スタイルを使用し、送信前に設定の詳細を確認できるレビューページが含まれています。
- 単一の VMware 仮想マシンをナビゲーションの回数を少なくしてインポートできます。
- 仮想マシンテンプレートと仮想マシン設定を編集します。
- Pod ベースのサービスの場合のように、仮想マシンベースのサービスの正常性をモニターできます。
- 仮想マシンイメージ用に永続的なローカルストレージを有効にできます。
- 仮想マシンに接続されている仮想 CD-ROM デバイスを追加し、編集し、表示できます。
- グラフィカルエディターでネットワーク割り当て定義を追加し、表示できます。
2.1.3. 解決済みの問題
-
以前は、Web コンソールの Disks タブでディスクを仮想マシンに追加する場合、
kubevirt-storage-class-defaultConfigMap に volumeMode が設定されているかにかかわらず、追加されたディスクにFilesystemvolumeMode が常にありました。この問題は修正されています。(BZ#1753688) - 以前は、Virtual Machines Console タブに移動する際に、コンテンツが表示されないことがありました。この問題は修正されています。(BZ#1753606)
- 以前は、ブラウザーから Container-native Virtualization Operator のすべてのインスタンスの一覧表示を試行すると、404 (page not found) エラーが出されました。この問題は修正されています。(BZ#1757526)
-
以前は、仮想マシンが Guaranteed CPU を使用する場合、ラベル
cpumanager=trueがノードに自動的に設定されないためにスケジュールされませんでした。この問題は修正されています。(BZ#1718944)。
2.1.4. 既知の問題
- Container-native Virtualization 2.1.0 をデプロイしている場合、OpenShift Container Platform をアップグレードする前にまず Container-native Virtualization を 2.2.0 にアップグレードする必要があります。Container-native Virtualization をアップグレードする前に OpenShift Container Platform をアップグレードすると、仮想マシンが削除される可能性があります。(BZ#1785661)
-
仮想マシンの
masqueradeバインディングメソッドは、RHEL 7 コンピュートノードを含むクラスターでは使用できません。(BZ#1741626) 移行後、仮想マシンには新規の IP アドレスが割り当てられます。ただし、コマンドの
oc get vmiおよびoc describe vmiは古くなった IP アドレスを含む出力を依然として出力します。(BZ#1686208)回避策として、以下のコマンドを実行して正しい IP アドレスを表示します。
$ oc get pod -o wide
- 一部のリソースは、Container-native Virtualization の削除時に不適切に保持される状態が生じます。Container-native Virtualization を再インストールするためにこれらのリソースを手動で削除する必要があります。(BZ#1712429)
管理者権限を持たないユーザーは、仮想マシンのウィザードを使用して、L2 ネットワークのプロジェクトにネットワークインターフェースを追加できません。この問題は、ユーザーがネットワーク割り当て定義を読み込む権限がないために発生します。(BZ#1743985)
回避策として、ネットワークの割り当て定義を読み込むパーミッションを持つユーザーを指定します。
以下の例を使用して
ClusterRoleおよびClusterRoleBindingオブジェクトを YAML 設定ファイルに定義します。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cni-resources rules: - apiGroups: ["k8s.cni.cncf.io"] resources: ["*"] verbs: ["*"]
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <role-binding-name> roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cni-resources subjects: - kind: User name: <user to grant the role to> namespace: <namespace of the user>
cluster-adminユーザーとして以下のコマンドを実行し、定義したClusterRoleおよびClusterRoleBindingオブジェクトを作成します。$ oc create -f <filename>.yaml
ノードの CPU モデルが異なるとライブマイグレーションに失敗します。ノードに同じ物理 CPU モデルがある場合でも、マイクロコードの更新によって導入される違いにより同じ状況が生じます。これは、デフォルト設定が、ライブマイグレーションと互換性のないホスト CPU パススルー動作をトリガーするためです。(BZ#1760028)
回避策として、以下の例のように
kubevirt-configConfigMap にデフォルトの CPU モデルを設定します。注記ライブマイグレーションをサポートする仮想マシンを起動する前に、この変更を行う必要があります。
以下のコマンドを実行して、編集するために
kubevirt-configConfigMap を開きます。$ oc edit configmap kubevirt-config -n openshift-cnv
ConfigMap を編集します。
kind: ConfigMap metadata: name: kubevirt-config data: default-cpu-model: "<cpu-model>" 1- 1
<cpu-model>を実際の CPU モデルの値に置き換えます。すべてのノードにoc describe node <node>を実行し、cpu-model-<name>ラベルを確認してこの値を判別できます。すべてのノードに存在する CPU モデルを選択します。
virtctl image-uploadを実行してqcow2形式で大規模な仮想マシンディスクをアップロードすると、アップロードが通常に処理され、完了する場合でも、データ送信後に EOF (end-of-file) エラーが報告される場合があります。(BZ#1789093)以下のコマンドを実行して、指定された Pod でアップロードのステータスを確認します。
$ oc describe pvc <pvc-name> | grep cdi.kubevirt.io/storage.pod.phase
Haswell CPU を使用して仮想マシンの作成および起動を試行する場合、仮想マシンの起動が誤ってラベルが付けられたノードによって失敗する可能性があります。これは、以前のバージョンの Container-native Virtualization からの動作の変更点になります。この場合、仮想マシンは Haswell ホストで正常に起動されました。(BZ#1781497)
回避策として、可能であれば別の CPU モデルを選択します。
- オペレーティングシステムと領域を共有しているディレクトリーを選択すると、パーティションの領域を使い切ってしまう可能性があり、ノードが機能しなくなる可能性があります。代わりに、別のパーティションを作成し、そのパーティションにホストパスプロビジョナーをポイントし、これがオペレーティングシステムに干渉しないようにします。(BZ#1793132)
- Container-native Virtualization のアップグレードプロセスは、Operator Lifecycle Manager (OLM) の中断により失敗する可能性があります。この問題は、Container-native Virtualization Operator の状態を追跡するために宣言型 API を使用することに関連する制限によって生じます。インストール時に自動更新を有効にすることにより、この問題が発生するリスクが低くなります。(BZ#1759612)
-
Container-native Virtualization は、
oc adm drainまたはkubectl drainのいずれかを実行してトリガーされるノードのドレイン (解放) を確実に特定することができません。これらのコマンドは、Container-native Virtualization がデプロイされているクラスターのノードでは実行しないでください。ノードは、それらの上部で実行されている仮想マシンがある場合にドレイン (解放) を実行しない可能性があります。現時点の解決策として、ノードをメンテナンス状態にする方法があります(BZ#1707427) Operators
Installed Operators ページで Subscription タブに移動し、現在のアップグレードチャネルをクリックしてこれを編集する場合、結果が表示されない可能性があります。これが発生すると、エラーは表示されません。(BZ#1796410) 回避策として、以下の
ocpatch コマンドを実行して、CLI から Container-native Virtualization 2.2 へのアップグレードプロセスをトリガーします。$ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.2 && oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"'${CNV_CHANNEL}'"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'このコマンドは、アップグレードチャネル
2.2にサブスクリプションをポイントし、自動更新を有効にします。
