Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Faça upgrade da versão v1.6.x para v1.7.x

Informações gerais

Um botão de fazer upgrade aparece na tela Dashboard sempre que uma nova SUSE Virtualization versão para a qual você pode fazer upgrade se torna disponível. Para mais informações, veja Iniciar um upgrade.

Clusters executando v1.6.x podem fazer upgrade diretamente para v1.7.x porque SUSE Virtualization permite um máximo de um upgrade de versão menor para componentes subjacentes. v1.6.0 e v1.6.1 usam a mesma versão menor do RKE2 (v1.33), enquanto SUSE Virtualization v1.7.0 e v1.7.1 usam a próxima versão menor (v1.34). Para mais informações, veja Caminhos de upgrade.

Para informações sobre como fazer upgrade SUSE Virtualization em ambientes air-gapped, veja Preparar um upgrade em ambiente air-gapped.

v1.7.x usa o NetworkManager em vez do wicked, que era usado em versões anteriores de SUSE Virtualization. Se você modificou a configuração da interface de gerenciamento após a instalação inicial, deve realizar etapas manuais adicionais para evitar problemas durante o upgrade. Para obter mais informações, consulte [Migration from wicked to NetworkManager].

Além disso, nomes persistentes de certas interfaces de rede Intel podem mudar durante os upgrades. Isso quebra a conectividade no host e requer etapas manuais de remediação.

Endereços IP do host configurados via DHCP podem mudar durante os upgrades. Isso impede que o cluster inicie corretamente e requer etapas manuais de recuperação. Para obter mais informações, consulte [Host IP address may change during upgrade when using DHCP].

Atualize a Extensão da UI do Harvester na SUSE Rancher Prime v2.13

Você deve usar uma versão compatível (v1.7.x) da Extensão da UI do Harvester para importar clusters SUSE Virtualization v1.7.x na Rancher v2.13.

  1. Na UI do Rancher, vá para local → Apps → Repositórios.

  2. Localize o repositório chamado harvester, e então selecione ⋮ → Atualizar.

  3. Vá para a tela Extensões.

  4. Localize a extensão chamada Harvester, e então clique em Atualizar.

  5. Selecione uma versão compatível, e então clique em Atualizar.

  6. Aguarde um tempo para que a extensão seja atualizada, e então atualize a tela.

Migração do wicked para o NetworkManager

SUSE Virtualization v1.7.x faz a transição do wicked para o NetworkManager para gerenciamento de rede. Como não há um mapeamento direto 1:1 entre os arquivos legados ifcfg e os perfis de conexão do NetworkManager, uma migração in-loco da configuração de rede existente não é possível.

Durante os upgrades, SUSE Virtualization gera novos perfis de conexão do NetworkManager usando as configurações de instalação originais armazenadas em /oem/harvester.config. Os arquivos legados ifcfg em /oem/90_custom.yaml permanecem no sistema, mas o NetworkManager ignora esses arquivos e, em vez disso, armazena sua configuração em /etc/NetworkManager.

Cenário Ação Necessária

Você instalou a versão v1.1 ou posterior e nunca modificou manualmente a interface de gerenciamento ou a configuração de DNS.

Nenhuma

Você modificou manualmente a configuração da interface de gerenciamento editando o arquivo /oem/90_custom.yaml ou adicionando recursos do CloudInit aos arquivos ifcfg.

Necessário (A configuração personalizada será ignorada após o upgrade para v1.7.0.)

Se a ação for necessária, escolha um dos seguintes métodos:

  • Pré-atualização (Recomendado): Edite o arquivo /oem/harvester.config em cada nó. Configure as configurações de rede relevantes, particularmente os.dns_nameservers e install.management_interface. Para mais informações, consulte Arquivo de Configuração.

    Se você instalou inicialmente a v1.0, certifique-se de que install.management_interface siga o esquema atualizado exigido pelas versões posteriores de SUSE Virtualization.

  • Pós-atualização: Use a ferramenta nmcli para reaplicar manualmente sua configuração personalizada aos novos perfis de conexão do NetworkManager.

Se você encontrar algum problema durante o upgrade, pode realizar as seguintes soluções alternativas:

Cenário Solução Resultado

Um nó fica preso no estado "Aguardando Reinicialização".

Faça login via console e verifique a configuração de rede usando a ferramenta nmcli. Se necessário, corrija manualmente a configuração e reinicie o nó.

O upgrade retoma automaticamente.

Erros ocorrem quando você altera manualmente a configuração.

Se você quiser reverter para os perfis de conexão do NetworkManager gerados automaticamente, execute o comando harvester-installer generate-network-config.

Os perfis de conexão do NetworkManager em /etc/NetworkManager/system-connections/ são recriados com base na configuração especificada em /oem/harvester.config.

Problemas conhecidos

O endereço IP do host pode mudar durante o upgrade ao usar DHCP.

v1.7.x usa o NetworkManager em vez do wicked, que era usado em versões anteriores de SUSE Virtualization. Essas duas pilhas de rede têm padrões diferentes para gerar IDs de cliente DHCP.

