QEMU + KVM

Aprenda como configurar o QEMU/KVM para tirar máximo proveito, inclusive habilitar a aceleração gráfica 3D para máquinas virtuais Windows!

---

| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. Mais detalhes clicando aqui.

---

Introdução

Linux é sinônimo de liberdade. E dentro dessa liberdade temos a possibilidade de executar softwares do Windows com aceleração 3D de diversas maneiras.

Hoje, vou mostrar como configurar o QEMU em conjunto com o Módulo KVM para ter uma máquina virtual Windows, que acessa a placa de vídeo dando total aceleração 3D a games no Linux, evitando a configuração de um dual-boot!

1. O que é o QEMU?

O QEMU é um emulador e virtualizador de máquinas virtuais, de código aberto e gratuito.

Quando usado como um emulador de máquina, o QEMU pode executar sistemas operacionais e programas feitos para diferentes arquiteturas em seu computador, que normalmente é amd64 ou i386 (x64 e x86 bits). Usando a tradução dinâmica, quase o que o WINE faz porém a nível de hardware, obtém-se um desempenho muito próximo dos 95%, se considerar 100% um sistema nativamente instalado. – Inclusive é graças a isso que é possível rodar Android no sistema, semelhante ao que o Bluestacks faz no Windows.

Quando usado como um virtualizador, o QEMU alcança desempenho quase nato, executando o código convidado diretamente na CPU do sistema hospedeiro. O QEMU suporta a virtualização sob um leque de opções: seja com o hypervisor Xen ou usando o módulo nativo do kernel Linux chamado KVM. Ao usar o KVM, o QEMU, entre outras opções, pode virtualizar máquinas x86, servidores PowerPC, POWER de 64 bits, S390, ARM de 32 bits e 64 bits e arquitetura MIPS.

2. O que é KVM?

O KVM – Kernel-based Virtual Machine – é um hypervisor completo nativo no kernel Linux desde a versão 2.6.20, que contém extensões de virtualização tanto Intel-VT quanto AMD-V. Ele consiste em um módulo do kernel chamado kvm.ko, que fornece a infraestrutura de virtualização central e um módulo específico do processador, tanto kvm-intel.ko ou kvm-amd.ko.

Usando o KVM, é possível executar várias máquinas virtuais executando imagens Linux ou Windows. Cada máquina virtual possui hardware virtualizado separado da hospedeira: uma placa de rede, disco, placa de vídeo, etc.

O componente do Espaço de Usuário do KVM está incluído no QEMU principal desde a versão 1.3, motivo pelo qual é preferível fazer a mistura QEMU + KVM para virtualização a nível de hardware.

2.1 Hypervisor

Existem 2 tipos básicos de hypervisor:

• Tipo 1 – Este dá ás máquinas virtuais acesso direto ao hardware.
  Normalmente o KVM e o Xen permitem isso.
• Tipo 2 – Ele roda a máquina virtual numa camada acima de software, dando acesso limitado ao hardware.
  O exemplo mais popular é o VirtualBox

Portanto usaremos aqui um Tipo 1, que dá total acesso ao hardware permitindo passthrough, isto é, você terá na máquina virtual, acesso a partes pré-definidas pelo usuário ao hardware real. Com isso, um game executando num Windows XP virtualizado rodará com total aceleração 3D como se fosse um sistema nativo da máquina, enquanto seu Linux está ali rodando também como sistema principal.

O processo é descrito com foco em usuários que usam sistemas baseados em Debian porém a maior parte dos comandos podem ser feitos em outros sistemas como Fedora e CentOS, bastando fazer as devidas adaptações nos gerenciadores de pacotes.

3. Hardware

Até o passo da instalação do QEMU e configuração da máquina virtual é um processo relativamente simples. O problema maior está em configurar o KVM para transferir vídeo para a GPU nativa. Detalhe que é preferível que você tenha uma GPU dedicada, offboard, ou seja, NVIDIA ou AMD, para fazer uso do recurso.

Máquinas com GPU onboard, integrada, como quem usa Intel HD Graphics e Ryzen com VEGA terá problemas na execução do componente virtualizado. Até porque ele requer exclusividade no acesso para evitar conflito entre o kernel Linux e a máquina virtualizada seja ela qual for.

