INACCESSIBLE_BOOT_DEVICE em máquinas virtuais do Hyper-V 2012 R2

Question

Tenho um cluster do Hyper-V 2012 R2, 4 servidores Dell PowerEdge R620 conectados a um storage array Dell PowerVault MD3600F por meio de conexões FC; é tudo bastante simples, todos os servidores executam o WS2012R2, o cluster foi recém-construído há alguns meses, todos os drivers e firmwares estão atualizados, o Windows está atualizado com os últimos patches disponíveis (mesmo aqueles lançados há dois dias). Há também um servidor do SCVMM 2012 R2 gerenciando a coisa toda, mas isso não parece realmente importar para o problema em questão.

Existem várias VMs em execução neste cluster; alguns deles são VMs de geração 1 executando o Windows Server 2008 R2, enquanto a maioria deles são VMs de geração 2 executando o Windows Server 2012 R2; esses também incluem as últimas atualizações disponíveis; Na verdade, eles foram implantados a partir de um modelo que foi criado logo após o cluster e são atualizados periodicamente quando a Microsoft lança novos patches.

Tudo funciona muito bem, mas às vezes (ou seja, sem razão aparente ou causa) uma VM não inicializa, travando com o temido código de erro INACCESSIBLE_BOOT_DEVICE ; isso acontece apenas na inicialização (ou reinicialização): nenhuma VM já caiu durante a execução.

Sempre que isso acontece, não há como fazer a reinicialização da VM com falha novamente; isso aconteceu na primeira vez há duas semanas com uma VM que ainda não estava executando nenhuma carga de trabalho de produção (foi implantada recentemente); tínhamos muita pressa para fazê-lo funcionar, por isso simplesmente arranhamos e implantamos um novo; mas a causa raiz do problema não foi encontrada.

Depois aconteceu dois dias atrás, quando reiniciamos várias VMs depois de corrigi-las; três deles não voltaram, enquanto outros iniciaram sem nenhum problema.

As VMs com defeito não conseguem inicializar nem no modo de segurança; no entanto, ao inicializar no Ambiente de Recuperação do Windows (do próprio sistema, assim do disco local (virtual), não de um DVD do Windows; significando que o disco virtual pode realmente ser acessado), tudo parece estar ok: o gerenciador de inicialização lista corretamente o sistema a ser inicializado (a saída de bcdedit /enum all /v é realmente idêntica à de uma VM funcional), todos os volumes estão acessíveis e até chkdsk não mostra erro algum. A única anomalia é que, ao executar bootrec /scanos ou bootrec /rebuildbcd , a ferramenta diz que não consegue encontrar nenhuma instalação do Windows (embora o volume C: esteja lá e esteja perfeitamente legível).

Isso só aconteceu (pelo menos até agora) com as VMs WS2012R2 de geração 2, portanto, presumo que seja causado por algum problema na emulação EFI e / ou no bootloader EFI; no entanto, isso é apenas uma suposição da minha parte.

A razão pela qual mencionei as atualizações é porque estou ciente de que isso aconteceu antes e KB2919355 foi responsável por isso; Além disso, a Microsoft lançou recentemente outra mega-atualização, KB3000850 , e isso também foi aplicado aos hosts, às máquinas virtuais e o modelo WS2012R2.

(Coincidentemente, no dia seguinte ao lançamento desta atualização, a Microsoft sofreu uma queda mundial de toda a plataforma de nuvem do Azure, que tem algumas semelhanças impressionantes com o que está acontecendo com o nosso cluster; mas estou apenas dando palpites por aqui). / p>

Já abri um caso de suporte com a Microsoft, mas também estou postando aqui, talvez alguém possa ajudar; é claro, se a Microsoft fornecer uma solução, eu postarei assim que as VMs estiverem novamente on-line.

    

Answer 1

Nós encaminhamos o problema para o Microsoft Premier Support e obtivemos um especialista em depuração de kernel trabalhando nele; ele descobriu que algo desinstalava todos os drivers do Hyper-V das VMs convidadas, tornando-as incapazes de inicializar; ele conseguiu que um deles inicializasse manualmente injetando os drivers no sistema de arquivos e no Registro da VM, e conseguimos recuperar alguns dados críticos (era uma Autoridade de Certificação); no entanto, a VM agora estava em um estado completamente sem suporte e, portanto, decidimos reconstruí-la; nós também reconstruímos todas as outras VMs, que não tinham dados críticos sobre elas.

Quanto a o que causou a desinstalação do driver, o caso ainda está aberto e a causa ainda não foi encontrada; o problema estava latente no modelo que usamos, porque logo afetou todas as VMs que foram implantadas usando esse modelo; nós criamos outro modelo, e este não mostrou o mesmo problema, então estamos correndo bem agora ... mas ainda não sabemos o que causou o problema em primeiro lugar.

Atualização:

Depois de um tempo, nós FINALMENTE descobrimos o que aconteceu (eu esqueci de atualizar esta resposta antes).

Parece que alguém ou algo atualizou forçosamente os Serviços de Integração do Hyper-V no modelo básico, que já os tinha , baseando-se exatamente no mesmo O.S. liberação dos hosts; isso causou um problema latente no sistema convidado, onde esses drivers seriam marcados como duplicados e / ou substituídos e, portanto, precisariam ser removidos; mas esse evento só é acionado após um intervalo de tempo variável, quando o Windows executa algum processo de limpeza automatizado periódico. Isso eventualmente levou à desinstalação completa de todos os drivers do Hyper-V em cada VM instanciada a partir desse modelo, tornando-o completamente incapaz de inicializar.

Quanto a quem ou o que executou esta atualização (o que não pode ser feito inserindo o disco de instalação do Integration Services e executando sua configuração, porque o instalador detecta corretamente que os drivers já estão instalados e sai), <<> Não tenho nenhuma pista. Alguém que deveria ter conhecido melhor fez isso manualmente usando PowerShell ou DISM , ou o SCVMM foi o culpado.

    

Answer 2

Exporte a VM e conecte-a em um host Hyper-V separado

inicializa esta vm no novo host Hyper v, então inicializa e verifica se tudo está funcionando bem ou não?

obtivemos sucesso no nosso caso.

tente.