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 de v1.5.x para v1.6.x

Informações gerais

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

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

Apenas clientes afetados por problemas listados na seção de Correção de Bug das notas de lançamento devem instalar v1.5.2.

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

Atualize a extensão de UI do Harvester na SUSE Rancher Prime v2.12

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

  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. Permita algum tempo para que a extensão seja atualizada, e então atualize a tela.

Problemas conhecidos

A atualização está presa no estado "Pré-drenado"

Em certas situações, o Gerenciador de Instâncias pode falhar em limpar uma instância de engine, mesmo após o estado do CR da engine ter mudado para "Parado". O processo de atualização fica preso no estado "Pré-drenado" porque o pod do gerenciador de instâncias não pode ser excluído enquanto o correspondente PodDisruptionBudget (PDB) ainda existir.

A solução alternativa é excluir o PDB do gerenciador de instâncias após garantir que todos os volumes estejam saudáveis.

Problemas relacionados: #8977 e #11605

O cluster de convidados está preso no estado "Atualizando"

Um cluster de convidados RKE2 pode ficar preso no estado "Atualizando" após a atualização do SUSE Virtualization. A seguinte mensagem de erro é exibida na interface do SUSE Virtualization:

Configuring etcd node(s) rke2-pool1-xdvfc-qf4vb: Node condition MemoryPressure is Unknown. Node condition DiskPressure is Unknown. Node condition PIDPressure is Unknown. Node condition Ready is Unknown, waiting for probes: calico, etcd, kube-apiserver, kube-controller-manager

O problema ocorre quando o endereço IP do nó convidado muda após a atualização, causando mau funcionamento do etcd. É provável que a máquina virtual subjacente tenha sido reiniciada várias vezes e recebido um novo endereço IP do servidor DHCP.

Para resolver o problema, execute os seguintes passos:

  1. Na interface do Rancher, exclua o nó que causa o erro do cluster de convidados.

  2. Na interface do SUSE Virtualization, verifique o status da máquina virtual subjacente.

  3. Se necessário, reinicie a máquina virtual.

A máquina virtual é removida e o cluster de convidados tenta criar um novo nó. Uma vez que o nó é criado, o status do cluster de convidados muda para "Ativo".

Problema relacionado: #8950

Máquina virtual parada está presa no estado "Iniciando"

Um volume SUSE Storage pode alternar entre os estados "Desanexando" e "Desanexado" após uma migração ao vivo. Como o volume não está pronto, a máquina virtual associada não consegue iniciar completamente.

A solução alternativa é limpar o status.currentMigrationNodeID do volume usando o seguinte comando:

kubectl patch -n longhorn-system volume <volume> \
  --type=merge \
  --subresource status \
  -p '{"status":{"currentMigrationNodeID":""}}'

Problemas relacionados: #8949 e #11479

Nós presos no estado "Aguardando Reinício" devido a erro de configuração de rede

Os nós podem ficar presos no estado Waiting Reboot durante uma atualização se os seguintes critérios forem atendidos:

  • SUSE Virtualization v1.2.1 ou uma versão anterior foi instalada inicialmente, e os nós foram atualizados incrementalmente.

  • O campo vlan_id na configuração install.management_interface está definido como 1 ou está vazio.

O problema ocorre devido a um erro de configuração de rede, conforme indicado pela mensagem yaml: line did not find expected key nos logs do nó.

Durante a atualização, o arquivo /oem/90_custom.yaml é atualizado para refletir mudanças no comportamento da v1.5.x, que adicionou VLANs 2–4094 ao mgmt-br e mgmt-bo. Dois scripts nesse arquivo (/etc/wicked/scripts/setup_bond.sh e /etc/wicked/scripts/setup_bridge.sh) podem ser truncados por uma operação sed se utilizarem o formato gerado por gopkg.in/yaml.v2, que foi usado no instalador de versões SUSE Virtualization anteriores à 1.2.2. A operação sed remove a linha bridge vlan add vid 2-4094 dev $INTERFACE. Esse problema de truncamento não afeta scripts que utilizam o formato gerado por gopkg.in/yaml.v3.

A seguir estão os conteúdos do script /etc/wicked/scripts/setup_bond.sh no arquivo /oem/90_custom.yaml:

  • Gerado a partir de gopkg.in/yaml.v2:

    "#!/bin/sh\n\nACTION=$1\nINTERFACE=$2\n\ncase $ACTION in\n\tpost-up)\n\t\t#
