Informações importantes

Este documento foi criado usando como bases algumas fontes de conhecimento, tentei mesclar e deixar o mais claro possível para o leitor, revisando e pegando o que tinha de melhor nessas fontes de conhecimento, tentando deixar esse documento o mais prático possível, mas sem dispensar a teoria que é de extrema importância.

Todas as fontes usadas estão no final do tutorial na sessão Fontes, mas você verá que existem algumas fontes que aparecem bastante lá, isso porque além das muitas fontes da Internet que foram usadas, algumas são a base para a criação deste documento e são de extrema recomendação minha, são elas: Guia de Administração de Virtualização da RedHat e Mastering KVM Virtualization.

O documento vai se basear no uso do comando virsh, apesar de ser possível gerenciar tudo via interface gráfica, vou evitar o uso da mesma, já que no dia a dia é quase certeza que a maioria só terá a CLI para gerenciar as máquinas virtuais.

Introdução

O Kernel-based Virtual Machine (KVM) é uma tecnologia de virtualização open source. Ele é integrado ao Linux, ou seja, é possível transformar o Kernel Linux em um hypervisor, permitindo assim que o sistema execute vários ambientes virtuais, conhecidos com guest ou máquinas virtuais. O KVM é um hypervisor do tipo 1 (bare-metal), embora precise de um sistema operacional Linux para funcionar, ele é implementado no Kernel Linux.

O KVM faz parte do Linux e foi incluído na versão 2.6.20 do Kernel!

Embora o KVM transforme o kernel do Linux em um hipervisor completo, ele foca especificamente na virtualização da CPU e pela execução das vCPUs, enquanto a memória e os dispositivos são gerenciados em conjunto com o kernel Linux e ferramentas em espaço de usuário, como o QEMU.

Principais Conceitos sobre Virtualização

A virtualização é uma tecnologia que possibilita a criação ambientes virtuais, independentes do hardware físico do computador. Isso possibilita a execução de sistemas operacionais, aplicativos e recursos de computação em múltiplas instâncias virtuais dentro de um único hardware. O principal objetivo da virtualização é distribuir os recursos do hardware hospedeiro com as máquinas virtuais, que são: CPU, Memória, Armazenamento e Rede (também conhecidos como Core Four, são os recursos compartilhados).

É importante que a máquina virtual funcione exatamente como uma máquina física (que não está sendo virtualizada), além disso, o administrador têm o controle total do hypervisor e pode virtualizar qualquer Sistema Operacional, independente do S.O usado pelo hypervisor.

::::tip O que é um hypervisor? Um hypervisor (ou Virtual Machine Monitor - VMM) é um software que permite a execução simultânea de múltiplos sistemas operacionais em um único hardware, facilitando a virtualização, ou seja, é o servidor hospedeiro que vai compartilhar seu hardware com as máquinas virtuais. ::::

Emulação versus Virtualização

Quanto trabalhamos com máquinas virtuais, muitas vezes, temos a emulação e virtualização trabalhando lado a lado e nem percebemos. Na virtualização, o sistema operacional convidado (máquina virtual) deve ser compatível com a arquitetura do hardware do host, pois suas instruções são executadas diretamente pela CPU física. Por isso, não é possível virtualizar um sistema ARM em hardware AMD64. Podemos fazer isso funcionar graças a emulação.

Já na emulação, as instruções do sistema convidado não são executadas diretamente pela CPU física. Em vez disso, a CPU executa um código intermediário que interpreta ou traduz essas instruções para a arquitetura do host. Por envolver essa camada adicional de tradução, a emulação tende a apresentar desempenho inferior ao da virtualização.

Hardware Virtual Machine - HVM

O HVM (em Português Virtualização de Hardware), também conhecido como Full Virtualization, é um tipo de virtualização no qual o sistema operacional convidado é executado sem qualquer modificação. Nesse modelo, o acesso aos recursos de hardware como CPU, memória, armazenamento e dispositivos de entrada e saída é controlado pelo hypervisor.

