Quando você instala um aplicativo de virtualização em uma máquina com Windows na qual o Hyper-V ou serviços relacionados estão instalados, erros podem ocorrer com frequência. Erros que acontecem ao executar VMs em aplicativos de virtualização não-Hyper-V causam problemas significativos. Esta postagem no blog explica o que causa esses erros, como corrigi-los e como executar outros aplicativos de virtualização em um computador com Hyper-V.
Fundo e Princípio de Funcionamento
Depois de instalar o VMware Workstation, VMware Player ou Oracle VirtualBox em uma máquina com Windows, você pode encontrar erros ao iniciar uma VM nesses aplicativos de virtualização. Os erros ocorrem mesmo se as VMs do Hyper-V não estiverem em execução naquele momento. Você pode instalar o VMware Workstation e o VirtualBox, e executar VMs do VMware e do VirtualBox no mesmo computador, mas não simultaneamente. O que causa esse problema com o Hyper-V? Vamos dar uma olhada mais de perto.
O VMware Workstation, VMware Player e o VirtualBox são hipervisores do tipo 2, enquanto o Hyper-V é um hipervisor do tipo 1. Um hipervisor do tipo 2 é instalado no sistema operacional que está sendo executado no hardware. Um hipervisor do tipo 1 é instalado em cima do hardware. Todos os hipervisores requerem extensões de virtualização de processador, que são conjuntos de instruções para virtualização de hardware – Intel VT-x ou AMD-V. O Hyper-V assume o controle das extensões de virtualização quando o Windows é inicializado. Essas extensões de virtualização não estão disponíveis para o VMware Workstation e o VirtualBox quando o Windows é carregado. Apenas um componente de software pode usar Intel VT-x ou AMD-V por vez.
Esta incompatibilidade é causada pelo Hyper-V porque as extensões de virtualização não são expostas aos hipervisores tipo 2 instalados em uma máquina Windows onde a função Hyper-V está ativada.
Erros do VMware Workstation:
O VMware Workstation e o Hyper-V não são compatíveis. Remova a função Hyper-V do sistema antes de executar o VMware Workstation.
O VMware Workstation e o Device/Credential Guard não são compatíveis. O VMware Workstation pode ser executado após desabilitar o Device/Credential Guard.
Erros do VirtualBox:
Tela Azul da Morte, como Tela Azul da Morte com EXCEÇÃO_DE_SERVIÇO_DO_SISTEMA
VT-x não está disponível (VER_VMX_NO_VMX). E_FAIL (0x80004005).
A VirtualBox VM works too slowly and uses the paravirtualisation (emulation) mode.
A situação mais interessante é quando um usuário não instala o Hyper-V e ainda encontra um dos erros mencionados anteriormente ao usar o VMware Workstation ou o VirtualBox. O erro ocorre quando as atualizações automáticas do Windows estão habilitadas. Com as atualizações (Windows 10 v1607 e as versões apropriadas do Windows Server a partir do Windows Server 2016), algumas novas funcionalidades relacionadas ao Hyper-V são instaladas e habilitadas automaticamente sem o consentimento do usuário do Windows. Essas funcionalidades são o Device Guard e o Credential Guard. As atualizações do Windows corrigem vulnerabilidades conhecidas, mas podem adicionar problemas e destruir uma configuração de trabalho. É por isso que muitos usuários não gostam de atualizações automáticas.
O Device Guard é um conjunto de recursos de segurança no Windows. A ideia de implementar este recurso é fortalecer a execução de código malicioso. O Device Guard está disponível no Windows 10, Windows Server 2019 e Windows Server 2019. Os principais requisitos são: UEFI rodando em modo nativo e Secure Boot ativado.
O Credential Guard é um recurso para minimizar o impacto de ataques se código malicioso já estiver em execução, isolando segredos do sistema e do usuário para tornar mais difícil comprometer.
Modo Seguro Virtual (VSM) é um recurso para aproveitar as extensões de virtualização do processador que protegem dados em uma região isolada da memória. HVCI é Integridade de Código Protegido pelo Hipervisor. LSA é Autoridade de Segurança Local.
Segurança Baseada em Virtualização (VBS) é uma classe de tecnologias que utiliza extensões de virtualização, incluindo VSM, para fornecer segurança no Windows. O papel do Hyper-V é necessário para fazer esses recursos funcionarem (as ferramentas de gerenciamento do Hyper-V não são necessárias).
O hipervisor (Hyper-V) carrega primeiro e depois o sistema operacional (Windows) carrega. O Hyper-V fornece uma camada de abstração entre o hardware e o sistema operacional. Um VSM permite a marcação de processos críticos específicos e memória usada por eles, pois pertencem a um sistema operacional independente separado controlado pelo Hyper-V. O princípio é semelhante ao isolamento de duas VMs em execução em um host Hyper-V, onde cada VM pode usar apenas os recursos de hardware provisionados para ela.
Observação: Se você precisar de um hipervisor do tipo 1 da VMware, use VMware ESXi e o ambiente VMware vSphere. Saiba mais nestes posts de blog: Hyper-V vs VMware, VMware Workstation vs VMware Player e Como instalar o ESXi no Hyper-V.
Vamos explorar como resolver o problema de incompatibilidade do Hyper-V e outras aplicações de virtualização em detalhes.
Método 1: Desinstalar o Hyper-V no GUI
Verifique informações do sistema sobre a configuração do Windows executando o seguinte comando no CMD:
msinfo32.exe
A System Information window opens. On the following screenshot, you see that Hyper-V is enabled (a hypervisor has been detected), and Device Guard Virtualization-based security is running. Now you can remove these features.
Você deve estar ciente de que os seguintes recursos relacionados ao Hyper-V não estarão disponíveis após a remoção do Hyper-V:
- Hyper-V
- Credential Guard e Device Guard
- Plataforma de Máquina Virtual
- Caixa de Areia do Windows
- WSL2.
Remova o recurso Hyper-V na interface gráfica do usuário (GUI) usando o Painel de Controle, a Adicionar Roles e o Assistente de Recursos.
No Windows 10, abra Painel de Controle, clique em Programas e Recursos, em seguida, clique em Ativar ou desativar recursos do Windows.
A janela de Recursos do Windows é aberta.
Desmarque a caixa de seleção Hyper-V e clique em OK.
Para concluir a remoção do Hyper-V, reinicie o computador.
Os passos para remover o Hyper-V no Windows 10 e no Windows Server 2016 são semelhantes.
No Windows Server 2016, abra o Gerenciador de Servidores e clique em Gerenciar > Remover Funções e Recursos. No Assistente de Remoção de Funções e Recursos, vá para a etapa Funções de Servidor e desmarque Hyper-V. Clique em Próximo em cada etapa para continuar. É necessário reiniciar para concluir a remoção do papel do Hyper-V.
Método 2: Use o PowerShell para Desabilitar o Recurso Hyper-V
Você pode fazer uma ação semelhante usando a interface de linha de comando em vez da GUI.
Entre no PowerShell como Administrador e execute o comando para desabilitar o recurso Hyper-V:
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor
Reinicie seu host:
shutdown -r -t 0
Método 3: Desabilitar o Hyper-V Usando o BCDedit
A ideia por trás deste método é editar os dados de configuração de inicialização e desabilitar a inicialização do Hyper-V sem desinstalar o papel do Hyper-V.
Entre no PowerShell como Administrador ou execute o comando a partir de um prompt de comando elevado para desabilitar o Hyper-V:
bcdedit /set hypervisorlaunchtype off
Se você precisar reabilitar o Hyper-V e definir o valor padrão de volta, execute este comando:
bcdedit /set hypervisorlaunchtype auto
Para obter mais controle e conveniência, desative o modo de inicialização rápida no Windows 10. Abra o Editor de Registro do Windows e vá para:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
Defina o parâmetro HiberbootEnabled como 0
Se você precisar usar VMs Hyper-V às vezes, crie duas entradas para um carregador de inicialização do Windows: uma para inicializar o Windows com Hyper-V e outra para inicializar o Windows sem Hyper-V. Em seguida, selecione a opção necessária antes de inicializar o Windows. Essa abordagem evita que você execute comandos no PowerShell manualmente sempre que precisar ativar ou desativar o Hyper-V.
bcdedit /copy “{current}” /d “No Hyper-V”
“A entrada foi copiada com sucesso para {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.”
Copie e cole seu valor em vez de xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
bcdedit /set “{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}” hypervisorlaunchtype off
Reinicie o computador.
Depois que o computador for reiniciado, você deve ver duas opções no Gerenciador de Inicialização do Windows.
Se você quiser remover a entrada de inicialização No Hyper-V, use a opção /delete para bcdedit.
Obtenha uma lista das entradas de inicialização atuais:
bcdedit /v
A list of all entries with their identifiers is displayed in the output. Copy the ID of the entry which you want to remove, and run the following command:
bcdedit /delete “{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}”
Método 4: Desinstalar o Papel do Hyper-V no PowerShell com dism.exe
A ideia por trás deste método é usar a ferramenta de manutenção e gerenciamento de imagens de implantação no interface de linha de comando para desinstalar o Hyper-V.
Faça login no CMD ou PowerShell como Administrador. Execute o seguinte comando para desinstalar o Hyper-V:
dism.exe /Online /Disable-Feature:Microsoft-Hyper-V
Se você quiser instalar o Hyper-V novamente, use este comando:
dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
Método 5: Desativar a Segurança Baseada em Virtualização no Windows
Este método é usado para desabilitar o Device Guard e o Credential Guard, que são recursos relacionados ao Hyper-V.
Abra o Editor de Política de Grupo para uma máquina local. O Editor de Política de Grupo está disponível no Windows 10 Pro, Enterprise e Education. No prompt de comando, execute gpedit.msc
Vá para Política de Computador Local > Configuração do Computador > Modelos Administrativos > Sistema > Device Guard
Clique duas vezes em Ativar Segurança Baseada em Virtualização. Por padrão, o status desta configuração é Não configurado.
Na janela que se abre, selecione Desativado e aperte OK para salvar as configurações e feche a janela.
Editar o Registro como alternativa
No Windows 10 Home, onde o Editor de Políticas de Grupo não está presente, você pode desabilitar a Segurança Baseada em Virtualização no Registro do Windows.
Crie um backup do registro do Windows antes de alterar as configurações do registro para evitar erros e problemas.
Abra o Editor do Registro. Execute regedit na linha de comando que deve ser aberta como Administrador.
Vá para HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > DeviceGuard
Crie a entrada EnableVirtualizationBasedSecurity se essa entrada estiver ausente. Para criar uma nova entrada, clique com o botão direito em um espaço vazio na DeviceGuard diretório e, no menu de contexto, clique em New > DWORD (32-bit) Value. Insira o nome EnableVirtualizationBasedSecurity para essa entrada no registro. Por padrão, os dados definidos para essa entrada devem ser 0 (veja a captura de tela a seguir). Você pode clicar duas vezes na EnableVirtualizationBasedSecurity e definir 0 manualmente.
Vá para HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Lsa
Crie uma nova entrada de registro no Lsa diretório. Clique com o botão direito em um espaço vazio na parte direita da janela do Editor do Registro. No menu de contexto, clique em New > DWORD (32-bit) Value.
Insira o nome LsaCfgFlags para esse valor. Esse valor deve ser definido como 0.
Feche o Editor do Registro e reinicie seu computador.
Você pode executar os seguintes comandos no PowerShell (como Administrador) para desativar o Device Guard e o Credential Guard na próxima inicialização do Windows.
Monte uma partição UEFI no disco X: (selecione um volume desocupado):
mountvol X: /s
Copie o C:\Windows\System32\SecConfig.efi para X:\EFI\Microsoft\Boot\SecConfig.efi com a opção de substituir o arquivo se o arquivo já existir. Este arquivo é uma imagem de inicialização para a ferramenta de configuração de segurança do Windows.
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
Crie uma nova opção no menu de inicialização com o ID {0cb3b571-2f2e-4343-a879-d86a476d7215} e o DebugTool nome:
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d “DebugTool” /application osloader
Defina a opção de inicialização que você criou no passo anterior para \EFI\Microsoft\Boot\SecConfig.efi:
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path “\EFI\Microsoft\Boot\SecConfig.efi”
Defina o Gerenciador de inicialização do Windows para tornar a nova entrada a padrão para a próxima reinicialização. Depois disso, reinicie seu Windows, que deve voltar para a inicialização normal.
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
Defina o carregador de inicialização para passar as opções DISABLE-LSA-ISO, DISABLE-VBS para o SecConfig.efi arquivo quando o carregador de inicialização iniciar o arquivo.
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO, DISABLE-VBS
Defina a partição para o disco de inicialização na unidade X:
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
Desmonte a unidade X: do sistema:
mountvol X: /d
Método 6: Atualizar o VMware Workstation
Se você tem o Windows 10 versão 2004 (20H1) build 19041 ou mais recente em seu computador físico, você pode atualizar o VMware Workstation para o VMware Workstation 15.5.6 ou mais recente e executar VMs do VMware em sua máquina Windows sem desativar/desinstalar o Hyper-V e a Segurança Baseada em Virtualização (VBS), incluindo Device Guard e Credential Guard.
Devido a muitas reclamações de clientes, a Microsoft e a VMware decidiram desenvolver um projeto conjunto que adota as APIs da Plataforma de Hypervisor do Microsoft Windows (WHP) para permitir que hipervisores de tipo 2, como o VMware Workstation, sejam executados em um host onde o Hyper-V está habilitado. Essas APIs permitem que aplicativos gerenciem recursos de CPU, leiam/escrevam valores do registro, terminem a operação da CPU e gerem interrupções.
O VMware Workstation antes da versão 15.5.5 usa um Monitor de Máquina Virtual (VMM) que tem acesso direto a uma CPU e conjuntos de instruções de virtualização (Intel VT-x ou AMD-V). Um VMM opera em um modo privilegiado. Se os recursos de Segurança Baseada em Virtualização estiverem habilitados em um host do Windows, então uma camada adicional de hypervisor (Hyper-V) é adicionada entre o hardware e o Windows. O Hyper-V tem acesso direto a recursos da CPU usados para virtualização de hardware, e o VMM não tem acesso a recursos de virtualização da CPU.
A VMware fez alterações na arquitetura do VMware Workstation 15.5.6 para permitir que seu produto utilize as APIs do Microsoft WHP e corrija o problema de compatibilidade. O VMM agora pode ser executado no nível do usuário (não no modo privilegiado) usando as APIs do WHP e executar VMs sem acesso direto aos recursos de virtualização de CPU. Esse modo é chamado de Monitor de Nível de Usuário (ULM) ou modo VBS de host. Se você desinstalar recursos relacionados ao Hyper-V de seu host Windows, o VMware Workstation detecta automaticamente e o VMM é alternado para acesso direto aos recursos de virtualização de CPU (executando no modo privilegiado).
O Windows Hypervisor Platform (WHP) deve ser instalado em uma máquina física Windows onde o Hyper-V está habilitado para permitir que o VMware Workstation execute VMs VMware nessa máquina. Instale o recurso Windows Hypervisor Platform no Painel de Controle clicando em Ativar ou desativar recursos do Windows.
Assim, você pode atualizar o Windows 10 e o VMware Workstation na sua máquina física para versões que suportam a execução de recursos relacionados ao Hyper-V e VMs do VMware Workstation na mesma máquina.
Limitações do modo VBS de host:
- O Windows Hypervisor Platform não é suportado no Windows Server 2016 e em outras versões e edições do Windows Server. Como resultado, o VMware Workstation não pode executar VMs no modo VBS de host em máquinas físicas rodando o Windows Server.
- A virtualização aninhada não é suportada. Você não pode executar VMs aninhadas (VMs dentro de VMs do VMware Workstation).
- As VMs do VMware podem ser executadas mais lentamente.
- Contadores de monitoramento de desempenho x86 (PMC) não são suportados.
- A capacidade de chaves de proteção de modo usuário (PKU) não está disponível.
- As capacidades de memória transacional restrita (RTM) e elisão de bloqueio de hardware (HLE) não estão disponíveis.
O VirtualBox e o Hyper-V
O VirtualBox pode coexistir com o Hyper-V, Device Guard e Credential Guard a partir do VirtualBox 6.0. O VirtualBox 6 pode funcionar com APIs do Hyper-V de forma semelhante ao VMware Workstation no Windows 10 v1803 x64.
Esses recursos devem ser ativados em uma máquina host com Windows para permitir que o VirtualBox funcione com APIs do Hyper-V:
- Hyper-V
- Plataforma de Hipervisor do Windows
Se o recurso Hyper-V estiver ativado, mas o recurso Plataforma de Hipervisor do Windows estiver desativado, em Sistema > Aceleração no resumo de configuração da VM, você pode ver que o modo Paravirtualização está ativado. Se você tentar iniciar uma VM, o VirtualBox lembra que você deve ativar a Plataforma de Hipervisor do Windows e exibe a mensagem de erro.
A mensagem de erro:
O WHvCapabilityCodeHypervisorPresent é FALSO! Certifique-se de ter ativado o recurso ‘Plataforma de Hipervisor do Windows’.
(VERR_NEM_NOT_AVAILABLE).
O VT-x não está disponível (VERR_VMX_NO_VMX).
Se os recursos relacionados ao Hyper-V necessários no Windows estiverem ativados, as seguintes informações são exibidas para a VM na seção Sistema:
Aceleração: VT-x/AMD-v, Paginação Aninhada, Hyper-V de Paravirtualização
A VM deve iniciar com sucesso. Um ícone de tartaruga verde é exibido no painel inferior da janela do VirtualBox. Este ícone indica que uma VM está sendo executada no modo de paravirtualização Hyper-V em vez do modo nativo que é normalmente usado pelo VirtualBox ao interagir diretamente com as extensões de virtualização da CPU. O desempenho das VMs do VirtualBox degrada em máquinas nas quais o Hyper-V e recursos relacionados estão habilitados. Você pode desativar ou remover o Hyper-V conforme explicado anteriormente para executar VMs no VirtualBox no modo nativo usando extensões de virtualização da CPU diretamente.
Leia também a comparação entre VirtualBox e Hyper-V e a comparação entre VirtualBox e VMware.
Conclusão
Novos recursos do Windows, como Segurança Baseada em Virtualização (Device Guard e Credential Guard), Windows Sandbox, WSL que usam o motor Hyper-V, causam muitos problemas aos usuários, administradores e desenvolvedores de software que usam outros hypervisores, como VMware Workstation, VirtualBox, QEMU e Google Android Emulator em máquinas Windows. Existem duas abordagens para resolver esses problemas de incompatibilidade: Desativar/desinstalar o Hyper-V ou usar novas versões de aplicativos de virtualização que suportam o trabalho com APIs do Hyper-V, como a API Windows Hypervisor Platform fornecida pela Microsoft.
Executar VMs no VirtualBox, VMware Workstation e outros hypervisors em máquinas com Hyper-V usando APIs pode degradar o desempenho das VMs não-Hyper-V. O backup de dados é crucial para os casos em que as aplicações de virtualização falham. Se ainda não escolheu a melhor solução de backup do Hyper-V para o seu ambiente, considere o NAKIVO Backup & Replication. A solução oferece backup robusto, proteção contra ransomware, recuperação de desastres e mais. Baixe a Edição Gratuita para ver a solução em ação.