Desktop hypervisors são uma tecnologia popular entre os tecnófilos. Temos todo o tipo de razões para usá-los. Alguns de nós precisamos de testar software que outras pessoas escreveram para ver se é bom. Alguns de nós precisamos de testar software que escrevemos para ver se é bom. Às vezes, precisamos restringir a atividade a um ambiente temporário. Outras vezes, só queremos manter nosso ambiente primário fora das garras de um instalador invasor. Chegar com razões para usar um hipervisor de desktop é simples. Decidir qual hipervisor de desktop usar pode ser mais complicado. Este artigo irá comparar e contrastar o Hyper-V Cliente da Microsoft com o VirtualBox da Oracle.

>

Como regra, eu não digo às pessoas qual produto usar. Eu acredito que você deve escolher o que melhor se adapta às suas necessidades. Se nada estiver disponível que se alinhe perfeitamente, misture e combine até chegar o mais perto que puder. Não gosto quando as pessoas escolhem primeiro o seu produto e depois deitam fora justificações convenientes para essa escolha. Dois exemplos comuns são: “Nunca ninguém foi despedido por comprar IBM” e, “Este produto é o mais popular”. Meu propósito aqui não é ditar qual produto é superior, mas guiá-lo para uma decisão informada. Essa decisão pode ser para usar ambos hypervisors.

Client Hyper-V e VirtualBox: A Technology Overview

Todos nós somos pessoas de tecnologia aqui, então vamos começar olhando para estes dois hipervisores de um ponto de vista tecnológico.

Não são do tipo um do outro

A diferença mais óbvia entre os dois produtos é que o Cliente Hyper-V é um hipervisor tipo 1 e o VirtualBox é um hipervisor tipo 2. Agora, cada vez que eu digo “Hyper-V é um hipervisor tipo 1” e depois tento explicar o que é um hipervisor tipo 1, invariavelmente recebo pelo menos alguns comentários que me dizem que minha descrição está toda errada e que, “Hyper-V é…”, e então o comentador prossegue descrevendo Hyper-V como um hipervisor tipo 2. Ou as minhas explicações não são muito boas ou as pessoas simplesmente não acreditam que Hyper-V é um hipervisor de tipo 1. Eu espero que a maior parte é que a linha entre o tipo 1 e o tipo 2 não seja tão sólida quanto algumas pessoas querem que você acredite, e portanto esses comentaristas apenas vêem as coisas de maneira diferente.

Ainda, eu vou tentar um novo método de explicar o tipo 1 vs. tipo 2, mas restringi-lo a este contexto.

Hypervisor Startup Process: Oracle VirtualBox

I’m going to start by explaining how VirtualBox is started. É um hipervisor tipo 2 e o mais fácil de entender.

1. O computador físico é iniciado
2. O sistema de inicialização do computador físico (BIOS ou UEFI) passa o controle para o sistema operacional instalado no hardware. Para o VirtualBox, que pode ser Windows, Linux, OSX ou Solaris
3. O utilizador (que é você) inicia a aplicação VirtualBox.
4. O utilizador (que é você) selecciona qual a(s) máquina(s) virtual(is) a iniciar. A VirtualBox gera processos de hospedagem

Simples, right?

Hypervisor Startup Process: Cliente Hyper-V

>

Como um hipervisor tipo 1, a rotina de inicialização do cliente Hyper-V é bastante diferente da da VirtualBox em um nível fundamental.

1. O computador físico é iniciado
2. O sistema de inicialização do computador físico (BIOS ou UEFI) passa o controle para Hyper-V
3. Hyper-V inicia o sistema operacional de gerenciamento. O sistema operativo de gestão só pode ser Windows, Windows Server ou Hyper-V Server
4. Em resposta às configurações automáticas ou instruções manuais do utilizador (é você), o Hyper-V gera partições para máquinas virtuais

Existem variações na forma como os diferentes hipervisores de tipo 1 e tipo 2 atingem os seus objectivos, por isso não posso fazer apenas algumas declarações de blanquetas e ir-me embora. Vamos dar uma olhada em algumas das diferenças genéricas.

A Importância das diferenças de tipo

Você pode encontrar uma grande quantidade de material escrito sobre as diferenças entre os hipervisores tipo 1 e tipo 2. À luz das capacidades do hardware moderno, software de virtualização e sistemas operacionais, a maior parte desse material é de valor questionável. Eu vou pular as partes questionáveis e lidar apenas com o que podemos verificar.