Nesse tipo de virtualização, o sistema operacional da máquina virtual não tem conhecimento de que está sendo executado em um ambiente virtualizado. Ele funciona como se estivesse em hardware físico dedicado, permitindo a execução de sistemas operacionais que não foram originalmente projetados para virtualização.

O HVM utiliza extensões de virtualização assistidas por hardware (Hardware-Assisted Virtualization) para alcançar desempenho próximo ao nativo. Essas extensões são fornecidas pela própria CPU, como Intel VT-x (VMX) e AMD-V (SVM), permitindo que instruções do sistema convidado sejam executadas diretamente no processador físico de forma segura e controlada pelo hypervisor.

Paravirtualização - PV

Na paravirtualização, o sistema operacional da máquina virtual é modificado para saber que está sendo executado em um ambiente virtualizado. Com isso, ele passa a interagir diretamente com o hypervisor por meio de interfaces específicas, reduzindo a sobrecarga de virtualização e melhorando a eficiência da comunicação entre o guest e o host.

Nesse modelo, não é obrigatório que o hardware possua extensões de virtualização assistida por hardware, como no HVM. No entanto, o kernel do sistema convidado precisa oferecer suporte aos mecanismos de paravirtualização e às interfaces de integração com o hypervisor, algo que já vem habilitado por padrão em sistemas Linux modernos.

Um detalhe importante é que, na paravirtualização, o sistema operacional não acessa dispositivos de hardware virtualizados de forma transparente. Em vez disso, ele realiza chamadas explícitas ao hypervisor, conhecidas como hypercalls, delegando a ele operações como acesso a disco, rede e gerenciamento de memória.

egrep -o -m1 '(vmx|svm)' /proc/cpuinfo

Resumindo, no HVM a máquina virtual acredita que está sendo executada em hardware físico. Já na PV, ela sabe que está sendo virtualizada. O que muda é a forma de acesso aos recursos, que no HVM ocorre de forma transparente, enquanto na PV é feita por meio de chamadas explícitas ao hypervisor.

Tipos de hypervisors

Os hypervisors são tradicionalmente divididos em dois tipos. O tipo 1, comumente conhecido como hypervisor nativo ou bare-metal, é executado diretamente sobre o hardware físico do host e é responsável por gerenciar a execução dos sistemas operacionais convidados.

Nesse modelo, o hypervisor assume o controle direto dos recursos de hardware, como CPU, memória e dispositivos de entrada e saída, realizando o isolamento e o agendamento das máquinas virtuais sem a necessidade de um sistema operacional host convencional.

Alguns exemplos de hypervisors do tipo 1 são: VMware vSphere/ESXi, Microsoft Hyper-V, Oracle VM Server, Xen, KVM.

Já o tipo 2, também conhecido como hosted, é executado sobre um sistema operacional convencional. Nesse modelo, o hypervisor funciona como uma aplicação de software, utilizando os serviços do sistema operacional host para acessar os recursos de hardware e gerenciar as máquinas virtuais.

Nesse tipo de hypervisor, o sistema operacional host continua sendo responsável pelo controle direto do hardware, enquanto o hypervisor atua como uma camada intermediária responsável pela criação, execução e isolamento das máquinas virtuais.

Normalmente, o gerenciamento do hypervisor em si é simples, envolvendo apenas a instalação e algumas configurações iniciais. A partir desse ponto, a maior parte do gerenciamento passa a ser feita diretamente nas máquinas virtuais, já que a base fornecida pelo sistema operacional host permanece estável.

Um hypervisor do tipo 2 é mais usado por usuários individuais que desejam executar múltiplos sistemas operacionais em um computador pessoal para fins de testes, aprendizado ou desenvolvimento. Mesmo assim, também podem ser encontrados em pequenos ambientes corporativos.