Além disso, uma vez definido, somente funcionará o vídeo e o som pela máquina virtual. Porém há um meio de, editando o menu GRUB, mudar isso durante o boot. Assim você terá o Linux normal e o com suporte a QEMU KVM!

3.1 Notebooks

Aqui chamo a atenção a quem utiliza notebooks com placa de vídeo dedicada e desejam fazer testes com o QEMU KVM.
Caso você use uma máquina convencional, gabinete, pule para o próximo item.

Os notebooks com placa de vídeo podem possuir 2 tipos de placa: iGPU e dGPU.
A iGPU é a placa Intel HD Graphics ou VEGA, existente máquinas Intel ou AMD.
Já a dGPU é a placa dedicada, seja ela Nvidia ou AMD, que você insere no slot PCI.
E temos notebooks que possuem uma, outra ou ambas!

Agora, para saber se seu notebook suporta passthrough, saiba que eles podem operar sob 2 modos: MUXED e MUXELESS. E você deve saber que modos são esses! Para entender isso, primeiramente, você deve conhecer como é a arquitetura de vídeo do seu notebook, de forma simples:

Abra o terminal no seu notebook e digite o seguinte comando:

$ lspci -nn

Procure sua placa de vídeo. Se for híbrido, Intel + Nvidia, procure as 2.
Veja como o sistema descreve ambas, essa descrição pode ser:

• 3D Controller
• VGA Compatible Controller

Um exemplo da saída desse comando:

01:00.0 3D controller [0302]: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1)
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:591b] (rev 04)

Com essa informação em mãos, descubro que:

• 3D Controller – Significa placa de vídeo sem multiplexador (Ela é MUXLESS).
  Ela não é uma placa controladora real, mas sim um suporte que reforça o poder da Intel. Tecnicamente a “placa de vídeo” é apenas um acelerador 3D. Logo mais abaixo explicarei isso.
• VGA Compatible Controller – Significa placa de vídeo com multiplexador (Ela é MUXED).
  Isso significa que a placa possui isolamento real e pode ser controlada independente do hardware, tal qual um PC comum em gabinete.

O ideal era que ambas fossem VGA Compatible Controller. Mas como não são, as coisas se complicam!

Esta imagem melhor demonstra o esquema de montagem das placas atuais:

Antigamente os notebooks que vinham com 2 placas de vídeo eram independentes (primeiro desenho); depois, se tornou comum o uso de placas que se complementam, em máquinas atuais (segundo desenho). Por fim, somente notebooks de uso profissional/industrial (E não gamer!) estão vindo com multiplexador (terceiro desenho).

Multiplexador é um chip que gerencia as 2 placas de vídeo para saírem em 1 monitor.
Se não há multiplexador, a imagem, por exemplo, da Nvidia, passa pela Intel e só depois vai pra tela.

De forma sintética, 90% dos notebooks gamers do mercado atual possuem placa de vídeo híbrida como o segundo desenho acima: O controle PCI da placa de vídeo Nvidia/AMD (em laranja) é o mesmo controlador PCI do processador. Sem multiplexador.

Mas o que isso tudo significa?

Que se seu notebook possuir uma placa de vídeo do tipo 3D Controller, seu caro notebook gamer com todo o poder gráfico á mão, não serve para fazer passthrough via QEMU KVM. Triste realidade, este tutorial será inútil.

Na verdade, até é possível. Mas requer extrair a vBIOS da placa e patchea-la na BIOS da máquina virtual, algo demasiadamente complexo, que não trará bons resultados: A máquina virtual jamais vai ter total suporte á ela.
Se quiser tentar algo, este tutorial explica isso de forma mais completa, mas eu já lhes aviso: É uma briga sem vencedores, se você for bem sucedido, nunca terá sequer 40% do desempenho original da placa e terá sérios problemas com máquinas virtuais Windows.

Mas se você realmente precisa de aceleração 3D, não vai escapar do DualBoot. Boa sorte.

4. Instalação

Continuando para a galera que possui gabinetes e placa via PCI.

Apesar do KVM ser nativo do kernel Linux, alguns pacotes são necessários para ter pleno acesso a ele. São todos nativos dos repositórios das principais distribuições Linux, instale conforme seu gerenciador de pacotes:

