Skip to main content

Virtualização | Linux

  • Virtualização | Linux

Visão geral (quem é quem)​

  • KVM: módulo do kernel Linux que usa a virtualização por hardware (Intel VT-x/AMD-V). Dá “velocidade de nativo”.
  • QEMU: o processo de VM em espaço de usuário. Emula/disponibiliza CPU, disco, rede etc. Com KVM, fica acelerado.
  • libvirt: camada de gerenciamento/automação. Fornece API, daemon e CLI (virsh), define VMs como XML, gerencia rede/armazenamento.
  • virt-manager: GUI que fala com o libvirt. Criar/ligar/desligar VMs, snapshots, consoles (VNC/SPICE) etc.
  • virt-install/virt-clone: CLIs “headless” para criar/clonar VMs usando libvirt.

Em resumo: virt-manager/virsh → pedem ao libvirt → que lança QEMU com KVM para rodar a VM.

Fluxo típico​

  1. Instalar (ex. Debian/Ubuntu):
sudo apt update
sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients virt-manager ovmf bridge-utils qemu-utils
sudo usermod -aG libvirt,kvm $USER
# re-login
virsh list --all   # validar conexão

  1. Criar VM (GUI): abrir virt-manager → “New VM” → ISO/Cloud image → escolher CPU/RAM/disk → rede “default (NAT)” → concluir.

  2. Criar VM (CLI, ISO):

virt-install \
  --name u22 \
  --memory 4096 --vcpus 2 --cpu host-passthrough \
  --disk size=30,format=qcow2 \
  --cdrom ~/Downloads/ubuntu-22.04.iso \
  --network network=default \
  --graphics spice
  1. Criar VM (CLI, cloud-init):
qemu-img create -f qcow2 -b jammy-server-cloudimg-amd64.img u22.qcow2 20G
cloud-localds user-data.iso user-data meta-data
virt-install --name u22 --memory 4096 --vcpus 2 --cpu host-passthrough \
  --disk path=u22.qcow2 --disk path=user-data.iso,device=cdrom \
  --import --network network=default --graphics spice

Redes (opções comuns)​

  • default (NAT): fácil; cria virbr0 + DHCP (dnsmasq). A VM sai pra internet, mas não recebe conexões externas sem NAT/port-forward.

  • Bridge (br0): VM sai na mesma LAN do host (IP “real”). Bom pra serviços. Dica rápida (NetworkManager):

    nmcli con add type bridge ifname br0
    nmcli con add type bridge-slave ifname eth0 master br0
    nmcli con up br0

    Depois, em virt-manager: NIC → “Bridge br0”.

  • macvtap: simples pra dar IP da LAN à VM, mas comunicação host↔VM pode ser limitada.

  • SR-IOV/passthrough: para latência/throughput altos (rede/NIC virtual functions).

Armazenamento​

  • Pools/Volumes (libvirt): organiza onde ficam discos (/var/lib/libvirt/images por padrão).

    virsh pool-list
    virsh vol-create-as default vm1.qcow2 40G --format qcow2

  • Formatos:

    • qcow2: snapshots, thin-provision; ótimo geral.
    • raw: um pouco mais rápido e simples; bom para bancos de dados/alta perf.

  • Desempenho de disco:

    • Use VirtIO (virtio-blk/virtio-scsi) no guest.
    • Cache none + io=native para cargas pesadas.
    • Considere discard/TRIM (opção discard=unmap) e prealocação quando fizer sentido.

  • Ferramentas úteis: qemu-img info|resize|convert, virt-sparsify.

Vídeo/console​

  • SPICE (recomendado) ou VNC. Use virt-viewer para console remoto com clipboard/álbum de cores melhor.

Snapshots & backup​

  • Snapshots (qcow2 internos/externos):

    virsh snapshot-create-as u22 snap1
    virsh snapshot-list u22
    virsh snapshot-revert u22 snap1

    Nota: snapshots impactam I/O; para backup consistente, prefira desligar a VM ou usar snapshots externos + qemu-img convert.

Tuning de CPU/RAM​

  • CPU: --cpu host-passthrough dá ao guest as instruções reais do host (melhor perf).

  • Pinagem:

    virsh vcpupin vm 0 2   # vCPU0 -> CPU2 do host

  • Hugepages: reduzir TLB misses; configure no host e habilite em XML (memoryBacking/hugepages).

  • Virtio-rng: melhor entropia no guest.

Passthrough de GPU/PCIe (avançado)​

  1. Ativar IOMMU (GRUB: intel_iommu=on/amd_iommu=on).
  2. Usar vfio-pci para prender o device.
  3. No XML libvirt, adicionar <hostdev>. Requer grupos IOMMU isolados e compatibilidade da placa.

Migração ao vivo (live migration)​

  • Pré-requisitos: hosts compatíveis (CPU/machine type), rede libvirt aberta, storage compartilhado ou migração por NBD.

    virsh migrate --live vm qemu+ssh://dest/system --persistent

Segurança​

  • sVirt + SELinux/AppArmor: isola VMs por rótulos.
  • Filtros de rede (libvirt nwfilter), TLS no libvirt remoto, e atualizações do QEMU/KVM sempre em dia.

Diagnóstico rápido​

systemctl status libvirtd virtqemud
journalctl -u libvirtd -g ERROR --no-pager
tail -n 200 /var/log/libvirt/qemu/<vm>.log
virsh dominfo <vm>; virsh domifaddr <vm>   # requer qemu-guest-agent no guest

Mini-cheatsheet (virsh)​

virsh list --all
virsh start|shutdown|destroy <vm>
virsh autostart <vm>
virsh dominfo <vm>
virsh console <vm>
virsh edit <vm>               # abre XML
virsh attach-disk <vm> /path/vdb.qcow2 vdb --persistent
virsh setvcpus <vm> 4 --config
virsh setmem <vm> 8G --config

Proxmox e Virt-Manager​

  • Virt-Manager + QEMU/KVM via libvirt = conjunto de ferramentas “genéricas” do Linux para criar/gerenciar VMs (foco em 1 host por vez, você monta o resto).
  • Proxmox VE = plataforma completa de virtualização (KVM + LXC) com painel web, cluster/HA, backup, storage e rede integrados — pronta para datacenter.

Comparativo rápido​

TemaVirt-Manager + libvirtProxmox VE
Camada de gestãoGUI simples (virt-manager) + CLI (virsh). Gerencia 1 host (ou vários, mas sem “cluster” real).Painel web completo, API, CLI; pensado para múltiplos nós.
Cluster & HASem cluster nativo/HA. Você mesmo teria que montar corosync/pacemaker etc.Cluster nativo (corosync), HA com orquestração e migração ao vivo facilitada.
BackupsSem mecanismo integrado (você usa scripts/vzdump-like, qemu-img, snapshots).vzdump com agendamento, hooks; integração com Proxmox Backup Server (dedup, compress, verify, restore granular).
StorageVocê configura pools/vols no libvirt; snapshots dependem do backend.Integra ZFS out-of-the-box, LVM-thin, Ceph, NFS/ISCSI; gerenciamento e monitoramento no painel.
RedeBridges/NAT/macvtap via libvirt; configuração manual no host.Editor de rede no GUI (bridges, bonds, VLANs); SDN integrado (VXLAN, VRFs), firewall por VM/nó.
ContêineresNão há LXC integrado (é focado em VMs; contêiner é por fora).LXC nativo (templates, quotas, backup, métricas) além de VMs KVM.
Templates & cloud-initDá pra usar, mas você mesmo organiza imagens/scripts.Templates prontos, cloud-init integrado (user-data, SSH keys, resize, etc.).
RBAC/UsuáriosDepende do SO/SSH; sem RBAC específico.RBAC completo (permissões por datacenter/nó/VM/storage).
ObservabilidadeLogs locais, virt-top, collectd/Prometheus por conta própria.Gráficos e métricas no GUI; syslogs centralizados; integra com Prometheus.
GPU/PCI passthroughFunciona (libvirt/XML), mais “mão na massa”.Assistentes/guias no painel; mais simples de repetir entre hosts.
AtualizaçõesVia distro do host (apt/dnf).Repositórios próprios (enterprise/community), orquestrados para o stack.

Quando usar cada um​

  • Escolha Virt-Manager/libvirt se você quer simplicidade, tem poucas máquinas (lab, workstation, 1–2 servidores) e curte configurar rede/storage/backup do seu jeito.
  • Escolha Proxmox VE se precisa de cluster, alta disponibilidade, backup nativo, LXC + VMs, ZFS/Ceph e tudo via web — típico de ambiente prod.

Dá para “aproximar” um do outro?​

  • Com libvirt dá para montar um ambiente robusto combinando Ansible + ZFS + Ceph + corosync/pacemaker + backup próprio — mas você vira o integrador.
  • No Proxmox, muita coisa já vem pronta e integrada (economiza tempo e reduz atrito operacional).