第3章 Container-native Virtualization 2.1 リリースノート
3.1. Container-native Virtualization 2.1 リリースノート
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 ツールの使用による仮想マシンへの接続
- 既存の仮想マシンのインポートおよびクローン作成
- ネットワークインターフェースコントローラーおよび仮想マシンに割り当てられたストレージディスクの管理
- 仮想マシンのノード間でのライブマイグレーション
機能強化された 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. Web コンソールの強化
-
OpenShift Container Platform ダッシュボードは、クラスターについてのハイレベル情報をキャプチャーします。OpenShift Container Platform Web コンソールから、Home
Dashboards Overview をクリックしてダッシュボードにアクセスします。Web コンソールのプロジェクトの概要には、仮想マシンが一覧表示されていないことに注意してください。仮想マシンは Cluster Inventory ダッシュボードカードに一覧表示されるようになります。
3.1.2.2. その他の改善点
Container-native Virtualization のインストール後に、MAC プールマネージャーが自動的に起動します。MAC アドレスを指定せずにセカンダリー NIC を定義すると、MAC プールマネージャーは一意の MAC アドレスを NIC に割り当てます。
注記特定の MAC アドレスでセカンダリー NIC を定義する場合、MAC アドレスがクラスター内の別の NIC と競合する可能性があります。
3.1.3. 解決済みの問題
-
以前のバージョンでは、Web コンソールを使用して、既存の仮想マシンと同じ名前を持つ仮想マシンテンプレートを作成すると、操作に失敗していました。これにより、
Name is already used by another virtual machineというメッセージが出されました。この問題は Container-native Virtualization 2.1 で修正されています。(BZ#1717802) -
以前は、
bridgeモードで仮想マシンを作成し、cloud-initディスクを使用する場合、仮想マシンは再起動後にそのネットワーク接続を失いました。この問題は Container-native Virtualization 2.1 で修正されています。(BZ#1708680)。
3.1.4. 既知の問題
-
仮想マシンの
masqueradeバインディングメソッドは、RHEL 7 コンピュートノードを含むクラスターでは使用できません。(BZ#1741626) Container-native Virtualization のインストール時に KubeVirt HyperConverged Cluster Operator Deployment カスタムリソースを作成する場合、YAML ファイルは間違った値で表示されます。ファイルは以下の例のようになります。
apiVersion: hco.kubevirt.io/v1alpha1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: BareMetalPlatform: 'false' 1- 1
'false'という語の周りにある単一引用符が適切ではありません。このファイルを編集し、Create をクリックする前に行にBareMetalPlatform: falseと表示されるようにします。引用符が削除されないと、デプロイメントは成功しません。(BZ#1767167)
-
Web コンソールの Disks タブでディスクを仮想マシンに追加する場合、
kubevirt-storage-class-defaultConfigMap に volumeMode が設定されたかどうかに関わらず、追加されたディスクにFilesystemvolumeMode が常にあります。(BZ#1753688) 移行後、仮想マシンには新規の IP アドレスが割り当てられます。ただし、コマンドの
oc get vmiおよびoc describe vmiは古くなった IP アドレスを含む出力を依然として出力します。(BZ#1686208)回避策として、以下のコマンドを実行して正しい IP アドレスを表示します。
$ oc get pod -o wide
仮想マシンウィザードは、管理者権限を持たないユーザーの場合は読み込まれません。この問題は、ユーザーがネットワーク割り当て定義を読み込む権限がないために発生します。(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
- Virtual Machines Console タブに移動する際に、コンテンツが表示されないことがあります。回避策として、シリアルコンソールを使用します。(BZ#1753606)
ブラウザーからの Container-native Virtualization Operator のすべてのインスタンスの一覧表示を試行すると、404 (page not found) エラーが出されます。(BZ#1757526)
回避策として、以下のコマンドを実行します。
$ oc get pods -n openshift-cnv | grep operator
一部のリソースは、Container-native Virtualization の削除時に不適切に保持される状態が生じます。Container-native Virtualization を再インストールするためにこれらのリソースを手動で削除する必要があります。(BZ#1712429), (BZ#1757705)
- 回避策として、「Removing leftover resources from container-native virtualization 2.1 uninstallation」の手順に従ってください。
-
仮想マシンが Guaranteed CPU を使用する場合、ラベル
cpumanager=trueがノードに自動的に設定されないためにスケジュールされません。回避策として、CPUManagerエントリーをkubevirt-configConfigMap から削除します。次に、ノードにcpumanager=trueのラベルを手動で付けてからクラスター上で Guaranteed CPU を持つ仮想マシンを実行します(BZ#1718944)。 ノードの 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 モデルを選択します。
- 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) virtctl image-uploadを実行してqcow2形式で大規模な仮想マシンディスクをアップロードすると、アップロードが通常に処理され、完了する場合でも、データ送信後に EOF (end-of-file) エラーが報告される場合があります。(BZ#1754920)以下のコマンドを実行して、指定された Pod でアップロードのステータスを確認します。
$ oc describe pvc <pvc-name> | grep cdi.kubevirt.io/storage.pod.phase