Para esta discussão, a distinção mais importante entre hipervisores tipo 1 e tipo 2 é que um hipervisor tipo 1 está sempre ligado. A única maneira de “parar” o Hyper-V do Cliente é desligar o computador ou remover a função. Claro, você pode parar o serviço “Hyper-V Virtual Machine Management”, mas isso não é Hyper-V. É um serviço de gerenciamento. Acho que foi por isso que lhe deram esse nome em particular. Pará-lo impede que você gerencie qualquer uma das máquinas virtuais, mas não afeta as máquinas virtuais ou o hipervisor. Você não pode ver o Hyper-V ao poking através do sistema operacional de gerenciamento.

Por outro lado, o VirtualBox pode ser aberto e fechado à vontade. Você pode localizar o aplicativo VirtualBox, seu serviço e suas máquinas virtuais no gerenciador de tarefas do sistema operacional de gerenciamento. Se fechar a interface principal, quaisquer máquinas virtuais activas continuarão a funcionar porque o VirtualBox irá deixar o seu kernel hypervisor na memória. Se você parar a última máquina virtual VirtualBox, então não há mais VirtualBox. Você precisará iniciá-la novamente para que qualquer máquina virtual funcione.

As diferenças de tipo de Hyper-V e VirtualBox têm várias consequências:

• O sistema operacional de gerenciamento do Hyper-V usa a vCPU como as máquinas virtuais
• Você precisa usar contadores de desempenho Hyper-V para ver qualquer coisa sobre o uso de recursos do Hyper-V, e isso não conta toda a história
• A atribuição de hardware funciona de forma diferente
• A prioridade de recursos funciona de forma diferente

Hyper-V vs. VirtualBox: Acesso de Hardware

Quando leio as reclamações sobre o Hyper-V do Cliente, problemas de hardware saltam direto para o topo da pilha. Inevitavelmente, são feitas comparações com VirtualBox, VMware Workstation/Player, e outros hipervisores tipo 2. Os queixosos raramente deixam de mencionar como os problemas de dispositivos são quase inexistentes nesses produtos. A raiz do problema está no hipervisor tipo.

Quando o VirtualBox (ou qualquer outro hipervisor tipo 2) gera uma máquina virtual, o seu contentor corre dentro do sistema operativo de gestão onde vivem as aplicações. Como outras aplicações, elas não têm acesso directo ao hardware; devem solicitar acesso ao dispositivo através do sistema operativo.

Por exemplo, vejamos a atribuição do meu hardware de som ao meu ambiente de trabalho Windows 10:

Eu tenho múltiplos dispositivos de hardware de som e múltiplas aplicações. Todo o acesso e atribuição de hardware ocorre através do sistema operacional. Nota: O acima descrito é apenas para fins ilustrativos. Você não usa o Volume Mixer para conectar os convidados da VirtualBox ao hardware de som.

Então, quando você liga um convidado da VirtualBox, você pode usar seu container de aplicativos para solicitar acesso ao hardware.

Agora, pense no Cliente Hyper-V. O sistema operacional de gerenciamento é executado em sua própria partição, separado dos sistemas operacionais guest. Ao contrário do VirtualBox, os sistemas operacionais guest do Client Hyper-V não têm nenhuma projeção para o sistema operacional de gerenciamento. Eles não podem simplesmente chamar a API no sistema operacional de gerenciamento da maneira que os convidados do VirtualBox podem, pois não conseguem alcançá-la. Existem características no Client Hyper-V que podem ajudá-lo a resolver essa diferença, mas tudo isso é causado por diferenças fundamentais nas tecnologias hypervisor.

Takeaway desta seção: se você quiser usar hardware conectado a USB e discos externos com suas máquinas virtuais guest, você terá um tempo mais fácil com VirtualBox.

Hyper-V vs. VirtualBox: Apresentação de Hardware

Esta secção liga-se fortemente à secção anterior. Se você folhear as abas de configurações de uma máquina virtual no VirtualBox, você vai encontrar muitas coisas que você não verá no Hyper-V. Você deve decidir entre um PIIX3 ou um chipset ICH9. Você deve escolher entre um controlador de áudio Intel, um controlador de áudio ICH AC97, e um controlador de áudio SoundBlaster 16. Se você permitir que uma máquina virtual tenha um controlador USB, você deve escolher entre um dispositivo 1.1, 2.0, ou 3.0. Hyper-V não lhe pede para fazer escolhas como essa.