$ sudo apt/dnf/yum install qemu-kvm libvirt-clients 
libvirt-daemon-system bridge-utils virt-manager ovmf

4.1 Configuração da Rede

Após a instalação dos pacotes, vamos configurar a ponte de redes. Você precisa configurar um acesso Bridge para que a máquina virtual possa se comunicar com a internet caso você assim necessite. – se for pra jogar um game online na máquina virtual por exemplo.

Primeiro encontre sua interface de redes com algum desses comandos:

$ ip a

$ ifconfig

Ignorando a “lo”, o resultado será algo como eth0 ou enp5s0. Vamos supor que seja eth0!
Edite seu arquivo /etc/network/interfaces. Assim, você verá as seguintes linhas:

auto lo
iface lo inet loopback

Adicione estas linhas imediatamente abaixo, considerando que no nosso exemplo vamos usar eth0.

iface eth0 inet manual

iface virbr0 inet dhcp
    bridge_ports eth0

Isso vai apenas criar uma ponte da sua conexão com a máquina virtual, não vai diminuir o desempenho da sua internet. Agora salve e feche.

4.2 Configurando seu Usuário

Agora você vai adicionar seu usuário atual aos 2 grupos do QEMU, assim você não precisará de permissões de root para executá-la:

$ sudo usermod -aG libvirt SEUUSUARIO
$ sudo usermod -aG libvirt-qemu SEUUSUARIO

5. Configurando o Passthrough

Muito bem. Chegamos ao cerne de nosso tutorial!

Se você usa placa de vídeo AMD ou NVIDIA, siga o tutorial normalmente!
Caso você use Intel HD Graphics, desça até o tópico “Caso use Intel…”.

Esta também é a parte mais difícil, pois exige atenção para o usuário não danificar o sistema. Depois de preparar seu sistema, instalar os pacotes e configurar sua máquina virtual, você precisa habilitar o passthrough de GPU para utilizar a aceleração 3D.

Lembre-se de verificar se seu computador suporta as tecnologias de virtualização Intel-VT ou AMD-V e se elas estão ativadas na BIOS.

Encontre o vendor-ID:device-ID da sua placa de vídeo e da saída de audio:
Se for Nvidia:

$ lspci -nn | grep -i nvidia

Se for AMD:

$ lspci -nn | grep -i amd

Audio:

$ lspci -nn | grep audio

Olhe no final das linhas que começam com “VGA compatible controller” e “Audio device”.
O resultado é semelhante a: [8086:1616] e [8086:160c].
Anote esses valores!

Execute os comandos, considerando que em negrito está o código da sua placa de vídeo e de audio visto com o comando lspci do item anterior:

$ cat /sys/bus/pci/devices/0000:01:00.0/modalias
$ cat /sys/bus/pci/devices/0000:00:1f.3/modalias

Edite o arquivo /etc/modprobe.d/vfio.conf:

Adicione as seguintes 4 linhas dentro do arquivo; caso ele não exista, crie-o:

alias pci:v000010DEd00001C8Dsv0000144Dsd0000C790bc03sc02i00 vfio-pci
alias pci:v00008086d0000A171sv0000144Dsd0000C790bc04sc03i00 vfio-pci
options vfio-pci ids=10de:1c03,10de:10f1
options vfio-pci disable_vga=1

Habilite o módulo vfio-pci que você acabou de criar:

$ echo "vfio-pci" | sudo tee /etc/modules-load.d/vfio-pci.conf

Configura se dentro do arquivo vfio-pci.conf está como vfio-pci SEM aspas!Adicione estas linhas ao inicio do sistema editando o arquivo /etc/initramfs-tools/modules:

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
vhost-net

Atualize seu Initramfs:

$ sudo update-initramfs -u

Atualize seu GRUB

$ sudo update-grub2

5.1 GRUB

Uma situação chata que ocorre com QEMU KVM, é que uma vez configurado, você ficará sem sua placa de vídeo e sem som no seu sistema. Então os games que rodavam no Wine ou nativos da Steam deixam de funcionar em prol da máquina virtual.

Caso queira-os de volta, aliás, caso queira ter ambos, faça o seguinte:

Baixe e instale o Grub-Customizer!

