Aula 13 — Virtualização
Objetivos
Ao final desta aula você deve ser capaz de:
- Definir virtualização e explicar a relação entre abstração, interfaces e camadas de indireção.
- Descrever o surgimento histórico das VMs (IBM VM/370, 1972) e os requisitos formais de um VMM (fidelidade, desempenho, segurança).
- Enumerar os benefícios da virtualização: isolamento, consolidação, migração dinâmica, snapshots, desenvolvimento/teste.
- Explicar os blocos de construção: VCPU, trap-and-emulate, tradução binária e tabelas de páginas aninhadas (NPT).
- Comparar Hipervisor Tipo 0, Tipo 1 e Tipo 2, indicando exemplos e casos de uso.
- Distinguir paravirtualização de virtualização completa.
- Diferenciar VMs de containers e explicar o modelo de compartilhamento de kernel dos containers.
Conteúdo
O problema fundamental: abstração × interfaces
Sistemas operacionais expõem três interfaces para o mundo externo:
┌─────────────────────────────────────────┐
│ Aplicações de usuário │
├─────────────────────────────────────────┤
│ Interface de usuário (ABI — System │ ← interface para aplicações
│ calls, bibliotecas, formato de exec.) │
├─────────────────────────────────────────┤
│ Sistema Operacional │
├─────────────────────────────────────────┤
│ Interface de hardware (ISA — │ ← interface SO-hardware
│ conjunto de instruções) │
├─────────────────────────────────────────┤
│ Hardware │
└─────────────────────────────────────────┘
Virtualização insere uma camada adicional de software — o VMM — que replica estas interfaces, fazendo com que o software convidado acredite estar em cima do hardware real, quando na verdade está em cima de uma abstração:
┌──────────────┬──────────────┐
│ SO Convidado │ SO Convidado │ ← acreditam ter hardware exclusivo
│ (Guest OS) │ (Guest OS) │
├──────────────┴──────────────┤
│ VMM / Hipervisor │ ← multiplexação e isolamento
├─────────────────────────────┤
│ Hardware Físico (Host) │
└─────────────────────────────┘
Indireção: "Todos os problemas em Ciência da Computação podem ser resolvidos com mais um nível de indireção." — David Wheeler. A virtualização é a aplicação sistemática desse princípio ao nível do hardware.
Histórico
1972 — IBM VM/370: primeiro sistema de virtualização comercial. O mainframe IBM System/370 executava múltiplos sistemas operacionais convidados simultaneamente. Cada convidado recebia minidiscos (fatias virtuais dos discos físicos). O convidado padrão era o CMS — sistema operacional monousuário interativo.
Requisitos formais de Popek e Goldberg (1974): qualquer VMM deve satisfazer três propriedades:
- Fidelidade: o ambiente fornecido ao convidado é essencialmente idêntico à máquina real — programas executam da mesma forma.
- Desempenho: a maioria das instruções executam nativamente (sem intervenção do VMM).
- Segurança/controle: o VMM tem controle total dos recursos físicos.
Anos 1990–2000: CPUs Intel x86 não atendiam nativamente os requisitos de Popek e Goldberg (havia instruções sensíveis que não geravam trap em modo usuário). VMware e Xen desenvolveram técnicas de contorno: tradução binária (VMware) e paravirtualização (Xen), lançando a era moderna da virtualização em x86.
2005–2006: Intel (VT-x) e AMD (AMD-V) adicionam suporte nativo à virtualização nas CPUs x86-64 — eliminando a necessidade de tradução binária. A virtualização se torna eficiente o suficiente para uso em produção.
2010s–hoje: a virtualização viabilizou a computação em nuvem (AWS, Azure, GCP). Containers (Docker, 2013) emergiram como alternativa leve.
Benefícios e recursos
1. Isolamento e proteção
Cada VM é completamente isolada das demais. Um vírus numa VM convidada não afeta o hospedeiro nem outras VMs. Uma VM que trava não derruba o sistema inteiro.
VM A (comprometida) → pode danificar apenas seus próprios recursos
VM B → completamente isolada, continua funcionando
Hospedeiro/VMM → protegido
2. Consolidação de sistemas
Em vez de 10 servidores físicos rodando a 10% de utilização cada, um único servidor físico executa 10 VMs — utilizando 100% do hardware. Reduz custo de energia, refrigeração e espaço físico.
3. Snapshots e clonagem
O VMM pode "congelar" o estado completo de uma VM (memória, disco, CPU) em um snapshot. Permitem:
- Rollback — restaurar a VM a um estado anterior se uma atualização falhar
- Clonagem — criar 10 servidores idênticos a partir de uma imagem em segundos
- Backup — tirar snapshot sem desligar a VM
4. Migração dinâmica (live migration)
Mover uma VM em execução de um servidor físico para outro sem interromper o serviço. O estado de memória é copiado incrementalmente para o destino; quando a diferença é pequena, a VM é brevemente pausada, o estado final copiado e a execução retomada no novo servidor.
Casos de uso: manutenção de hardware sem downtime, balanceamento de carga entre servidores.
5. Desenvolvimento e testes
Desenvolvedores podem ter múltiplos SOs na mesma máquina (Linux, Windows, BSD). QA pode testar a aplicação em vários ambientes sem ter múltiplos computadores. Facilita o teste de sistemas operacionais experimentais sem risco à máquina física.
Blocos de construção
A CPU Virtual (VCPU)
O VMM não executa o código do convidado diretamente na CPU física em todos os momentos. Em vez disso, mantém uma VCPU (Virtual CPU) por convidado — uma estrutura de dados que representa o estado da CPU como o convidado acredita que ele seja (registradores, PC, flags, modo de execução).
VCPU do Convidado A VCPU do Convidado B
[registradores] [registradores]
[PC convidado] [PC convidado]
[modo: kernel/user] [modo: kernel/user]
↕ ↕
[ VMM gerencia mudanças de contexto ]
↕
[ CPU Física (única) ]
A VCPU é análoga ao PCB: assim como o SO usa o PCB para salvar/restaurar o contexto de um processo, o VMM usa a VCPU para salvar/restaurar o contexto de um sistema operacional convidado inteiro.
Trap-and-Emulate
O mecanismo fundamental de virtualização em CPUs que suportam VT-x/AMD-V:
1. Convidado executa instrução privilegiada (ex.: leitura de CR3)
↓
2. CPU detecta: convidado está em modo não-privilegiado → gera TRAP
↓
3. Controle transferido ao VMM (saída de VM / VM exit)
↓
4. VMM emula a instrução: atualiza a VCPU ou gerencia o recurso real
↓
5. Controle devolvido ao convidado (entrada de VM / VM entry)
↓
6. Convidado continua como se a instrução tivesse executado nativamente
Instruções não-privilegiadas (ex.: soma, salto condicional, acesso a memória de usuário) executam diretamente na CPU física — nenhuma intervenção do VMM. Isso garante o requisito de desempenho: apenas uma pequena fração das instruções precisa de trap.
Tradução Binária
Antes do VT-x/AMD-V, CPUs x86 tinham instruções sensíveis que não geravam trap em modo usuário (violando o requisito de Popek-Goldberg). A solução da VMware: tradução binária.
Código convidado (binário original)
↓
VMM lê as próximas instruções antes de executar
↓
Instruções normais → executam nativamente
Instruções sensíveis → substituídas por código seguro equivalente
↓
Código traduzido armazenado em cache para reuso
O resultado da VMware: ~950.000 traduções no boot do Windows XP, ~3µs cada, overhead total de ~3 segundos (~5%) — aceitável para produção.
Tabelas de Páginas Aninhadas (NPT / EPT)
O convidado gerencia sua própria tabela de páginas (virtual → físico convidado). O VMM precisa de outra camada de tradução (físico convidado → físico real):
Endereço Virtual (convidado)
↓ tabela de páginas do convidado
Endereço Físico do Convidado (GPA)
↓ tabela de páginas do VMM (NPT/EPT — hardware)
Endereço Físico Real (HPA)
Com NPTs em hardware (Intel EPT, AMD RVI), essa dupla tradução é realizada automaticamente pela MMU — sem intervenção do software. Cada TLB miss percorre ambas as tabelas, mas o resultado é cacheado no TLB normalmente.
Tipos de Hipervisores
Tipo 0 — Firmware/Hardware
┌──────────┬──────────┬──────────┐
│Convidado │Convidado │Convidado │
│ (SO) │ (SO) │ (SO) │
├──────────┴──────────┴──────────┤
│ Hipervisor (FIRMWARE) │
├────────────────────────────────┤
│ Hardware │
└────────────────────────────────┘
- Implementado diretamente no firmware do sistema (BIOS/UEFI estendido)
- Carrega na inicialização antes de qualquer SO
- Recursos tipicamente dedicados a cada partição (não compartilhados)
- Conjuntos de recursos menores — implementação simplificada
- Exemplos: IBM LPARs (mainframes), Oracle LDOMs (Sparc), partições de servidores Itanium/HP-UX
Tipo 1 — Bare Metal
┌──────────┬──────────┬──────────┐
│Convidado │Convidado │Convidado │
│ (SO) │ (SO) │ (SO) │
├──────────┴──────────┴──────────┤
│ VMM Tipo 1 (SO especializado)│ ← executa diretamente no hardware
├────────────────────────────────┤
│ Hardware │
└────────────────────────────────┘
- SO especializado que executa diretamente no hardware
- Fornece funcionalidades de SO (scheduling, gerenciamento de memória, drivers) mais suporte a VMs
- Convidados normalmente não sabem que estão virtualizados
- Exemplos: VMware ESXi, Microsoft Hyper-V (Windows Server), KVM (Linux), Citrix XenServer, Proxmox
- Uso: data centers, nuvem (AWS usa Xen/KVM, Azure usa Hyper-V, Google usa KVM)
Tipo 1 híbrido: SOs de propósito geral com módulo KVM integrado (Linux com KVM, Windows Server com Hyper-V). O SO principal é também o hipervisor — gerencia VMs como processos especiais.
Tipo 2 — Hosted
┌──────────┬──────────┬──────────┐
│ Aplics. │Convidado │Convidado │
│ normais │ (SO) │ (SO) │
├──────────┴──────────┴──────────┤
│ VMM Tipo 2 (aplicação) │ ← processo comum no SO hospedeiro
├────────────────────────────────┤
│ SO Hospedeiro (Host OS) │
├────────────────────────────────┤
│ Hardware │
└────────────────────────────────┘
- VMM é uma aplicação comum executada sobre um SO hospedeiro
- O hospedeiro não sabe da virtualização — gerencia o VMM como qualquer processo
- Menor desempenho que Tipo 1 (overhead do SO hospedeiro)
- Não requer privilégios de boot — pode ser instalado por usuário comum
- Exemplos: VMware Workstation/Fusion, Oracle VirtualBox, QEMU (em modo usuário), Parallels Desktop
- Uso: desenvolvimento, testes, laboratório de aprendizado (ex.: este curso!)
Comparação
| Aspecto | Tipo 0 | Tipo 1 | Tipo 2 |
|---|---|---|---|
| Onde executa | Firmware | Bare metal | Sobre SO hospedeiro |
| Desempenho | Máximo | Alto | Menor |
| Isolamento | Máximo (hw dedicado) | Alto | Médio |
| Facilidade de uso | Mínima | Média | Alta |
| Instalação | Fábrica/hardware | Partição de boot | Aplicação comum |
| Exemplos | IBM LPARs | VMware ESXi, KVM | VirtualBox, Parallels |
| Uso típico | Mainframes | Data centers, nuvem | Desktop, desenvolvimento |
Paravirtualização
Na virtualização completa, o convidado não sabe que está virtualizado — executa código binário inalterado. Na paravirtualização, o convidado é modificado para cooperar com o VMM:
- Em vez de executar instruções privilegiadas (que geram trap), o convidado faz hypercalls diretamente ao VMM — mais eficiente
- Para I/O: em vez de emular dispositivos físicos complexos, o VMM expõe abstrações simples e claras (ex.: buffer circular compartilhado para disco/rede no Xen)
- Para memória: convidado mantém suas próprias tabelas de páginas (somente leitura) e notifica o VMM via hypercall quando precisa modificá-las
Virtualização Completa: Paravirtualização:
instrução privilegiada → hypercall explícita →
trap (hardware) → VMM executa diretamente
VMM emula → sem overhead de trap
retorno ao convidado
Vantagem: menor overhead, maior eficiência de I/O. Desvantagem: requer modificação do kernel do convidado — só funciona com SOs "conscientes" da virtualização.
Xen foi o pioneiro da paravirtualização. Com o advento do VT-x, a paravirtualização tornou-se menos necessária para CPU, mas ainda é usada para I/O em muitos sistemas (virtio no KVM/Linux é paravirtualização de dispositivos).
Virtualização de Ambiente de Programação
Não virtualiza hardware — cria um ambiente virtual de execução de linguagem:
Programa Java (bytecode)
↓
JVM (Java Virtual Machine) ← "VMM" da linguagem
↓
Hardware (qualquer plataforma)
A JVM define um conjunto de instruções de bytecode portável. O mesmo programa Java executa identicamente em Linux x86, macOS ARM, Windows x64 — "write once, run anywhere".
Outros exemplos: .NET CLR (C#), Python interpreter, WebAssembly runtime.
Emulação
Diferente de virtualização (que executa na mesma ISA), emulação simula um hardware diferente:
Jogo de Super Nintendo (código MIPS/RISC)
↓
Emulador SNES (traduz MIPS → x86 dinamicamente)
↓
CPU x86 do computador moderno
- Overhead enorme (cada instrução precisa ser traduzida)
- Permite executar software legado em hardware diferente
- Exemplos: QEMU em modo de emulação completa, Wine (emula API Windows no Linux), Rosetta 2 (Apple — traduz x86 para ARM)
Containers: virtualização no nível do SO
Containers não virtualizam hardware — compartilham o kernel do SO hospedeiro. São processos isolados com namespace e cgroup próprios:
Virtualização (VMs): Containers:
┌──────┬──────┬──────┐ ┌──────┬──────┬──────┐
│SO G. │SO G. │SO G. │ │App A │App B │App C │
│+ App │+ App │+ App │ ├──────┴──────┴──────┤
├──────┴──────┴──────┤ │ Container Runtime │
│ VMM │ │ (Docker, podman) │
├────────────────────┤ ├─────────────────────┤
│ Hardware │ │ Kernel Linux (único)│
└────────────────────┘ ├─────────────────────┤
│ Hardware │
└─────────────────────┘
| Aspecto | VM | Container |
|---|---|---|
| Isolamento | Forte (HW separado) | Fraco-médio (namespace) |
| Overhead | Alto (SO completo por VM) | Mínimo (processo leve) |
| Boot time | Minutos (boot SO) | Segundos/milissegundos |
| Portabilidade | Alta (inclui SO completo) | Alta (inclui libs, não kernel) |
| Segurança | Melhor isolamento | Vulnerável a escapes de kernel |
| Uso típico | Isolamento forte, SO heterogêneo | Microserviços, CI/CD |
Mecanismos Linux para containers:
- namespaces: isolam visões de PID, rede, filesystem, usuário
- cgroups: limitam recursos (CPU%, memória máxima, I/O)
Casos de uso modernos
Cenário Tecnologia Exemplo
────────────────────────────────────────────────────────────
Data center / nuvem Tipo 1 (ESXi/KVM) AWS EC2, Azure VMs
Desenvolvimento local Tipo 2 (VirtualBox) Laboratório deste curso
CI/CD e microserviços Containers (Docker) GitHub Actions
Mainframe empresarial Tipo 0 (IBM LPAR) Bancos, seguradoras
Portabilidade de software Containers (Docker) Deploy em qualquer cloud
SO legado em hw moderno Emulação (QEMU) DOS em x86 moderno
Aplicações portáveis JVM / .NET CLR Java, C#
Exercícios
Questões dissertativas
Explique os três requisitos formais de Popek e Goldberg para um VMM (fidelidade, desempenho, segurança/controle). Por que as CPUs Intel x86 originais não os satisfaziam, e como VT-x resolveu o problema?
O que é uma VCPU? Qual é a analogia entre VCPU/VMM e PCB/SO?
Explique o mecanismo de trap-and-emulate. Quais são os dois tipos de instruções do ponto de vista do VMM, e como cada uma é tratada?
Compare Hipervisor Tipo 1 e Tipo 2 em termos de arquitetura, desempenho, facilidade de uso e caso de uso ideal. Dê dois exemplos concretos de cada tipo.
Explique a diferença entre virtualização completa e paravirtualização. Qual a vantagem e a desvantagem de cada uma? Por que a paravirtualização se tornou menos necessária para CPU após 2005?
O que é migração dinâmica (live migration)? Descreva as etapas do processo e dois casos de uso concretos em data centers.
Compare VMs e containers em termos de isolamento, overhead, portabilidade e caso de uso. Quando você escolheria cada um?
Explique o conceito de tabelas de páginas aninhadas (NPT). Por que são necessárias em virtualização e qual problema de desempenho elas introduzem?
Qual é a diferença entre virtualização e emulação? Por que emulação tem overhead muito maior? Dê um exemplo de uso legítimo de emulação.
Como a virtualização viabilizou a computação em nuvem? Explique o modelo de negócio IaaS (Infrastructure as a Service) e como VMs são a unidade fundamental de alocação.
Quiz de múltipla escolha
1. Qual dos três requisitos de Popek e Goldberg um sistema que executa instruções sensíveis sem trap em modo usuário viola?
- a)Fidelidade — o ambiente não é idêntico ao hardware real
- b)Desempenho — as instruções ficam mais lentas
- c)Segurança/controle — o VMM perde controle pois não intercepta as instruções
- d)Isolamento — as VMs podem se comunicar diretamente
- e)Disponibilidade — o sistema pode travar
2. A VCPU é para o VMM como o PCB é para o SO. Qual a analogia correta entre os dois?
- a)VCPU armazena o estado de um processo; PCB armazena o estado de uma VM
- b)VCPU representa o estado completo da CPU como o convidado acredita que seja; PCB representa o estado de um processo no SO
- c)VCPU e PCB são estruturas idênticas com nomes diferentes
- d)VCPU é usada para scheduling; PCB é usada para gerência de memória
- e)VCPU existe apenas em hipervisores Tipo 0; PCB existe apenas em Tipo 1
3. No mecanismo trap-and-emulate, o que acontece quando um processo dentro de uma VM tenta executar uma instrução privilegiada (ex.: modificar CR3)?
- a)A instrução é executada diretamente no hardware físico
- b)A VM inteira é pausada permanentemente
- c)A CPU gera VM exit, transferindo controle ao VMM, que emula o efeito na VCPU e devolve controle ao convidado via VM entry
- d)O hipervisor Tipo 2 do SO hospedeiro intercepta antes do VMM
- e)Uma exceção de proteção é lançada e o processo convidado termina
4. Qual a principal diferença entre Hipervisor Tipo 1 e Tipo 2?
- a)Tipo 1 usa paravirtualização; Tipo 2 usa virtualização completa
- b)Tipo 1 executa diretamente no hardware (bare metal); Tipo 2 executa como aplicação sobre um SO hospedeiro
- c)Tipo 1 suporta apenas Linux convidado; Tipo 2 suporta qualquer SO
- d)Tipo 1 é apenas software; Tipo 2 requer suporte de hardware
- e)Tipo 1 tem apenas uma VM; Tipo 2 pode ter múltiplas VMs
5. Por que a tradução binária foi necessária antes do VT-x para virtualizar x86?
- a)Porque CPUs x86 não tinham modo kernel antes do VT-x
- b)Porque certas instruções sensíveis do x86 não geravam trap em modo usuário, tornando trap-and-emulate impossível
- c)Porque x86 não suportava múltiplas VMs sem tradução
- d)Porque a tradução binária é mais rápida que trap-and-emulate em qualquer arquitetura
- e)Porque VMs precisam de código compilado em uma ISA especial
6. Qual das opções descreve corretamente a paravirtualização?
- a)O convidado executa código binário inalterado sem saber que está virtualizado
- b)O kernel do SO convidado é modificado para usar hypercalls em vez de instruções privilegiadas, cooperando com o VMM
- c)O VMM emula hardware diferente do hospedeiro (ISA diferente)
- d)Containers que compartilham o kernel hospedeiro
- e)Virtualização onde o hipervisor está no firmware
7. Um container Docker e uma VM rodam a mesma aplicação Node.js. Qual consome menos memória e por quê?
- a)VM — porque tem acesso direto ao hardware, sem overhead de tradução
- b)Container — não carrega um SO completo, apenas as bibliotecas necessárias para a aplicação
- c)São equivalentes — ambos carregam as mesmas bibliotecas
- d)Container — porque usa compressão de memória automática
- e)VM — porque o hipervisor otimiza o uso de memória com balloon driver
8. A migração dinâmica move uma VM de servidor A para servidor B. Qual o mecanismo que permite fazer isso sem interromper conexões de rede ativas?
- a)O endereço IP da VM muda para o servidor B — os clientes reconectam automaticamente
- b)As conexões são fechadas e reabertas transparentemente pelo VMM
- c)A memória é copiada iterativamente enquanto a VM executa; após VM entry no servidor B, o endereço MAC/IP permanece o mesmo e um ARP gratuito atualiza as tabelas dos switches
- d)O servidor A mantém o IP e faz proxy de todas as requisições para o servidor B
- e)A migração só é possível quando não há conexões ativas
9. Qual dos seguintes é um exemplo de Hipervisor Tipo 0?
- a)VMware Workstation
- b)Oracle VirtualBox
- c)VMware ESXi
- d)IBM LPARs (Logical Partitions em mainframes)
- e)Docker
10. Por que um TLB miss é mais caro em um ambiente virtualizado do que em hardware nativo?
- a)Porque o VMM adiciona um passo extra de verificação de segurança em cada TLB miss
- b)Porque a CPU precisa percorrer tanto a tabela de páginas do convidado quanto a tabela do VMM (NPT), totalizando até 24 acessos à memória em vez de 4
- c)Porque VMs não têm cache L1 disponível para a tradução de endereços
- d)Porque o VMM desabilita o TLB para garantir isolamento entre convidados
- e)Porque cada TLB miss gera um VM exit automático que o VMM precisa processar
Referências
Principais (essenciais)
- SILBERSCHATZ, A.; GALVIN, P. B.; GAGNE, G. Fundamentos de Sistemas Operacionais. 9. ed. LTC, 2015.
- §16.1 — Visão Geral
- §16.2 — História (VM/370, requisitos Popek-Goldberg)
- §16.3 — Benefícios e Recursos
- §16.4 — Blocos de Construção (VCPU, trap-and-emulate, tradução binária, NPT)
- §16.5 — Tipos de VMMs (Tipo 0, 1, 2, paravirtualização, JVM, emulação)
Aprofundamento (opcionais)
- POPEK, G. J.; GOLDBERG, R. P. "Formal Requirements for Virtualizable Third Generation Architectures." CACM, v. 17, n. 7, 1974. (artigo fundamental da área)
- BARHAM, P. et al. "Xen and the Art of Virtualization." SOSP, 2003. (paravirtualização moderna)
- TANENBAUM, A. S. Sistemas Operacionais Modernos. 4. ed. Pearson, 2016. §7.12 — Máquinas Virtuais.
Recursos Complementares
Opcional — Vídeos para reforçar os conceitos desta aula.
25:00:00Operating Systems — Full Course (25h)
freeCodeCamp.org
Para esta aula, foque no módulo Virtual Machines dentro do curso completo.