Possíveis soluções quando a migração de ambiente em produção falhar em hospedeiros com o mesmo tipo de CPU

Sintoma : Ao efetuar a migração de ambiente em uso de uma máquina virtual Hyper-V para um hospedeiro que tenha o mesmo tipo de CPU da fonte, o Hyper-V reclama de incompatibilidades entre as duas CPUs. Além disso esse mesmo processo de migração provavelmente funcionou no passado.

A identificação do evento é 21502. O texto completo da mensagem de erro é:

A migração ao vivo de ‘Virtual Machine VMName ‘ falhou.

A operação de migração da máquina virtual para ‘VMNAME’ falhou no destino de migração ‘DESTINATION_HOST’. (ID de máquina virtual VMID )

A máquina virtual ‘VMNAME’ está usando recursos específicos do processador não suportados no computador físico ‘DESTINATION_HOST’. Para permitir a migração desta máquina virtual para computadores físicos com processadores diferentes, modifique as configurações da máquina virtual para limitar os recursos do processador usados pela máquina virtual. (ID de máquina virtual VMID).

Possíveis razões pela migração de ambiente em produção possa falhar em hospedeiros com o mesmo tipo de CPU

Normalmente, é um problema surge em hospedeiros utilizando CPUs que expõem conjuntos de recursos diferentes – assim como os estados da mensagem de erro. É sugerido o uso de uma ferramenta como CPU-Z para identificá-las.

Neste artigo o objetivo é apenas apresentar casos em que as CPUs têm o mesmo conjunto de recursos. Alguns conjuntos de recursos como; identificadores de CPU exibem os mesmos números de família, modelo, classe de revisão e número de revisão. E ainda, o Hyper-V informa precisarem utilizar o modo de compatibilidade.

Causa 1: Mitigações do Spectre:

As atenuações do Spectre são suficientes para impedir as migrações entre ambientes em produção, mesmo assim pode não ser óbvio para qualquer pessoa que não siga as notas de atualização do BIOS. Para confirmar se é o caso, verifique o nível de atualização do BIOS nos hospedeiros. Faça isso rapidamente pedindo ao PowerShell para verificar o WMI: Get-WmiObject -ClassName Win32_BIOS, Get-CimInstance -ClassName Win32_BIOS, ou de maneira mais simples, gwmi win32_bios:

Uma diferença nas versões do BIOS pode responder por toda a história ao analisar as notas de lançamento. Quando as atualizações foram lançadas contemplando a primeira onda de vulnerabilidades de CPU de classe Spectre, elas incluíam o microcódigo que modificava a maneira como as CPUs processam as instruções. Então, os conjuntos de recursos da CPU não mudaram no geral, mas sua funcionalidade foram modificadas.

As atualizações que evitam o Specctre repara o BIOS nem sempre causam falhas de migração ao vivo

É possível já existirem alguns sistemas que receberam as atualizações de hardware que não impediram a migração de ambiente em produção. Muitos eventos estão em execução todas essas atualizações que equivalem a muitas partes móveis:

• São atualizações que exigem uma inicialização a frio do sistema físico para serem aplicadas totalmente. A maioria dos sistemas modernos de grandes fabricantes tem a capacidade de inicialização automática após uma atualização do BIOS, mesmo assim nem todos fazem isso. É possível que exista no ambiente uma atualização parcialmente aplicada aguardando uma inicialização a frio.

• Essas atualizações exigem uma correção plena do sistema operacional executado no hospedeiro. Ele pode estar aguardando a instalação ou reinicialização após a aplicação de uma rotina de correção.

• São atualizações que exigem dos convidados serem inicializados a frio a partir de um hospedeiro já atualizado. Alguns clusters estão funcionando tão bem há tanto tempo que não é possível saber a última vez que um determinado convidado foi inicializado a frio. Se não for de um hospedeiro atualizado, ele não terá as atenuações e não se importará se for movido para um hospedeiro desatualizado. Também serão facilmente transferidos para um hospedeiro desatualizado.

• Podem existir configurações de registro que bloqueiam as migrações, o que teria um efeito colateral para impedir que interfiram no processo de migração em ambiente de produção.

A seguir uma combinação “infalível” que sempre previne a migração em produção:

• Hospedeiro de origem totalmente corrigido – BIOS e Windows.

• Sistema operacional da máquina virtual totalmente corrigido.

• Configurações do registro permitem a verificação no hospedeiro, o convidado e a máquina virtual.

• O convidado foi inicializado a frio a partir do hospedeiro de origem.

• O hospedeiro de destino não possui pelo menos a atualização correta do BIOS.