$ sudo add-apt-repository ppa:danielrichter2007/grub-customizer
$ sudo apt update
$ sudo apt install grub-customizer

Abra o grub-customizer como super usuário e você provavelmente verá entradas comuns: Uma do seu sistema, e uma sub-entrada, com o seu sistema, entrada de recuperação e 2 entradas de verificação de memória.
Devem haver mais se você usa mais de 1 sistema na máquina. Algo semelhante a isso:

Clique direito sobre a primeira entrada, a principal do seu sistema em Editar.
Na página abaixo selecione tudo e copie.

Pode fechar.

Clique na barra de menus Editar, Novo.

Crie uma entrada com um nome diferente das demais, por exemplo “QEMU KVM”, mude o Tipo para Outro e cole as entradas da tela anterior, nessa. Serão iguais por enquanto.

Agora, vem o importante: Expliquei como configura o QEMU KVM mas ele ainda não inicia com o sistema.
Nessa tela que você colou os mesmos parâmetros da entrada de boot anterior, edite da seguinte maneira:

Vá até a linha que começa com “linux”, normalmente a penultima, vá até “quiet splash” e adicione esta linha, tudo em 1 linha, caso seu sistema tenha GPU Nvidia:

intel_iommu=on nvidia.modeset=0 nvidia_uvm.modeset=0 nvidia_drm.modeset=0 
nvidia_modeset.modeset=0 nouveau.modeset=0

Caso sua placa de vídeo seja AMD:

amd_iommu=on radeon.modeset=0 amdgpu.modeset=0

Feche, clique em Salvar.
Se quiser “reforçar”, vá na barra de menus, Arquivo, Gravar na MBR.

Reinicie seu sistema.

Ao reiniciar, aperte ESC várias vezes logo que a tela cinza do GRUB surgir e escolha a entrada nova: QEMU KVM! Agora sim você deverá verificar se está tudo nos conformes.

Após o reinicio, verifique se o módulo iommu está ativo com o comando:

$ dmesg | grep -E "DMAR|IOMMU"

Devem surgir várias linhas, sem erros, indicando instruções do módulo iommu, semelhantes a essas:

[ 0.000000] ACPI: DMAR 0x00000000BF79E0D0 000118 (v01 AMI OEMDMAR 00000001 MSFT 00000097)
[ 0.000000] DMAR: IOMMU enabled
[ 0.000000] DMAR: Host address width 40
[ 0.000000] DMAR: DRHD base: 0x000000fbffe000 flags: 0x1
[ 0.000000] DMAR: dmar0: reg_base_addr fbffe000 ver 1:0 cap c90780106f0462 ecap f020fe
[ 0.000000] DMAR: RMRR base: 0x000000000ec000 end: 0x000000000effff
[ 0.000000] DMAR: RMRR base: 0x000000bf7ec000 end: 0x000000bf7fffff
[ 0.000000] DMAR: ATSR flags: 0x0
[ 0.000000] DMAR-IR: IOAPIC id 6 under DRHD base 0xfbffe000 IOMMU 0
[ 0.000000] DMAR-IR: Enabled IRQ remapping in xapic mode
[ 1.228883] DMAR: dmar0: Using Queued invalidation
[ 1.228904] DMAR: Setting RMRR:
[ 1.229153] DMAR: Setting identity map for device 0000:00:1a.0 [0xbf7ec000 – 0xbf7fffff]
[ 1.229426] DMAR: Setting identity map for device 0000:00:1a.1 [0xbf7ec000 – 0xbf7fffff]
[ 1.229676] DMAR: Setting identity map for device 0000:00:1a.2 [0xbf7ec000 – 0xbf7fffff]
[ 1.229969] DMAR: Setting identity map for device 0000:00:1a.7 [0xbf7ec000 – 0xbf7fffff]

Verifique tambem se o módulo vfio-pci está ativo:

$ dmesg | grep -i vfio

Serão apenas algumas linhas com instruções, semelhante a essas:

[ 4.338817] VFIO – User Level meta-driver version: 0.3
[ 4.348806] vfio_pci: add [10de:1c03[ffff:ffff]] class 0x000000/00000000
[ 4.348958] vfio_pci: add [10de:10f1[ffff:ffff]] class 0x000000/00000000