A diferença aqui também está relacionada com toda aquela discussão tipo 1 vs. tipo 2. Os hipervisores tipo 2 são projetados para rodar em uma gama muito maior de ambientes, o que apresenta qualquer número de problemas. Para resolver esses problemas, os hipervisores do tipo 2 fazem uso extensivo de emulação. Emulação é quando uma construção de software imita as interfaces de um dispositivo de hardware. VirtualBox emula todas as coisas que eu listei no parágrafo anterior e muito mais. Cliente Hyper-V emula muito pouco – os mais notáveis são seu controlador IDE e o adaptador de rede legado.

Emulação resolve os problemas de aplicabilidade generalizada. Como você pode imaginar, esta versatilidade vem com um custo. Todo o propósito do hardware especializado, como placas de rede e adaptadores de vídeo, é que eles lidam com suas respectivas cargas de trabalho para que o fardo não caia em outro lugar. Como eles são construídos especificamente para suas tarefas, eles (presumivelmente) o fazem melhor do que outros componentes construídos com outros objetivos em mente. Com hardware emulado, sua CPU de propósito geral assume toda a responsabilidade de hardware dedicado.

Takeaway a partir desta seção: VirtualBox trabalha com uma gama mais ampla de hardware em uma gama mais ampla de sistemas às custas de overhead com impacto no desempenho.

Hyper-V vs. VirtualBox: Resource Priority

Porque o VirtualBox só funciona dentro do sistema operacional instalado em hardware, está à mercê do agendador desse sistema operacional. Uma das razões pelas quais eu pulei qualquer uma das discussões típicas sobre anéis de CPU é que o VirtualBox inclui este diálogo:

O que isso significa é que o VirtualBox pode acessar as mesmas características que muitas pessoas só associam com o anel -1 da CPU e as extensões de monitor da máquina virtual usadas pelos hipervisores “true” tipo 1.

No entanto, o VirtualBox ainda está vinculado por restrições impostas pelo sistema operacional instalado por hardware. Se você tem um jogo Flash em execução absorvendo memória e CPU no seu sistema operacional instalado por hardware, o sistema operacional pode e irá fazer com que o desempenho das máquinas virtuais VirtualBox sofra a qualquer ponto que ele goste. Se for preciso, você pode usar o Task Manager para matar qualquer processo VirtualBox ou guest.

Em contraste, o Client Hyper-V fornece os mesmos controles de priorização que seu irmão mais velho baseado no servidor. Você pode priorizar CPU e memória, ativar a qualidade de armazenamento do serviço e definir limitações de largura de banda da rede para todas as suas máquinas virtuais.

Takeaway a partir desta seção: Cliente Hyper-V concede controle fino sobre a priorização de recursos; VirtualBox não.

Hyper-V vs. VirtualBox: Aceleração do Vídeo

Esta seção é um pouco diferente da discussão anterior porque nada aqui será universalmente verdadeiro. Vou recontar como as diferenças entre os dois hipervisores influenciaram as minhas experiências. Sua milhagem pode variar.

Both Client Hyper-V e VirtualBox emulam vídeo. Nas minhas experiências, não tenho sido capaz de distinguir que uma é melhor que a outra quando se trata de aceleração 2D. Não acredito que eu peça muito de aceleração 2D, mas também sei que a maioria dos sistemas operacionais desktop modernos utilizam aceleração 2D de maneiras que nem sempre são óbvias até que não estejam disponíveis. Dois exemplos principais são a suavização de fontes e animações de janelas. Com a reserva expressa de que sua quilometragem pode variar, não acredito que a aceleração 2D deva ser um fator fortemente a favor de qualquer um dos hypervisores.

3D aceleração é uma história diferente. O cliente Hyper-V oferece o RemoteFX. Na minha experimentação, ele funciona muito bem dentro dos limites do que ele foi projetado para fazer. RemoteFX não projeta o adaptador de vídeo para o sistema operacional convidado, então você não pode acessar todas as suas funcionalidades. RemoteFX também tem funcionado em todos os sistemas com os quais eu já tentei usá-lo, desde que ele contivesse o driver necessário compatível com WDDM acelerado em 3D.

3D aceleração no VirtualBox é uma história completamente diferente. Eu falhei completamente em fazê-lo funcionar o suficiente para exibir um desktop Windows básico corretamente. Nunca cheguei perto de tentar qualquer recurso de aceleração 3D. Portanto, não posso dar nenhuma comparação significativa entre os dois.

