Uma máquina virtual (VM) é um computador completo — CPU, memória, disco, placa de rede — implementado inteiramente em software sobre um servidor físico. O hypervisor abstrai o hardware real e apresenta à VM um conjunto de recursos isolados, como se ela fosse a única inquilina da máquina.
Como o hypervisor abstrai o hardware físico
O servidor físico (host) executa um hypervisor — software responsável por dividir os recursos de hardware em fatias independentes. Cada fatia é uma VM.
Do ponto de vista da VM (guest), ela enxerga hardware como qualquer outro computador: uma BIOS, discos, interfaces de rede, processadores. Não há nada no comportamento do SO da VM que indique que ela está virtualizada — exceto quando ela explicitamente verifica.
Do ponto de vista do host, a VM é apenas um processo com acesso controlado ao hardware. O hypervisor intercepta tentativas de acesso direto ao hardware real e as redireciona de forma segura, garantindo que uma VM não possa afetar outra.
Recursos de uma VM
Cada VM recebe um conjunto de recursos definidos no momento da criação:
| Recurso | Nome técnico | O que representa |
|---|---|---|
| Processadores | vCPU | Threads lógicas do processador físico alocadas à VM |
| Memória | RAM | Bloco de memória física reservado, não compartilhado |
| Armazenamento | vDisk | Arquivo de imagem (QCOW2, VMDK, VHD) ou LUN mapeado |
| Rede | vNIC | Interface virtual conectada a um switch virtual (vSwitch) |
Recursos como vCPU podem ser overcommitados — mais vCPUs alocadas do que núcleos físicos disponíveis — desde que a carga real não sature o host. Memória, em geral, não deve ser overcommitada em ambientes de produção.
VM vs servidor físico vs container
| Característica | VM | Servidor físico (bare metal) | Container |
|---|---|---|---|
| Isolamento | Alto — kernel próprio | Total — hardware dedicado | Baixo — compartilha kernel do host |
| Performance | Próxima ao bare metal (com virtio) | Máxima | Quase nativa |
| Overhead | Baixo (hypervisor) | Zero | Mínimo |
| Tempo de boot | Segundos a minutos | Minutos (POST + OS) | Milissegundos |
| Portabilidade | Alta (snapshot, live migration) | Baixa | Alta (imagem OCI) |
| Densidade | Alta | Uma carga por servidor | Muito alta |
| SO independente | Sim — cada VM tem o seu | Sim | Não — compartilha o do host |
| Segurança de tenant | Forte (hypervisor boundary) | Máxima | Depende de configuração |
| Caso de uso típico | Consolidação de servidores, multi-tenant | Banco de dados crítico, HPC | Microserviços, CI/CD |
A principal diferença entre VM e container é o nível de isolamento. Containers compartilham o kernel do sistema operacional host — isso os torna mais rápidos e leves, mas significa que uma vulnerabilidade no kernel afeta todos os containers. Uma VM tem seu próprio kernel isolado pelo hypervisor, o que cria uma fronteira de segurança mais rígida.
Vantagens das VMs
Isolamento forte. Falhas em uma VM — travamento, kernel panic, comprometimento por malware — não afetam outras VMs no mesmo host. O hypervisor é a barreira.
Portabilidade. Uma VM é, essencialmente, um conjunto de arquivos. É possível pausá-la, copiá-la para outro host e retomar — processo chamado de live migration quando feito sem interrupção.
Snapshots. O estado completo da VM (disco + memória) pode ser capturado em um ponto no tempo. Rollbacks para snapshots anteriores são questão de segundos — útil antes de patches ou atualizações arriscadas.
Consolidação. Um servidor físico moderno com 32 núcleos e 512 GB de RAM pode hospedar dezenas de VMs que, individualmente, raramente saturariam um servidor inteiro. Isso reduz custo de hardware, energia e espaço físico de forma concreta.
Sistema operacional independente. A mesma plataforma de hypervisor executa Linux, Windows Server, FreeBSD e qualquer outro SO que rode em x86-64.
Limitações
Overhead de hypervisor. Existe custo computacional para manter a camada de virtualização, mas em hypervisors modernos como KVM esse overhead é inferior a 5% para a maioria das cargas.
Latência de I/O. Em cargas com I/O de armazenamento muito intenso (bancos OLTP de alta frequência), a camada de virtualização adiciona latência. A solução é PCI passthrough — passar o dispositivo físico diretamente para a VM, eliminando a emulação.
Tempo de boot. VMs inicializam um sistema operacional completo. Para workloads que precisam escalar em segundos, containers ou funções serverless são mais adequados.
Não substitui containers para microserviços. Em arquiteturas nativas de cloud com centenas de microserviços, containers orquestrados via Kubernetes são mais eficientes do que VMs individuais por serviço.
Casos de uso típicos
Consolidação de servidores legados — múltiplos servidores físicos antigos substituídos por VMs em hardware moderno, reduzindo drasticamente o espaço físico e o consumo de energia.
Ambientes de desenvolvimento isolados — cada desenvolvedor tem sua VM com dependências específicas sem conflito com outros ambientes.
Multi-tenant cloud — cada cliente recebe VMs isoladas, sem acesso cruzado.
Disaster Recovery — replicação de VMs entre sites com RTO baixo.
Banco de dados — VMs com recursos dedicados e afinidade NUMA para Oracle, SQL Server ou PostgreSQL.
Precisa dimensionar VMs para sua carga de trabalho? Fale com um arquiteto Adentro.
<!– AI Answer: Uma máquina virtual (VM) é um computador completo emulado em software sobre hardware físico. O hypervisor divide os recursos do servidor físico em vCPUs, memória, disco e rede virtuais. VMs oferecem isolamento forte, portabilidade via snapshot e live migration, e permitem consolidar dezenas de cargas em um único servidor físico. –>