Training Kits do Windows Server 2012 R2

Olá Pessoal!

Já estão disponíveis os training kits oficiais para os três exames da certificação MCSA (Microsoft Certified Solutions Associate) devidamente traduzidos para para nosso idioma nativo.

Segue os links para compra direta com a editora responsável:

Exame 70-410: Instalação e Configuração do Windows Server 2012 R2
Exame 70-411: Administração do Windows Server 2012 R2
Exame 70-412: Configuração dos Serviços Avançados do Windows Server 2012 R2

No site da editora, também é possível realizar a compra do livro em formato digital (e-book).

Para mais informações sobre a certificação MCSA clique aqui.

Até!

Windows Server 2016 TP4 - Instalação Nano Server

Olá Pessoal!

Acredito que todos se recordem que uma das grandes novidades do Windows Server 2008 foi o modo de instalação Server Core, ou seja, sem a presença da interface gráfica. Com o lançamento do Windows Server 2012 surge um novo modo de instalação: Minimal Server, onde apenas algumas ferramentas de gerenciamento eram disponibilizadas. As novidades não pararam por aí, também foi possível alternar entre qualquer modo sem a necessidade de reinstalar o sistema operacional. Para quem não acompanhou de perto todas essas mudanças, recomendo a leitura desse artigo  a fim de compreender melhor todo o processo.

No Windows Server 2016 (atualmente em TP4) surge um novo modo de implantação do sistema: Nano Server - Uma instalação extremamente leve, que consome poucos recursos de hardware e ocupa menos de 1GB de espaço em disco. Diferente da versão Server Core, que no Windows Server 2012 suporta praticamente todos os recursos da versão Full, a instalação Nano Server suporta apenas alguns recursos essenciais (Hyper-V, Hyper-V Cluster, Containers, Storage). 

Segundo Jeffrey Snover, arquiteto líder do Windows Server, segue alguns benefícios do Nano Server:

• Instalação 93% menor se comparada a versão completa;
• Redução de 92% no número de atualizações;
• Redução de 80% no número de reinicializações obrigatórias.

Nesse artigo, irei discutir os procedimentos básicos para instalação do Windows Server 2016 TP4 no  modo Nano Server para ser executado dentro do Hyper-V. Vale lembrar que diferente do que ocorria no modo Server Core, o modo Nano Server não é alcançado apenas selecionando uma opção durante a instalação do sistema.

Construindo uma imagem do Nano Server:

Primeiramente, baixe o Windows Server 2016 TP4 e inicie uma sessão do Windows PowerShell com direitos administrativos e monte a mídia baixada:

1. Mount-DiskImage "D:\Libardi\Downloads\ISO´s\en_windows_server_2016_technical_preview_4_x64_dvd_7258292.iso"

Crie uma pasta para armazenar o disco virtual do Nano Server bem como os arquivos necessários para implantação:

MD D:\NanoServer
Copy E:\NanoServer\Convert-WindowsImage.ps1 D:\NanoServer
Copy E:\NanoServer\NanoServerImageGenerator.psm1 D:\NanoServer

Habilite a execução de scripts no PowerShell:

Set-ExecutionPolicy Unrestricted

Importe o modulo do Nano Server:

Import-Module D:\NanoServer\NanoServerImageGenerator.psm1

Crie o disco virtual do Nano Server:

New-NanoServerImage -MediaPath E:\ -BasePath D:\NanoServer\Base -TargetPath D:\NanoServer\NanoServer.VHDX -ComputerName NanoServer01 -GuestDrivers -AdministratorPassword (ConvertTo-SecureString -String "P@ssw0rd" -AsPlainText -Force) -Ipv4Address 192.168.100.202 -Ipv4SubnetMask 255.255.255.0 -Ipv4Gateway 192.168.100.1 -InterfaceNameOrIndex Ethernet -EnableRemoteManagementPort

Principais Opções:

