- \n
- Acelera\u00e7\u00e3o gr\u00e1fica virtual dedicada (iGVT-d): um convidado por GPU;<\/li>\n
- Acelera\u00e7\u00e3o gr\u00e1fica virtual compartilhada (iGVT-s): m\u00faltiplos convidados por GPU;<\/li>\n
- GPU virtual: (iGVT-g): m\u00faltiplos convidados por GPU. Nesse artigo, ser\u00e1 dado foco nessa implementa\u00e7\u00e3o.<\/li>\n<\/ul>\n
Intel GVT-g (ou iGVT-g, Intel\u00ae Graphics Virtualization Technology-g) \u00e9 uma tecnologia que permite criar GPU virtuais que podem ser utilizadas por convidados KVM ou Xen. Dependendo da quantidade de mem\u00f3ria RAM dispon\u00edvel e da fatia de mem\u00f3ria dada a cada convidado, \u00e9 poss\u00edvel ter at\u00e9 sete convidados utilizando a mesma GPU Intel.<\/p>\n
Atrav\u00e9s dela, \u00e9 poss\u00edvel criar m\u00e1quinas virtuais capazes de utilizar as capacidades de codifica\u00e7\u00e3o e decodifica\u00e7\u00e3o de v\u00eddeo da Intel (Intel QSV e\/ou VAAPI), \u00e9 poss\u00edvel utilizar a acelera\u00e7\u00e3o 3D para o uso de programas de CAD (Computer Aided Design) e jogos. Tudo isso dentro do convidado e ainda permitindo ao hospedeiro utilizar a GPU.
\n<\/p>\nREQUISITOS PARA O HOSPEDEIRO<\/h1>\n
Para utilizar a tecnologia iGVT-g, \u00e9 necess\u00e1rio ter um processador Intel, ao menos, da 5\u00aa Gera\u00e7\u00e3o com GPU Intel Graphics, com a virtualiza\u00e7\u00e3o ativada (VT-d e VT-x) e uma placa-m\u00e3e compat\u00edvel. A quantidade de mem\u00f3ria dispon\u00edvel para ceder aos convidados e a quantidade de convidados simult\u00e2neos dependem de quanta mem\u00f3ria RAM o sistema hospedeiro possui instalada.<\/p>\n
Nesse caso, ser\u00e1 utilizado o QEMU\/KVM para criar os convidados. A necessidade ou n\u00e3o de construir o QEMU depender\u00e1 de qual alternativa ser\u00e1 escolhida a respeito da tela do convidado (isso ser\u00e1 explicado adiante).<\/p>\n
O hospedeiro utilizado no exemplo \u00e9 o Xubuntu 18.04. O Ubuntu 18.04 vem com o kernel\u00a0Linux<\/a>\u00a0na vers\u00e3o 4.15 (no momento em que escrevo, 4.15.0-23). Essa vers\u00e3o possui as configura\u00e7\u00f5es necess\u00e1rias para o funcionamento do Intel GVT-g com KVM. A partir da vers\u00e3o 4.16 uma op\u00e7\u00e3o essencial para permitir a estabilidade de convidados Windows passou a funcionar. Portanto, recomenda-se usar o kernel Linux com a vers\u00e3o ao menos 4.16.<\/p>\n
Caso seja necess\u00e1rio construir um kernel porque o que determinada distribui\u00e7\u00e3o prov\u00ea n\u00e3o possui as configura\u00e7\u00f5es necess\u00e1rias, \u00e9 preciso garantir que as seguintes configura\u00e7\u00f5es estejam presentes e configuradas: CONFIG_DRM_I915_GVT, CONFIG_DRM_I915_GVT_KVMGT, CONFIG_VFIO_MDEV e CONFIG_VFIO_MDEV_DEVICE<\/p>\n
Um exemplo, baseando-se nas configura\u00e7\u00f5es do kernel do Ubuntu 18.04:<\/p>\n
CONFIG_DRM_I915_GVT=y
\nCONFIG_DRM_I915_GVT_KVMGT=m
\nCONFIG_VFIO_MDEV=m
\nCONFIG_VFIO_MDEV_DEVICE=m<\/div>\nTenha certeza de que as op\u00e7\u00f5es acima est\u00e3o no arquivo .config ANTES de construir o kernel. Para construir o kernel (o foco n\u00e3o \u00e9 ensinar a construir o kernel, mas ainda assim h\u00e1 essa pequena explica\u00e7\u00e3o):<\/p>\n
<\/i>\u00a0git clone git:\/\/git.kernel.org\/pub\/scm\/linux\/kernel\/git\/torvalds\/linux.git
\n$ make oldconfig<\/strong><\/p>\nAntes do comando abaixo, veja se as op\u00e7\u00f5es CONFIG_* acima est\u00e3o configuradas corretamente no arquivo .config:<\/p>\n
<\/i>\u00a0make -j `nproc` bindeb-pkg<\/strong><\/p>\n
Recomenda-se grandemente ler a ajuda do makefile do kernel Linux (make help), h\u00e1 op\u00e7\u00f5es que criam pacotes DEB (como a do exemplo) e pacotes RPM prontos para serem instalados em distribui\u00e7\u00f5es que utilizam tais pacotes.<\/p>\n
Uma vez com o kernel constru\u00eddo e instalado com as configura\u00e7\u00f5es necess\u00e1rias, \u00e9 preciso adicionar alguns m\u00f3dulos no initramfs. No caso do Xubuntu 18.04, \u00e9 necess\u00e1rio adicionar no arquivo\u00a0\/etc\/initramfs-tools\/modules<\/em>\u00a0as seguintes tr\u00eas linhas:<\/p>\n
kvmgt
\nvfio-iommu-type1
\nvfio-mdev<\/div>\nE atualizar o initramfs com:<\/p>\n
<\/i>\u00a0sudo update-initramfs -u -k all<\/strong><\/p>\n
Caso haja muitas vers\u00f5es do kernel Linux instaladas, isso pode demorar. -u significa update (atualizar), -k define a vers\u00e3o do kernel. Com “all”, todas as vers\u00f5es s\u00e3o atualizadas.<\/p>\n
Com o kernel configurado e instalado e o initramfs atualizado, \u00e9 preciso adicionar algumas op\u00e7\u00f5es na linha de comando da inicializa\u00e7\u00e3o do sistema. No caso do GRUB2 no Xubuntu 18.04, o arquivo \u00e9 o\u00a0\/etc\/default\/grub<\/em>, para edit\u00e1-lo, pode-se usar o seguinte comando:<\/p>\n
<\/i>\u00a0sudo nano \/etc\/default\/grub<\/strong><\/p>\n
Na linha que cont\u00e9m:<\/p>\n
GRUB_CMDLINE_LINUX_DEFAULT=<\/p>\n
Algumas op\u00e7\u00f5es precisam ser adicionadas entre as aspas. Por padr\u00e3o, h\u00e1 apenas “quiet splash”. \u00c9 NECESS\u00c1RIO ADICIONAR:<\/p>\n
intel_iommu=on i915.enable_gvt=1<\/p>\n
A linha de comando fica semelhante a:<\/p>\n
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash intel_iommu=on i915.enable_gvt=1″<\/div>\nOutras op\u00e7\u00f5es s\u00e3o recomendadas. kvm.ignore_msrs=1 \u00e9 importante caso os convidados sejam Windows, sem ela o sistema se torna inst\u00e1vel pois o convidado pode tentar ler registros de forma direta onde o KVM n\u00e3o definiu valores. kvm.halt_poll_ns=0 e kvm.halt_poll_ns_grow=0 s\u00e3o op\u00e7\u00f5es relevantes para o som, sem elas configuradas os convidados tornam-se cada vez mais lentos conformes sons s\u00e3o reproduzidos neles, especialmente convidados Windows. A linha de comando ficaria algo como:<\/p>\n
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash intel_iommu=on i915.enable_gvt=1 kvm.ignore_msrs=1 kvm.halt_poll_ns=0 kvm.halt_poll_ns_grow=0″<\/div>\nEnt\u00e3o um:<\/p>\n
<\/i>\u00a0sudo update-grub<\/strong><\/p>\n
Atualiza o GRUB2 para que as op\u00e7\u00f5es estejam presentes ao iniciar o sistema. Ao reinici\u00e1-lo, o sistema ir\u00e1 iniciar com essas op\u00e7\u00f5es adicionais.<\/p>\n
Caso tudo tenha ocorrido corretamente, deve ser poss\u00edvel ver quais s\u00e3o os modos dispon\u00edveis em que se pode criar as GPUs virtuais. Para isso, h\u00e1 um diret\u00f3rio no sysfs onde as op\u00e7\u00f5es podem ser vistas. Nesse exemplo, o Intel HD Graphics \u00e9 o dispositivo PCI 00:02.0, o endere\u00e7o PCI pode ser diferente, logo pode ser necess\u00e1rio adaptar o caminho do diret\u00f3rio, isso pode ser visto com o comando:<\/p>\n
<\/i>\u00a0lspci<\/strong><\/p>\n
Com o endere\u00e7o PCI sendo 00:02.0, o diret\u00f3rio \u00e9:<\/p>\n
\/sys\/bus\/pci\/devices\/0000:00:02.0\/mdev_supported_types\/<\/p>\n
Dentro desse diret\u00f3rio devem haver outros, cada um representando um modo. No exemplo, tem-se:<\/p>\n
i915-GVTg_V5_4
\ni915-GVTg_V5_8<\/p>\nE, dentro de cada um desses diret\u00f3rios, h\u00e1 tr\u00eas arquivos com informa\u00e7\u00f5es. O arquivo available_instances mostra quantas GPUs virtuais podem ser criadas com aquela configura\u00e7\u00e3o, o arquivo device_api mostra a API utilizada, nesse caso, vfio-pci, e o arquivo description tem detalhes do modo:<\/p>\n
low_gm_size: 128MB
\nhigh_gm_size: 512MB
\nfence: 4
\nresolution: 1920×1200
\nweight: 4<\/div>\nO diret\u00f3rio devices tem liga\u00e7\u00f5es simb\u00f3licas para as GPUs virtuais criadas. O arquivo create \u00e9 utilizado para criar as GPUs virtuais, seu uso ser\u00e1 explicado nas configura\u00e7\u00f5es do convidado.<\/p>\n
Enquanto com o que foi feito at\u00e9 agora j\u00e1 seria poss\u00edvel inicializar o QEMU, na experi\u00eancia utilizando iGVT-g sem configurar o driver de v\u00eddeo do hospedeiro em um Lenovo Ideapad 310-14ISK com um Intel Core i3-6100U e uma Intel HD Graphics 520, podem ocorrer piscadas na tela por um motivo ainda desconhecido.<\/p>\n
Para corrigir \u00e9 preciso alterar o driver de v\u00eddeo que \u00e9 utilizado de “modesetting” para “intel”. Inicialmente \u00e9 preciso instalar o driver Intel caso n\u00e3o esteja instalado. No caso do Ubuntu 18.04, para instalar o pacote necess\u00e1rio se utiliza:<\/p>\n
<\/i>\u00a0sudo apt install xserver-xorg-video-intel<\/strong><\/p>\n
Ent\u00e3o deve-se editar ou criar o arquivo\u00a0\/etc\/X11\/xorg.conf<\/em>\u00a0usando:<\/p>\n
<\/i>\u00a0sudo nano \/etc\/X11\/xorg.conf<\/strong><\/p>\n
Deixando-o com o seguinte conte\u00fado:<\/p>\n
\nSection \"Device\"\r\n Identifier \"Intel Graphics\"\r\n Driver \"intel\"\r\n Option \"DRI\" \"3\"\r\nEndSection<\/pre>\n<\/div>\n
E ent\u00e3o se pode reiniciar a sess\u00e3o do X com, por exemplo:<\/p>\n
<\/i>\u00a0sudo systemctl restart lightdm.service<\/strong><\/p>\n
Ou reiniciar o sistema para aplicar a nova configura\u00e7\u00e3o do driver de v\u00eddeo.<\/p>\n
Al\u00e9m disso, \u00e9 recomend\u00e1vel utilizar UEFI para os convidados. Usando iGVT-g muitas das capacidades de v\u00eddeo est\u00e3o dispon\u00edveis, mas os modos VGA n\u00e3o est\u00e3o, devido a sua complexidade. Isso significa que a tela inicial do GRUB2, ou a tela inicial do ISOLINUX n\u00e3o aparecem no modo BIOS, o que compromete o funcionamento dos convidados. Enquanto o GRUB2 consegue lidar com o fato de n\u00e3o poder ser exibido, o ISOLINUX faz com que o convidado trave.<\/p>\n
Como alternativa, h\u00e1 um framebuffer b\u00e1sico que funciona apenas em UEFI. Ele \u00e9 capaz de prover a tela inicial do GRUB2 de forma limitada, mas suficiente para escolher e editar op\u00e7\u00f5es do GRUB2.<\/p>\n
Para usar convidados com UEFI, o hospedeiro precisa do OVMF. H\u00e1 o pacote ovmf no Ubuntu 18.04:<\/p>\n
<\/i>\u00a0sudo apt install ovmf<\/strong><\/p>\n
Ou h\u00e1 a possibilidade de construir o OVMF do Git\u00a0https:\/\/github.com\/tianocore\/edk2<\/a>, mas o processo n\u00e3o \u00e9 t\u00e3o trivial, leia a documenta\u00e7\u00e3o dispon\u00edvel primeiro.<\/p>\n<\/div>\n
DMA-BUF E SUA IMPORT\u00c2NCIA<\/h1>\n
<\/p>\n
dma-buf<\/em>\u00a0\u00e9 como se fosse uma tela virtual, onde o convidado pode exibir a imagem como se ele estivesse conectado a um monitor f\u00edsico. O uso \u00e9 bem simples: exibir a tela do convidado em uma janela no hospedeiro.<\/p>\n\u00c9 importante saber que n\u00e3o \u00e9 necess\u00e1rio utilizar o dma-buf para os convidados. Isso \u00e9 opcional. No entanto, sem o dma-buf, para poder visualizar a tela do convidado ser\u00e1 preciso usar algum protocolo como o VNC ou RDP, que podem n\u00e3o ser suficientes dependendo do tipo de uso que ser\u00e1 feito do sistema convidado.<\/p>\n
Exemplos: caso o convidado ser\u00e1 um servidor sem interface gr\u00e1fica para codifica\u00e7\u00e3o de m\u00eddia, SSH \u00e9 o suficiente. Caso ele tenha uma interface gr\u00e1fica mas os v\u00eddeos n\u00e3o s\u00e3o intensos e a lat\u00eancia n\u00e3o \u00e9 cr\u00edtica, VNC ou RDP podem ser suficientes. Caso o convidado seja utilizado para CAD ou para jogos, onde as inefici\u00eancias dos protocolos remotos podem causar perda de produtividade ou de partidas, dma-buf \u00e9 a melhor op\u00e7\u00e3o.<\/p>\n
H\u00e1 mais de uma interface pela qual \u00e9 poss\u00edvel utilizar o dma-buf:<\/p>\n
- \n
- Spice – Utiliza o protocolo Spice para exibir a tela;<\/li>\n
- GTK – Cria uma janela GTK, padr\u00e3o do QEMU;<\/li>\n
- VNC – Utiliza o protocolo VNC para exibir a tela;<\/li>\n
- Libvirt – Utiliza o Spice tamb\u00e9m, mas pode ser gerenciado atrav\u00e9s do virt-manager.<\/li>\n<\/ul>\n
N\u00e3o h\u00e1 recomenda\u00e7\u00f5es espec\u00edficas, mas como as demais op\u00e7\u00f5es s\u00e3o protocolos remotos, a interface GTK foi a que se mostrou mais r\u00e1pida, sendo limitada pelo gerenciador de janelas do hospedeiro: percebeu-se significativa redu\u00e7\u00e3o no desempenho do convidado ao desativar a composi\u00e7\u00e3o de tela no hospedeiro (xfwm4). H\u00e1 vantagens interessantes ao utilizar Spice, como copiar e colar e arrastar e soltar (dependentes de drivers) que podem fazer o Spice ser a melhor op\u00e7\u00e3o. O melhor \u00e9 testar cada uma.<\/p>\n
QEMU<\/h1>\n
Caso se tenha chegado \u00e0 conclus\u00e3o de que ser\u00e1 necess\u00e1rio utilizar o dma-buf, ser\u00e1 preciso construir o QEMU do c\u00f3digo fonte. Isso acontece porque o QEMU disponibilizado no Ubuntu 18.04 n\u00e3o possui as configura\u00e7\u00f5es necess\u00e1rias para acelerar o v\u00eddeo, nem usando Spice, VNC ou GTK. Nesse caso, s\u00f3 seria poss\u00edvel criar convidados que n\u00e3o utilizam o dma-buf.<\/p>\n
Para construir o QEMU capaz de usar dma-buf, \u00e9 preciso baixar o c\u00f3digo fonte e configur\u00e1-lo. A partir da vers\u00e3o 2.10 est\u00e1vel j\u00e1 deve ser poss\u00edvel construir o QEMU com as op\u00e7\u00f5es necess\u00e1rias, para os corajosos h\u00e1 o Git, mas \u00e9 melhor usar a vers\u00e3o 2.12 por ser a vers\u00e3o est\u00e1vel mais recente. H\u00e1 v\u00e1rias depend\u00eancias que precisam ser instaladas. No caso de uma instala\u00e7\u00e3o limpa do Xubuntu 18.04, as depend\u00eancias podem ser instaladas atrav\u00e9s do seguinte comando:<\/p>\n
<\/i>\u00a0sudo apt install gcc pkg-config zlib1g-dev libgtk-3-dev libgtk-3-dev libsdl2-dev libjpeg-turbo8-dev libbluetooth-dev libsasl2-dev libepoxy-dev libdrm-dev libgbm-dev libspice-server-dev libusb-dev libusb-1.0-0-dev libusbredirhost-dev<\/strong><\/p>\n
S\u00e3o muitos pacotes mesmo. Um exemplo para construir a vers\u00e3o 2.12 do QEMU com as op\u00e7\u00f5es necess\u00e1rias \u00e9:<\/p>\n
<\/i>\u00a0wget -c -t 0 https:\/\/download.qemu.org\/qemu-2.12.0.tar.xz
\n$ tar xf qemu-2.12.0.tar.xz
\n$ cd qemu-2.12.0
\n$ .\/configure –target-list=x86_64-softmmu –audio-drv-list=pa,alsa,sdl
\n–prefix=$HOME\/qemu-2.12-build –enable-opengl –enable-gtk
\n–enable-sdl –enable-libusb –enable-bluez –enable-kvm –enable-spice
\n–enable-vnc –enable-vnc-png –enable-vnc-jpeg –enable-vnc-sasl
\n–enable-membarrier –enable-vhost-net –enable-usb-redir
\n$ make -j `nproc`
\n$ make install<\/strong><\/p>\nProvavelmente ser\u00e1 necess\u00e1rio trocar o local de instala\u00e7\u00e3o. A op\u00e7\u00e3o –enable-membarrier n\u00e3o existe nas vers\u00f5es anteriores \u00e0 2.12. Pode ser que o configure falhe por determinadas bibliotecas de desenvolvimentos n\u00e3o estarem instaladas, o componente faltante \u00e9 especificado na mensagem de erro. Instale a(s) biblioteca(s) faltante(s) e repita o uso do configure.<\/p>\n
Uma vez com o QEMU pronto, pode-se configurar o convidado.<\/p>\n<\/div>\n
<\/p>\n
PREPARANDO O CONVIDADO LINUX SEM DMA-BUF<\/h1>\n
<\/p>\n
Com o hospedeiro preparado e o QEMU constru\u00eddo, pode-se come\u00e7ar a prepara\u00e7\u00e3o do convidado. A instala\u00e7\u00e3o do convidado \u00e9 feita utilizando uma VGA virtual do QEMU, como QXL, Cirrus or STD. Uma vez com o sistema instalado e configurado, pode-se remover a VGA virtual e utilizar apenas a GPU Intel, acessando o convidado usando SSH, VNC ou RDP. Usar a VGA virtual e a GPU Intel ao mesmo pode causar s\u00e9rios problemas de estabilidade, inclusive no hospedeiro. Por isso, \u00e9 melhor utilizar a VGA virtual apenas para instalar o sistema.<\/p>\nESSAS ETAPAS AINDA OCORREM NO HOSPEDEIRO<\/h1>\n
Inicialmente, \u00e9 preciso criar a GPU virtual que ser\u00e1 utilizada por esse convidado. Para isso, deve-se usar um comando echo com o nome que se deseja dar para a GPU virtual. A Intel, no seu guia, usa o comando uuid para gerar os nomes para as GPUs virtuais e, por isso, uuid tamb\u00e9m \u00e9 utilizado nesse exemplo. Pode ser necess\u00e1rio instalar o pacote uuid, dispon\u00edvel no Ubuntu 18.04 usando:<\/p>\n
<\/i>\u00a0sudo apt install uuid<\/strong><\/p>\n
Por exemplo:<\/p>\n
<\/i>\u00a0uuid<\/strong>
\n334b65fc-731c-11e8-8325-1ffce6ac7959<\/samp><\/p>\nCom esse uuid, pode-se criar a GPU virtual usando o seguinte comando, lembrando-se que o endere\u00e7o PCI pode ser diferente e que o diret\u00f3rio do modo tamb\u00e9m pode ser diferente, dependendo da op\u00e7\u00e3o escolhida:<\/p>\n
<\/i>\u00a0sudo sh -c ‘echo 334b65fc-731c-11e8-8325-1ffce6ac7959 > \/sys\/bus\/pci\/devices\/0000:00:02.0\/mdev_supported_types\/i915-GVTg_V5_8\/create’<\/strong><\/p>\n
O modo da i915-GVTg_V5_8 cria uma GPU virtual com 64 MB de mem\u00f3ria com resolu\u00e7\u00e3o m\u00e1xima de 1024×768 nesse exemplo.<\/p>\n
Para criar a imagem do HD, pode-se utilizar o seguinte comando:<\/p>\n
<\/i>\u00a0qemu-img create -f qcow2 bionic.qcow2 10G<\/strong><\/p>\n
create: criar; -f qcow2: formato da imagem QCOW2; o nome da imagem; o tamanho da imagem (nesse caso, 10 GB).<\/p>\n
Uma vez com a GPU virtual criada e com o a imagem do HD criada, pode-se iniciar a m\u00e1quina virtual com QEMU. Um exemplo de comando pode ser visto a seguir (altere o caminho para o QEMU 2.12 que foi constru\u00eddo anteriormente, adapta\u00e7\u00f5es ser\u00e3o necess\u00e1rias para vers\u00f5es anteriores \u00e0 2.12):<\/p>\n
<\/i>\u00a0sudo qemu-system-x86_64 -m 1280 -enable-kvm -cpu host -smp cores=2,threads=2
\n-device vfio-pci,sysfsdev=\/sys\/bus\/pci\/devices\/0000:00:02.0\/334b65fc-731c-11e8-8325-1ffce6ac7959,rombar=0,x-igd-opregion=on,display=off,x-vga=off
\n-monitor vc -display gtk -vga std -serial stdio -hda bionic.qcow2
\n-cdrom “xubuntu-18.04-core-amd64.iso”
\n-bios \/usr\/share\/ovmf\/OVMF.fd -netdev user,id=net0,hostfwd=::59000-:5900 -device e1000,netdev=net0<\/strong><\/p>\nExplica\u00e7\u00e3o da linha de comando:<\/p>\n
A m\u00e1quina virtual tem 1280 MB de mem\u00f3ria RAM. Usa KVM, a CPU \u00e9 do mesmo modelo do hospedeiro, foram designadas dois n\u00facleos da CPU, cada um deles com duas threads.<\/p>\n
A GPU virtual foi designada com o display=off, ou seja, sem dma-buf. A falta da op\u00e7\u00e3o igd-opregion=on pode gerar graves problemas de estabilidade no hospedeiro, mas com vers\u00f5es mais antigas do kernel (de 4.15 para baixo) ela n\u00e3o funciona, sendo necess\u00e1rio remov\u00ea-la. O modo vga n\u00e3o funciona, ent\u00e3o est\u00e1 desligado, rombar=0 porque n\u00e3o h\u00e1 nenhuma ROM a ser utilizada.<\/p>\n
O terminal (ele \u00e9 chamado de monitor, de onde se podem adicionar dispositivos USB ou enviar comandos ao convidado enquanto o convidado est\u00e1 em execu\u00e7\u00e3o, por exemplo) do QEMU est\u00e1 em um console virtual que pode ser acessado da pr\u00f3pria interface (depende da op\u00e7\u00e3o -display), foi escolhida a interface GTK para exibir a m\u00e1quina virtual, a VGA virtual foi escolhida como a STD, a porta serial est\u00e1 no stdio (no terminal se aberto por ele).<\/p>\n
Uma imagem QCOW2 foi escolhida como HD (pode ser criado com qemu-img), uma ISO \u00e9 usada como CD-ROM e o firmware UEFI do OVMF foi escolhida como o firmware da m\u00e1quina virtual.<\/p>\n
A rede escolhida \u00e9 do tipo usu\u00e1rio, com o id net0, em que a porta 59000 do hospedeiro \u00e9 passada para a 5900 do convidado. Ou seja, ao se conectar na porta 59000 do hospedeiro, a conex\u00e3o ocorre, na verdade, na porta 5900 do convidado. O controlador Ethernet virtual \u00e9 um 82540EM Gigabit Ethernet Controller, que usa a netdev com o id net0.<\/p>\n
ESSAS ETAPAS DEVEM SER FEITAS NO(S) SISTEMA(S) CONVIDADO(S)<\/h1>\n
Com aquele comando do QEMU, o convidado \u00e9 iniciado e \u00e9 aberta uma janela GTK, onde deve aparecer por alguns segundos o logo do TianoCore e o terminal de onde o comando foi executado deve ficar vazio. Na janela deve aparecer o GRUB2 com as op\u00e7\u00f5es para testar sem instalar\/instalar o Xubuntu 18.04. Ent\u00e3o pode-se instalar o Xubuntu 18.04 normalmente, nesse est\u00e1gio n\u00e3o h\u00e1 configura\u00e7\u00f5es especiais a se fazer.<\/p>\n
Quando a instala\u00e7\u00e3o terminar, reinicie o convidado e acesse sua conta rec\u00e9m criada. A primeira configura\u00e7\u00e3o a se fazer \u00e9 no GRUB2. Edite o arquivo\u00a0\/etc\/default\/grub<\/em>\u00a0usando:<\/p>\n
<\/i>\u00a0sudo nano \/etc\/default\/grub<\/strong><\/p>\n
E remova a op\u00e7\u00e3o splash da linha. A corrup\u00e7\u00e3o na tela usando a VGA virtual e a GPU Intel simultaneamente enquanto o convidado inicializa deixa de existir. Aplique a nova configura\u00e7\u00e3o do GRUB2 usando o comando:<\/p>\n
<\/i>\u00a0sudo update-grub<\/strong><\/p>\n
Para ser poss\u00edvel usar o convidado sem dma-buf e sem a VGA virtual \u00e9 necess\u00e1rio configurar algum protocolo remoto, como o SSH ou o VNC. Nesse exemplo ser\u00e1 utilizado o VNC.<\/p>\n
Inicialmente, o pacote x11vnc precisa ser instalado. No Ubuntu 18.04, pode-se utilizar o seguinte comando para instal\u00e1-lo:<\/p>\n
<\/i>\u00a0sudo apt install x11vnc<\/strong><\/p>\n
Ent\u00e3o \u00e9 necess\u00e1rio criar um servi\u00e7o do systemd que vai permitir que o convidado seja acessado atrav\u00e9s do protocolo VNC j\u00e1 na tela de login. Na p\u00e1gina de ajuda do Ubuntu h\u00e1 uma explica\u00e7\u00e3o muito clara de como cri\u00e1-lo e configur\u00e1-lo, as \u00fanicas altera\u00e7\u00f5es feitas foram desativar a senha e escolher o modo de autentica\u00e7\u00e3o do LightDM (o convidado \u00e9 Xubuntu 18.04, que usa LightDM).<\/p>\n
Para iniciar a edi\u00e7\u00e3o do servi\u00e7o, use o seguinte comando:<\/p>\n
<\/i>\u00a0sudo nano \/lib\/systemd\/system\/x11vnc.service<\/strong><\/p>\n
Esse \u00e9 o conte\u00fado que precisa ser inserido no arquivo:<\/p>\n
[Unit]
\nDescription=Start x11vnc at startup.
\nAfter=multi-user.target<\/p>\n[Service]
\nType=simple
\nExecStart=\/usr\/bin\/x11vnc -auth \/var\/run\/lightdm\/root\/:0 -forever -loop -noxdamage -repeat -rfbport 5900 -shared<\/p>\n[Install]
\nWantedBy=multi-user.target<\/p><\/div>\nAp\u00f3s isso, o systemd precisa ser recarregado, o servi\u00e7o ativado e iniciado para poder testar o acesso:<\/p>\n
<\/i>\u00a0sudo systemctl daemon-reload
\n$ sudo systemctl enable x11vnc.service
\n$ sudo systemctl start x11vnc.service<\/strong><\/p>\nNa pr\u00f3xima inicializa\u00e7\u00e3o, o servi\u00e7o x11vnc.service iniciar\u00e1 automaticamente j\u00e1 na tela de login. Tente acessar o convidado atrav\u00e9s de um visualizador VNC e veja se funcionou. TESTE ANTES DE REMOVER A VGA VIRTUAL. Caso n\u00e3o seja poss\u00edvel conectar ao servidor VNC, investigue as causas:<\/p>\n
1) N\u00e3o tenho acesso \u00e0 porta 5900 do convidado!<\/p>\n
Isso pode acontecer quando op\u00e7\u00f5es a respeito da rede n\u00e3o s\u00e3o escolhidas no QEMU. Uma alternativa \u00e9 redirecionar uma porta do hospedeiro para o convidado. Um exemplo de op\u00e7\u00f5es que fazem isso \u00e9:<\/p>\n
-netdev user,id=net0,hostfwd=::59000-:5900 -device e1000,netdev=net0<\/strong><\/p>\n
Existem alternativas mais avan\u00e7adas de configura\u00e7\u00e3o da rede, mas que fogem do escopo do artigo.<\/p>\n
2) Adicionei a op\u00e7\u00e3o para passar a porta para o convidado mas ainda n\u00e3o tenho acesso!<\/p>\n
Se o firewall foi ativado, pode ser que o acesso esteja sendo negado. Libere as portas necess\u00e1rias no convidado.<\/p>\n
3) A porta funciona, mas o servidor VNC n\u00e3o!<\/p>\n
O servi\u00e7o do systemd foi testado com o LightDM. Outros gerenciadores de login precisam de configura\u00e7\u00f5es um pouco diferentes.<\/p>\n
Uma vez com o servidor VNC funcionando, \u00e9 necess\u00e1rio trocar o driver de “modesetting” para “intel” tamb\u00e9m. Em primeiro lugar, veja se o driver intel est\u00e1 instalado. Para instal\u00e1-lo no Ubuntu 18.04, use:<\/p>\n
<\/i>\u00a0sudo apt install xserver-xorg-video-intel<\/strong><\/p>\n
Ent\u00e3o crie\/edite o arquivo\u00a0\/etc\/X11\/xorg.conf<\/em>\u00a0no convidado tamb\u00e9m:<\/p>\n
<\/i>\u00a0sudo nano \/etc\/X11\/xorg.conf<\/strong><\/p>\n
O conte\u00fado \u00e9 o mesmo utilizado no hospedeiro, pois \u00e9 a mesma GPU:<\/p>\n
\nSection \"Device\"\r\n Identifier \"Intel Graphics\"\r\n Driver \"intel\"\r\n Option \"DRI\" \"3\"\r\nEndSection<\/pre>\n<\/div>\n
Enquanto usar o driver intel n\u00e3o \u00e9 NECESS\u00c1RIO, \u00e9 EXTREMAMENTE RECOMEND\u00c1VEL. Sem ele, prepare-se para travamentos no hospedeiro durante a inicializa\u00e7\u00e3o do convidado e mensagens no dmesg do hospedeiro como:<\/p>\n
[75756.681054] i915 0000:00:02.0: Resetting rcs0 after gpu hang<\/samp><\/p>\n
Com essa configura\u00e7\u00e3o realizada, desligue o convidado, pois a linha de comando do QEMU precisa ser alterada para remover a VGA virtual.<\/p>\n
RETORNANDO AO HOSPEDEIRO<\/h1>\n
Uma vez com o servidor VNC configurado e funcionando, deve ser poss\u00edvel utilizar o convidado sem uma VGA virtual. Um exemplo de comando para ser usado no hospedeiro para iniciar o convidado pode ser visto a seguir:<\/p>\n
<\/i>\u00a0sudo qemu-system-x86_64 -m 1280 -enable-kvm -cpu host -smp cores=2,threads=2
\n-device vfio-pci,sysfsdev=\/sys\/bus\/pci\/devices\/0000:00:02.0\/334b65fc-731c-11e8-8325-1ffce6ac7959,rombar=0,x-igd-opregion=on,display=off,x-vga=off
\n-monitor vc -display none -vga none -serial stdio -hda bionic.qcow2
\n-bios \/usr\/share\/ovmf\/OVMF.fd -netdev user,id=net0,hostfwd=::59000-:5900 -device e1000,netdev=net0<\/strong><\/p>\nAs diferen\u00e7as em rela\u00e7\u00e3o ao comando anterior s\u00e3o:<\/p>\n
- \n
- N\u00e3o h\u00e1 display;<\/li>\n
- N\u00e3o h\u00e1 VGA virtual;<\/li>\n
- N\u00e3o h\u00e1 CD-ROM.<\/li>\n<\/ul>\n
N\u00e3o vai abrir nenhuma janela e o terminal de onde o comando foi executado, dessa vez, exibir\u00e1 algumas mensagens:<\/p>\n
erro: nenhum modo de v\u00eddeo adequado encontrado.
\nerro: nenhum modo de v\u00eddeo adequado encontrado.
\nIniciando no modo cego<\/samp><\/p>\nPor que elas surgem? Porque nenhum modo VGA existe. Tenha paci\u00eancia enquanto o convidado inicia, pois nada ser\u00e1 vis\u00edvel durante a inicializa\u00e7\u00e3o, exceto essas tr\u00eas mensagens.<\/p>\n
Ap\u00f3s esperar um tempo, use um visualizador VNC (vinagre, por exemplo). Para instalar no Ubuntu 18.04, use:<\/p>\n
<\/i>\u00a0sudo apt install vinagre<\/strong><\/p>\n
Para iniciar, execute no terminal:<\/p>\n
<\/i>\u00a0vinagre<\/strong><\/p>\n
Ou utilize outro visualizador de \u00e1rea de trabalho remota de sua escolha e conecte-se ao localhost na porta 59000 (conforme o exemplo). Se tudo deu certo, a tela de login do LightDM deve ter aparecido e o convidado est\u00e1 pronto.<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_Convidado_VNC_Login.png\")
<\/a><\/div>\n![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_Convidado_VNC_LSPCI.png\")
<\/a><\/div>\nUma vez com o convidado desligado, talvez se queira criar uma GPU virtual com mais capacidade, mas a GPU virtual criada anteriormente ainda existe. Para remov\u00ea-la, se utiliza o seguinte comando:<\/p>\n
<\/i>\u00a0sudo sh -c ‘echo 1 > \/sys\/bus\/pci\/devices\/0000:00:02.0\/334b65fc-731c-11e8-8325-1ffce6ac7959\/remove’<\/strong><\/p>\n
Para facilitar a inicializa\u00e7\u00e3o, pode-se criar um script onde a GPU virtual \u00e9 adicionada e removida automaticamente, como por exemplo:<\/p>\n
#!\/bin\/bash
\n<\/span>sudo sh -c ‘echo 334b65fc-731c-11e8-8325-1ffce6ac7959 > \/sys\/bus\/pci\/devices\/0000:00:02.0\/mdev_supported_types\/i915-GVTg_V5_8\/create’
\nsudo qemu-system-x86_64 -m 1280 -enable-kvm -cpu host
\n-smp cores=2,threads=2 -device vfio-pci,sysfsdev=\/sys\/bus\/pci\/devices\/0000:00:02.0\/334b65fc-731c-11e8-8325-1ffce6ac7959,rombar=0,x-igd-opregion=on,display=off,x-vga=off
\n-monitor vc -display none -vga none -serial stdio -hda bionic.qcow2
\n-bios \/usr\/share\/ovmf\/OVMF.fd -netdev user,id=net0,hostfwd=::59000-:5900 -device e1000,netdev=net0
\nsudo sh -c ‘echo 1 > \/sys\/bus\/pci\/devices\/0000:00:02.0\/334b65fc-731c-11e8-8325-1ffce6ac7959\/remove’<\/div>\n<\/div>\n<\/p>\n
PREPARANDO O CONVIDADO LINUX COM DMA-BUF<\/h1>\n
<\/p>\n
Para usar o\u00a0dma-buf<\/em>, \u00e9 necess\u00e1rio usar o kernel\u00a0Linux<\/a>\u00a0com a vers\u00e3o m\u00ednima 4.16. Com a vers\u00e3o 4.15 a tela n\u00e3o \u00e9 carregada, impossibilitando visualizar o convidado.<\/p>\nAINDA NO HOSPEDEIRO<\/h1>\n
Tendo a vers\u00e3o m\u00ednima do kernel Linux e o QEMU constru\u00eddo com GTK e OpenGL (explicado anteriormente), pode-se criar o convidado. Nesse exemplo \u00e9 criada uma GPU virtual com 128 MB de mem\u00f3ria e resolu\u00e7\u00e3o m\u00e1xima de 1920×1200 (\u00e9 necess\u00e1rio ver se a GPU tem esse modo dispon\u00edvel):<\/p>\n
<\/i>\u00a0uuid<\/strong>
\nd4253d2e-73d8-11e8-a4b7-cb5f65b15073<\/samp><\/p>\n<\/i>\u00a0sudo sh -c ‘echo d4253d2e-73d8-11e8-a4b7-cb5f65b15073 > \/sys\/bus\/pci\/devices\/0000:00:02.0\/mdev_supported_types\/i915-GVTg_V5_4\/create’<\/strong><\/p>\n
Com a GPU virtual criada, pode-se iniciar o convidado usando um comando como (adapte conforme suas configura\u00e7\u00f5es e caminhos):<\/p>\n
<\/i>\u00a0sudo qemu-system-x86_64 -m 1280 -enable-kvm -cpu host
\n-smp cores=2,threads=2 -device vfio-pci,sysfsdev=\/sys\/bus\/pci\/devices\/0000:00:02.0\/d4253d2e-73d8-11e8-a4b7-cb5f65b15073,x-igd-opregion=on,rombar=0,display=on,x-vga=off
\n-monitor vc -display gtk,gl=on -vga none -serial stdio -hda bionicdma.vdi
\n-cdrom “xubuntu-18.04-desktop-amd64.iso”
\n-bios \/usr\/share\/ovmf\/OVMF.fd -netdev user,id=net0 -device e1000,netdev=net0<\/strong><\/p>\nExplica\u00e7\u00e3o do comando (n\u00e3o se surpreenda se algumas partes forem iguais \u00e0 p\u00e1gina anterior):<\/p>\n
A m\u00e1quina virtual tem 1280 MB de mem\u00f3ria RAM. Usa KVM, a CPU \u00e9 do mesmo modelo do hospedeiro, foram designadas dois n\u00facleos da CPU, cada um deles com duas threads.<\/p>\n
A GPU virtual foi designada com o display=on, ou seja, com dma-buf. A falta da op\u00e7\u00e3o igd-opregion=on pode gerar graves problemas de estabilidade no hospedeiro. O modo vga n\u00e3o funciona, ent\u00e3o est\u00e1 desligado, rombar=0 porque n\u00e3o h\u00e1 nenhuma ROM a ser utilizada.<\/p>\n
O terminal (ele \u00e9 chamado de monitor, de onde se podem adicionar dispositivos USB ou enviar comandos ao convidado enquanto o convidado est\u00e1 em execu\u00e7\u00e3o, por exemplo) do QEMU est\u00e1 em um console virtual que pode ser acessado da pr\u00f3pria interface (depende da op\u00e7\u00e3o -display), foi escolhida a interface GTK para exibir a m\u00e1quina virtual e a acelera\u00e7\u00e3o OpenGL ser\u00e1 utilizada na janela GTK, n\u00e3o h\u00e1 uma VGA virtual pois n\u00e3o h\u00e1 necessidade e a porta serial est\u00e1 no stdio (no terminal se aberto por ele).<\/p>\n
Uma imagem VDI foi escolhida como HD, uma ISO \u00e9 usada como CD-ROM e o firmware UEFI do OVMF foi escolhido como o firmware da m\u00e1quina virtual.<\/p>\n
A rede escolhida \u00e9 do tipo usu\u00e1rio, com o id net0. O controlador Ethernet virtual \u00e9 um 82540EM Gigabit Ethernet Controller, que usa a netdev com o id net0. N\u00e3o h\u00e1 a necessidade de redirecionar portas dessa vez, pois n\u00e3o h\u00e1 a necessidade de visualizar a tela com protocolos remotos.<\/p>\n
HOSPEDEIRO E CONVIDADO JUNTOS, ATEN\u00c7\u00c3O<\/h1>\n
A inicializa\u00e7\u00e3o da m\u00e1quina virtual nesse modo \u00e9 bastante peculiar. O GRUB2 aparece, mas n\u00e3o na janela da m\u00e1quina virtual, e sim no terminal! Isso ocorre porque o framebuffer est\u00e1 sendo passado pela porta serial, e no comando do QEMU foi configurado que a porta serial fosse o stdio. Relevando esse fato, o GRUB2 funciona como o GRUB2, permitindo escolher as op\u00e7\u00f5es e edit\u00e1-las.<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_XubComdmabuf.png\")
<\/a><\/div>\nUma vez escolhida, a inicializa\u00e7\u00e3o come\u00e7a e as mesmas mensagens avisando sobre a inicializa\u00e7\u00e3o em modo cego aparecem, mas ent\u00e3o a janela GTK \u00e9 inicializada. Devem aparecer algumas mensagens referente ao UEFI e pode surgir uma mensagem de erro da GPU virtual, acusando a aus\u00eancia do firmware (devido a rombar=0 e x-vga=off), mas o convidado inicia normalmente. Instale o convidado como se fosse um convidado comum e reinicie quando a instala\u00e7\u00e3o terminar.<\/p>\n
O convidado est\u00e1 pronto.<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_Xub1804Convidado.png\")
<\/a><\/div>\nN\u00e3o se assustem, \u00e9 Xubuntu 18.04 mesmo.<\/p>\n
Isso funciona com outras distribui\u00e7\u00f5es tamb\u00e9m, como com o openSUSE Tumbleweed:<\/p>\n
![\"Linux:](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_openSUSEGuest.png\")
<\/a><\/div>\nPode parecer inacredit\u00e1vel, mas \u00e9 isso mesmo. Utilizando o dma-buf \u00e9 mais complicado de deixar o hospedeiro pronto, mas a configura\u00e7\u00e3o necess\u00e1ria no convidado Linux \u00e9 zero.<\/p>\n
A configura\u00e7\u00e3o opcional no convidado \u00e9 trocar o driver de v\u00eddeo de “modesetting” para “intel”, como foi feito no hospedeiro e no convidado sem dma-buf. Inicialmente, deve-se ter certeza de que o driver intel est\u00e1 instalado. No Ubuntu 18.04, para instal\u00e1-lo pode se utilizar:<\/p>\n
<\/i>\u00a0sudo apt install xserver-xorg-video-intel<\/strong><\/p>\n
Ent\u00e3o criar\/editar o arquivo\u00a0\/etc\/X11\/xorg.conf<\/em>:<\/p>\n
<\/i>\u00a0sudo nano \/etc\/X11\/xorg.conf<\/strong><\/p>\n
E deix\u00e1-lo com o seguinte conte\u00fado:<\/p>\n
\nSection \"Device\"\r\n Identifier \"Intel Graphics\"\r\n Driver \"intel\"\r\n Option \"DRI\" \"3\"\r\nEndSection<\/pre>\n<\/div>\n
Reiniciando a sess\u00e3o do LightDM altera o modo:<\/p>\n
<\/i>\u00a0sudo systemctl restart lightdm<\/strong><\/p>\n
Uma vez que foi conclu\u00eddo o uso do convidado, remova a GPU virtual:<\/p>\n
<\/i>\u00a0sudo sh -c ‘echo 1 > \/sys\/bus\/pci\/devices\/0000:00:02.0\/d4253d2e-73d8-11e8-a4b7-cb5f65b15073\/remove’<\/strong><\/p>\n<\/div>\n
<\/p>\n
PREPARANDO O CONVIDADO WINDOWS<\/h1>\n
<\/p>\n
Convidados Windows n\u00e3o s\u00e3o muito dif\u00edceis de serem configurados, mas falhar em configur\u00e1-los de forma apropriada causa muitos problemas, podendo tornar o sistema hospedeiro inoperante. A vers\u00e3o a ser utilizada no sistema convidado \u00e9 o Windows 10 Single Language (pt-BR) Pro x86_64. A recomenda\u00e7\u00e3o \u00e9 usar o kernel\u00a0Linux<\/a>\u00a0ao menos na vers\u00e3o 4.16 no hospedeiro.<\/p>\nInicialmente, tenha certeza de que na linha de comando da inicializa\u00e7\u00e3o do hospedeiro Linux as seguintes op\u00e7\u00f5es estejam configuradas:<\/p>\n
kvm.ignore_msrs=1 kvm.halt_poll_ns=0 kvm.halt_poll_ns_grow=0 intel_iommu=on i915.enable_gvt=1<\/div>\nAs op\u00e7\u00f5es intel_iommu=on e i915.enable_gvt=1 s\u00e3o requeridas para usar o iGVT-g.<\/p>\n
A op\u00e7\u00e3o kvm.ignore_msrs=1 \u00e9 essencial para a estabilidade dos sistemas hospedeiro e convidado, pois sem ela o Windows pode tentar acessar endere\u00e7os da mem\u00f3ria n\u00e3o definidos ou n\u00e3o acess\u00edveis pelo KVM, causando telas azuis e\/ou corrup\u00e7\u00e3o.<\/p>\n
Veja as consequ\u00eancia de ignorar a op\u00e7\u00e3o do par\u00e1grafo acima:<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_Win10MalConfigurado.png\")
<\/a><\/div>\nA corrup\u00e7\u00e3o chegou ao sistema hospedeiro, tornando-o inoperante.<\/p>\n
As op\u00e7\u00f5es kvm.halt_poll_ns=0 e kvm.halt_poll_ns_grow=0 diminuem a degrada\u00e7\u00e3o de desempenho que a emula\u00e7\u00e3o de som causa (ap\u00f3s algumas horas ligado, o convidado fica lento sem elas mesmo sem uma sa\u00edda de \u00e1udio).<\/p>\n
Tendo certeza de que o hospedeiro est\u00e1 pronto, \u00e9 poss\u00edvel come\u00e7ar as prepara\u00e7\u00f5es para o convidado. A primeira observa\u00e7\u00e3o: o convidado Windows precisa de bem mais espa\u00e7o que o convidado Linux. Ao inv\u00e9s de criar imagens de 10 GB, \u00e9 melhor criar images de, no m\u00ednimo, 32 GB. Mesmo assim, o convidado Windows tende a ficar sem espa\u00e7o devido \u00e0s atualiza\u00e7\u00f5es do sistema, ent\u00e3o \u00e9 necess\u00e1rio cuidado com o espa\u00e7o em disco.<\/p>\n
Inicialmente, deve-se criar a GPU virtual para o Windows. Use o comando uuid para criar um identificador para nomear a GPU virtual. Se n\u00e3o estiver instalado, instale usando:<\/p>\n
<\/i>\u00a0sudo apt install uuid<\/strong><\/p>\n
Ent\u00e3o:<\/p>\n
<\/i>\u00a0uuid<\/strong>
\n185802b6-7405-11e8-9e14-6ff0319bd0dc<\/samp><\/p>\n<\/i>\u00a0sudo sh -c ‘echo 185802b6-7405-11e8-9e14-6ff0319bd0dc > \/sys\/bus\/pci\/devices\/0000:00:02.0\/mdev_supported_types\/i915-GVTg_V5_4\/create’<\/strong><\/p>\n
V\u00e1rias op\u00e7\u00f5es que n\u00e3o eram relevantes em convidados Linux ser\u00e3o requeridas em convidados Windows, por isso a linha de comando do QEMU fica bastante grande:<\/p>\n
<\/i>\u00a0sudo env PULSE_LATENCY_MSEC=0 QEMU_PA_SAMPLES=98875 QEMU_AUDIO_DAC_FIXED_FREQ=48000
\nqemu-system-x86_64
\n-hda win10.raw -enable-kvm -cpu host -smp cores=2,threads=2 -m 3G
\n-device vfio-pci,sysfsdev=\/sys\/bus\/pci\/devices\/0000:00:02.0\/185802b6-7405-11e8-9e14-6ff0319bd0dc,rombar=0,x-igd-opregion=on,display=off,x-vga=off
\n-usb -device usb-mouse -bios \/usr\/share\/ovmf\/OVMF.fd -monitor vc -serial stdio
\n-vga cirrus -display gtk -cdrom “Win10_1709_BrazilianPortuguese_x64.iso”
\n-netdev user,id=net0,hostfwd=::33890-:3389 -device e1000,netdev=net0,bus=pci.0,addr=0x8<\/strong><\/p>\nEm primeiro lugar, h\u00e1 algumas vari\u00e1veis de ambiente. A primeira (PULSE_LATENCY_MSEC=0) faz com que a lat\u00eancia do PulseAudio seja de 0 ms (isso n\u00e3o \u00e9 perfeito e h\u00e1 aplica\u00e7\u00f5es que podem ter problemas, mas essa n\u00e3o teve). A segunda (QEMU_AUDIO_DRV=pa) escolhe o driver de \u00e1udio do QEMU, nesse caso PulseAudio. A terceira (QEMU_PA_SAMPLES=98875) define quantas amostras ser\u00e3o armazenadas no buffer do som. A quarta (QEMU_AUDIO_DAC_FIXED_FREQ=48000) \u00e9 a taxa de amostragem utilizada pelo QEMU. Mesmo com todas essas op\u00e7\u00f5es, o som emulado ainda pode ter problemas, mas eles ser\u00e3o muito menores do que antes. Os valores foram iterados at\u00e9 chegar a uma experi\u00eancia boa.<\/p>\n
A respeito do comando do QEMU em si:<\/p>\n
A imagem do HD \u00e9 raw, KVM \u00e9 habilitado, a CPU escolhida \u00e9 a mesma do hospedeiro, foram alocados dois n\u00facleos, cada um com duas threads e foram alocados 3 GB de mem\u00f3ria RAM.<\/p>\n
A GPU virtual \u00e9 configurada, sem passar ROM para ela, com x-igd-opregion=on (com convidados Windows, \u00e9 necess\u00e1rio pela estabilidade), o display e a VGA est\u00e3o desativados, ou seja, sem dma-buf.<\/p>\n
Foi definido que a m\u00e1quina virtual tem dispositivos USB, um mouse USB foi definido (isso \u00e9 importante), \u00e9 utilizado o firmware UEFI do OVMF, o monitor (terminal do QEMU) est\u00e1 no console virtual (na mesma janela onde aparece a tela do convidado) e a porta serial est\u00e1 no stdio (no terminal de onde o comando foi executado, por exemplo).<\/p>\n
A VGA virtual \u00e9 Cirrus, o display (a interface) \u00e9 GTK, o CD-ROM \u00e9 a m\u00eddia de instala\u00e7\u00e3o do Windows 10, a rede foi escolhida em modo usu\u00e1rio e redireciona a porta 33890 do hospedeiro para a 3389 do convidado (para utilizar com o protocolo RDP). O endere\u00e7o PCI do adaptador de rede foi selecionado bem alto para evitar conflitos com as GPUs (tanto a VGA virtual como a GPU Intel).<\/p>\n
A instala\u00e7\u00e3o procede normalmente, mas aten\u00e7\u00e3o: para usar como convidado, n\u00e3o \u00e9 poss\u00edvel usar o Windows 10 Home, \u00e9 necess\u00e1rio ter uma licen\u00e7a, ao menos, do Windows 10 Pro.<\/p>\n
Uma vez com o sistema instalado, ser\u00e1 pedido sua conta da Microsoft (se houver) ou poder\u00e1 criar um novo usu\u00e1rio e senha, e haver\u00e1 a possibilidade de configurar quais informa\u00e7\u00f5es s\u00e3o enviadas. Uma vez com tudo pronto, o sistema deve iniciar e quase que imediatamente avisar a respeito da aus\u00eancia de um driver de v\u00eddeo, e ele est\u00e1 correto. No entanto, o que ele faz a seguir \u00e9 ruim (mais sobre isso adiante), ele instala o driver gen\u00e9rico.<\/p>\n
\u00c9 preciso ativar o acesso remoto do convidado Windows. Para isso, abra o Meu Computador, v\u00e1 em Propriedades -> Configura\u00e7\u00f5es remotas -> Remoto e escolha a op\u00e7\u00e3o “Permitir conex\u00f5es remotas com este computador”. Aplique e teste tentando conectar-se ao localhost:33890 com o vinagre ou outro programa. Se falhar, tente desmarcar a op\u00e7\u00e3o “Permitir conex\u00f5es somente de computadores que estejam executando a \u00c1rea de Trabalho Remota com Autentica\u00e7\u00e3o no N\u00edvel da Rede (recomend\u00e1vel)” e aplique. S\u00f3 desative se a tentativa falhar.<\/p>\n
Uma vez com o protocolo RDP funcionando, \u00e9 preciso instalar o driver da Intel. Para isso, acesse o site da Intel pelo convidado e busque pelo driver adequado para sua GPU Intel (sim, \u00e9 o mesmo driver que seria utilizado se o Windows 10 fosse o hospedeiro). Qual \u00e9 a vers\u00e3o do driver depende da GPU, mas \u00e9 necess\u00e1rio que seja baixado o arquivo ZIP, pois o arquivo EXE tende a falhar por n\u00e3o ser certificado (explica\u00e7\u00f5es a frente). A p\u00e1gina onde se podem buscar os driver \u00e9 https:\/\/downloadcenter.intel.com\/ .<\/p>\n
Pode haver mais de um driver dispon\u00edvel. Os certificados pela Intel s\u00e3o da vers\u00e3o 15.45, mas eles n\u00e3o t\u00eam DirectX12, t\u00eam desempenho pior e ser\u00e1 uma luta constante para impedir que o Windows Update instale o driver gen\u00e9rico. A vers\u00e3o 15.45 do driver era mais est\u00e1vel com vers\u00f5es 4.15 do kernel Linux. A partir do kernel 4.16, a diferen\u00e7a de estabilidade diminuiu muito ou deixou de existir, mas a de desempenho ainda \u00e9 gritante. Busque pelo modelo de sua GPU e baixe a vers\u00e3o ZIP do driver que desejar.<\/p>\n
Os drivers mais antigos da Intel podem fazer o convidado nunca iniciar a tela, e podem fazer o seguinte erro surgir no dmesg:<\/p>\n
[26948.391884] Detected your guest driver doesn’t support GVT-g.
\n[26948.391888] Now vgpu 1 will enter failsafe mode.<\/samp><\/p>\nSe as mensagens acima surgirem ao iniciar o convidado, a tela nunca ser\u00e1 iniciada. Reinicie o convidado para tentar novamente.<\/p>\n
Evite o driver gen\u00e9rico a todo o custo (\u00e9 aquele com data 11\/11\/2016). O driver gen\u00e9rico causa erros 43 de forma consistente e impede que o driver Intel seja atualizado normalmente. Caso ele acabe instalado, \u00e9 melhor remov\u00ea-lo no Modo de Seguran\u00e7a e ent\u00e3o, ao reiniciar e voltar ao modo normal, desativar a internet para poder instalar o driver da Intel sem o gen\u00e9rico reaparecer. Com as vers\u00f5es 24.xxx, o gen\u00e9rico n\u00e3o ser\u00e1 mais oferecido.<\/p>\n
Uma vez que os drivers corretos tenham sido devidamente instalados, abra o dxdiag. Se n\u00e3o der tela azul no momento ou alguns segundos depois, \u00e9 sucesso. O Windows 10 convidado est\u00e1 est\u00e1vel.<\/p>\n
O dxdiag deve mostrar algo semelhante a:<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_dxdiagUEFI.png\")
<\/a><\/div>\nNas configura\u00e7\u00f5es de energia, \u00e9 melhor desabilitar a op\u00e7\u00e3o de apagar a tela devido a inatividade e desabilitar a suspens\u00e3o do sistema (uma das poucas ocasi\u00f5es em que telas azuis ainda ocorrem).<\/p>\n
O convidado Windows 10 sem dma-buf est\u00e1 pronto para ser usado e a VGA virtual pode ser removida.<\/p>\n
Para criar um convidado com dma-buf, os cuidados com o hospedeiro s\u00e3o os mesmos, mas o comando usado no QEMU \u00e9 um pouco diferente:<\/p>\n
<\/i>\u00a0sudo env PULSE_LATENCY_MSEC=0 QEMU_PA_SAMPLES=98875 QEMU_AUDIO_DAC_FIXED_FREQ=48000
\nqemu-system-x86_64
\n-hda win10.raw -enable-kvm -cpu host -smp cores=2,threads=2 -m 3G
\n-device vfio-pci,sysfsdev=\/sys\/bus\/pci\/devices\/0000:00:02.0\/185802b6-7405-11e8-9e14-6ff0319bd0dc,rombar=0,x-igd-opregion=on,display=on,x-vga=off
\n-usb -device usb-mouse -bios bios.bin -monitor vc -serial stdio
\n-vga cirrus -display gtk,gl=on -cdrom “Win10_1709_BrazilianPortuguese_x64.iso”
\n-netdev user,id=net0,hostfwd=::33890-:3389 -device e1000,netdev=net0,bus=pci.0,addr=0x8<\/strong><\/p>\nBoa parte do comando \u00e9 igual, mas a op\u00e7\u00e3o display=on foi configurada para ativar o dma-buf, a op\u00e7\u00e3o -bios foi trocada para a bios.bin, que \u00e9 a SeaBIOS, constru\u00edda junto com o QEMU 2.12 (ela pode ser localizada no diret\u00f3rio onde o QEMU 2.12 foi instalado, dentro do diret\u00f3rio share\/qemu), pois o convidado Windows 10 n\u00e3o inicializa a tela em modo UEFI (s\u00f3 pode ser acessado remotamente). Na op\u00e7\u00e3o -display, adicionou-se o gtk,gl=on para que a janela GTK seja acelerada por OpenGL.<\/p>\n
Os procedimentos para configurar o convidado Windows 10 com dma-buf s\u00e3o iguais aos do convidado Windows 10 sem dma-buf, incluindo o RDP, que precisa ser ativado no convidado com dma-buf tamb\u00e9m.<\/p>\n
Quando usando o modo BIOS, o dxdiag deve mostrar algo como:<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_dxdiagBIOS.png\")
<\/a><\/div>\nPreste aten\u00e7\u00e3o nos valores exibidos em BIOS: veja como o dxdiag n\u00e3o \u00e9 capaz de apresentar os valores. Sem a op\u00e7\u00e3o kvm.ignore_msrs=1 na linha de comando do kernel Linux e sem a op\u00e7\u00e3o x-igd-opregion=on na linha de comando do QEMU, quando o Windows tenta ler os valores que deveriam preencher o local das vari\u00e1veis, o convidado sofre uma pane e d\u00e1 tela azul, podendo comprometer a funcionalidade do hospedeiro tamb\u00e9m.<\/p>\n
Uma vez que o uso do convidado tenha terminado, pode-se remover a GPU virtual usando (vide exemplo):<\/p>\n
<\/i>\u00a0sudo sh -c ‘echo 1 > \/sys\/bus\/pci\/devices\/0000:00:02.0\/185802b6-7405-11e8-9e14-6ff0319bd0dc\/remove’<\/strong><\/p>\n<\/div>\n
<\/p>\n
OBSERVA\u00c7\u00d5ES ADICIONAIS, RESULTADOS OBTIDOS E REFER\u00caNCIAS<\/h1>\n
<\/p>\n
Inicialmente: n\u00e3o me responsabilizo por danos ou perda de capacidade consequentes de seguir esses passos. \u00c9 por sua pr\u00f3pria conta e risco. O que est\u00e1 descrito aqui foi testado e funcionou de forma adequada, mas n\u00e3o \u00e9 poss\u00edvel garantir o pleno funcionamento de nada descrito aqui ou outros casos impl\u00edcitos.<\/p>\nAlgumas etapas como a configura\u00e7\u00e3o do servidor VNC sem senha e a n\u00e3o ativa\u00e7\u00e3o do firewall foram feitas de tal forma porque considera-se que o sistema convidado pode ter plena confian\u00e7a no hospedeiro e ele s\u00f3 pode ser acessado a partir do hospedeiro. N\u00e3o exponha um computador configurado daquela forma direto na internet!<\/p>\n
Nas refer\u00eancias, h\u00e1 algumas op\u00e7\u00f5es adicionais que s\u00e3o utilizadas nos exemplos, mas que n\u00e3o foi poss\u00edvel encontrar suas fun\u00e7\u00f5es e, aparentemente, a aus\u00eancia n\u00e3o prejudicou o desempenho ou a estabilidade dos convidados ou do hospedeiro. Por isso, foram omitidas.<\/p>\n
Prepare-se para o dmesg ficar vermelho: muit\u00edssimas mensagens de erro surgem, praticamente todas inofensivas. A partir da vers\u00e3o 4.17 do kernel\u00a0Linux<\/a>, v\u00e1rias delas deixaram de existir, tornando a leitura do dmesg mais f\u00e1cil.<\/p>\n
O qu\u00e3o capazes s\u00e3o os convidados criados com iGVT-g? Os resultados variam bastante, mas geralmente eles s\u00e3o muito positivos. Referente \u00e0s capacidades de codifica\u00e7\u00e3o de v\u00eddeo com VA-API, um v\u00eddeo de teste foi usado como refer\u00eancia. O teste realizado \u00e9 codificar esse v\u00eddeo usando o FFmpeg com o seguinte comando:<\/p>\n
<\/i>\u00a0ffmpeg -vaapi_device \/dev\/dri\/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i input.webm -vf format=nv12,hwupload -acodec aac -vcodec h264_vaapi output.mp4<\/strong><\/p>\n
O hospedeiro com Xubuntu 18.04 codifica o v\u00eddeo a uma velocidade de 13,5x o tempo real. O convidado com Xubuntu 18.04, executando o mesmo comando com a mesma vers\u00e3o do FFmpeg para codificar o v\u00eddeo o codifica a uma velocidade de 8x o tempo real.<\/p>\n
Foi percebida uma diferen\u00e7a not\u00e1vel no uso de recursos do hospedeiro entre o comando ser executado no hospedeiro ou no convidado. Usando o programa intel-gpu-overlay junto com o Xephyr, foi poss\u00edvel capturar a tela mostrando a diferen\u00e7a existente:<\/p>\n
Hospedeiro:<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_codifica_host.png\")
<\/a><\/div>\nConvidado:<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_codifica_guest.png\")
<\/a><\/div>\nNo Windows 10, o FFmpeg utiliza os codificados Intel QSV (Quick Sync Video) ao inv\u00e9s de VA-API. O comando no Windows ficaria algo como:<\/p>\n
<\/i>\u00a0ffmpeg -i input.webm -acodec aac -vcodec h264_qsv output.mp4<\/strong><\/p>\n
E a velocidade obtida foi de 5,5x o tempo real. A vers\u00e3o do FFmpeg era diferente, o sistema era diferente e, mesmo assim, o codificador Intel QSV funcionou corretamente.<\/p>\n
Os resultados de benchmark foram bastante interessantes. Foi utilizado o PassMark PerformanceTest 9.0 para obter os resultados. O sistema hospedeiro com Windows 10 obteve o seguinte resultado:<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_HostW10.png\")
<\/a><\/div>\nO convidado Windows 10 com o driver vers\u00e3o 15.45:<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_GuestW101545.png\")
<\/a><\/div>\nO convidado Windows 10 com o driver vers\u00e3o 24.20:<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_GuestW102420.png\")
<\/a><\/div>\nChegou-se ao ponto de o convidado ter um desempenho 3D maior que o hospedeiro, mesmo com a sobrecarga do KVM mais o hospedeiro Linux. Evidentemente, um teste do “mundo real” deveria ser feito:<\/p>\n
![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_PlantSimulation13Demo.PNG\")
<\/a><\/div>\n![\"\"](\"https:\/\/img.vivaolinux.com.br\/imagens\/artigos\/comunidade\/thumb_EuroTruckW10Convidado.png\")
<\/a><\/div>\n