Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Mettez à niveau de v1.6.x vers v1.7.x

informations générales

Un bouton de mise à niveau apparaît sur l’écran Tableau de bord chaque fois qu’une nouvelle SUSE Virtualization version à laquelle vous pouvez mettre à niveau devient disponible. Pour plus d’informations, consultez Démarrer une mise à niveau.

Les clusters exécutant v1.6.x peuvent être mis à niveau directement vers v1.7.x car SUSE Virtualization permet un maximum d’une mise à niveau mineure pour les composants sous-jacents. v1.6.0 et v1.6.1 utilisent la même version mineure de RKE2 (v1.33), tandis que SUSE Virtualization v1.7.0 et v1.7.1 utilisent la prochaine version mineure (v1.34). Pour plus d’informations, consultez Chemins de mise à niveau.

Pour des informations sur la mise à niveau de SUSE Virtualization dans des environnements isolés physiquement, consultez Préparer une mise à niveau isolée physiquement.

v1.7.x utilise NetworkManager au lieu de wicked, qui était utilisé dans les versions antérieures de SUSE Virtualization. Si vous avez modifié la configuration de l’interface de gestion après l’installation initiale, vous devez effectuer des étapes manuelles supplémentaires pour éviter des problèmes lors de la mise à niveau. Pour plus d’informations, reportez-vous au [Migration from wicked to NetworkManager].

De plus, les noms persistants de certaines interfaces réseau Intel peuvent changer lors des mises à niveau. Cela interrompt la connectivité sur l’hôte et nécessite des étapes de remédiation manuelles.

Les adresses IP des hôtes configurées via DHCP peuvent changer lors des mises à niveau. Cela empêche le cluster de démarrer correctement et nécessite des étapes de récupération manuelles. Pour plus d’informations, reportez-vous au [Host IP address may change during upgrade when using DHCP].

Mettez à jour l’extension UI de Harvester sur SUSE Rancher Prime v2.13

Vous devez utiliser une version compatible (v1.7.x) de l’extension UI de Harvester pour importer des clusters SUSE Virtualization v1.7.x sur Rancher v2.13.

  1. Sur l’interface Rancher, allez à local → Apps → Repositories.

  2. Localisez le dépôt nommé harvester, puis sélectionnez ⋮ → Actualiser.

  3. Allez à l’écran Extensions.

  4. Localisez l’extension nommée Harvester, puis cliquez sur Mettre à jour.

  5. Sélectionnez une version compatible, puis cliquez sur Mettre à jour.

  6. Laissez un certain temps pour que l’extension soit mise à jour, puis actualisez l’écran.

Migration de wicked vers NetworkManager

La version SUSE Virtualization v1.7.x passe de wicked à NetworkManager pour la gestion des réseaux. Étant donné qu’il n’existe pas de correspondance directe 1:1 entre les fichiers ifcfg hérités et les profils de connexion de NetworkManager, une migration sur place de la configuration réseau existante n’est pas possible.

Lors des mises à niveau, SUSE Virtualization génère de nouveaux profils de connexion NetworkManager en utilisant les paramètres d’installation d’origine stockés dans /oem/harvester.config. Les fichiers ifcfg hérités dans /oem/90_custom.yaml restent sur le système, mais NetworkManager ignore ces fichiers et stocke plutôt sa configuration sous /etc/NetworkManager.

Scénario Action requise

Vous avez installé la version v1.1 ou ultérieure, et vous n’avez jamais modifié manuellement l’interface de gestion ou la configuration DNS.

aucune

Vous avez modifié manuellement la configuration de l’interface de gestion en éditant le fichier /oem/90_custom.yaml ou en ajoutant des ressources CloudInit aux fichiers ifcfg.

Requis (La configuration personnalisée sera ignorée après la mise à niveau vers v1.7.0.)

Si une action est requise, choisissez l’une des méthodes suivantes :

  • Avant la mise à niveau (Recommandé) : Modifiez le fichier /oem/harvester.config sur chaque nœud. Configurez les paramètres réseau pertinents, en particulier os.dns_nameservers et install.management_interface. Pour plus d’informations, consultez Fichier de configuration.

    Si vous avez initialement installé la version v1.0, assurez-vous que install.management_interface suit le schéma mis à jour requis par les versions ultérieures de SUSE Virtualization.

  • Après la mise à niveau : Utilisez l’outil nmcli pour réappliquer manuellement votre configuration personnalisée aux nouveaux profils de connexion NetworkManager.

Si vous rencontrez des problèmes lors de la mise à niveau, vous pouvez effectuer les solutions de contournement suivantes :

Scénario Solution provisoire Résultat

Un nœud reste bloqué dans l’état "En attente de redémarrage".

Connectez-vous via la console et vérifiez la configuration réseau à l’aide de l’outil nmcli. Si nécessaire, corrigez manuellement la configuration, puis redémarrez le nœud.

La mise à niveau reprend automatiquement.

Des erreurs se produisent lorsque vous modifiez manuellement la configuration.

Si vous souhaitez revenir aux profils de connexion NetworkManager générés automatiquement, exécutez la commande harvester-installer generate-network-config.

Les profils de connexion NetworkManager dans /etc/NetworkManager/system-connections/ sont recréés en fonction de la configuration spécifiée dans /oem/harvester.config.

Problèmes connus

L’adresse IP de l’hôte peut changer pendant la mise à niveau lors de l’utilisation de DHCP.

v1.7.x utilise NetworkManager au lieu de wicked, qui était utilisé dans les versions antérieures de SUSE Virtualization. Ces deux piles réseau ont des valeurs par défaut différentes pour la génération des identifiants de client DHCP.

