O gerenciamento ESXi falha, recusando conexões, após copiar na unidade de inicialização de um backup

Question

Estou escrevendo isso depois de ter encontrado a solução sozinho, porque foi uma “pegadinha” tão estranha que merece ser documentada.

Embora eu tenha encontrado esse problema ao fazer uma restauração, é possível que isso aconteça em outros casos de inicialização em outro sistema operacional enquanto a unidade de inicialização de uma instalação ESXi estiver conectada ao sistema, principalmente se o tamanho do disco tiver mudado.

Recentemente, restaurei uma unidade de inicialização de instalação do VMware ESXi, também contendo um armazenamento de dados que contém a maioria das VMs e seus discos virtuais de inicialização/sistema, apenas para descobrir que esse estado supostamente bom foi de alguma forma interrompido.

Com base na exibição no console local do servidor, o ESXi parecia estar inicializando normalmente, mas exibia muitos sintomas problemáticos:

• Não foi possível fazer login com o vSphere Client, que exibia a mensagem “O vSphere Client não pôde se conectar aohospedar. Ocorreu um erro de conexão desconhecido. (A solicitação falhou devido a uma falha de conexão. (Não é possível conectar-se ao servidor remoto))”.

• O log do vSphere Client incluiu um erro:

  System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it

• Ao tentar fazer login no servidor com um navegador da web, o navegador relatou que a conexão foi recusada.

• Não foi possível fazer SSH no servidor mesmo depois de ativar isso no console local.

• Reiniciar a rede de gerenciamento e os agentes de gerenciamento por meio do console local não resolveu o problema.

• No console local, descobriu-se que hostdnão estava em execução e a reinicialização não resolveu o problema.

• esxclicomandos sempre davam:Connect to localhost failed: Connection failure

• Havia menos diretórios abaixo /vmfs/volumesdo esperado e nenhum deles parecia ser algum dos meus armazenamentos de dados.

• Mesmo “Redefinir configuração do sistema” na interface local não resolveu o problema. (Eu só tentei isso porque tinha uma imagem em bom estado que poderia restaurar novamente, o que fiz depois de resolver o problema, embora não tenha certeza se isso mudou alguma coisa.)

A cópia de backup da qual eu estava restaurando era uma imagem de baixo nível do disco lógico RAID obtida com o servidor inativo. Depois de excluir uma matriz RAID potencialmente corrompida e recriá-la, usei uma unidade separada conectada a um HBA para inicializar uma instalação física do Windows Server e copiar a imagem para o novo RAID. Usei a ferramenta HDD Raw Copy dehddguru. com, que é basicamente uma alternativa menos enigmática e complicada ao ddcomando Linux.

(Esta é uma maneira reconhecidamente bárbara - embora bastante completa - de fazer backup do VMware, mas esse disco armazena principalmente apenas discos de inicialização/sistema de VM, não dados, portanto, não é feito backup com muita frequência, de qualquer maneira, exceto ao fazer grandes alterações. Temos sistemas de backup muito melhores para dados primários.)

Tornei o novo disco lógico RAID maior do que aquele do qual foi feito backup, pois atualizamos para unidades maiores no RAID e o armazenamento de dados estava um pouco cheio. Eu estava planejando aumentar o armazenamento de dados, depois de confirmar que o backup funcionou.

Assim que terminei a cópia bruta, inicializei no ESXi e descobri que ela estava funcionando. O que aconteceu?!

Este é um ESXi 5.0 U3 bem antigo. (Ele tem atendido perfeitamente às nossas necessidades atuais e não temos nenhuma equipe de TI em tempo integral para gerenciar atualizações apenas por atualizações, corrigir os problemas que elas costumam causar, etc.)

Answer 1

No meu caso, o dano pode ter vindo do Windows, mas outro software pode causar o mesmo problema.

Isso definitivamente se aplica ao ESXi 5.0 U3 e provavelmente a qualquer ESXi 5.x, e acho que possivelmente a qualquer ESXi 6.x. É menos provável que se aplique ao ESXi 7, que usa um layout de partição diferente e mais simples.