Como a migração em produção funciona com mais frequência do que falha, é difícil prever quando uma migração em produção será bem-sucedida em hospedeiros incompatíveis.

Corrigindo um bloqueio de migração em produção causado pelo Spectre

A primeira e melhor opção é atualizar todos os hospedeiros, sistemas operacionais dos hospedeiros e sistemas operacionais convidados, garantindo que nenhuma configuração de registro impeça sua aplicação. Preocupações com desempenho e tempo de inatividade são reais, é claro, mas não tão grandes quanto a ameaça de uma exposição por falha. Além disso, estando na posição em que este artigo pode ser aplicado, já terá pelo menos um hospedeiro atualizado. Permitindo muito bem colocá-lo em prática.

Existem vários caminhos para resolver esse problema. A seguir uma rota que pode resultar em menos interrupções:

• Consertar todos os convidados mas não permitir que sejam reiniciados.

• Atualizar o hospedeiro até o BIOS mais atual e os níveis de arquivos de correção.

• Incluir todas as VMs que poderia acrescentar; em dois clusters de nós, significando utilizar todos os convidados.

• Executar um desligamento completo e a inicialização dessas VMs; permitindo aplicar os arquivos de correção e utilizar o status de atualização do hospedeiro em um ciclo de inicialização. Também os bloqueou nesse nó, então fique atento a isso.

• Mover através dos hospedeiros restantes no cluster. Em clusters maiores, isso também significava VMs adicionais oportunamente inicializadas a frio.

Dessa maneira, cada máquina virtual foi inicializada a frio apenas uma vez, não ocorrendo nenhuma falha da migração em produção. Certifique-se de verificar essa atividade em cada ponto antes de prosseguir – há muito trabalho a ser feito aqui e uma etapa perdida provavelmente resultará em reinicializações adicionais.

Nota : Ativar o recurso de compatibilidade da CPU provavelmente não ajudará a superar o problema da migração em produção – mas pode. Não parece afetar todos de maneira idêntica, como devido a diferenças fundamentais em diferentes gerações de processadores.

Automatizando o lançamento de mitigação do Spectre

Os processos de automação de arquivos de correção normais abrangem reinicializações, não inicializações a frio e elaborar uma rotina infalível para abordar adequadamente tudo o que pode ocorrer impede estabelecer um roteiro. São arquivos de correção disruptivos, no caso de processos de correção como esse se tornarem um evento regular (muito provável de ocorrer), essa conclusão poderá ser revista. Uma roteirização poderia ser necessária na existência de dezenas ou mais sistemas para gerenciar.

• Utilizar regras GPOs para alterar o comportamento do arquivo de correção, evitando reinicializações.

• Utilizar regras GPOs para filtrar seletivamente o aplicativo de mitigação até que esteja pronto

• Para inicializar com facilidade todas as VMs em um host, experimente: Get-VM | Stop-VM -Passthru | Start-VM. Mantenha a atenção para qualquer VM que não queira parar – deliberadamente, a dica é tentar não forçá-las.

• Possibilidade de utilizar Cluster Aware Updating para implementar arquivos de correção do BIOS. Mesmo assim é válido organizar manualmente as atualizações do BIOS nesse caso e, em seguida, permitir a reinicialização planejada do arquivo de correção lidar com o aplicativo final.

De maneira geral, pouco foi apresentado além de programar manualmente os ciclos de energia dos convidados.

Causa 2: Incompatibilidade de versão do Hypervisor

É interessante estabelecer laboratórios utilizando o Windows Server Insider. Um ambiente em cluster da versão 2016 permite conhecer as novidades das versões mais recentes. Uma experiência ocorreu em algum momento durante sua execução onde começaram a surgir erros do conjunto de recursos da CPU tentando se movimentar entre si. Depois de ativar o recurso de compatibilidade CPU não inibiu essas falhas neste caso, mesmo sendo uma versão ainda em desenvolvimento acaba fornecendo elementos para desenvolver contra-medidas em ambientes em execução.

Corrigir este bloco de incompatibilidade até a versão final 2019 RTM seria o esperado. Diferente disso a Atualização de Agrupamento de Clusters poderá não funcionar com os hospedeiros das versões 2016 e até 2019.

Corrigindo um bloqueio de migração em produção causado por versões de hospedeiros mistos

Nessa situação inesperada é interessante saber como desenvolver uma solução, neste laboratório foi resolvido apenas encerrando as VMs e as movendo manualmente.Nas máquinas virtuais que estejam em execução é sugerido tero modo de compatibilidade entre CPU ativado.