Uma última observação:
Você verá que seu som não funciona, não toca qualquer música; E que ao digitar “inxi -b”, você vai ver que o driver da Nvidia/AMD foi substituido pelo vfio_pci.

• Mas o que acontece com aquela “alternância de drivers” entre Intel e Nvidia que o Linux tem?

Não importa qual foi definido antes do reinicio, se você ia usar Intel ou Nvidia, o sistema deve reiniciar como Intel e o driver Nvidia não vai carregar.

Mas ele memoriza, então quando reiniciar normalmente, o driver Nvidia volta a funcionar, permitindo jogos pelo Wine e/ou Steam.

Se ver mais problemas, alguns parâmetros extras que podem ajuda-lo:

intel_iommu=on iommu=pt intel_iommu=igfx_off pcie_acs_override=downstream 
video=vesafb:off,efifb:off nofb i915.preliminary_hw_support=1 
i915.enable_hd_vgaarb=1

Use-os com cuidado.

6. Em caso de Problemas…

Estas são configurações extras caso seu sistema virtualizado apresente problemas, se o driver gráfico não carregar, se o kernel não reconhecer a placa externa ou qualquer outro tipo de problema. Além disso nessa sessão abordarei questões particularmente interessantes para quem usa alguma GPU AMD.

As instruções abaixo foram feitas para as placas AMD;
O tutorial acima funciona bem para quem usa NVIDIA mas não sei informar quanto a possíveis problemas com NVIDIA e se estes códigos abaixo, adaptados, resolvem. Se você for um usuário experiente e quiser tentar, nos dê o feedback e eu atualizo o post!

O disco de RAM inicial (/boot/initrd*) contém drivers e “outras coisas” necessárias para inicializar o sistema e montar o sistema de arquivos raiz e continuar com o restante do boot processo. – abordamos melhor isso nesta postagem!

Como os drivers de gráficos tendem a carregar cedo, e porque o amdgpu vai querer segurar as duas placas gráficas ao mesmo tempo, devemos cuidadosamente garantir que o driver vfio-pci tenha a oportunidade de carregar antes do driver amdgpu para que ele tenha prioridade.

Isso é feito modificando o ramdisk inicial da seguinte maneira:

Edite o arquivo: /etc/initramfs-tools/modules
E modifique as seguintes linhas:

softdep amdgpu pre: vfio vfio_pci

vfio
vfio_iommu_type1
vfio_virqfd
options vfio_pci ids=1002:699f,1002:aae0
vfio_pci ids=1002:699f,1002:aae0
vfio_pci
amdgpu

Lembrando mais uma vez que os trechos em negrito correspondem á sua vendor-ID e device-ID encontrados anteriormente.

Atualize seu initramfs:

$ sudo update-initramfs -u

Para o sistema ficar consistente, adicione isto ao arquivo /etc/modules:

vfio
vfio_iommu_type1
vfio_pci ids=1002:699f,1002:aae0

Caso ainda tenha problemas, adicione ao arquivo /etc/modprobe.d/amdgpu.conf a seguinte linha:

softdep amdgpu pre: vfio vfio_pci

Depois, edite o arquivo /etc/modprobe.d/vfio_pci.conf e adicione esta linha:

options vfio_pci ids=1002:699f,1002:aae0

Ao final, reinicie a máquina e veja com este comando abaixo…

$ lspci -nnv | less

… você visualiza linhas semelhantes a essas:

Kernel driver in use: vfio-pci
Kernel modules: amdgpu

Isso indica que o módulo vfio-pci é o prioritário e o amdgpu carrega depois!

Tudo ok?
Tudo ok!
Você sobreviveu á parte mais complicada e seu computador não explodiu no processo.

Agora vem a parte mais tranquila, configurar sua máquina virtual.

7. Caso use Intel…

Insisto aqui para que NÃO faça passthrough de GPU para VM ao usar Intel.
Os problemas são maiores e você terá baixo desempenho; Se ainda assim quiser arriscar…

Edite seu /etc/default/grub e edite a linha GRUB_CMDLINE_LINUX_DEFAULT com os seguintes parâmetros:

intel_iommu=on video=efifb:off

Ficando assim:

GRUB_CMDLINE_LINUX_DEFAULT=”intel_iommu=on video=efifb:off”

Atualize o grub!

