1. O que é virtualização
Virtualização é a técnica de criar múltiplos computadores independentes em cima de um único hardware físico. Cada um com seu próprio SO, suas próprias dependências, seu próprio espaço de falha. O que acontece em um não afeta os outros.
O valor central não é economizar hardware, é isolamento. Antes da virtualização, isolar ambientes significava um servidor físico por ambiente: caro, lento de provisionar e difícil de gerenciar. Virtualização resolve isso sem abrir mão do isolamento. Você tem ambientes completamente independentes, só que todos no mesmo ferro.
Na prática isso significa:
- Uma VM pode travar ou ser comprometida sem afetar as outras
- Cada ambiente pode ter SOs, versões de libs e configurações completamente diferentes sem conflito
- O estado inteiro de uma VM pode ser congelado, clonado ou restaurado a qualquer momento
2. Como funciona
O que torna isso possível é uma camada de software chamada hypervisor, também conhecido como VMM (Virtual Machine Monitor).
O hypervisor senta entre o hardware físico e as VMs. Ele intercepta todo acesso ao hardware e entrega para cada VM uma versão virtualizada dos recursos: CPU virtual, memória virtual, disco virtual, rede virtual. A VM não sabe que está num ambiente virtualizado. Ela enxerga hardware como se fosse seu.
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ VM 1 │ │ VM 2 │ │ VM 3 │
│ (Linux) │ │ (Windows) │ │ (Linux) │
├─────────────┴──┴─────────────┴──┴─────────────┤
│ Hypervisor │
│ intercepta · traduz · isola · agenda │
├────────────────────────────────────────────────┤
│ Hardware físico │
│ CPU · RAM · Disco · Rede │
└────────────────────────────────────────────────┘
Quando uma VM tenta executar uma operação privilegiada (acessar memória, falar com um dispositivo, modificar configurações do processador), o hypervisor intercepta, processa e devolve o resultado simulado. Para a VM, foi uma operação normal.
3. Tipo 1 vs Tipo 2
Existem dois modelos de hypervisor, e a diferença está em onde ele vive.
Tipo 1 (bare-metal)
O hypervisor roda diretamente no hardware, sem nenhum SO por baixo. Ele é o sistema. O servidor inicializa direto nele, sem Windows, sem Linux, sem área de trabalho.
O gerenciamento é feito remotamente, de outro computador, via interface web ou linha de comando. Você cria e configura VMs de lá.
Exemplos: VMware ESXi, Microsoft Hyper-V, KVM. Usado em: servidores de produção, data centers, nuvem.
Tipo 2 (hosted)
O hypervisor roda como um programa dentro de um SO convencional. O SO host faz a ponte com o hardware.
Exemplos: VirtualBox, VMware Workstation. Usado em: desenvolvimento local, testes, uso pessoal.
A diferença prática é overhead e propósito. Tipo 1 tem acesso direto ao hardware e é o que sustenta ambientes de produção. Tipo 2 é mais fácil de usar mas tem uma camada a mais por baixo.
4. O que vive dentro de uma VM
Uma VM é, na essência, um conjunto de arquivos no disco do servidor.
/vms/minha-vm/
├── minha-vm.vmx ← configuração (CPU, RAM, rede)
├── minha-vm.vmdk ← disco virtual (pode ter centenas de GB)
└── minha-vm.nvram ← estado do BIOS virtual
Dentro desse disco virtual vive um SO completo: kernel, libs, configurações, dados, aplicações. A VM não compartilha nada disso com o host ou com outras VMs.
Por ser um arquivo, algumas operações que seriam complexas num servidor físico ficam triviais:
- Snapshot: congela o estado inteiro da VM num momento. Você pode voltar para aquele ponto a qualquer hora.
- Clone: copia o arquivo e você tem uma VM idêntica em segundos.
- Migração: mover uma VM entre servidores físicos é mover o arquivo pela rede. Em ambientes enterprise isso acontece com a VM ainda rodando, sem downtime.
5. Rede
Cada VM tem sua própria interface de rede virtual, com endereço MAC e IP próprios. O hypervisor cria um switch virtual em software que conecta essas interfaces, o mesmo papel que um switch físico faz com cabos.
Existem três modos principais de rede:
Bridge
A VM ganha um IP diretamente do roteador da rede, igual a qualquer dispositivo físico. Para outros computadores na rede, ela aparece como uma máquina separada. Acesso direto nos dois sentidos.
Usado quando a VM precisa ser acessível na rede local ou exposta para fora.
NAT
O hypervisor age como roteador para a VM. Ela tem um IP numa rede interna privada e acessa a internet pelo IP do host. De fora parece o mesmo IP do host e a VM fica invisível.
Usado quando a VM só precisa acessar a internet, sem ser acessível por outros.
Host-only
Rede fechada entre o host e as VMs. Sem internet, sem rede local. Isolamento total.
Usado para testar comunicação entre VMs sem expor nada para fora.
6. VM vs Docker vs Kubernetes
Os três resolvem problemas parecidos mas em níveis diferentes. Não são concorrentes: na prática coexistem em camadas.
VM: isola o SO
Cada VM tem seu próprio kernel. O isolamento é total: falha, segurança, dependências. Você pode rodar SOs completamente diferentes no mesmo hardware. O custo é peso: cada VM carrega um SO inteiro, ocupa GBs e leva minutos para iniciar.
Docker: isola o processo
Containers compartilham o kernel do host. O isolamento é feito via recursos do Linux: namespaces (cada container enxerga só seus próprios processos e arquivos) e cgroups (limita quanto CPU e memória cada container pode usar).
O resultado é muito mais leve: containers sobem em segundos, ocupam MBs. A troca é que todos os containers precisam ser compatíveis com o kernel do host. Você não roda Windows em cima de Linux sem uma VM por baixo.
Na rede, containers compartilham o IP do host e se diferenciam por porta. Internamente têm IPs privados, mas invisíveis para fora.
Kubernetes: orquestra containers
Kubernetes não substitui Docker, ele senta em cima dele. Resolve o problema de operar muitos containers em muitos servidores: em qual servidor um container vai rodar, o que fazer se morrer, como distribuir tráfego, como escalar.
Como os três convivem na prática
Hardware físico
└── Hypervisor (Tipo 1)
└── VM (Linux)
└── Docker Engine
├── Container A (app)
├── Container B (banco)
└── Container C (cache)
↑
Kubernetes orquestra
isso em N servidores
O servidor físico roda um hypervisor. O hypervisor cria VMs. Dentro das VMs roda Linux com Docker. O Kubernetes coordena os containers entre várias VMs. Cada camada resolve um problema diferente.
Referências
Vídeos para aprofundar o estudo: