|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
v1.6.xからv1.7.xにアップグレードする
一般情報
新しいSUSE Virtualizationバージョンにアップグレードできるようになると、*ダッシュボード*画面に*アップグレード*ボタンが表示されます。詳細については、アップグレードを開始するを参照してください。
v1.6.xを実行しているクラスターは、SUSE Virtualizationが基盤コンポーネントのマイナーバージョンのアップグレードを最大1回許可するため、v1.7.xに直接アップグレードできます。v1.6.0およびv1.6.1はRKE2の同じマイナーバージョン(v1.33)を使用し、SUSE Virtualization v1.7.0およびv1.7.1は次のマイナーバージョン(v1.34)を使用します。詳細については、アップグレードパスを参照してください。
エアギャップ(された)環境でのSUSE Virtualizationのアップグレードに関する情報は、エアギャップ(された)アップグレードの準備を参照してください。
|
v1.7.xは、以前のSUSE Virtualizationのバージョンで使用されていたwickedの代わりにNetworkManagerを使用します。初回インストール後に管理インターフェースの設定を変更した場合、アップグレード中の問題を避けるために追加の手動手順を実行する必要があります。詳細については、[Migration from wicked to NetworkManager]を参照してください。 さらに、特定のIntelネットワークインタフェースの永続的な名前がアップグレード中に変更される可能性があります。これによりホストの接続が切断され、手動での修復手順が必要になります。 |
|
DHCPを介して設定されたホストのIPアドレスは、アップグレード中に変更される可能性があります。これによりクラスターが正しく起動できなくなり、手動での回復手順が必要になります。詳細については、[Host IP address may change during upgrade when using DHCP]を参照してください。 |
SUSE Rancher Prime v2.13でHarvester UI拡張機能を更新する
Rancher v2.13でSUSE Virtualization v1.7.xクラスターをインポートするには、Harvester UI拡張機能の互換性のあるバージョン(v1.7.x)を使用する必要があります。
-
Rancher UI で、ローカル → アプリ → リポジトリ に移動します。
-
harvester*という名前のリポジトリを見つけて、⋮ → 更新*を選択します。
-
*拡張機能*画面に移動します。
-
*Harvester*という名前の拡張機能を見つけて、*更新*をクリックします。
-
互換性のあるバージョンを選択し、*更新*をクリックします。
-
拡張機能が更新されるまでしばらく待ち、画面を更新します。
wickedからNetworkManagerへの移行
SUSE Virtualization v1.7.xはネットワーク管理のためにwickedからNetworkManagerに移行します。レガシー`ifcfg`ファイルとNetworkManagerの接続プロファイルの間には直接的な1:1のマッピングがないため、既存のネットワーク設定のインプレース移行は不可能です。
アップグレード中、SUSE Virtualizationは`/oem/harvester.config`に保存された元のインストール設定を使用して新しいNetworkManager接続プロファイルを生成します。/oem/90_custom.yaml`内のレガシー`ifcfg`ファイルはシステムに残りますが、NetworkManagerはこれらのファイルを無視し、代わりに/etc/NetworkManager`の下に設定を保存します。
| 場面 | 必須アクション |
|---|---|
v1.1以降をインストールし、管理インターフェースやDNS設定を手動で変更したことはありません。 |
なし |
`/oem/90_custom.yaml`設定ファイルを編集するか、`ifcfg`設定ファイルにCloudInitリソースを追加することで、管理インターフェースの設定を手動で変更しました。 |
必須（v1.7.0へのアップグレード後はカスタム設定が無視されます。） |
アクションが必要な場合は、次のいずれかの方法を選択してください：
-
アップグレード前（推奨）：各ノードの`/oem/harvester.config`ファイルを編集します。関連するネットワーク設定、特に`os.dns_nameservers`と`install.management_interface`を構成します。詳細については、設定ファイルを参照してください。
最初にv1.0をインストールした場合は、`install.management_interface`が後のSUSE Virtualizationバージョンで必要とされる更新されたスキーマに従っていることを確認してください。
-
アップグレード後：`nmcli`ツールを使用して、新しいNetworkManager接続プロファイルにカスタム設定を手動で再適用します。
アップグレード中に問題が発生した場合は、次の回避策を実行できます：
| 場面 | 解決策 | 結果 |
|---|---|---|
ノードが「再起動待機」状態で固まります。 |
コンソール経由でログインし、`nmcli`ツールを使用してネットワーク設定を確認します。必要に応じて、手動で設定を修正し、その後ノードを再起動します。 |
アップグレードは自動的に再開されます。 |
手動で設定を変更するとエラーが発生します。 |
自動生成されたNetworkManager接続プロファイルに戻したい場合は、コマンド`harvester-installer generate-network-config`を実行します。 |
|
当バージョンの注意事項
DHCPを使用している場合、アップグレード中にホストIPアドレスが変更される可能性があります。
v1.7.xは、以前のSUSE Virtualizationのバージョンで使用されていたwickedの代わりにNetworkManagerを使用します。これらの2つのネットワークスタックは、DHCPクライアントIDを生成するためのデフォルトが異なります。
ホストIPアドレスがDHCPを使用して構成されている場合、SUSE Virtualizationのアップグレードとその後の再起動により、DHCPサーバーが以前のホストが使用していたものとは異なるIPアドレスを割り当てる可能性があります。その結果、影響を受けたホストは、IPアドレスの変更により、起動時にクラスタに参加できません。
この問題は、DHCPサーバーがDHCPクライアントIDのみに基づいてIPアドレスを割り当てるときに通常発生します。DHCPサーバーがMACアドレスに基づいて固定IPアドレスを割り当てるように設定されている場合（ iPXEの例で示されているように）、この問題に遭遇する可能性は低いです。
この問題の影響はクラスタのサイズによって異なります。
-
シングルノードクラスタ：SUSE Virtualizationは再起動後にIPアドレスが変更されたため、起動に失敗します。
-
マルチノードクラスタ：管理ノードは「再起動待機」状態で固まります。
この問題に対処するには、次の手順を実行してください。
|
アップグレードが完了し、IPアドレスが変更された after、影響を受けた各ノードに対して手順を実行する必要があります。 |
-
影響を受けたノードにログインします。新しいIPアドレスでSSHを介してノードにアクセスするか、コンソールを使用できます。
-
/var/lib/wicked`ディレクトリで、リースXMLファイル（/var/lib/wicked/lease-mgmt-br-dhcp-ipv4.xml`に似た名前）を確認します。VLANを使用している場合、ファイル名にはVLAN IDが含まれます（例：
/var/lib/wicked/lease-mgmt-br.2017-dhcp-ipv4.xml）。 -
ファイルを表示し、DHCPクライアントIDを特定します。
$ cat /var/lib/wicked/lease-mgmt-br-dhcp-ipv4.xml <lease> ... <ipv4:dhcp> <client-id>ff:00:dd:c7:05:00:01:00:01:30:ae:a0:d3:52:54:00:dd:c7:05</client-id> ... </ipv4:dhcp> </lease> -
適切なNetworkManager接続プロファイルのDHCPクライアントIDを設定するには、`nmcli`コマンドを使用します。
変更が必要な接続プロファイルは、ノードがVLANを使用しているかどうかによって異なります。
-
使用されるVLAN：DHCPクライアントIDを`vlan-mgmt`接続プロファイルに追加します。
-
VLANなし：DHCPクライアントIDを`bridge-mgmt`接続プロファイルに追加します。
例（VLANなし）：
$ nmcli con modify bridge-mgmt \ ipv4.dhcp-client-id \ ff:00:dd:c7:05:00:01:00:01:30:ae:a0:d3:52:54:00:dd:c7:05例のクライアントIDを、実際のクライアントID（wickedリースファイルから取得したもの）に置き換える必要があります。
-
-
ノードを再起動します。
DHCPサーバーは元のIPアドレスを返すべきで、影響を受けたノードはクラスターに参加できるはずです。
|
v1.6.xからv1.7.1にアップグレードする際、DHCPクライアントIDのwickedからNetworkManagerへの伝播は自動的に行われます。この回避策はv1.7.0にアップグレードする際のみ必要です。 |
アップグレードが「システムサービスのアップグレード中」で停止しています。
アップグレードプロセスは「システムサービスのアップグレード中」フェーズで停止する可能性があります。この問題は`apply-manifest`ジョブおよびSUSE® Rancher Prime: Continuous Deliveryアップグレードに関連する2つの既知の問題に関連している可能性があります。
次のようなログメッセージに遭遇することがあります。
...
Happy Containering!
Wait for Rancher dependencies helm releases...
wait helm release cattle-fleet-system fleet fleet-108.0.0+up0.14.0 0.14.0 deployed
wait helm release cattle-fleet-system fleet-crd fleet-crd-108.0.0+up0.14.0 0.14.0 deployed原因と関連する回避策を特定するためにHelmの履歴を確認してください。
-
シナリオ1:SUSE® Rancher Prime: Continuous Deliveryのアップグレードステータスは、アップグレードが完了した後も`pending-upgrade`です。
$ helm history fleet -n cattle-fleet-system REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 6 Tue Nov 4 06:22:34 2025 superseded fleet-105.0.2+up0.11.2 0.11.2 Upgrade complete 7 Tue Nov 4 06:22:49 2025 superseded fleet-105.0.2+up0.11.2 0.11.2 Upgrade complete 8 Mon Dec 8 07:10:43 2025 superseded fleet-106.1.1+up0.12.3 0.12.3 Upgrade complete 9 Mon Dec 8 07:26:49 2025 deployed fleet-106.1.1+up0.12.3 0.12.3 Upgrade complete 10 Mon Dec 8 07:27:10 2025 pending-upgrade fleet-106.1.1+up0.12.3 0.12.3 Preparing upgradeこの問題に対処するには、次の回避策を実行してください：
-
コマンド`$ helm rollback fleet -n cattle-fleet-system`を実行します。
-
埋め込まれたRancherが`ClusterRepo` CRDを調整し、Helmチャートのアップグレードをトリガーするのを待ちます。プロセスを加速するために、埋め込まれたRancherポッドを再起動することができます。
-
-
シナリオ2:アップグレードがリリース候補（RC）バージョンで停止しています。
これは、RCバージョンから安定版へアップグレードする場合にのみ発生する現象であり、サポート対象外です。サポートが必要な場合は、[GitHub issue](https://github.com/harvester/harvester/issues)を作成してください。
# helm history fleet -n cattle-fleet-system REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 2 Mon Dec 8 10:43:42 2025 superseded fleet-108.0.0+up0.14.0-rc.1 0.14.0-rc.1 Upgrade complete 3 Mon Dec 8 10:49:51 2025 superseded fleet-108.0.0+up0.14.0-rc.1 0.14.0-rc.1 Upgrade complete 4 Mon Dec 8 10:50:04 2025 superseded fleet-108.0.0+up0.14.0-rc.1 0.14.0-rc.1 Upgrade complete 5 Mon Dec 8 10:56:30 2025 superseded fleet-108.0.0+up0.14.0-rc.1 0.14.0-rc.1 Upgrade complete 6 Mon Dec 8 10:56:42 2025 deployed fleet-108.0.0+up0.14.0-rc.1 0.14.0-rc.1 Upgrade complete
特定のネットワークインタフェースの永続的な名前は、アップグレード中に変更される可能性があります。
SUSE Virtualization v1.7.xはLinuxカーネルの`i40e`および`ice`ネットワークドライバーの新しいバージョンを使用しており、X710などの特定のIntelネットワークインタフェースの名前にポート番号が追加される原因となります。例えば、`enp6s0f0`という名前のネットワークインタフェースは、SUSE Virtualization v1.6.xで、v1.7.0へのアップグレード中に`enp6s0f0np0`に変更されます。これにより、既存のネットワーク設定が元の名前を参照し続けるため、ホストの接続が切断されます。
この問題を解決するには、影響を受けたネットワークインタフェースの元の名前を復元するカーネル引数を適用してください。
-
ノード上のデフォルト以外のカーネル引数のリスト(
third_party_kernel_args)を取得します。$ grub2-editenv /oem/grubenv list third_party_kernel_args=multipath=off -
ノード上の各ネットワークインタフェースに対して`ifname=nicName:macAddress`を追加し、元の名前を復元します。
`third_party_kernel_args`引数を追加する際に`ifname=`が含まれていることを確認してください。
例:
$ grub2-editenv /oem/grubenv set \ third_party_kernel_args="multipath=off ifname=enp6s0f0:d4:c9:ef:ce:30:68 ifname=enp6s0f1:d4:c9:ef:ce:30:69" -
ノードを再起動します。
|
この回避策は、v1.7.0へのアップグレード時にのみ必要です。v1.7.1以降のバージョンでは、これらの`ifname=`引数が自動的に追加され、ドライバーの更新中にネットワークの中断を防ぎます。 |