Antecedentes da Investigação

Eu estava muito perto de fazer uma nova instalação quando finalmente comecei a descobrir.

Olhando por aí /vmfs/volumes, uma coisa estranha que notei foi que havia $RECYCLE.BINdiretórios em todos eles, e estes continham DESKTOP.INIarquivos, com conteúdos consistentes com as extensões de shell do Windows Explorer. É um pouco estranho encontrar isso nas partições do sistema de um hipervisor que não é e nunca foi baseado em Windows.

Imediatamente suspeitei que o sistema operacional Windows que usei para copiar na imagem do disco tivesse feito algo com isso. O ESXi usa várias partições FAT em seu disco de inicialização, então talvez o Windows possa brincar com elas. Considerando que a imagem do disco foi tirada de um estado bom conhecido, mas falhou sem fazer nadadentro deESXi, este parecia ser o curso de investigação mais promissor.

Fiquei inicialmente consternado quando descobri, através de um editor hexadecimal, que esses $RECYCLE.BINdiretórios também apareciam na imagem do disco. A princípio, entendi que isso significava que o dano já havia sido feito antes da imagem ser capturada – também no Windows Server. No entanto, estes revelaram-se benignos, embora me tenham conduzido na direção certa. O Windows provavelmente os adicionou assim que viu o disco lógico original, que ainda não havia sido aumentado – e apesar do disco ter sido mantido “offline” o tempo todo.

Procurando mais no editor hexadecimal (HxD - Editor hexadecimal e editor de disco, ferramenta realmente boa) revelou uma pequena diferença estranha entre a tabela de partição GPT na imagem do disco e aquela existente no novo disco RAID. Esta não é uma diferença que um editor de partições teria mostrado, porquena verdade não faz diferença logicamente, até onde sei. Isso é algo que você teria que vasculhar em um despejo hexadecimal bruto para encontrar.

Causa raiz

Em ambos os casos, havia sete entradas não vazias na matriz de partições. No entanto, da maneira como o ESXi escreveu originalmente a matriz, havia um intervalo de uma entrada vazia (todos os 128 bytes zerados) após as três primeiras entradas, de modo que as últimas quatro entradas válidas caíssem em seu próprio setor de 512 bytes. No disco ativo, onde o ESXi foi instalado, as últimas quatro entradas válidas foram deslocadas uma entrada para cima para preencher a lacuna. As entradas eram idênticas.

Não sei quem fez isso, Windows ou HDD Raw Copy Tool, mas suspeito um pouco do Windows. Eu testei novamente e essa mudança estará presenteimediatamenteapós a cópia ser feita, mesmo que a unidade lógica RAID esteja “Offline” no snap-in Gerenciamento de disco do MMC durante e após a cópia. É uma mudança obviamente intencional, porque os CRCs estão todos corretos e o GPT de backup também foi alterado.

Minha teoria é que quem está fazendo isso está reescrevendo o GPT porque ele não corresponde ao tamanho do disco e que, em vez de apenas copiar exatamente o array existente, está memorizando as partições como uma lista em alguma estrutura interna e depois re- escrever o array diretamente, o que obviamente não produz uma lacuna.

Como observação lateral, as entradas na matriz escritas pelo ESXi não estavam na mesma ordem em que as partições ocorrem fisicamente no disco, mas qualquer que seja o programa que preencheu a lacuna, pelo menos não tomou a liberdade de classificar as entradas também, agradecidamente!

Correção manual

Não conheço nenhuma maneira fácil de recriar essa lacuna, porque geralmente qualquer editor de partição fará a mesma coisa: converter a tabela existente em uma representação interna usada pela ferramenta, fazer as alterações solicitadas nessa representação e em seguida, escreva a tabela novamente no formato GPT para que ela tenha os dados corretos. Até onde sei, o posicionamento exato no disco das entradas da matriz não é considerado relevante e, portanto, não fará parte dos ditos “dados corretos” que ele grava.

No entanto, tive um palpite de que o ESXi poderia ser meticuloso quanto ao layout exato do array, então decidi corrigi-lo manualmente para ver o que aconteceria. O procedimento foi:

1. Certifique-se de que o disco esteja “Offline” no snap-in Gerenciamento de disco do MMC (como precaução).
2. Abra o disco em um editor hexadecimal. Em HxD está abaixoExtras→Abra o disco...e você deve selecioná-lo em “Discos físicos”. Certifique-se de desmarcar “Abrir como somente leitura”, que está ativado por padrão. Você receberá um aviso adequado sobre isso ser perigoso.
3. No array primário do GPT, que geralmente começa em LBA 2 (confirme na quadword do cabeçalho às 48h), deslize para baixo as entradas que deveriam estar após o intervalo, copiando os intervalos, colando mais abaixo e zerando o intervalo. Melhor ainda, basta copiar a tabela real da imagem de backup, se houver; mas observe que se o tamanho do LUN mudou, você não pode simplesmente copiar no cabeçalho GPT ou a situação poderá se repetir, pois esse cabeçalho terá os valores errados para os campos 20h e 30h.
4. Selecione osinteirointervalo da matriz do GPT. Tecnicamente, você deve determinar o intervalo usando o produto das palavras duplas em 50h e 54h no cabeçalho GPT, mas esse número normalmente será de 16.384 bytes.
5. Pegue o CRC32 do intervalo selecionado na etapa 4. Não consegui encontrar os parâmetros matemáticos do algoritmo CRC32 na especificação UEFI, mas consegui descobrir que é um muito comum, aquele na ISO 802‑3, com o polinômio normal 04C11DB7h. Você pode calculá-lo com uma calculadora on-lineaqui, certificando-se de definir “Tipo de entrada” como hexadecimal. Coloque isso no cabeçalho GPT em little endian às 58h.
6. Coloque zero temporariamente nos quatro bytes do cabeçalho GPT às 10h.
7. Pegue o CRC32 do cabeçalho, cujo comprimento é especificado no próprio cabeçalho pela palavra dupla em 0Ch. Coloque isso no cabeçalho às 10h.
8. Repita as etapas 3 a 7 para o GPT de backup. O array e seu CRC serão os mesmos, então você pode simplesmente copiá-los, mas o cabeçalho será diferente e, portanto, terá um CRC diferente. O cabeçalho do backup normalmente está no último setor do disco, com a matriz imediatamente antes dele, mas tecnicamente você deve verificar quadword 20h no cabeçalho GPT primário e quadword 48h no cabeçalho de backup para confirmar.
9. Se vocês sãocompletamente certovocê fez tudo certo, clique em Salvar. Novamente, o HxD fornecerá um aviso adequado aqui.

Você pode consultar oArtigo da Wikipédiapara obter os detalhes técnicos básicos do formato GPT.

Capturas de tela

Esta é a aparência de parte do array GPT “quebrado”; observe que as entradas válidas terminam em 77Fh e que não há longas séries de zeros antes disso:

Veja como eu consertei; observe que as entradas válidas agora terminam às 7FFh:

Resultado

Eu realmente não esperava que isso funcionasse. Não estudei isso, mas esperaria que a especificação UEFI não atribua importância à ordem ou ao espaçamento das entradas da matriz. Na verdade, cada partição possui um GUID exclusivoprecisamentepara que vocênãotemos que confiar em tais heurísticas frágeis. Como tal, depender dos índices da matriz serem os mesmos de quando você escreveu a tabela seria uma má ideia.

^{(Então, novamente, não seria a primeira vez que vejo software e firmware de nível empresarial envolvidos em ideias ruins. Parece que em todas as outras ocasiões em que coloco meu chapéu de administrador de sistemas, sou confrontado com um ou outro extremamente estúpido peça de programação... mas não me deixe reclamar.)}

Então, salvei cuidadosamente a tabela ajustada, inicializei novamente no RAID, o ESXi foi iniciado, o vSphere Client foi conectado e tudo voltou ao normal.

Idealmente, normalmente é melhor usar algo como Veeam Backup, mas em algumas situações é maisAd hocas soluções podem estar em ordem; nesse caso, você pode encontrar esse bug.