Trazendo o Hyper-V para o “Windows 8”
Nesta postagem, falaremos sobre como será nosso suporte à virtualização no SO “cliente” do Windows. Originalmente lançada para o Windows Server, onde sua tecnologia se tornou bastante popular e bem-sucedida, nossa ideia era oferecer a virtualização em um conjunto de cenários para os profissionais que usam o Windows. Os dois cenários mais comuns, nos quais nos concentramos, destinam-se aos desenvolvedores de software que trabalham em várias plataformas, clientes e servidores, e aos profissionais de TI que desejam gerenciar clientes e servidores virtualizados com simplicidade. Mathew John, autor desta postagem, é gerente de programa da nossa equipe do Hyper-V. É importante observar que, assim como em todos os demais recursos, discutiremos a engenharia do trabalho, e não o produto final, já que essas opções são feitas bem mais adiante, no projeto. –Steven
PS: Não tínhamos planejado publicar tantas postagens consecutivas, por isso voltaremos a adotar um ritmo mais tranquilo. Pedimos desculpas se causamos muitas expectativas inadvertidamente. Neste exato momento, estamos trabalhando para o BUILD em tempo integral!
Muitos de vocês, desenvolvedores de software, administradores de TI ou simplesmente entusiastas, precisam executar múltiplos sistemas operacionais, geralmente usando várias máquinas diferentes. Nem todos nós temos acesso a um pacote completo de laboratórios para incluir todas essas máquinas, por isso a virtualização pode ser muito útil para poupar espaço e tempo.
Durante o desenvolvimento do Windows 8, trabalhamos para habilitar o Hyper-V, a tecnologia de virtualização de máquinas que fez parte das duas versões mais recentes do Windows Server, para funcionar também no SO cliente. Em resumo, o Hyper-V permite que você execute mais de um sistema operacional de 32 ou 64 bits x86 ao mesmo tempo, no mesmo computador. Em vez de trabalhar diretamente com o hardware do computador, os sistemas operacionais são executados em uma máquina virtual (VM).
Com o Hyper-V, os desenvolvedores podem manter facilmente vários ambientes de teste e obter um mecanismo simples para alternar entre esses ambientes sem custos adicionais de hardware. Por exemplos, lançamos máquinas virtuais pré-configuradas que contêm versões antigas do Internet Explorer para dar suporte aos desenvolvedores da Web. O administrador de TI obtém o benefício adicional da paridade da máquina virtual e uma experiência comum de gerenciamento com o Hyper-V no Windows Server e no cliente Windows. Também sabemos que muitos de vocês usam a virtualização para experimentar algo novo sem que haja riscos para o PC que está em uso no momento.
Uma introdução ao Hyper-V
O Hyper-V requer um sistema de 64 bits com SLAT (Second Level Address Translation). O SLAT é um recurso que está presente na geração atual de processadores de 64 bits da Intel e da AMD. Você também precisará de uma versão de 64 bits do Windows 8 e, pelo menos, 4 GB de memória RAM. O Hyper-V não dá suporte para a criação de sistemas operacionais de 32 e 64 bits nas VMs.
A memória dinâmica do Hyper-V permite que a memória requerida pela VM seja alocada e desalocada dinamicamente (você especifica um mínimo e um máximo) e compartilhe a memória não utilizada entre as VMs. É possível executar 3 ou 4 VMs em uma máquina com 4 GB de memória RAM, mas seria preciso mais memória RAM para 5 ou mais VMs. Por outro lado, também é possível criar grandes VMs com 32 processadores e 512 GB de memória RAM.
Pensando na experiência do usuário com VMs, o Windows oferece dois mecanismos para o uso de máquinas virtuais: o Console de VM e a Conexão de Área de Trabalho Remota.
O Console de VM (também conhecido como VMConnect) é um visualizador do console da VM. Ele fornece uma exibição unificada de monitoramento da VM com resolução de até 1600 x 1200 em cores de 32 bits. Esse console proporciona a visualização do processo de inicialização da VM.
Para obter uma experiência mais avançada, você pode se conectar a uma VM com o uso da Conexão de Área de Trabalho Remota (RDC). Com a RDC, a VM aproveita os recursos presentes no seu PC físico. Por exemplo, se você tiver vários monitores, a VM poderá mostrar seus gráficos em todos eles. Da mesma forma, se você tiver uma interface habilitada para multitoque no PC, a VM poderá usar essa interface para proporcionar uma experiência com toque. A VM também oferece recursos completos de multimídia, com o uso dos alto-falantes e microfone do sistema físico. O SO raiz (o SO Windows principal que está gerenciando as VMs) também pode compartilhar a área de transferência e as pastas com as VMs. E, por último, com a RDC, você também pode conectar qualquer dispositivo USB diretamente à VM.
Para o armazenamento,você pode adicionar vários discos rígidos aos controladores IDE ou SCSI disponíveis na VM. É possível usar discos rígidos virtuais (arquivos .VHD ou .VHDX) ou discos físicos, que são utilizados diretamente pela máquina virtual. Os VHDs também podem residir em um servidor de arquivos remotos, facilitando a manutenção e o compartilhamento de um conjunto comum de VHDs predefinidos por toda a equipe.
O recurso “Live Storage Move” do Hyper-V permite que as VMs sejam mais independentes do armazenamento adjacente. Com isso, você poderia migrar o armazenamento da VM de uma unidade local para outra, para um dispositivo USB ou para um compartilhamento de arquivo remoto, sem precisar interromper a VM. Eu descobri que este recurso é bastante útil para implantações rápidas: Quando preciso de uma VM rapidamente, inicio uma a partir de uma biblioteca de VMs mantida em um compartilhamento de arquivos e, em seguida, migro o armazenamento da VM para o meu disco local.
Outro recurso ótimo do Hyper-V é a capacidade de obter instantâneos de uma máquina virtual enquanto ela está em execução. O instantâneo salva todas as informações da máquina virtual, permitindo que você volte para um momento anterior na vida de uma VM, além de ser uma ótima ferramenta para a depuração de problemas complicados. Além disso, as máquinas virtuais do Hyper-V contam com todos os benefícios da gerenciabilidade do Windows. O Windows Update pode instalar patches em componentes do Hyper-V, para que você não precise configurar processos de manutenção adicionais. O Windows oferece todos os recursos inerentes com o Hyper-V instalado.
No entanto, apesar de tudo, o uso da virtualização tem suas limitações. Os recursos e aplicativos que dependem de hardware específico não funcionam bem em uma VM. Por exemplo, o Windows BitLocker e o Measured Boot, que dependem de um TPM (Trusted Platform Module), talvez não funcionem devidamente em uma VM; e os jogos ou aplicativos que exigem processamento com GPUS (sem fornecer fallback de software) também não deverão funcionar bem. Além disso, os aplicativos que dependem de temporizadores sub 10 ms (aplicativos de alta precisão sensíveis à latência, como aplicativos de mixagem de música ao vivo), poderão apresentar problemas ao serem executados em uma VM. O SO raiz também é executado acima da camada de virtualização do Hyper-V, mas de forma especial, com acesso direto a todo o hardware. É por isso que os aplicativos com requisitos especiais de hardware continuam trabalhando com perfeição no SO raiz, mas aqueles com alta precisão e sensíveis à latência podem apresentar problemas ao serem executados no SO raiz.
Lembramos que continua sendo necessário obter licenças para todos os sistemas operacionais usados nas VMs.
Em seguida, apresentamos um breve resumo de como o Hyper-V funciona no Windows 8.
Baixe este vídeo para assisti-lo no seu controlador de mídia favorito:
MP4 de alta qualidade | MP4 de qualidade inferior
Criando suporte para comunicações de VM com adaptadores de rede sem fio
Como você viu na demonstração, criar um comutador de rede externo é tão simples como selecionar um adaptador físico de rede (NIC) em uma lista suspensa e clicar em OK. Esse processo já funcionava bem no Hyper-V do Windows Server, mas para obtermos resultados semelhantes no Windows 8, precisávamos executá-lo com placas de rede sem fio, o que representava um novo desafio.
O problema
O comutador virtual no Hyper-V é um “comutador da camada 2”, o que significa que ele alterna (determina a rota para um determinado pacote de Ethernet) com o uso dos endereços MAC que identificam cada placa de rede (física e virtual) com exclusividade. Os endereços MAC das máquinas de origem e de destino são enviados em cada pacote de Ethernet, e um comutador da camada 2 usa essa informação para determinar para onde o pacote de entrada deve ser enviado. Um comutador virtual externo é conectado ao mundo externo por meio de um adaptador de rede físico. Os pacotes de Ethernet de uma VM que se destinam a uma máquina no mundo externo são enviados por meio desse adaptador de rede físico. Isso significa que o adaptador de rede físico deve ser capaz de transportar o tráfego de todas as VMs conectadas a esse comutador virtual, fazendo com que os pacotes transportados pelo adaptador de rede físico contenham vários endereços MAC (um para cada adaptador de rede virtual da VM). Esse método é suportado em adaptadores de rede físicos (configurando o adaptador de rede no modo promíscuo), mas não é suportado em adaptadores de rede sem fio, já que o canal sem fio estabelecido pelo adaptador de rede WiFi e seu ponto de acesso permite apenas pacotes de Ethernet com o endereço MAC do adaptador de rede WiFi e nenhum outro. Em outras palavras, o Hyper-V não poderia usar adaptadores de rede WiFi para um computador externo, se continuássemos a usar a arquitetura atual de comutador virtual.
Figura 1: Conexão de rede entre VM e máquina externa com o uso de conexão com fio
A solução
Para solucionar essa limitação, usamos a solução Microsoft Bridging, que implementa proxies ARP (para IPv4) e proxies de descoberta de vizinhos (para IPv6), para substituir o endereço MAC do adaptador de rede virtualpelo endereço MAC do adaptador WiFi para os pacotes de saída. A ponte mantém um mapeamento interno entre o endereço IP do adaptador de rede virtual e seu endereço MAC, para garantir que os pacotes recebidos do mundo externo sejam enviados para o adaptador de rede virtual apropriado.
O Hyper-V integra a ponte como parte da criação do comutador virtual, para que quando você crie um comutador virtual externo com o uso de um adaptador WiFi, o Hyper-V possa:
- Criar uma única ponte de adaptador conectada ao adaptador WiFi
- Criar um comutador virtual externo
- Associar o comutador virtual externo para usar a ponte, em vez do adaptador WiFi diretamente
Nesse modelo, a comutação Ethernet continua ocorrendo no comutador virtual, e a conversão do endereço MAC ocorre na ponte. Para um usuário final que criar uma rede externa, o fluxo de trabalho será o mesmo, seja com um adaptador de rede com ou sem fio.
Figura 2: Conexão de rede entre VM e máquina externa com o uso de conexão WiFi
Como conclusão, ao trazermos o Hyper-V do Windows Server para o cliente Windows, podemos oferecer uma tecnologia de virtualização robusta, desenvolvida para atender às necessidades de escalabilidade, segurança, confiabilidade e desempenho da maioria dos data centers. Com o Hyper-V, os desenvolvedores e profissionais de TI podem criar um ambiente mais eficiente e econômico para a utilização e realização de testes em várias máquinas.
--Mathew John