Virtualização: hipervisor tipo 1 × tipo 2, snapshots, live migration, VM × contêiner

A ideia que organiza o assunto

Um servidor físico dedicado a uma aplicação passa a maior parte da vida ocioso, e mesmo assim ocupa rack, consome energia e exige refrigeração. A saída foi parar de entregar o hardware e passar a entregar uma abstração dele: uma camada de indireção entre o recurso físico e quem o usa. Quem fica nessa camada multiplexa um processador, uma memória e um disco reais em vários processadores, memórias e discos aparentes, e convence cada hóspede de que a máquina é só dele.

É daí que sai tudo. O hipervisor (também chamado monitor de máquina virtual, VMM) é essa camada; a máquina virtual é a ilusão que ele entrega; o isolamento é a garantia de que uma ilusão não enxerga nem derruba a outra; a consolidação de servidores é a consequência econômica de caber muita ilusão em pouco ferro.

Mas a camada de indireção pode ser posta em dois lugares diferentes, e é essa escolha que organiza o assunto inteiro:

• Embaixo do sistema operacional. O hipervisor fala direto com o hardware e cada hóspede traz o seu próprio sistema operacional completo, com kernel próprio. É a máquina virtual.
• Dentro do sistema operacional. O kernel do host é único e passa a servir vários conjuntos de processos que não enxergam uns aos outros. É o contêiner.

Guardadas essas duas perguntas — o hipervisor está sobre o hardware ou sobre um SO hospedeiro? e o kernel é próprio ou emprestado? — a maioria dos itens desta matéria se responde sem decorar produto nenhum.

Por que se usa (e o que custa)

Ganha-se consolidação: menos equipamentos físicos, menos espaço, menos energia, menos refrigeração, e um provisionamento que deixa de ser uma compra e passa a ser um comando. Ganha-se também mobilidade — uma máquina virtual é um conjunto de arquivos, e arquivo se copia, se versiona, se leva para outro host — e é isso que torna possíveis snapshot, clonagem, template e migração ao vivo.

Paga-se em três lugares. Há sobrecarga de desempenho: a camada extra custa ciclos, e o que a atenua é a virtualização assistida por hardware (Intel VT-x, AMD-V), não a boa vontade do administrador. Há concentração de risco: dez serviços que caíam separadamente agora caem juntos quando o host cai — daí cluster, alta disponibilidade e migração serem assunto obrigatório junto com virtualização, e não um capítulo à parte. E há proliferação de máquinas virtuais (VM sprawl): como criar é barato, cria-se demais, e o custo volta como licenças, armazenamento e superfície de ataque.

A formulação honesta para a prova: a virtualização não elimina o hardware, aumenta a taxa de utilização dele. Todo item que trate virtualização como supressão de algo físico — “elimina a necessidade de switches físicos”, “dispensa o hardware” — está esticando essa ideia.

Como funciona

Os dois tipos de hipervisor. O tipo 1, chamado bare metal ou nativo, executa diretamente sobre o hardware e ocupa o lugar do sistema operacional hospedeiro: não há SO embaixo dele. VMware ESXi, Microsoft Hyper-V e Xen são os exemplos que a banca usa. O tipo 2, ou hospedado, é instalado sobre um sistema operacional existente e roda como mais uma aplicação daquele SO — VirtualBox, VMware Workstation, VMware Player. O tipo 1 é o de datacenter porque tem menos camadas entre a máquina virtual e o processador; o tipo 2 é o de estação de trabalho porque convive com o sistema que o usuário já tem.

As três formas de entregar o hardware ao hóspede. Na virtualização completa o hipervisor exporta uma cópia fiel do hardware: o sistema operacional convidado roda sem qualquer alteração e sequer sabe que está virtualizado. Na paravirtualização o hipervisor exporta uma versão modificada do hardware, e por isso o convidado precisa ser alterado para chamar o hipervisor explicitamente, por hiperchamadas, em vez de executar as instruções sensíveis — ganha-se desempenho, perde-se a compatibilidade com sistemas fechados. Na emulação simula-se por software um conjunto completo de hardware, inclusive de arquitetura diferente da hospedeira (QEMU), ao custo do desempenho mais baixo dos três.

Snapshot. É a fotografia do estado de uma máquina virtual num instante: conteúdo dos discos virtuais, opcionalmente a memória, e a configuração. A partir dele o disco original congela e as escritas passam a ir para arquivos de diferença (delta), que crescem enquanto o snapshot existir. Serve para reverter uma atualização malsucedida em minutos; não serve como backup, porque depende do mesmo armazenamento e dos mesmos arquivos da máquina viva — perdido o datastore, perderam-se os dois. Cadeias longas de snapshot degradam desempenho e consomem espaço de forma silenciosa.

Migração ao vivo (live migration). Move uma máquina virtual em execução de um host para outro sem derrubar o serviço. A técnica clássica é a pré-cópia (pre-copy): copia-se a memória para o destino com a máquina ainda rodando, e copiam-se em rodadas sucessivas apenas as páginas sujadas desde a rodada anterior, até que o resto seja pequeno o bastante para uma parada final de milissegundos, quando se transferem o estado da CPU e as últimas páginas e o destino assume. Exige rede de baixa latência entre os hosts e, na forma tradicional, armazenamento compartilhado, já que só a memória e o estado de execução viajam — o disco fica onde está. No VMware chama-se vMotion; o equivalente de disco é o Storage vMotion.

Contêineres. Não há hipervisor nem sistema operacional convidado: os processos rodam sobre o kernel do host, que os separa com dois mecanismos distintos. Os namespaces isolam a visão — cada contêiner vê a sua própria árvore de processos, seus pontos de montagem, sua rede, seus usuários. Os cgroups (grupos de controle) limitam e contabilizam o consumo de CPU, memória, E/S e rede por grupo de processos. Some-se um sistema de arquivos em camadas e a imagem — aplicação, bibliotecas e dependências, sem kernel — pesa megabytes e sobe em segundos, contra gigabytes e minutos de uma máquina virtual.

O que decide os itens

Tipo 1 × tipo 2 — o eixo mais cobrado da matéria:

	tipo 1 (bare metal, nativo)	tipo 2 (hospedado)
onde é instalado	direto sobre o hardware	sobre um SO hospedeiro já existente
SO hospedeiro	não existe; o hipervisor ocupa o lugar dele	obrigatório
como as VMs aparecem	cargas gerenciadas pelo próprio hipervisor	processos/aplicativos do SO hospedeiro
desempenho e isolamento	maiores	menores
uso típico	servidor, datacenter	desktop, laboratório, teste
exemplos	ESXi, Hyper-V, Xen, KVM	VirtualBox, VMware Workstation/Player

Máquina virtual × contêiner — o segundo eixo:

	máquina virtual	contêiner
kernel	próprio, um por VM	compartilhado, o do host
o que empacota	SO convidado completo + aplicação	aplicação + bibliotecas + dependências
camada que isola	hipervisor	kernel do host (namespaces + cgroups)
tamanho e inicialização	gigabytes, minutos	megabytes, segundos
isolamento	mais forte (fronteira de hardware virtual)	mais fraco (mesma fronteira de kernel)
SO diferente do host	pode (Windows sobre Linux)	não, precisa do mesmo kernel

Completa × para × emulação:

técnica	o que o hipervisor exporta	o convidado é modificado?
virtualização completa	cópia fiel do hardware real	não
paravirtualização	versão modificada do hardware; hiperchamadas	sim
emulação	hardware simulado por software, até de outra arquitetura	não, mas o desempenho despenca

Namespaces × cgroups — par que a banca troca: namespace isola a visão, cgroup limita o recurso. Nenhum dos dois existe para “compartilhar todos os recursos”.

Snapshot × clone × backup × template — snapshot congela um ponto no tempo da mesma VM, no mesmo armazenamento; clone gera uma cópia independente e nova; backup é cópia em mídia separada, e é o único que sobrevive à perda do armazenamento; template é modelo imutável para provisionar novas VMs.

