Esta é provavelmente a mais comum e mais facilmente explicável forma de virtualização de servidores. Quando os departamentos de TI lutavam para obter resultados com as máquinas em plena capacidade, fazia sentido atribuir um servidor físico para cada função de TI aproveitando o hardware barato. A empresa típica teria uma máquina para SQL, uma para o servidor Apache e outra máquina para o servidor Exchange. Agora, cada uma dessas máquinas pode estar a ser usada apenas a 5% do seu potencial de processamento total. É aqui que entram em cena os emuladores de hardware, num esforço para consolidar os servidores.
Um emulador de hardware cria uma interface de hardware simulada para os sistemas operativos hóspedes. Na emulação de hardware, o software de virtualização (normalmente referido como um hipervisor) na verdade cria um dispositivo de hardware artificial com tudo o que precisa para executar um sistema operativo e apresenta um ambiente de hardware emulado em que os sistemas operativos hóspedes operam. Este ambiente de hardware emulado é normalmente referido como um Monitor de Máquina Virtual ou VMM (Virtual Machine Monitor).
A emulação de hardware suporta sistemas operacionais hóspedes reais; as aplicações em execução em cada sistema operativo hóspede são executadas em ambientes verdadeiramente isolados. Desta forma, podemos pode ter vários servidores a correr numa única máquina, cada um completamente independente do outro. O VMM fornece ao sistema operativo hóspede uma emulação completa do hardware subjacente e, por esta razão, este tipo de virtualização é também referida como Virtualização Total.
Assim, a virtualização total fornece uma simulação completa do hardware subjacente e é uma técnica usada para fornecer suporte para sistemas operativos hóspedes inalterados. Isto significa que todos os softwares, sistemas operativos e aplicações, que podem ser executados directamente no hardware, também podem ser executados na máquina virtual.
O termo inalterado refere-se a núcleos (kernels) do sistema operativo que não foram alterados para serem executados num hipervisor e, portanto, ainda executam operações privilegiadas como se corressem no anel 0 da CPU. A virtualização total usa o hipervisor para coordenar a CPU do servidor e os recursos da máquina anfitriã do sistema a fim de gerir o funcionamento de sistemas operativos hóspedes, sem qualquer modificação. Neste cenário, o hipervisor fornece emulação de CPU para modificar e lidar com as operações privilegiadas e protegidas da CPU feitas por núcleos inalterados de sistemas operativos hóspedes.
O sistema operacional hóspede faz chamadas de sistema para o hardware emulado. Estas chamadas, que iriam na realidade interagir com o hardware subjacentes, são interceptadas pelo hipervisor de virtualização que as mapeia para o hardware real subjacente. O hipervisor garante total independência e autonomia entre cada servidor virtual e outros servidores virtuais a correr na mesma máquina física. Cada servidor hóspede tem o seu próprio sistema operativo e pode até acontecer que um servidor hóspede seja Linux e outro seja Windows.
O hipervisor também monitoriza e controla os recursos do servidor físico, alocando o que é necessário para cada sistema operativo e certificando-se que os sistemas operativos hóspedes (as máquinas virtuais) não podem interromper-se uns aos outros. Com a virtualização total o sistema operativo hóspede não tem conhecimento de que está a ser virtualizado e, por isso mesmo, não requer nenhuma modificação.
Hipervisor de Tipo 1
Também conhecida como Virtualização Nativa ou no Metal Nu (bare-metal), esta é uma técnica onde a camada de abstracção está directamente sobre o hardware e todos os outros blocos residem em cima dela. O Hipervisor de Tipo 1 é executado directamente sobre o hardware do sistema anfitrião, no anel 0. A tarefa deste hipervisor é lidar com a alocação de recursos e memória para as máquinas virtuais, além de fornecer interfaces para administração de nível superior e ferramentas de monitorização. Os sistemas operativos correm num outro nível acima do hipervisor.
Claramente, com o hipervisor a ocupar o anel 0, os núcleos de quaisquer sistemas operativos hóspedes a correr no sistema devem ser executados em anéis de protecção da CPU menos privilegiados. O hipervisor de Tipo 1 contém funcionalidades como agendamento de CPU e gestão de memória e, mesmo não existindo um sistema operativo anfitrião, geralmente uma das máquinas virtuais tem um certo estatuto privilegiado.
Infelizmente, a maioria dos núcleos de sistema operativo são escritos para correrem explicitamente no anel 0, pela simples razão de que eles precisam executar tarefas que estão disponíveis apenas nesse anel, tais como a capacidade de executar instruções privilegiadas da CPU e manipular directamente a memória.
Além disso, dependendo da arquitectura, o hipervisor pode tanto conter os drivers para os recursos de hardware (sendo neste caso um Hipervisor Monolítico) ou os drivers podem ser mantidos ao nível do próprio sistema operativo hóspede (caso em que pode ser chamado Hipervisor com Microkernel).
Uma vez que tem acesso de baixo nível directo ao hardware, um hipervisor deste tipo é mais eficiente do que uma aplicação hospedada e oferece maior desempenho, pois utiliza menos recursos (sem ciclos de CPU ou espaço de memória separado, como no caso de um verdadeiro SO anfitrião).
A desvantagem deste modelo é que há dependência do hipervisor para os drivers (pelo menos no caso do hipervisor monolítico). Além disso, a maioria das implementações desta abordagem requerem suporte específica de virtualização a nível do hardware (Assistida por Hardware, a ser discutido num futuro artigo).
Exemplos desta arquitectura são o Microsoft Hyper-V e o VMware ESX Server.
Nota: O Microsoft Hyper-V (lançado em Junho de 2008) exemplifica um produto de Tipo 1 que pode ser confundido com um de Tipo 2. Tanto a versão isolada gratuita como a versão que faz parte do produto comercial Windows Server 2008, usam uma partição Windows Server 2008 virtualizada para gerir o hipervisor Hyper-V de Tipo 1. Em ambos os casos, o hipervisor Hyper-V arranca antes do sistema operativo de gestão e quaisquer ambientes virtuais criados são executados directamente sobre o hipervisor e não através do sistema operativo de gestão.
Hipervisor de Tipo 2
A Virtualização de Sistema Operativo Hóspede é talvez o conceito mais fácil de entender. Neste cenário, o sistema do computador anfitrião físico executa um sistema operativo padrão sem modificações, tal como Windows, Linux, Unix ou MacOS X, e a camada de virtualização corre em cima desse SO sendo na verdade uma aplicação hóspede. Nesta arquitectura, o VMM fornece a cada máquina virtual todos os serviços do sistema físico, incluindo uma BIOS virtual, dispositivos virtuais e memória virtual. Isso tem o efeito de levar o sistema hóspede a acreditar que está a ser executado directamente sobre o hardware do sistema, ao invés de numa máquina virtual dentro de uma aplicação.
O próprio SO fornece a camada de abstracção (conhecida como Hipervisor de Tipo 2), de tal forma que permite que outros sistemas operativos residam no seu interior, criando máquinas virtuais. Esta arquitectura pode então ser chamada como Virtualização Hospedada (Hosted Virtualization ) já que um OS a “hospeda”, como se pode ver na figura.
A camada de virtualização na figura acima contém o software necessário para hospedar e gerir as máquinas virtuais, mas a sua funcionalidade exacta pode variar de acordo com as diferentes arquitecturas de diferentes fornecedores. Nesta abordagem, o sistema operativo do hóspede depende do SO anfitrião subjacente para ter acesso aos recursos de hardware.
As múltiplas camadas de abstracção entre os SO hóspedes e o hardware anfitrião subjacente não são propícias a altos níveis de desempenho das máquinas virtuais. No entanto, esta técnica tem a vantagem de não ser necessária nenhuma alteração no SO anfitrião nem em nenhum dos hóspedes e não requere nenhum suporte especial de virtualização da CPU.
Exemplos de Hipervisores de Tipo 2 são a VirtualBox da Oracle, o VMware Server,o VMware Workstation e o Microsoft Virtual PC.
Hipervisor Incorporado
Na Virtualização ao Nível do Núcleo, o sistema operativo anfitrião é executado num núcleo (kernel) especialmente modificado que contém extensões projectadas para gerir e controlar várias máquinas virtuais, cada uma contendo um sistema operativo hóspede.
A camada de virtualização é incorporada num núcleo de sistema operativo e cada hóspede executa o seu próprio núcleo, apesar de se aplicarem restrições na medida em que os sistemas operativos hóspedes devem ter sido compilados para o mesmo hardware em que o kernel está em execução.
O benefício real desta abordagem é que o código do hipervisor é dramaticamente mais leve que o do Tipo 1 ou Tipo 2. Com o hipervisor embutido no kernel Linux, os sistemas operativos hóspedes beneficiam de excelente desempenho de disco e E/S de rede.
Exemplos de tecnologias de virtualização ao nível do kernel incluem o User Mode Linux (UML) e o Kernel-based Virtual Machine (KVM).
Vantagens da Virtualização Total
- Esta abordagem à virtualização significa que as aplicações são executadas num sistema operativo hóspede verdadeiramente isolado, com um ou mais SOs hóspedes a ser executados em simultâneo no mesmo hardware. Este método não só suporta múltiplos SOs como também pode suportar SOs diferentes, com diferenças mínimas (por exemplo, versão e nível de patch) ou diferenças grandes (por exemplo, os SOs podem ser completamente distintos como Windows e Linux);
- O SO hóspede não tem conhecimento de que está a ser virtualizado e não requere nenhuma modificação. A virtualização total é a única opção que não requer assistência do hardware ou do SO para ajudar a virtualizar as instruções confidenciais e privilegiadas. O hipervisor traduz todas as instruções do SO em tempo real e armazena os resultados para uso futuro, enquanto as instruções de nível de utilizador funcionam sem modificações em velocidade nativa;
- O VMM fornece um ambiente de hardware padronizado no qual o SO hóspede reside e interage. Como o SO hóspede e o VMM formam um conjunto consistente, esse conjunto pode ser migrado de uma máquina para outra, mesmo que as máquinas físicas que executam esses conjuntos sejam diferentes;
- A virtualização completa oferece o melhor isolamento e segurança para máquinas virtuais, e simplifica a migração e portabilidade visto que a mesma instância do SO hóspede pode ser executada virtualizada ou em hardware nativo.
Limitações da Virtualização Total
- O software de virtualização prejudica a performance, o que significa dizer que as aplicações funcionam frequentemente um pouco mais lentamente em sistemas virtualizados do que se fossem executadas em sistemas não virtualizados. O hipervisor necessita de processamento de dados, o que significa que parte do poder de computação de um servidor físico e recursos relacionados devem ser reservados para o programa hipervisor. Embora os VMMs pareçam resolver todos os problemas em relação a máquinas virtualizadas, trazem algum nível de degradação de desempenho, causada pelo processamento extra (em termos de "tradução de instruções") que o hipervisor tem que fazer. Isso pode ter um impacto negativo no desempenho geral do servidor e abrandar as aplicações;
- O hipervisor tem que conter as interfaces para os recursos da máquina; estes interfaces são conhecidos como drivers de dispositivo. Como a emulação de hardware usa software para enganar o SO hóspede para comunicar com hardware simulado inexistente, esta abordagem tem criado alguns problemas de compatibilidade de drivers. O problema é que o hipervisor contém os drivers de dispositivo e pode não ser fácil que novos drivers sejam instalados pelos utilizadores (ao contrário do que ocorre nos nossos PCs). Consequentemente, se uma máquina tem recursos de hardware para os quais o hipervisor não tem drivers, o software de virtualização não pode ser executado na máquina. Isso pode causar problemas, especialmente para organizações que querem tirar proveito de novas tecnologias de hardware.