$ sudo update-grub2

Edite o arquivo /etc/modprobe.d/blacklist.conf e adicione as seguintes linhas:

blacklist snd_hda_intel
blacklist snd_hda_codec_hdmi
blacklist i915

Encontre o vendor-ID:device-ID da sua placa de vídeo e da saída de audio:

$ lspci -nn | grep -i intel

Olhe no final das linhas que começam com “VGA compatible controller” e “Audio device”.
O resultado é semelhante a: [8086:1616] e [8086:160c].

Agora edite o arquivo /etc/modprobe.d/vfio.conf e adicione a seguinte linha:

options vfio-pci ids=[8086:1616],[8086:160c]

Adicione a seguinte linha ao arquivo /etc/modprobe.d/kvm.conf:

options kvm ignore_msrs=1

Isso pode ser feito com 1 comando!

$ echo "options kvm ignore_msrs=1" > /etc/modprobe.d/kvm.conf

Atualize seu initramfs:

$ sudo update-initramfs -u

8. Criando a Máquina Virtual

Uma vez que já adiantou as configurações acima, procure pelo programa virt-manager – ou execute-o diretamente no terminal – e configure sua máquina virtual como faria no VirtualBox. O virt-manager é como a interface do VirtualBox porém para o QEMU. É relativamente amigável de se utilizar.

Ao clicar no ícone que parece um monitor brilhante você vai primeiro decidir a fonte de onde virá o sistema (pendrive, seu disco local, etc); depois decidir qual a imagem do sistema (.ISO por exemplo); quanto de memória RAM e de CPU serão alocados para a máquina, lembrando de deixar um mínimo pra máquina hospedeira se manter funcionando; e após isso decida o tamanho da unidade virtual em Gb. Deixei o suficiente para instalar o sistema e configurar o game/aplicação que você deseja utilizar a aceleração 3D.

Lembre-se de marcar “Personalizar confirmação” na última etapa!

Essa parte de criar a máquina virtual depende da necessidade do usuário e do sistema que será executado. Apesar de não dar detalhes dessa etapa, peço que fique atento ás configurações para tirar o melhor desempenho da máquina – alocando mais memória RAM e núcleos de CPU pra ela – mas sem deixar o sistema hospedeiro morrer por inanição de recursos. Deixe pelo menos 1 núcleo e 2 Gb de RAM para o hospedeiro; pode ser 1 Gb de RAM caso seu sistema não esteja consumindo muitos recursos e não tenha mais nada aberto, nenhum browser.

8.1 E mais dicas!

Você deve alterar o Firmware do modo BIOS para OVMF, que é um BIOS UEFI. Você também deve remover “Video QXL” e “Display Spice” e quaisquer outros displays da configuração. Use “Adicionar Hardware” para adicionar a placa gráfica e seu dispositivo de áudio complementar, ela estará na sessão de dispositivos PCI. O autor recomenda ligar um segundo mouse e teclado e atribuir esses dispositivos USB aqui também. Quando a máquina virtual estiver ligada, ela atribuirá esses dispositivos USB à máquina virtual.

8.2 Mais um pouco!

Se quiser melhorar o desempenho da máquina virtual em como ela se comunica com o disco rígido ou SSD usado para hospedá-la, você pode também torná-la “nativa”: Passe o disco rígido inteiro para a máquina virtual – pelo bem da sua máquina faça isso num disco vazio a parte! – e assim ela terá I/O direto. Sem lentidão, sem gargalos, a desfragmentação ou ainda o TRIM do disco será responsabilidade integral da máquina virtual!

Primeiro procure pelo disco a ser passado para a máquina virtual. Abra o terminal e digite:

$ sudo blkid

Identifique a letra do dispositivo que deseja usar na máquina virtual. Não precisa estar montado para ver essa letra. Deve ser algo tipo /dev/sdc, /dev/sdd e etc. Aqui foi o /dev/sdb.

Agora este comando:

$ ls -al /dev/disk/by-id/

Você verá uma tabela semelhante a essa:

Você verá o nome que seu dispositivo /dev/sdXY foi identificado pelo kernel Linux no diretório /dev/disk/by-id. No meu caso foi o ata-KINGSTON_SA400S37480G_50026B77834C72A7 pois o final é o mesmo mencionado acima, sendo /sdb. Cada dispositivo possui uma identificação interna. Copie o caminho deixando-o completo, no meu exemplo é adicionar o /dev/disk/by-id ao começo + nome identificado:

/dev/disk/by-id/ata-KINGSTON_SA400S37480G_50026B77834C72A7

Na hora de adicionar um novo disco ao virt-manager, marque armazenamento customizado e deixe desta forma:

Em cache marque NONE e em modo de descarte defina como UNMAP – é equivalente ao TRIM. Se houver suporte, será automático assim.

Salve, seu armazenamento ficará assim:

Como o acesso é direto ao hardware, você pode alterar o tipo do disco como desejar, seja VirtIO, SCSI ou SATA. O mais rápido é o VirtIO – Não faça essa alteração com um disco que já tiver um sistema funcional! Isso é para antes mesmo da instalação.

Agora sim você pode instalar seu sistema.

8.3 Finalizando

Como o passthrough já foi configurado, você pode instalar normalmente seu game e os drivers que ele necessita, como o DirectX 9.0c, 10, 11 e etc.

Ao terminar, verifique caso sua máquina virtualizada seja Linux, se a placa de vídeo está disponível:

• Se for Intel:
  $ lspci | grep -i intel 
• Se for Nvidia:
  $ lspci | grep -i nvidia 
• Se for AMD:
  $ lspci | grep -i amd

Caso a máquina virtualizada seja Windows, verifique junto ao Gerenciador de Dispositivos se a placa de vídeo foi devidamente capturada. Se sim, tente instalar os drivers dela!

Explico: Ao contrário do VirtualBox que possui Adicionais de Convidado e o disco de Drivers próprios, que dão compatibilidade e desempenho á máquina virtualizada, o QEMU permite (e até exige) que você use os drivers nativos da máquina virtualizada. Ou seja, se for Windows numa máquina com NVIDIA, vá até o site da NVIDIA e baixe os drivers da placa de vídeo; se for um sistema Linux, verifique se o kernel suporta os drivers que você deseja e, caso contrário, compile-os.

Porém…

9. Adicionais de Convidado

Sim meus caros o QEMU também possui Adicionais de Convidado para a VM funcionar direito!
Eles não são distribuidos nativamente e quem compilou os drivers foi a equipe do projeto Fedora.
Basta baixar a .ISO clicando aqui, monta-la na máquina virtual via CDROM e aplicar os drivers conforme a necessidade. Eles fornecem drivers para barramento PCI e outros.

O unico driver que eles não tem, é de som. E nisso eu não posso ajuda-los: Som é um sério problema conhecido do QEMU KVM, sempre dá algum problema ;/

10. Em caso de mais problemas…

O qemu-kvm precisa de permissões especiais do APPArmor para acessar dispositivos (portas USB e etc). – Falamos dele nesta postagem recente! Caso você use Ubuntu, recomendo fortemente que faça o proposto abaixo.

Para habilitar essas permissões, edite o arquivo /etc/apparmor.d/abstractions/libvirt-qemu no sistema hospedeiro e encontre a seção #for usb access e modifique-a assim:

# for usb access
/dev/bus/usb/** rw,
/etc/udev/udev.conf r,
/sys/bus/ r,
/sys/class/ r,
/run/udev/data/* rw,

Se precisar de um dispositivo como uma partição completa, por exemplo /dev/sdb, adicione a seguinte linha:

/dev/sdb rw,

Sim, incluindo as vírgulas!
Caso queira remover o APPArmor por completo:

$ service apparmor stop
$ service apparmor teardown
$ update-rc.d -f apparmor remove
$ sudo apt purge apparmor #OPCIONAL!

Lembrando que, caso purge o AppArmor, o metapacote vai remover todos os pacotes Snap do sistema!
Portanto cuidado, ou terá que reinstalá-los novamente para não quebrar o sistema.

11. Debugando

Se você usa placa de vídeo AMD ou NVIDIA, siga abaixo normalmente!
Caso você use Intel HD Graphics, desça mais, até o tópico “Caso use Intel…”.

O QEMU + KVM é uma maravilha complicada de configurar que pode trazer problemas diversos. Se mesmo após TUDO que foi dito e feito acima você ainda teve problemas, dê uma olhada nesse pequeno throuble shoot que criamos e descubra onde pode estar seu problema!

11.1 Reset Bug

Observe que alguns hardwares gráficos sofrem com o que é conhecido como “Reset Bug” – isso significa que a placa gráfica pode ser apenas uma vez iniciada e a máquina deve ser desligada para suportar a reinicialização. As GPU’s da linha Fury são conhecidos por sofrer deste bug.

Quanto a isso não há muito o que fazer.

11.2 Code 43

Se você estiver usando uma placa Nvidia, é provável que você receba um erro “Code 43” criptografado. Os drivers da Nvidia não suportam a execução em uma máquina virtual, mas isso pode ser contornado modificando a configuração da máquina virtual para ocultar o fato de que um hypervisor está presente.

Então você precisa de um disco rígido local? Edite a configuração da sua máquina virtual:

$ virsh edit nome-da-sua-maquina-virtual

Deixe assim:

<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/sda '/>
<target dev='vdb' bus='sata'/>
</disk>

E se a sua placa NVIDIA ainda estiver dando o código 43, você precisa definir o ID do fornecedor e ocultar o kvm editando essas entradas – se elas não existirem, adicione-as:

<hyperv>
<relaxed state='on'/>
<vapic state='on'/>
<spinlocks state='on' retries='8191'/>
<vendor_id state='on' value='VENDORID'/>
</hyperv>
<kvm>
<hidden state='on'/>
</kvm>

Atento! Não se esqueça de editar sua configuração do APPArmor (caso esteja usando uma máquina hospedeira com Ubuntu e ele esteja habilitado) para, por exemplo, permitir acesso r/w a /dev/sda ou /dev/outros. E esse virtio é mais rápido que sata, mas você precisa instalar o driver virtio THEN para virtio de sata… ficando assim:

<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source dev='/dev/sda'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0d' function='0x0'/>
</disk>

Mas isso não vai ser problema caso ja tenha removido o APPArmor anteriormente.

Note que o Fedora não se preocupa em não ter driver/endereço, ou não se importa; mas o ubuntu se preocupa em ter o tipo de endereço pci/etc. Provavelmente pode precisar de um inicializável:

<boot order='1'/>

Pode ser necessário, dependendo do resto da sua configuração vm xml.

Se você mudar de sata para virtio para o disco de inicialização, você tem que dar um empurrão nele: Adicione um segundo disco ao virtio para certificar-se de que os drivers estejam funcionando corretamente, ENTÃO mude o disco primário de sata para o virtio.

11.3 Windows 10 Build 1830

Rodar a versão 1830 do Windows 10 pode ser uma dor de cabeça por causa de um bug no MSRS. Diga ao KVM hospedeiro que você quer ignorar o MSRS! Abra o terminal e digite:

$ options kvm ignore_msrs=1

11.4 Caso use Intel…

Para evitar o surgimento do erro Code 43 citado acima, o modo de correção nos usuários de Intel HD Graphics é diferente. Edite o arquivo /etc/pve/qemu-server/<Sua Maquina Virtual>.conf e modifique os seguintes argumentos conforme a família do seu processador – Google será seu amigo agora:

# Se o processador for > broadewell then, (upt mode)
args: -device vfio-pci,host=00:02.0,addr=0x18,x-vga=on,x-igd-opregion=on

# Se o processador for >= sandy then, (legacy mode)
machine:pc-i440fx-2.2
args: -device vfio-pci,host=00:02.0,addr=0x02
vga: none

12. Conclusão

Hoje aprendemos como configurar o QEMU em conjunto com o KVM para executar máquinas virtuais com aceleração gráfica, permitindo que games executem com desempenho bem próximo do de um sistema nativo.

É complicado? Muito. Com certeza a coisa mais avançada e complexa que já publiquei aqui no site.

Mas pode ser uma alternativa interessante pra quem não quer perder espaço em disco ou perder tempo configurando seu computador em dual-boot. – Apesar que… nesse nível de complicação, o dual-boot é mais fácil e perde-se menos tempo! Aí vai do gosto do freguês…

#UrbanCompassPony

Fontes:
linuxConfig
dRaiser’s techblog
level1techs
server-world
proxmox
vfio.blogspost