Takeway desta secção: a aceleração 2D parece ser uma lavagem entre os dois. A aceleração 3D parece mais confiável no Cliente Hyper-V.

Hyper-V Vs. VirtualBox: Virtual Hard Disk Compatibility

VirtualBox suporta vários formatos de disco rígido virtual. Você pode escolher entre:

• VDI, o formato nativo da VirtualBox
• VMDK, formato VMware
• VHD, formato Microsoft
• HDD, formato Parallel’s
• QED e QCOW, usado em QEMU e outros hipervisores

Você não pode usar VHDX com a VirtualBox. A capacidade de usar outro formato de disco hipervisor não significa necessariamente que você será capaz de transitar suavemente um disco rígido virtual de um hipervisor para outro, seja.

Takeaway desta seção: esta é uma informação quase geral, porque a capacidade de usar múltiplos formatos de disco rígido virtual não é tão útil como poderia parecer no início. Se você pretende tentar mover um disco rígido virtual de uma plataforma para outra sem utilizar um conversor, o VirtualBox é sua melhor escolha.

Hyper-V vs. VirtualBox: Outras Características de Vídeo

VirtualBox fornece algumas características de vídeo que o Cliente Hyper-V não compete diretamente com.

• Cliente Hyper-V pode exibir apenas em um monitor ou em todos os monitores. Você pode especificar entre um e oito monitores para VirtualBox.
• VirtualBox fornece um modo servidor que permite que computadores remotos se conectem ao sistema operacional instalado por hardware para visualizar o console de um ou mais convidados específicos. Cada endpoint permite múltiplas conexões remotas simultâneas. O cliente Hyper-V fornece funcionalidade similar com o vmconnect.exe, mas não é tão versátil.
• VirtualBox pode fazer uma gravação de vídeo de um sistema operacional convidado.
• VirtualBox permite definir uma máquina virtual para o modo “Seamless”. Os aplicativos que você iniciar na máquina virtual aparecerão e funcionarão como se estivessem rodando no sistema operacional instalado por hardware.

Takeaway a partir desta seção: se qualquer uma destas características lhe atrai, o VirtualBox é a única opção.

Hyper-V vs. VirtualBox: Acesso ao código fonte

VirtualBox é um software de código aberto. Se você não gosta de alguma coisa e acredita que pode fazer melhor, tenha em mente. Se você só quer saber como funciona, baixe o conjunto de códigos e escave em.

Microsoft está gradualmente aquecendo a noção de código aberto e tem submetido uma grande quantidade de código para a comunidade. O Windows está notoriamente ausente. Como eu entendo, a base de código Hyper-V está muito bem acoplada ao Windows. Eu tenho minhas dúvidas que alguma vez veremos o código do Hyper-V publicado.

Takeaway desta seção: se usar um hypervisor de código aberto é importante para você, isso desqualifica o Hyper-V.

Hyper-V vs. VirtualBox: Licença de Uso

Client Hyper-V é enviado como um componente das SKUs Profissional e Empresarial do Windows 10. Se você está de outra forma licenciado para usar um desses, então você está licenciado para usar Client Hyper-V.

Oracle licencia o pacote VirtualBox principal atual (versões 5.x+) sob a GPLv2. Eles também fornecem algumas “extensões” sob uma licença separada chamada “Licença de Avaliação e Uso Pessoal do VirtualBox”. Eu pessoalmente não uso nenhuma dessas funcionalidades, embora elas englobem algumas das funcionalidades de que falei acima. Eu não me aprofundei nos termos desta licença, mas ela parece ser bastante generosa. Como sempre, eu recomendo que você permita que um consultor jurídico treinado possa colocar qualquer uma de suas questões de licenciamento.

No que diz respeito às licenças do sistema operacional guest, essas são um conto à parte. Nem o Cliente Hyper-V nem a VirtualBox fornecem qualquer licença de sistema operacional para convidados. Se você instalar qualquer sabor de Windows ou Windows Server em um sistema operacional convidado sob qualquer hypervisor, você deve licenciar corretamente o hardware.

Takeaway desta seção: o licenciamento é sempre importante.

Acquiring Client Hyper-V e VirtualBox

Se você estiver executando Windows 10 Professional ou Enterprise, então você só precisa habilitar a função Hyper-V para começar a usá-la.

VirtualBox está disponível em seu website: https://www.virtualbox.org/