Se os endereços IP dos hosts estiverem configurados usando DHCP, um upgrade SUSE Virtualization e o reinício subsequente podem fazer com que o servidor DHCP atribua endereços IP diferentes dos que os hosts usaram anteriormente. Consequentemente, os hosts afetados não conseguem ingressar no cluster na inicialização devido à mudança de endereço IP.

Esse problema geralmente ocorre quando o servidor DHCP aloca endereços IP com base apenas no ID do cliente DHCP. É improvável que você encontre esse problema quando o servidor DHCP estiver configurado para alocar endereços IP fixos com base no endereço MAC (como demonstrado nos Exemplos de iPXE).

O impacto desse problema varia de acordo com o tamanho do cluster:

  • Clusters de nó único: SUSE Virtualization falha ao iniciar após reiniciar porque o endereço IP mudou.

  • Clusters de múltiplos nós: Os nós de gerenciamento ficam presos no estado "Aguardando Reinício".

Para resolver o problema, execute os seguintes passos:

Você deve realizar os passos para cada nó afetado após a conclusão do upgrade e a mudança do endereço IP.

  1. Faça login no nó afetado. Você pode acessar o nó via SSH em seu novo endereço IP ou usar o console.

  2. No diretório /var/lib/wicked, verifique o arquivo XML de locação (nome semelhante a /var/lib/wicked/lease-mgmt-br-dhcp-ipv4.xml).

    Se você estiver usando uma VLAN, o nome de arquivo inclui o ID da VLAN (por exemplo, /var/lib/wicked/lease-mgmt-br.2017-dhcp-ipv4.xml).

  3. Visualize o arquivo e identifique o ID do cliente 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. Use o comando nmcli para definir o ID do cliente DHCP para o perfil de conexão do NetworkManager apropriado.

    O perfil de conexão que você precisa modificar depende se seu nó usa uma VLAN.

    • VLAN utilizada: Adicione o ID do cliente DHCP ao perfil de conexão vlan-mgmt.

    • Sem VLAN: Adicione o ID do cliente DHCP ao perfil de conexão bridge-mgmt.

      Exemplo (sem 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

      Você deve substituir o ID do cliente no exemplo pelo ID do cliente real do seu arquivo de lease do wicked.

  5. Reinicie o nó.

O servidor DHCP deve retornar o endereço IP original e o nó afetado deve ser capaz de ingressar no cluster.

A propagação do ID do cliente DHCP do wicked para o NetworkManager ocorre automaticamente durante o upgrade de v1.6.x para v1.7.1. Esta solução alternativa é necessária apenas ao upgrade para v1.7.0.

Problemas relacionados: #9260 e #3418

O upgrade está preso em "Atualizando Serviço do Sistema".

O processo de upgrade pode ficar preso na fase "Atualizando Serviço do Sistema". Este problema está provavelmente relacionado ao trabalho apply-manifest e a dois problemas conhecidos relacionados ao upgrade SUSE® Rancher Prime: Continuous Delivery.

Você pode encontrar mensagens de log semelhantes às seguintes:

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

Verifique o histórico do Helm para determinar a causa e a solução alternativa relacionada.

  • Cenário 1: O status do upgrade SUSE® Rancher Prime: Continuous Delivery é pending-upgrade mesmo após o upgrade ter sido concluído.

    $ 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

    Para resolver o problema, execute a seguinte solução alternativa:

    1. Execute o comando $ helm rollback fleet -n cattle-fleet-system.

    2. Aguarde o Rancher embutido reconciliar o CRD ClusterRepo e acionar o upgrade do gráfico Helm. Para acelerar o processo, você pode reiniciar os pods do Rancher embutido.

  • Cenário 2: O upgrade está preso em uma versão candidata de lançamento (RC).

    Isso não deve ocorrer, a menos que você esteja fazendo upgrade de uma versão RC para uma versão estável, o que não é suportado. Para assistência, crie um [problema no 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

Problemas relacionados: #9738 e #9680

Nomes persistentes de certas interfaces de rede podem mudar durante o upgrade.

SUSE Virtualization v1.7.x usa versões mais recentes dos drivers de rede i40e e ice do kernel Linux, fazendo com que um número de porta seja adicionado ao nome de certas interfaces de rede Intel, como a X710. Por exemplo, uma interface chamada enp6s0f0 na SUSE Virtualization v1.6.x é renomeada para enp6s0f0np0 durante o upgrade para v1.7.0. Isso quebra a conectividade no host porque as configurações de rede existentes ainda fazem referência ao nome original.

Para resolver esse problema, aplique argumentos do kernel que restauram os nomes originais das interfaces afetadas.

  1. Recupere a lista de argumentos do kernel não padrão (third_party_kernel_args) no nó.

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

  2. Adicione ifname=nicName:macAddress para cada interface de rede no nó para restaurar os nomes originais.

    Certifique-se de que third_party_kernel_args esteja incluído ao adicionar os argumentos ifname=.

    Exemplo:

    $ 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. Reinicie o nó.

Essa solução alternativa é necessária apenas ao atualizar para v1.7.0. Nas versões v1.7.1 e posteriores, esses argumentos ifname= são adicionados automaticamente para evitar interrupções na rede durante as atualizações do driver.

Problemas relacionados: #9815 e #9802