• MediaPath: Mídia de instalação do Windows Server 2016 TP4;
• BasePath: Caminho para os arquivos de construção da imagem;
• TargetPath: Caminho de saída do arquivo VHDX;
• ComputerName: Nome do Computador;
• Guest-Drivers: Instala os drivers corretos para o VHDX poder ser executado no Hyper-V;
• AdministratorPassword: Senha do administrador;
• IPv4Address: Endereço IP;
• IPv4SubnetMask: Mascara de Rede;
• Ipv4Gateway: Gateway padrão;
• InterfaceNameOrIndex: Interface que receberá as configurações IP;
• EnableRemoteManagementPort: Habilita a administração remota.

 

Com essas opções o Windows Server 2016 TP4 Nano Server é instalado sem nenhuma função, em um próximo artigo irei discutir como instalar funções no Nano Server bem como administra-las remotamente.

Após o processo ser concluído, crie uma nova máquina virtual no Hyper-V e defina o VHDX criado anteriormente como disco rígido:

 

Tela de logon - Windows Server 2016 TP4 Nano Server

Monitoramento de Rede em Ambientes Virtualizados (Hyper-V)

Olá Pessoal!

Acredito que grande parte dos administradores de rede já se depararam com a seguinte situação: identificar o motivo pelo qual o servidor de determinada aplicação não responde como planejado. Todos nos sabemos que fatores como o uso do processador, memória RAM, velocidade das unidades de disco, qualidade da implantação física e lógica da rede influenciam diretamente no desempenho dos servidores, principalmente quando os mesmos são responsáveis por funções críticas (banco de dados, e-mail, entre outros). Em ambientes virtualizados, o processo de identificação se torna ainda mais complexo, afinal, o problema pode estar relacionado a falta de recursos no host físico, ao mal dimensionamento das máquinas virtuais ou ambos. Nesse artigo irei discutir como monitorar e detectar problemas relacionados a conectividade de rede.

Tipicamente, o sistema operacional de gerenciamento (host de virtualização) deve possuir diversas interfaces rede rede, algumas são dedicadas exclusivamente a atender uma ou mais máquinas virtuais, outras são compartilhadas entre as VMs e o host de virtualização, e ainda, algumas podem ser utilizadas unicamente para fins de gerenciamento. Confira atentamente a imagem abaixo:

Switch Virtual do Hyper-V - Modo Externo (fonte:
http://www.altaro.com/hyper-v/the-hyper-v-virtual-switch-explained-part-1/).

Note que existe uma interface de rede real (Physical NIC) conectada diretamente a uma rede física qualquer (Physical Network). Para que as máquinas virtuais possam se comunicar com outros hosts na rede física, as mesmas devem estar vinculadas a um switch virtual externo. Na figura acima, podemos notar que existem três maquinas virtuais conectadas a um único switch virtual. Observe que esse switch virtual está diretamente vinculado a um único adaptador de rede físico. É exatamente nesse ponto que devemos prestar bastante atenção! Será que a largura de banda oferecida pelo adaptador é suficiente para suportar o tráfego gerado pelas três máquinas virtuais? Quais das máquinas virtuais consomem mais recursos de rede? Todas essas respostas podem ser obtidas por meio de um utilitário muito conhecido: O Performance Monitor!

Performance Monitor

Essa ferramenta traz dois grandes desafios: saber o que monitorar (existem milhares de marcadores de desempenho) e analisar os resultados obtidos. Não entrarei em detalhes de como operar a ferramenta (o que é relativamente simples), concentrarei os esforços em contadores de desempenho específicos e analise dos resultados.

Comece monitorando as interfaces de rede físicas alocadas ao host de virtualização. Para isso, utilize os seguintes contadores de desempenho:

Network Interface(*)\Bytes Total/sec

Esse contador indica a quantidade total de bytes por segundo que "atravessam" determinada interface de rede. Use os seguintes parâmetros para concluir sua analise:

• Interface de 10Gb: Máximo de 1.250.000.000 (1 bilhão duzentos e cinquenta milhões de Bytes/sec);
• Interface de 1Gb: Máximo de 125.000.000 (cento e vinte e cinco milhões de Bytes/sec);
• Interface de 100 Mb: Máximo de 12.500.000 (doze milhões e quinhentos mil Bytes/sec).

Para calcular a porcentagem de uso da interface de rede, utilize o seguinte exemplo:

Você monitorou sua rede durante um dia comum de trabalho e obtive o número médio de 100.850,637 para o contador Bytes Total/sec. Divida esse valor por mil e encontrará o valor de 100,85 MB/sec. Por fim, divida esse valor por 1,25 (1% da largura de banda de uma interface de 1Gb) e encontrará o valor aproximado de 81% de uso.

Em relação a porcentagem de uso da rede, a Microsoft adverte para os seguinte valores:

•  Até 49% - Utilização considerada normal;
• Entre 50% e 79% - Utilização alta;
• Acima de 80% - Utilização extremamente alta. Possível degradação de desempenho.

Se você precisa de uma analise mais detalhada, pode usar os seguintes contadores para separar os dados recebidos dos dados enviados:

•  Network Interface(*)\Bytes Received/sec
• Network Interface(*)\Bytes Sent/sec

 

Network Interface(*)\Network Queue Length

 

Esse contador indica o número de pacotes aguardado na fila de saída de determinada interface de rede. Preferencialmente, esse contador deve ser sempre igual a 0. Valores entre 1 e 2 requerem atenção, valores superiores a 2 indicam uma sobrecarga da interface de rede.

Network Interface(*)\Current Bandwidth

Esse contador indica a largura de banda máxima suportada por cada interface (bits/sec). Ideal para detectar se realmente a interface está operando na velocidade adequada. Por exemplo, se você conectar uma interface de 1Gb em uma porta do switch limitada a 100Mb esse contador irá indicar a velocidade real, ou seja, 100Mb.

 

Se algum problema for detectado, como saber qual máquina virtual que esta consumindo um número maior de recursos de rede? Para isso, existem contadores específicos do Hyper-V:

 

Hyper-V Virtual Network Adapter(*)\Bytes/sec

 

Esse contador indica a quantidade total de bytes por segundo que "atravessam" determinada interface de rede virtual. Ideal para detectar a quantidade de bytes enviados e recebidos por cada VM.

 

Hyper-V Virtual Network Adapter(*)\Bytes Received/sec

 

Esse contador indica a quantidade de bytes recebidos por uma interface de rede virtual específica.

 

Hyper-V Virtual Network Adapter(*)\Bytes Sent/sec

 

Esse contador indica a quantidade de bytes enviados por uma interface de rede virtual específica.

 

Por fim, também é possível monitorar o tráfego de rede no switch virtual. Para isso, utilize os seguintes contadores:

 

Hyper-V Virtual Switch(*)\Bytes/sec

 

Esse contador indica a quantidade total de bytes por segundo que "atravessam" o switch virtual.

Hyper-V Virtual Switch(*)\Bytes Received/sec

Esse contador indica a quantidade de bytes recebidos pelo switch virtual.

Hyper-V Virtual Switch(*)\Bytes Sent/sec

Esse contador indica a quantidade de bytes enviados pelo switch virtual.

 

Importante: Os contadores relacionados ao switch virtual mostram o dobro de tráfego se comparado aos contadores de interfaces de rede física. Eles computam os dados de entrada/saída para cada porta. Por exemplo, se uma máquina virtual está enviando 1000 bytes/sec, isso quer dizer que o switch virtual visualiza 1000 bytes/sec na porta que a VM está conectada e 1000 bytes/sec na porta que o switch virtual está conectado à rede externa.

NAT Nativo no Hyper-V do Windows 10 (Versão 1511)

Olá Pessoal!

Se você esta habituado a trabalhar com máquinas virtuais em plataformas como o Oracle VitualBox ou VMWare Workstation possivelmente já configurou uma ou mais interfaces de rede de suas VMs em modo NAT (Network Address Translation). No modo NAT, a VM atua como um computador real que se conecta à Internet através de um roteador. O roteador, nesse caso, é representado pelo mecanismo de rede do software de virtualização. Por exemplo, o VirtualBox disponibiliza um "roteador virtual" entre cada VM e o host de virtualização, isso garante que cada VM possa acessar a Internet de forma transparente sem que exista comunicação entre as mesmas.

Em versões anteriores do Hyper-V existiam três tipos de switches virtuais:

• Privado (Private): Permite a comunicação entre as VMs em execução no host de virtualização. Até mesmo o sistema operacional de gerenciamento não está autorizado a se comunicar com tais VMs. Essa opção é 100% lógica e não cria nenhum adaptador virtual no sistema;
• Interno (Internal): Esse switch virtual é bem parecido com o privado, exceto pelo fato de que um adaptador de rede virtual é criado no sistema operacional de gerenciamento, permitindo a comunicação entre as VMs e o host de virtualização;
• Externo (External): Esse tipo de switch virtual é sempre conectado a um adaptador de rede físico. Ele permite que as máquinas virtuais possam se conectar a rede física por meio de tal adaptador.

Note que não existe um switch virtual específico a fim de compartilhar a conexão da Internet entre as VMs através de NAT. Logo, soluções alternativas como, por exemplo, o ICS (Internet Connection Sharing) eram adotadas.

A partir da versão 1511 do Windows 10 (atualização liberada no mês de novembro de 2015) é possível criar um switch virtual do tipo NAT. Todo o processo deve ser realizado por meio do Windows PowerShell.

Criando o switch NAT:

O processo para disponibilizar o novo switch do tipo NAT é dividido em duas partes: criar o switch virtual e então configurar o objeto NAT no sistema operacional host. Para criar o switch virtual execute o Windows PowerShell com credenciais administrativas e execute o seguinte comando:

New-VMSwitch -Name "NAT" -SwitchType NAT -NATSubnetAddress 10.0.2.0/24

 

O Parâmetro -Name define um nome qualquer para o novo switch virtual. O parâmetro -SwitchType define o tipo do novo switch e obrigatoriamente deve ser definido como "NAT". O parâmetro -NATSubnetAddress define a sub-rede que será usada pelos clientes quando conectados ao novo switch. Após a execução do comando, um novo adaptador de rede será criado no sistema operacional host.

 

Novo adaptador de rede virtual criado no sistema de gerenciamento.

 O endereço IP do novo adaptador de rede virtual será automaticamente definido como 10.0.2.1 (primeiro endereço disponível dentro da sub-rede 10.0.2.0/24). Observe que esse endereço será o gateway padrão para as VMs operando em modo NAT.

 

Propriedades do protocolo TCP/IPv4 do adaptador de rede NAT.

Agora, execute o seguinte comando do Windows PowerShell para instanciar o objeto NAT no sistema operacional host:

New-NetNat –Name NAT –InternalIPInterfaceAddressPrefix 10.0.2.0/24

 

O parâmetro -Name define o nome do novo objeto a ser instanciado no sistema operacional host. O parâmetro -InternalIPInterfaceAddressPrefix deve possuir o mesmo valor informado no comando anterior.

 

Testando as configurações:

 

Depois de configurar uma máquina virtual para utilizar o novo switch virtual, basta definir manualmente as configurações de rede. Em meu exemplo utilizei o endereço IP: 10.0.2.100/24 e o gateway padrão 10.0.2.1 (endereço IP da interface NAT). Não se esqueça de configurar um servidor DNS público qualquer.

 

Configuração do protocolo TCP/IPv4 da VM.

 

 

 

 

  

Mudanças no Licenciamento do Windows Server 2016

Olá Pessoal!

O Windows Server 2016 será lançado no segundo semestre de 2016 e a Microsoft já adiantou muitas informações quanto ao seu processo de licenciamento, é importante lembrar que tais informações poderão ser alteradas até o lançamento oficial do produto.

Muitos administradores de rede e gestores de TI não entendem que quando você compra uma licença do Windows Server, você está pagando pelo direito de instalar o software em um de seus servidores, ou seja, uma licença não é sinônimo de propriedade absoluta sobre o software. Historicamente, a família Windows Server segue o seguinte modelo de licenciamento:

Conforme proposto na figura acima, é necessário adquirir uma licença para o servidor, uma licença para a estação de trabalho (cliente) e uma CAL de acesso. Esse modelo permanece inalterado para o Windows Server 2016.

Uma Windows Server CAL (licença de acesso do cliente) licencia um usuário ou dispositivo a acessar qualquer edição do Windows Server da mesma versão da CAL comprada ou anterior, por exemplo: Sua rede é composta por 3 servidores executando o Windows Server 2008 R2, 4 servidores executando o Windows Server 2012 R2 e 2 servidores executando o Windows Server 2016. Se você possui 200 usuários será necessário comparar 200 licenças de acesso do cliente (CAL) do Windows Server 2016 a fim garantir que todos os usuários possam acessar recursos em todos os servidores. CAL de dispositivos são mais caras, porém algumas empresas possuem um número superior de usuários se comparado a dispositivos: Imagine uma empresa de telemarketing que possui 100 computadores e 300 usuários, a aquisição de CAL por dispositivo tornará o licenciamento menos custoso.

Vale lembrar que serviços como RDS (Remote Desktop Services) e AD RMS (Active Directory Rights Management Services) exigem CAL adicionais.

 Standard x Datacenter:

O que também se mantém inalterado, são as duas edições primárias do Windows Server (Standard e Datacenter) e as regras relativas a instalação do produto e máquinas virtuais. 

No Windows Server 2012 a Microsoft simplificou bastante o processo de licenciamento, tanto a versão Standard quanto a versão Datacenter disponibilizavam os mesmos recursos. A única diferença estava no número de máquinas virtuais que poderiam ser utilizadas sem a aquisição de licenças adicionais: 2 máquinas virtuais para a versão Standard e máquinas virtuais ilimitadas para a versão Datacenter (mesmo hardware). A partir do Windows Server 2016 as edições Standard e Datacenter voltarão a oferecer recursos distintos. As regras relacionadas ao número de máquinas virtuais sem aquisição de licenças adicionais permanecem inalteradas.

Licenciamento baseado no número de núcleos físicos do processador:

No Windows Server 2008 R2 apenas a edição Datacenter era licenciada a partir do número de processadores físicos existentes no servidor, as edições Standard e Enterprise eram adquiridas sem levar em conta o número de processadores físicos. A partir do Windows Server 2012 a Microsoft retirou a versão Enterprise de comercialização e passou a licenciar as edições Standard e Datacenter por número de processadores físicos (uma licença é necessária para cada dois processadores físicos instalados no servidor). A partir do Windows Server 2016 o licenciamento será baseado no número de núcleos físicos (core) existentes no processador. Vamos aos detalhes:

• Licenças de núcleos físicos serão vendidas em pacotes modulares de duas unidades;
• Minimamente serão exigidas 8 licenças de núcleos (4 x 2 licenças) por processador;
• Minimamente serão exigidas 16 licenças de núcleos (8 x 2 licenças) por servidor.

Você pode estar bem assustado agora, mas a Microsoft garante que o custo das licenças por núcleo físico adicional custará 1/8 do valor da licença adquirida hoje no Windows Server 2012 (1 licença para cada dois processadores físicos). Vale lembrar que núcleos virtuais não entram nessa conta.

Baixe o folheto oficial do licenciamento do Windows Server 2016 aqui. Para um guia de perguntas e respostas frequentes, clique aqui.

 

Servidores DHCP Redundantes no Windows Server 2012 R2

Olá Pessoal.

Atualmente grande parte das empresas contam com ao menos um servidor DHCP a fim de atribuir automaticamente endereços IP aos seus dispositivos. Por ser na maioria das vezes um serviço simples e de fácil implantação, grande parte dos administradores acabam esquecendo que seu funcionamento é crucial para operação da rede, visto que não existe comunicação sem um endereço IP. O modo de operação do DHCP favorece esse "abandono", uma vez que os endereços IP são na verdade "emprestados" aos clientes por um determinado período de tempo (lease), logo a indisponibilidade do servidor DHCP pode ser contornada sem grandes prejuízos ao ambiente.

Uma das maneiras mais simples de garantir a redundância e balanceamento de carga do DHCP é trabalhar com dois servidores ativos distribuindo endereços IP distintos dentro da mesma sub-rede. Essa configuração pode ser realizada de forma manual ou por meio do recurso split scope, presente a partir do Windows Server 2008 R2. É importante notar que nesse modo de operação não existe o conceito de cluster, ou seja, ao atingir o final do empréstimo obtido por meio do servidor momentaneamente indisponível, o cliente perderá conexão com a rede e o processo de atribuição dinâmica se inicializará novamente.

A partir do Windows Server 2012 a Microsoft adicionou ao serviço DHCP um recurso interno de failover, agora as concessões (lease) e todas as outras configurações são replicadas a um servidor parceiro, garantindo que o mesmo possa renovar os empréstimos de endereços IP inicialmente atribuídos por outro servidor, ou seja, não existe perda momentânea de conexão.

Pré-requisitos para implantação:

• Dois servidores executando o Windows Server 2012 ou superior;
• Serviço DHCP instalado em ambos os servidores;
• Ao menos um escopo devidamente configurado em qualquer um dos servidores.

Nota: A função de failover não é configurada diretamente para o servidor DHCP. As configurações de failover são definidas por escopo, ou seja, um único servidor DHCP pode hospedar réplicas primárias e secundárias de múltiplos escopos.

Cenário:

Nesse exemplo existem dois servidores DHCP: WS2012R2-01 e WS2012R2-02. O servidor WS2012R2-01 possui um único escopo configurado ([192.168.100.0] - Escopo 01). O servidor WS2012R2-02 apenas possui o serviço DHCP instalado (Figura 1).

Figura 1. Servidores DHCP.

Ao clicar com o botão direito em "Escopo 01" e selecionar a opção "Configurar Failover" o assistente abaixo é iniciado. Note que é possível ativar o failover para todos os escopos existentes no servidor ou apenas para escopos específicos (Figura 2).

Figura 2. Assistente de Configuração Failover DHCP (Seleção de Escopos).

  

Após clicar em "Avançar" digite o nome do servidor parceiro (Figura 3).

Figura 3. Nome do servidor parceiro.

Na próxima etapa do assistente de configuração a modalidade de failover é efetivamente definida (Figura 4).

Figura 4. Configuração do failover

Definição de cada uma das configurações realizadas na Figura 4:

Nome da Relação: Um nome qualquer que identifique a relação criada entre os servidores DHCP;

Prazo de Entrega Máximo do Cliente (MCLT): Talvez esse seja o parâmetro mais complexo de todo o processo de configuração. O MCLT define um tempo de empréstimo especial que será oferecido aos clientes em caso de falha em um dos servidores. Nos servidores DHCP Windows o valor definido no campo MCLT também é o primeiro tempo de empréstimo oferecido a novos clientes. Esse comportamento garante que não exista a possibilidade de distribuição de endereços IP duplicados em caso de falha do servidor primário antes de atualizar as informações sobre empréstimos ao servidor secundário. Exemplo: O cliente COMPUTADOR-01 obtive sua concessão a partir do servidor WS2012R2-01. O servidor WS2012R2-01 (primário) falha antes de enviar as informações sobre o empréstimo ao servidor WS2012R2-02 (secundário). Quando o cliente tentar renovar seu empréstimo por meio do servidor secundário, esse servidor desconhecerá qualquer informação sobre o cliente (fato que poderia causar a distribuição de endereços IP duplicados) porém detecta que o cliente utiliza um tempo de empréstimo igual ao MCLT e renova sua concessão mesmo não possuindo essa informação em seu banco de dados;

Modo: O modo de operação padrão do failover é de balanceamento de carga. Cada servidor é responsável por distribuir 50% do total de endereços IP disponíveis dentro do escopo. Também é possível optar pelo modo espera ativa (apenas um servidor distribui endereços IP, o servidor secundário é só utilizado em caso de falha no servidor primário). No modo espera ativa é necessário definir uma porcentagem de endereços IP que serão reservados ao o servidor secundário a fim de atender novos clientes em caso de falha no servidor primário (Figura 5);

Figura 5. Modo Espera ativa.

Intervalo de Alternância de Estado: Tempo que o servidor secundário tentará retomar a comunicação com o servidor primário antes de assumir o controle de todo escopo (100% dos endereços). Essa é outra configuração que costuma causar duvidas, na verdade o servidor secundário só assume o controle de todo escopo após o tempo definido no parâmetro "intervalo de alternância de estado" + MCLT. No exemplo apresentado na Figura 4 o servidor WS2012R2-02 iria assumir o controle total do escopo após duas horas;

Habilitar autenticação de Mensagem: Senha para garantir a relação de parceria somente entre os servidores autorizados.

Para informações sobre como configurar esse serviço no Linux clique Aqui!

Até a próxima!

Hyper-V e VirtualBox no Windows 8.1

Olá Pessoal!

Um dos destaques do Windows 7/8/8.1/10 é a possibilidade de instalação do Hyper-V (mesma versão disponível no Windows Server 2012/2012 R2, porém sem os recursos voltados para alta disponibilidade). Os seguintes itens são obrigatórios para que o Hyper-V possa ser instalado com sucesso no Windows 8:

• Windows 8/8.1 Pro ou Enterprise 64 bits;
• Processador com suporte a instruções de virtualização (Intel-VT ou AMD-V);
• 4 GB de memória RAM;
• Processador com suporte a DEP (Data Execution Protection);
• Processador com tecnologia SLAT (Second Level Address Translation).
• Intel: Extended Page Table (EPT);
• AMD: Nested Page Table (NPT).

Importante: No Windows 8/8.1 32 bits é possível instalar as ferramentas para gerenciamento remoto do Hyper-V! Não é possível executar maquinas virtuais.

Depois que o Hyper-V é habilitado, o kernel do sistema operacional passa a ser virtualizado, o que impede a execução de maquinas virtuais que necessitam de suporte a instruções de virtualização (Intel-VT ou AMD-V). Esse artigo aborda a instalação do Hyper-V no Windows 8.1 e demonstra como executar máquinas virtuais em qualquer outro software de virtualização sem ter que remover o Hyper-V.

1. Verificação dos pré-requisitos do processador:

Utilize o coreinfo.exe com a opção -v para exibir se seu processador possui suporte aos recursos exigidos pelo Hyper-V (suporte a instruções de virtualização e SLAT).

Figura 1. Resultado das tecnologias de virtualização disponíveis no processador.

Nota-se na Figura 1 que não existe nenhum Hypervisor habilitado na máquina (-) e que o processador possui suporte a instruções de virtualização e a tecnologia SLAT (*).

2. Habilitar o Hyper-V por meio do PowerShell:

Enable-WindowsOptionalFeature -FeatureName Microsoft-Hyper-V-All -Online

Reinicie o computador para concluir a instalação.

3. Modificar o boot do sistema para suportar outros softwares de virtualização:

A partir do comando bcdedit.exe verifica-se as entradas disponíveis para inicialização do Windows. Note que para a instalação do Windows que encontra-se na partição C: o hypervisorlaunchtype está definido como "auto", ou seja, o Hyper-V está ativo.

Figura 2. Saída do comando bcdedit.exe.

Agora criaremos uma copia desse "carregador de inicialização" com o Hyper-V desabilitado:

bcdedit /copy {current} /d "Sem Hyper-V"

Ao verificarmos as entradas disponíveis para inicialização novamente (bcdedit.exe) nota-se a existência de uma entrada duplicada, porém com a descrição alterada:

Figura 3. Entrada de inicialização duplicada.

Desativaremos o Hypervisor para essa nova entrada:

bcdedit /set {70bbee7f-09e7-11e4-b06b-bb638dcdca96} hypervisorlaunchtype off

Importante: O valor definido entre "{}" deve ser o mesmo presente no campo identificador da Figura 3.

Pronto! Agora é só reiniciar o sistema e escolher se deseja executar o Windows 8.1 com ou sem Hyper-V.

Outros comandos úteis:

Define a entrada padrão durante a inicialização do sistema:

bcdedit /default {70bbee7f-09e7-11e4-b06b-bb638dcdca96}
Modifica o titulo da entrada:

bcdedit /set {70bbee7f-09e7-11e4-b06b-bb638dcdca96} description "Novo Título"