Alguns exemplos de hypervisors do tipo 2 são: Oracle VirtualBox e VMWare Workstation.

QEMU - Quick Emulator

O Quick Emulator, ou simplesmente QEMU, é um dos principais componentes da virtualização e emulação. Sua função é fornecer uma plataforma capaz de emular hardware completo ou atuar como frontend de virtualização, dependendo do modo de execução utilizado.

Quando utilizado sozinho, o QEMU funciona como um emulador, simulando uma CPU e demais componentes de hardware em software. Nesse modo, existe uma camada de tradução entre o sistema convidado e o hardware físico, permitindo a execução de sistemas operacionais projetados para arquiteturas diferentes, porém, existe um impacto significativo no desempenho.

Já quando utilizado em conjunto com o KVM, o QEMU passa a delegar a execução da CPU ao kernel Linux, utilizando virtualização assistida por hardware. Nesse cenário, o QEMU permanece responsável pela criação da máquina virtual, pela definição do layout de memória e pela emulação ou paravirtualização de dispositivos como rede, armazenamento e firmware, enquanto o KVM executa as instruções do sistema convidado diretamente na CPU física.

Resumindo, o QEMU é responsável pela emulação de dispositivos, como redes, discos, placas de vídeo e outros componentes de hardware, que são necessários para que as máquinas virtuais funcionem corretamente. Ele fornece uma camada de abstração que permite que as máquinas virtuais acessem esses dispositivos, mesmo que eles não estejam fisicamente presentes no hardware real.

Já o KVM vai fornece recursos de virtualização de hardware, como HVM (Hardware Virtual Machine), para o QEMU. Isso permite que o QEMU execute as máquinas virtuais de forma mais eficiente, aproveitando as extensões de virtualização do processador subjacente. Com o KVM, as máquinas virtuais podem ter um desempenho melhor e um acesso mais direto aos recursos de hardware do sistema hospedeiro.

A imagem abaixo demonstra as camadas no Sistema com uso do Xen, KVM e apenas QEMU. A imagem é disponibilizada por researchgate.net.

QEMU Image

Para executar máquinas virtuais, o QEMU precisa de um local para armazenar os dados do sistema convidado. Esse local geralmente é um arquivo chamado de image (imagem, em Português Brasileiro), que atua como um dispositivo de bloco virtual, equivalente a um disco rígido para a máquina virtual.

Em uma explicação simples, uma image pode ser entendida como o disco da máquina virtual, onde o sistema operacional irá criar partições, filesystems e armazenar seus dados. Podemos criar um disco virtual utilizando o QEMU com o comando abaixo, embora não seja necessário criar o disco primeiro, esse é apenas um exemplo.

# Criando um disco do tipo raw:
$ qemu-img create -f raw ubuntu.img 15G 

# Criando um disco do tipo qcow2:
qemu-img create -f qcow2 ubuntu.qcow2 20G

Para obter informações sobre a imagem criada:

$ qemu-img info ubuntu.img 
image: ubuntu.img
file format: raw
virtual size: 15 GiB (16106127360 bytes)
disk size: 4 KiB

# Verificando o tamanho do "disco":
$ du -hs ubuntu.img 
4,0K	ubuntu.img

O qemu-img é um utilitário que permite criar, converter e modificar imagens de convidados, é espcialmente útil quando precisamos redimensionar tamanho de disco. Vamos ver abaixo os dicos mais comuns e que são suportados pelo QEMU.

Com o qemu-img ainda podemos converter imagens de disco entre diferentes formatos. Isso é bom quando temos uma imagem de um sistema convidado gerado por exemplo no Virtual Box e queremos utiliza-lá no KVM. Por exemplo, para converter uma imagem no formato raw para qcow2, podemos utilizar o seguinte comando:

qemu-img convert -f raw -O qcow2 original_disk.img new_disk.qcow2

Caso a imagem tenha sido criada no formato VDI, mais comum no VirtualBox, o comando ficaria assim:

qemu-img convert -f vdi -O qcow2 disk.vdi disk.qcow2

Por fim, ainda com o qemu-img podemos usar o argumento check para verificar se o arquivo da imagem está íntegra ou se houve corrupções nos metadados do formato utilizado.

# Verificar integridade:
$ qemu-img check zfsdisk5.qcow2
No errors were found on the image.
163840/163840 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 10739318784

Criando máquinas virtuais com QEMU

O comando qemu-system-x86_64 é um utilitário usado para criar os ambientes emulados ou virtualizados direto pelo QEMU. É graças a esse comando que podemos ter um modelo virtual completo de uma máquina, simulando não apenas o processador, mas também a memória e uma vasta lista de dispositivos periféricos, como controladores de disco, placas de vídeo, portas USB e interfaces de rede.

Lembrando que se for usado sem o KVM, a máquina virtual será emulada e não virtualizada. Para virtualizar e obter o desempenho próximo ao nativo, é necessário usar as opções -enable-kvm ou -accel kvm.

qemu-system-x86_64 \
  -enable-kvm \
  -machine q35,accel=kvm \
  -cpu host \
  -smp 2 \
  -m 2G \
  -drive file=ubuntu.qcow2,if=virtio,format=qcow2 \
  -cdrom /home/bruno/Downloads/ubuntu-22.04.5-live-server-amd64.iso \
  -boot d \
  -netdev user,id=net0 \
  -device virtio-net-pci,netdev=net0 \
  -display gtk

As linhas -enable-kvm e -machine q35,accel=kvm ativam virtualização assistida por hardware, sem isso, o QEMU entra em emulação (TCG). A linha -cpu host expõe a CPU real para a VM e -smp 2 cria 2 vCPUs. A opção -m 2 define 2G de RAM.

Esse comando é bom para testes rápidos, já que ao finalizar o processo a VM “morre”. Todos os dados armazenados no disco continuam lá, mas você deve recriar a VM informando o disco a ser usado.

Definindo a Placa Mãe Virtual

Eu queria falar um pouco da opção -machine, mesmo que seja um pouco cedo para introduzir esse tema. Tanto no QEMU quanto no KVM vamos frequentemente ver alguma configuração que tenha a nomeclatura machine.

Essa opção é usada para definir o modelo da máquina virtual, o que essencialmente determina a arquitetura do barramento, o chipset e os recursos de hardware que estarão disponíveis para o sistema convidado. Abaixo podemos ver uma tabela com algumas das opções suportadas:

• PC

  É o padrão por ser compátivel com sistemas antigos. Ele utiliza o chipset i440fx, baseado em uma arquitetura mais antiga, com barramento PCI clássico e firmware do tipo BIOS legacy por padrão. Esse modelo é amplamente compatível com sistemas operacionais antigos e ambientes legados, mas não oferece suporte nativo a PCI Express.

  Por isso, recursos modernos como passthrough avançado, dispositivos PCIe e algumas funcionalidades recentes de virtualização ficam limitados ou indisponíveis. Ainda assim, é útil quando o objetivo é rodar sistemas mais antigos ou garantir máxima compatibilidade.

• q35

  O tipo de máquina q35 representa uma plataforma mais moderna e próxima do hardware atual. Ele utiliza o chipset Intel Q35, oferecendo suporte nativo a PCI Express, melhor integração com dispositivos modernos e maior compatibilidade com recursos avançados de virtualização, como PCI passthrough.

  Esse modelo funciona naturalmente com UEFI (via OVMF) e é o mais indicado para sistemas operacionais modernos, especialmente quando se deseja desempenho, suporte a hardware recente e configurações mais próximas de um ambiente físico real. Por esses motivos, o q35 é a configuração recomendada para novos ambientes e laboratórios atuais.

