Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

2.1. Container-native Virtualization リリースノート

2.1.1. Container-native Virtualization 2.3 について

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 クラスターコンテナーおよびインフラストラクチャーと共に管理するためのグラフィカルポータルを提供します。

Container-native Virtualization は OVN-Kubernetes または OpenShiftSDN ネットワークプロバイダーのいずれかを使って使用できます。

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. 新機能および変更された機能

  • Container-native Virtualization は、Windows Server のワークロードを実行する Microsoft の Windows Server Virtualization Validation Program (SVVP) で認定されています。

    • SVVP の認定は、Intel および AMD の CPU に適用されます。
    • SVVP 認定 Red Hat Enterprise Linux CoreOS 8 ワーカーの名前は、Red Hat OpenShift Container Platform 4 on RHEL CoreOS 8 です。
  • Microsoft Windows 10 と互換性がある新しいテンプレートを利用できます。

2.1.2.1. ネットワーク

  • Container-native Virtualization は、OVN-Kubernetes または OpenShiftSDN ネットワークプロバイダーのいずれかを使って使用できます。

  • Container-native Virtualization は nmstate を使用してノードネットワークの状態を報告し、設定します。単一の設定マニフェストをクラスターに適用して、すべてのノードに Linux ブリッジ、ボンドおよび VLAN デバイスを作成するなどして、ネットワークポリシーの設定を変更することができます。

2.1.2.2. ストレージ

  • これで、CPU およびメモリーリソースの制限が適用される namespace に仮想マシンディスクをインポートし、アップロードし、そのクローンを作成できるようになりました。
  • virtctl ツールは、サーバー側のアップロードの後処理を非同期的に監視し、仮想マシンのディスクのアップロード のステータスをより正確に報告できるようになりました。

2.1.2.3. Web コンソール

  • Web コンソールで仮想マシンの Paused ステータスを表示できるようになりました。Web コンソールでは、Virtual Machines ダッシュボードと Virtual Machine Details ページにこのステータスが表示されます。
注記

oc CLI を使用して、仮想マシンの Paused ステータスを表示することもできます。 

$ oc get vmi testvm -o=jsonpath='{.status.conditions[?(@.type=="Paused")].message}'
  • 仮想マシンのステータスが Paused の場合、Web コンソールからその一時停止を解除 できます。
  • 仮想マシンの一覧内の仮想マシンから切り離された仮想マシンインスタンスを表示し、管理できます。
  • Container-native Virtualization を使用すると、 仮想マシンウィザード で CD-ROM を設定できます。ドロップダウンリストから CD-ROM 設定のタイプ (Container、URL、または Attach Disk) を選択できます。また、Virtual Machine Details ページで CD-ROM 設定を編集 することもできます。
  • ブート順序の一覧 が Virtual Machine Details で利用可能になりました。項目を追加したり、削除したり、またブート順序の一覧を変更したりすることができます。
  • 仮想マシンおよび仮想マシンテンプレートウィザードでは、さまざまなオペレーティングシステムの CPU およびメモリーサイズおよびディスクバスの要件を検証できるようになりました。特定のオペレーティングシステムの要件を満たさない仮想マシンまたは仮想マシンテンプレートを作成しようとすると、ウィザードによりリソースの警告が表示されます。
  • Virtual Machine Details ページで、仮想マシンの専用リソース を表示し、設定できるようになりました。専用リソースを有効にしたら、仮想マシンのワークロードが他のプロセスで使用されていない CPU で実行されることを確認します。これにより、仮想マシンのパフォーマンスとレイテンシー予測の精度が向上します。

2.1.3. 主な技術上の変更点

  • Container-native Virtualization を、openshift-cnv という名前の単一 namespace にデプロイする必要があります。openshift-cnv namespace は、存在していない場合、デプロイメント時に自動的に作成されるようになりました。
  • エラーを防ぐために、Container-native Virtualization デプロイメント時に作成する CNV Operator Deployment カスタムリソースの名前を変更できなくなりました。デフォルト名の kubevirt-hyperconverged という名前のカスタムリソースを作成しようとする場合、作成が失敗し、エラーメッセージが Web コンソールに表示されます。

  • 意図しないデータ損失を防ぐために、クラスターに仮想マシンまたは DataVolume が定義されている場合は、Container-native Virtualization をアンインストールできなくなりました。

    • Container-native Virtualization をアンインストールする前に、すべての 仮想マシン (VM)、仮想マシンインスタンス (VMI)、および DataVolume (DV) を手動で削除する必要があります。

    • Container-native Virtualization のアンインストールを試行する際に VM、VMI、または DV オブジェクトが存在する場合は、残りのオブジェクトが削除されるまでアンインストールプロセスは完了しません。

      注記

      保留中のオブジェクトが原因でアンインストールが一時停止されていることを確認するには、Events タブを表示します。