Consolidação de servidores — muitos servidores virtuais dentro de um equipamento físico. Reduz quantidade de equipamentos, espaço, energia e refrigeração. Qualquer item que a descreva na direção contrária (várias máquinas físicas servindo a uma VM — isso é cluster/grid) ou que lhe atribua aumento de consumo de energia está invertido.

Tipos de virtualização — nem toda virtualização usa hipervisor:

tipo	o que abstrai	precisa de hipervisor?
de servidor / hardware	a máquina física, em várias VMs	sim
de desktop (VDI)	a estação do usuário, executada centralmente e acessada remotamente	sim
de rede	switches, roteadores e enlaces em software	não
de armazenamento	discos físicos em pools lógicos	não
de dados	várias fontes de dados vistas como uma só, sem mover os dados	não
de aplicação	a aplicação isolada do SO onde executa	não

Mapa VMware — quase todo item de produto se resolve com esta lista:

produto	papel
ESXi	o hipervisor tipo 1 da VMware (não é QEMU, não é Xen)
vSphere	a plataforma: ESXi + vCenter + camadas de infraestrutura e serviços
vCenter Server	gerência centralizada de vários hosts
vMotion	migração ao vivo de VM entre hosts, sem interrupção
Storage vMotion	migração ao vivo dos discos entre datastores
DRS	balanceia carga entre hosts do cluster, automaticamente
HA	reinicia VMs em outro host após falha — há interrupção
vRealize Orchestrator	automação e orquestração de processos, inclusive de terceiros

Xen — hipervisor tipo 1 de código aberto. O dom0 é o domínio privilegiado, com os drivers e as ferramentas de administração; os domU são os domínios hóspedes. Nasceu paravirtualizado, mas com apoio do processador (HVM) também emula dispositivos físicos reais e os expõe aos hóspedes. Comandos da família xm/xl: xm dmesg mostra o buffer de mensagens do hipervisor e xm dmesg --clear o esvazia; sync_console é opção de inicialização que força a saída de console imediata, sem buffer, para não perder mensagens numa falha.

Como a CEBRASPE derruba você aqui

Medido sobre os 30 itens errados já explicados do tópico. Mais da metade — 53% — é uma só manobra: o sentido da técnica ao contrário. Ou a descrição está correta e apontada para o lado errado, ou o item nega justamente a capacidade que faz a virtualização existir. Descrição e rótulo nunca se conferem juntos: leia a descrição primeiro e o nome por último.

Inversão — 53%, e ela aparece de três jeitos. O primeiro é o rótulo trocado pela definição do vizinho: o hipervisor tipo 1 que “é instalado em um sistema operacional existente e permite que máquinas virtuais sejam executadas como um aplicativo”, que é o tipo 2; “cada container contém seu próprio kernel do sistema operacional (SO)”, que é a máquina virtual; “os contêineres são mais pesados e menos integrados ao sistema operacional da máquina host”, quando compartilhar o kernel é exatamente o que os torna leves. O segundo é negar uma capacidade real: o VMware “é incapaz de virtualizar clusters de alta disponibilidade de serviços” (vSphere HA, FT, DRS), o mesmo VMware que “não possibilita reduzir custos de TI em uma organização”, o Hyper-V que “não permite a virtualização de servidores de AD”, um ambiente em que “não há proteção entre máquinas virtuais hospedadas em um único hardware”, um disco cheio para o qual “uma nova máquina virtual deverá ser criada”. O terceiro é a conta ao contrário: consolidar seria “agrupar várias máquinas físicas para atender uma ou mais máquinas virtuais”, quando é o inverso; a virtualização de desktop serviria para “destinar uma máquina física para cada usuário”, que é o modelo que ela veio substituir; a consolidação que “gera o aumento dos custos com o consumo de energia”; os cgroups “com o objetivo de compartilhar todos os recursos disponíveis”, quando eles limitam e contabilizam, e quem isola a visão são os namespaces. Defesa: se o item proibir, negar ou eliminar uma capacidade, ele quase sempre está errado — e se ele contar equipamentos, confira a direção da conta.