Basicamente, imagine que esse argumento (-machine) cria a placa mãe virtual e cada placa mãe terá recursos que outros tipos não possuem. Podemos usar os nomes abreviados como vimos acima ou os nomes completos. Para ver todas as opções disponíveis no sistema, podemos usar o comando qemu-system-x86_64 -machine help.

Definindo o Processador Virtual

Outra opção bastante vista é a -cpu ou alguma variação dela. Ela é usada para definir qual modelo de processador será apresentado ao sistema convidado. Ela não altera o fato de a CPU ser virtualizada por hardware quando o KVM está ativo, mas controla quais características, extensões e identificadores de CPU a máquina convidada irá enxergar.

Pense assim, enquanto o KVM é responsável por executar as instruções da máquina convidada diretamente na CPU física, a opção -cpu define como essa CPU será “vista” pela máquina virtual. Isso influencia compatibilidade, desempenho, suporte a instruções específicas e até a possibilidade de migração entre hosts diferentes.

• host

  Essa opção expõe para a máquina virtual a CPU física do host quase que integralmente, incluindo a maioria das extensões e recursos disponíveis no processador real. É a configuração que oferece melhor desempenho, já que o sistema convidado pode utilizar instruções avançadas, desde que existam no hardware.

  No entanto, por refletir fielmente a CPU do host, essa opção dificulta ou inviabiliza a migração da máquina virtual para outro servidor com CPU diferente. É ideal para ambientes locais, laboratórios ou servidores dedicados onde a VM não será migrada.

  Na prática, esse modo oferece desempenho muito próximo ao host-passthrough, mas com menos garantias de fidelidade absoluta. Ele costuma ser usado como uma opção prática quando se deseja bom desempenho sem se preocupar excessivamente com ajustes finos de CPU.

• Application Default

  O “aplicativo” como o virt-manager vai decidir automaticamente qual configuração usar. Normalmente ele escolhe algo seguro para inicializar a VM, mas quase sempre perde em otimização para migração ou desempenho.

• Hypervisor Default

  Nesse modo o QEMU escolhe automaticamente um modelo de CPU compatível. No geral é sempre algo como qemu64 ou kvm64. Esses modelos são bem genéricos, mas garantem alta compatibilidade com muitos hosts. O problema é que pode esconder várias extensões modernas do processador.

• host-model

  O modo host-model cria um modelo de CPU baseado no processador físico do host, mas com uma seleção mais conservadora de extensões. Algumas flags específicas ou instáveis podem ser ocultadas para aumentar a compatibilidade.

  Esse modo oferece um bom equilíbrio entre desempenho e portabilidade, sendo mais amigável para cenários onde existe a possibilidade de mover a VM entre hosts semelhantes, mas não idênticos.

• host-passthrough

  O modo host-passthrough expõe para a máquina virtual a CPU física do host de forma praticamente idêntica, incluindo todas as extensões, flags e instruções disponíveis no processador real. Nesse modo, não existe tentativa de mascarar ou adaptar recursos para compatibilidade, o que garante o máximo desempenho possível.

  Essa configuração é ideal quando a VM não precisa ser migrada para outros hosts com CPUs diferentes, pois qualquer diferença de microarquitetura pode impedir a migração ou até mesmo a inicialização da máquina virtual em outro ambiente. É a opção mais próxima de rodar diretamente em hardware físico.

• Modelos específicos de CPU

  O QEMU também permite especificar modelos concretos de processadores, como Haswell, Skylake, EPYC, entre outros. Nesse caso, o sistema convidado enxerga uma CPU que corresponde a uma microarquitetura específica, independentemente do processador real do host, desde que este suporte as instruções necessárias.

  Essa abordagem é muito usada em ambientes que exigem padronização de CPU, compatibilidade entre múltiplos hosts ou suporte consistente para migração ao vivo.

Assim como ocorre com a opção -machine, podemos usar nomes abreviados ou modelos completos. Para listar todas as opções de CPU disponíveis no sistema, basta executar o comando qemu-system-x86_64 -cpu help.