Si les adresses IP des hôtes sont configurées à l’aide de DHCP, une mise à niveau SUSE Virtualization et un redémarrage ultérieur peuvent amener le serveur DHCP à attribuer des adresses IP différentes de celles utilisées précédemment par les hôtes. Par conséquent, les hôtes concernés ne peuvent pas rejoindre le cluster au démarrage en raison du changement d’adresse IP.

Ce problème se produit généralement lorsque le serveur DHCP attribue des adresses IP uniquement en fonction de l’identifiant de client DHCP. Il est peu probable que vous rencontriez ce problème lorsque le serveur DHCP est configuré pour attribuer des adresses IP fixes en fonction de l’adresse MAC (comme démontré dans les Exemples iPXE).

L’impact de ce problème varie en fonction de la taille du cluster :

  • Clusters à nœud unique : SUSE Virtualization ne parvient pas à démarrer après le redémarrage car l’adresse IP a changé.

  • Clusters à nœuds multiples : Les nœuds de gestion se bloquent dans l’état "En attente de redémarrage".

Pour résoudre le problème, effectuez les étapes suivantes :

Vous devez effectuer les étapes pour chaque nœud affecté après que la mise à niveau soit terminée et que l’adresse IP ait changé.

  1. Connectez-vous au nœud affecté. Vous pouvez soit accéder au nœud via SSH à sa nouvelle adresse IP, soit utiliser la console.

  2. Dans le répertoire /var/lib/wicked, vérifiez le fichier XML de bail (nommé de manière similaire à /var/lib/wicked/lease-mgmt-br-dhcp-ipv4.xml).

    Si vous utilisez un VLAN, le nom du fichier inclut l’ID VLAN (par exemple, /var/lib/wicked/lease-mgmt-br.2017-dhcp-ipv4.xml).

  3. Consultez le fichier et identifiez l’ID client DHCP.

    $ 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>

  4. Utilisez la commande nmcli pour définir l’ID client DHCP pour le profil de connexion NetworkManager approprié.

    Le profil de connexion que vous devez modifier dépend de l’utilisation d’un VLAN par votre nœud.

    • VLAN utilisé : Ajoutez l’ID client DHCP au profil de connexion vlan-mgmt.

    • Pas de VLAN : Ajoutez l’ID client DHCP au profil de connexion bridge-mgmt.

      Exemple (sans 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

      Vous devez remplacer l’ID client dans l’exemple par l’ID client réel de votre fichier de bail wicked.

  5. Redémarrez le nœud.

Le serveur DHCP devrait renvoyer l’adresse IP d’origine et le nœud affecté devrait pouvoir rejoindre le cluster.

La propagation de l’ID client DHCP de wicked à NetworkManager se produit automatiquement lors de la mise à niveau de v1.6.x à v1.7.1. Cette solution de contournement n’est requise que lors de la mise à niveau vers v1.7.0.

Problèmes connexes : #9260 et #3418

La mise à niveau est bloquée dans "Mise à niveau du service système"

Le processus de mise à niveau peut être bloqué dans la phase "Mise à niveau du service système". Ce problème est probablement lié au job apply-manifest et à deux problèmes connus liés à la mise à niveau SUSE® Rancher Prime: Continuous Delivery.

Vous pouvez rencontrer des messages de journal similaires aux suivants :

...
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

Vérifiez l’historique de Helm pour déterminer la cause et la solution de contournement associée.

  • Scénario 1 : L’état de mise à niveau SUSE® Rancher Prime: Continuous Delivery est pending-upgrade même après que la mise à niveau a été complétée.

    $ 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

    Pour résoudre le problème, effectuez la solution de contournement suivante :

    1. Exécutez la commande $ helm rollback fleet -n cattle-fleet-system.

    2. Attendez que le Rancher intégré réconcilie le CRD ClusterRepo et déclenche la mise à niveau du chart Helm. Pour accélérer le processus, vous pouvez redémarrer les pods Rancher intégrés.

  • Scénario 2 : La mise à niveau est bloquée sur une version candidate de publication (RC).

    Cela ne devrait pas se produire à moins que vous ne passiez d’une version RC à une version stable, ce qui n’est pas pris en charge. Pour obtenir de l’aide, créez un [problème GitHub](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

Problèmes connexes : #9738 et #9680

Les noms persistants de certaines interfaces réseau peuvent changer lors de la mise à niveau

SUSE Virtualization v1.7.x utilise des versions plus récentes des pilotes réseau i40e et ice du kernel Linux, ce qui entraîne l’ajout d’un numéro de port au nom de certaines interfaces réseau Intel, comme le X710. Par exemple, une interface nommée enp6s0f0 sur SUSE Virtualization v1.6.x est renommée en enp6s0f0np0 lors de la mise à niveau vers v1.7.0. Cela rompt la connectivité sur l’hôte car les configurations réseau existantes font toujours référence au nom d’origine.

Pour résoudre ce problème, appliquez des arguments du kernel Linux qui restaurent les noms d’origine des interfaces affectées.

  1. Récupérez la liste des arguments du kernel Linux non par défaut (third_party_kernel_args) sur le nœud.

    $ grub2-editenv /oem/grubenv list
third_party_kernel_args=multipath=off

  2. Ajoutez ifname=nicName:macAddress pour chaque interface réseau sur le nœud pour restaurer les noms d’origine.

    Assurez-vous que third_party_kernel_args est inclus lorsque vous ajoutez les arguments ifname=.

    Exemple :

    $ 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"

  3. Redémarrez le nœud.

Cette solution de contournement n’est nécessaire que lors de la mise à niveau vers v1.7.0. Dans les versions v1.7.1 et ultérieures, ces ifname= arguments sont ajoutés automatiquement pour éviter les interruptions réseau lors des mises à jour de pilotes.

Problèmes connexes : #9815 et #9802