2.1.4. 既知の問題

  • KubeMacPool は Container-native Virtualization 2.3 で無効にされています。つまり、Pod または仮想マシンのセカンダリーインターフェイスは、プールから一意のアドレスではなく、無作為に生成された MAC アドレスを取得します。稀なケースで、無作為に割り当てられた MAC アドレスが競合する可能性があります。(BZ#1816971)

  • Web コンソールで Container-native Virtualization Operator のサブスクリプションチャネルを編集しようとする際に、Subscription Overview の Channel ボタンをクリックすると JavaScript エラーが発生することがあります。(BZ#1796410)

    • 回避策として、以下の oc patch コマンドを実行して、CLI から Container-native Virtualization 2.3 へのアップグレードプロセスをトリガーします。 

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.3 && 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.3 にサブスクリプションをポイントし、自動更新を有効にします。

  • 仮想マシンおよび仮想マシンテンプレートウィザードでは、virtIO が CD-ROM を割り当てる際にデフォルトのインターフェイスになります。ただし、virtIO CD-ROM は仮想マシンの検証をパスせず、これを作成できません。(BZ#1817394)

    • 回避策として、仮想マシンおよび仮想マシンテンプレートを作成する際に、SATA を CD-ROM インターフェイスとして選択します。

  • Containerized Data Importer (CDI) は、インポートおよびアップロード操作に CDIConfig オブジェクトの scratchSpaceStorageClass 設定を常に使用する訳ではありません。代わりに、CDI はデフォルトのストレージクラスを使用してスクラッチ領域を割り当てます。(BZ#1828198)

    • 回避策として、クラスターのデフォルトストレージクラスが定義されていることを確認します。以下のコマンドを使用して、必要なアノテーションを適用できます。 

      $ oc patch storageclass <STORAGE_CLASS_NAME> -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'

  • 以前のバージョンの Container-native Virtualization のデプロイ時に Operator デプロイメントのカスタムリソースの名前を変更した場合、Container-native Virtualization 2.3 に直接アップグレードすることはできません。カスタムリソースは、デフォルト名の kubevirt-hyperconverged という名前にする必要があります。(BZ#1822266)

    • 回避策として、以下のいずれかを実行できます。

      • 既存のカスタムリソースの名前を kubevirt-hyperconverged に変更します。
      • デフォルトの kubevirt-hyperconverged という名前の新規のカスタムリソースを作成します。次に、kubevirt-hyperconverged という名前のカスタムリソースを削除します。
  • OpenShift Container Platform 4.4 Web コンソールには、NIC を仮想マシンに追加する際に slirp がオプションとして含まれますが、slirp は有効な NIC タイプではありません。NIC を仮想マシンに追加する場合、slirp は選択しないでください。(BZ#1828744)

  • 移行後、仮想マシンには新規の IP アドレスが割り当てられます。ただし、コマンドの oc get vmi および oc describe vmi は古くなった IP アドレスを含む出力を依然として出力します。(BZ#1686208)

    • 回避策として、以下のコマンドを実行して正しい IP アドレスを表示します。 

      $ oc get pod -o wide

  • 管理者権限を持たないユーザーは、仮想マシンのウィザードを使用して、L2 ネットワークのプロジェクトにネットワークインターフェイスを追加できません。この問題は、ユーザーがネットワーク割り当て定義を読み込む権限がないために発生します。(BZ#1743985)

    • 回避策として、ネットワークの割り当て定義を読み込むパーミッションを持つユーザーを指定します。

      1. 以下の例を使用して 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>

      2. cluster-admin ユーザーとして以下のコマンドを実行し、定義した ClusterRole および ClusterRoleBinding オブジェクトを作成します。 

        $ oc create -f <filename>.yaml

  • ノードの CPU モデルが異なると、ライブマイグレーションに失敗します。ノードに同じ物理 CPU モデルがある場合でも、マイクロコードの更新によって導入される違いにより同じ状況が生じます。これは、デフォルト設定が、ライブマイグレーションと互換性のないホスト CPU パススルー動作をトリガーするためです。(BZ#1760028)

    • 回避策として、以下の例のように kubevirt-config ConfigMap にデフォルトの CPU モデルを設定します。

      注記

      ライブマイグレーションをサポートする仮想マシンを起動する前に、この変更を行う必要があります。

      1. 以下のコマンドを実行して、編集するために kubevirt-config ConfigMap を開きます。 

        $ oc edit configmap kubevirt-config -n openshift-cnv

      2. 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 モデルを選択します。

  • Haswell CPU を使用して仮想マシンの作成および起動を試行する場合、仮想マシンの起動が誤ってラベルが付けられたノードによって失敗する可能性があります。これは、以前のバージョンの Container-native Virtualization からの動作の変更点になります。この場合、仮想マシンは Haswell ホストで正常に起動されました。(BZ#1781497)

    回避策として、可能であれば別の 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)

  • Operators Installed Operators ページで Subscription タブに移動し、現在のアップグレードチャネルをクリックしてこれを編集する場合、結果が表示されない可能性があります。これが発生すると、エラーは表示されません。(BZ#1796410)

    • 回避策として、以下の oc patch コマンドを実行して、CLI から Container-native Virtualization 2.3 へのアップグレードプロセスをトリガーします。 

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.3 && 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.3 にサブスクリプションをポイントし、自動更新を有効にします。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.