Termo trocado — 27%, e metade é o mesmo par. Virtualização completa contra paravirtualização, sempre no mesmo eixo: “uma paravirtualização” que simula todo o conjunto de hardware, quando isso é completa ou emulação; “utiliza-se a técnica de virtualização completa” para exportar uma versão do hardware, quando exportar versão modificada é para; “a arquitetura de virtualização completa” que exigiria convidado modificado; “a paravirtualização de sistemas” que induziria o convidado a crer que está direto sobre o hardware, o que é a completa. Ancore numa frase só: modificou o convidado, é para; não modificou, é completa. O restante da categoria é nome trocado dentro de metade verdadeira — o hipervisor da VMware que “chama-se QEMU”, quando é o ESXi; “o Chemosphere”, apresentado como plataforma de gerência de infraestrutura virtual; “um ambiente virtual bare metal” definido como forma de referência de objeto remoto; e a sintaxe “esxcli network vswitch ls”, que não existe nesse namespace. Use os mapas de produto acima em vez de confiar na plausibilidade da frase.

Absoluto — 7%. “Elimina completamente a necessidade de switches físicos”: a virtualização de rede reduz e simplifica o parque, mas o tráfego entre hosts continua passando por placa, cabo e switch, e o switch virtual precisa de uplink. E “diferentemente dos demais tipos de virtualização”, dito da de dados por dispensar hipervisor — rede, armazenamento e aplicação também dispensam. Achado o absoluto, confira a tabela de tipos acima.

Finalidade ou efeito inventado — 7%. “O objetivo da virtualização é executar nas máquinas virtuais os sistemas gerenciadores de banco de dados”: uma aplicação possível apresentada como razão de ser da técnica, que é abstrair e multiplexar o hardware. E, no encadeamento de comandos, “o resultado do último comando será a exibição das IRQs ativadas na inicialização do hypervisor” depois de um xm dmesg —clear, que esvaziou o buffer. Em item de sequência de comandos, execute a sequência mentalmente antes de julgar o resultado.

Equivalência afirmada e componente errado — 3% cada. “Contêineres e máquinas virtuais são equivalentes”: não são, e a própria segunda metade do item costuma descrever corretamente o contêiner e derrubar a equivalência. E, dentro do ESB, “o componente endpoints converte mensagens”, quando endpoint é o ponto de conexão e converter é trabalho da mediação e da transformação.

Erros clássicos

Achar que snapshot é backup. Não é. Vive no mesmo armazenamento, depende dos arquivos da própria máquina virtual e, se o datastore morrer, morrem os dois. Snapshot é para desfazer mudança; backup é para sobreviver a desastre.

Achar que contêiner é uma máquina virtual leve. A diferença não é de tamanho, é de kernel. Sem kernel próprio, não há como rodar Windows em contêiner sobre host Linux, e o isolamento nunca é o mesmo de uma VM.

Confundir namespace com cgroup. Isolar visão não é limitar recurso. Item que diga que cgroups servem para “compartilhar todos os recursos” inverteu a finalidade: eles existem para restringir e contabilizar.

Achar que migração ao vivo e alta disponibilidade são a mesma coisa. A migração ao vivo é planejada e não interrompe o serviço; a alta disponibilidade é reativa e reinicia a VM em outro host depois da falha — há, sim, interrupção.

Tratar disco de VM como tamanho definitivo. Disco virtual é arquivo: pode ser expandido, e em geral a quente. Não se cria uma máquina nova para ganhar espaço.

Supor que toda virtualização tem hipervisor. Rede, armazenamento, dados e aplicação são virtualizados sem nenhum. Só a virtualização de hardware/servidor (e a de desktop, que é servidor por baixo) exige um.

Esquecer que o isolamento é uma garantia do hipervisor. Uma VM comprometida não contamina automaticamente as vizinhas; dizer que “não há proteção entre máquinas virtuais no mesmo hardware” nega a razão de existir da camada.