inherit MAC address\n\t\tip link set dev mgmt-br address $(ip -json link show
dev $INTERFACE | jq -j '.[0][\"address\"]')\n\n\t\t# accept all vlan, PVID=1
by default\n\t\tbridge vlan add vid 2-4094 dev $INTERFACE\n\t\t;;\n\nesac\n"
```

  • Gerado a partir de gopkg.in/yaml.v3:

    #!/bin/sh
ACTION=$1
INTERFACE=$2
case $ACTION in
        post-up)
                # inherit MAC address
                ip link set dev mgmt-br address $(ip -json link show dev $INTERFACE | jq -j '.[0]["address"]')
                #accept all vlan,PVID=1 by default
                bridge vlan add vid 2-4094 dev $INTERFACE
                ;;
esac

A seguir estão os conteúdos do script /etc/wicked/scripts/setup_bridge.sh no arquivo /oem/90_custom.yaml:

  • Gerado a partir de gopkg.in/yaml.v2:

    "#!/bin/sh\n\nACTION=$1\nINTERFACE=$2\n\ncase $ACTION in\n\tpre-up)\n\t\t#
enable vlan-aware\n\t\tip link set dev $INTERFACE type bridge vlan_filtering 1\n\t\t\t;;\n\n\tpost-up)\n\t\t#
accept all vlan, PVID=1 by default\n\t\tbridge vlan add vid 2-4094 dev $INTERFACE
self\n\t\tbridge vlan add vid 2-4094 dev mgmt-bo\n\t\t;;\n\nesac\n"

  • Gerado a partir de gopkg.in/yaml.v3:

    #!/bin/sh
ACTION=$1
INTERFACE=$2
case $ACTION in
        pre-up)
               #enable vlan-aware
               ip link set $INTERFACE type bridge vlan_filtering 1
               ;;
        post-up)
                #accept all vlan, PVID=1 by default
                bridge vlan add vid 2-4094 dev $INTERFACE self
                bridge vlan add vid 2-4094 dev mgmt-bo
                ;;
esac

A solução alternativa é substituir o conteúdo do script desatualizado. Use os scripts no arquivo /oem/90_custom.yaml gerados a partir de gopkg.in/yaml.v3. Uma vez que os scripts sejam atualizados, a atualização é retomada.

Problema relacionado: #9033

Conectividade de rede perdida nas interfaces VLAN secundárias na rede do cluster mgmt.

SUSE Virtualization v1.6.0 introduziu uma mudança para reduzir o provisionamento desnecessário de VLANs. Anteriormente, todas as interfaces VLAN secundárias estavam conectadas à ponte mgmt-br e à interface mgmt-bo. Agora, apenas as interfaces VLAN necessárias estão conectadas. Consequentemente, quando um cluster é atualizado para v1.6.x, todas as interfaces VLAN secundárias que estavam anteriormente conectadas a mgmt-br e mgmt-bo são removidas dos hosts de gerenciamento.

Cargas de trabalho que dependem dessas interfaces perderão conectividade de rede.

Para mais informações, consulte problema #7650.

Após atualizar para a v1.6.x, realize as seguintes etapas:

  1. Verifique as VLANs anexadas a mgmt-br e mgmt-bo executando o seguinte comando nos hosts de gerenciamento:

    bridge vlan show

    Este comando exibe apenas a VLAN primária de mgmt-br e mgmt-bo.

  2. Adicione manualmente as VLANs secundárias necessárias à ponte mgmt-br e à interface mgmt-bo adicionando os seguintes comandos ao arquivo /oem/90_custom.yaml:

    • /etc/wicked/scripts/setup_bond.sh seção

      bridge vlan add vid <vlan-id> dev $INTERFACE

    • /etc/wicked/scripts/setup_bridge.sh seção

      bridge vlan add vid <vlan-id> dev $INTERFACE self
bridge vlan add vid <vlan-id> dev mgmt-bo

      Você deve incluir um comando separado para cada ID de VLAN distinto. Certifique-se de que o espaço reservado vlan-id seja substituído pelo ID real.

  3. Uma vez que o arquivo /oem/90_custom.yaml esteja atualizado, reinicie os hosts de gerenciamento.

  4. Verifique se todas as VLANs necessárias foram adicionadas executando o seguinte comando nos hosts:

    bridge vlan show

Exemplo de cenário de atualização

No exemplo a seguir, um cluster v1.5.x foi inicialmente instalado com uma interface de VLAN primária (ID da VLAN: 2021). Para adicionar uma interface de VLAN secundária (ID da VLAN: 2113), o arquivo /oem/99_vlan-ifcfg.yaml foi criado nos hosts de gerenciamento com o seguinte conteúdo:

stages:
  initramfs:
    - name: "Host VLAN interface mgmt-br.353"
      files:
        - path: /etc/sysconfig/network/ifcfg-mgmt-br.2113
          owner: 0
          group: 0
          permissions: 384
          content: |
            STARTMODE='onboot'
            BOOTPROTO='static'
            IPADDR='10.255.113.150/24'
            VLAN_ID='2113'
            ETHERDEVICE='mgmt-br'
            VLAN='yes'
            DEFROUTE='no'

A expectativa típica é que uma sub-interface de VLAN adicional seja criada na interface mgmt (mgmt-br.2113) e atribuída a um endereço IPv4. Além disso, espera-se que essa sub-interface e a interface primária (mgmt-br.2021) sejam usadas para conectividade L3 após a atualização do cluster para a v1.6.x.

Na realidade, após a atualização para a v1.6.0, a sub-interface de VLAN é criada, mas a VLAN secundária (ID da VLAN: 2113) é removida da ponte mgmt-br e da interface mgmt-bo. Após uma reinicialização, apenas o ID da VLAN primária é atribuído à ponte mgmt-br e à interface mgmt-bo (usando o arquivo /oem/90_custom.yaml).

Para mitigar os efeitos dessa mudança, você deve realizar a solução alternativa descrita na seção anterior. Isso envolve identificar interfaces de VLAN secundárias e, em seguida, adicionar as necessárias à ponte mgmt-br e à interface mgmt-bo.

Máquinas virtuais em execução exibem a mensagem Restart action is required

A interface SUSE Virtualization pode exibir a mensagem Restart action is required for the virtual machine configuration change to take effect para algumas máquinas virtuais em execução nas seguintes situações:

  • SUSE Virtualization é atualizado de v1.5.x para v1.6.x.

  • A Extensão da UI do Harvester é atualizada para v1.6.x.

  • SUSE Virtualization Os clusters são importados para Rancher v2.12.x.

Você deve reiniciar a máquina virtual para aplicar as alterações de configuração e limpar a mensagem.

A mensagem aparece porque a UI na versão SUSE Virtualization v1.6.0 e versões posteriores expõe a condição RestartRequired, que anteriormente só era visível na configuração YAML da máquina virtual. Essa visibilidade é essencial para recursos como hot plugging de CPU e memória, que envolvem alterações de configuração que só entram em vigor após a reinicialização da máquina virtual.

A condição RestartRequired foi introduzida para lidar com um descompasso de estado causado pelo método legado de sincronização de endereço MAC. Em versões anteriores à v1.6.0, o controlador KubeVirt aplicava automaticamente o patch do endereço MAC da instância da máquina virtual à especificação durante o processo de criação. Isso garantia que o endereço MAC permanecesse consistente entre as reinicializações. No entanto, como a especificação foi modificada enquanto a máquina virtual estava ativa, o controlador adicionou a condição RestartRequired para sinalizar que uma reinicialização manual era necessária para sincronizar o estado.

A máquina virtual não pode ser migrada ao vivo para o nó de destino.

Após uma atualização para v1.6.x, algumas máquinas virtuais podem permanecer no estado pendente de reinício. Essas máquinas virtuais não podem ser migradas ao vivo para o nó de destino especificado até que sejam reiniciadas.

A solução alternativa é reiniciar as máquinas virtuais. Uma vez reiniciadas, as migrações ao vivo específicas do nó subsequentes funcionarão.

Problema relacionado: #9739

O recurso cpu-feature.node.kubevirt.io/ipred-ctrl=true aparece durante o fazer upgrade.

O Harvester migra máquinas virtuais ao vivo para garantir zero tempo de inatividade durante as atualizações do nó. Se seu cluster usar algum dos seguintes modelos de CPU, você pode notar um sinalizador de recurso temporário (cpu-feature.node.kubevirt.io/ipred-ctrl=true) aparecer enquanto o fazer upgrade está em andamento.

  • Intel® Xeon® Gold 5418Y

  • Intel® Xeon® Silver 4509Y

Embora esse sinalizador de recurso seja removido automaticamente dos nós após o fazer upgrade, o seletor de nó correspondente é mantido na configuração da máquina virtual. Essa incompatibilidade entre os requisitos da máquina virtual e os rótulos do nó faz com que as migrações ao vivo subsequentes falhem.

Para resolver esse problema, execute uma das seguintes ações antes de iniciar o processo de fazer upgrade:

Mudança no comportamento padrão de VLAN para interfaces de pod secundárias

Nas versões v1.6.0 e anteriores, pods com interfaces de rede secundárias (como redes de VM e redes de armazenamento) eram automaticamente atribuídos ao ID de VLAN 1 e ao ID de VLAN configurado na rede VLAN. Essa configuração de VLAN com dois IDs permitia que a ponte de rede SUSE Virtualization encaminhasse tráfego não marcado para as interfaces veth desses pods.

Esse comportamento mudou na v1.6.1, que usa a v1.8.0 do plugin de ponte CNI. As interfaces de pod secundárias agora estão associadas apenas ao ID de VLAN atribuído à rede de VM. Como o ID de VLAN 1 não é mais adicionado, a ponte não consegue encaminhar tráfego não marcado para essas interfaces.

A mudança afeta clusters atualizados de v1.5.x para v1.6.1 se a porta do switch externo estiver configurada como uma porta de acesso enviando quadros não marcados. Atualizar a configuração do switch externo para usar uma porta trunk resolve o problema. Pods com interfaces secundárias que estão conectadas a redes não marcadas ou associadas ao ID de VLAN 1 não são afetados.

Problema relacionado: #8816