Após uma transição bem-sucedida para os desenvolvedores de software Linux, chegou o momento em que um pouco de trabalho também mudou o sistema operacional principal. As preocupações foram causadas pelo software necro-plataforma para apoiar projetos existentes. Parte do software trabalhava com vinho. No entanto, alguns softwares se recusam a trabalhar com vinho. Foi decidido executar o software na máquina virtual QEMU + KVM. O software começou a funcionar, mas trabalhar nele era bastante inconveniente. As placas de vídeo virtuais de software não diferem no desempenho, e o suporte a gráficos 3D é muito modesto. Eu tive que descobrir o pandeiro e procurar uma saída.
Aloque uma placa de vídeo separada para o sistema convidado!
Não demorou muito tempo para encontrar uma saída, mas a idéia de acertar um pandeiro com um holofote acabou sendo muito estranha. No tópico de encaminhamento de placas de vídeo para uma máquina virtual, a Internet está repleta de instruções diversas vezes e para vários hardwares. O que é um grande artigo no site do Arch Linux
[0] . Darei uma versão resumida das instruções para encaminhar uma placa de vídeo.
0. Verifique se o hardware suporta IOMMU
Por exemplo, aqui
[1] .
1. Incluímos suporte ao IOMMU em um kernel.
cat / etc / default / grubGRUB_CMDLINE_LINUX_DEFAULT = "respingo silencioso amd_iommu = ativado"
ou
GRUB_CMDLINE_LINUX_DEFAULT = "respingo silencioso intel_iommu = ativado"
Não se esqueça do
sudo update-grub
.
2. Nós selecionamos a placa de vídeo do driver
Pesquisamos os dispositivos necessários e vemos quais drivers os utilizam.
lspci -nnk04: 00.0 Controlador compatível com VGA [0300]: NVIDIA Corporation GT218 [GeForce 210] [ 10de: 0a65 ] (rev a2)
Driver de kernel em uso: nouveau
Módulos do kernel: nvidiafb, nouveau
04: 00.1 Dispositivo de áudio [0403]: Controlador de áudio de alta definição NVIDIA Corporation [ 10de: 0be3 ] (rev a1)
Driver de kernel em uso: snd_hda_intel
Módulos do kernel: snd_hda_intel
Adicione módulos VFIO para que eles sejam carregados no momento da inicialização.
cat / etc / modules | grep vfiovfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
Configuramos o módulo VFIO para que ele intercepte dispositivos, impedindo o carregamento dos principais drivers. Se necessário, adicione à lista negra o driver principal.
cat /etc/modprobe.d/vfio.confopções vfio-pci ids = 10de: 0a65,10de: 0be3
lista negra nouveau
3. Reinicialize e verifique se tudo deu certo
IOMMU ligado.
dmesg grep -e DMAR -e IOMMU -e AMD-ViDMAR: Tecnologia de virtualização Intel® para E / S direcionada
ou
AMD-Vi: IOMMU encontrado em 0000: 00: 00.2 cap 0x40
AMD-Vi: remapeamento de interrupção ativado
AMD-Vi: liberação lenta de IO / TLB ativada
Dispositivos compostos caíram em um grupo.
para um em / sys / kernel / iommu_groups / *; encontre $ a -type l; feito | sort --version-sort/sys/kernel/iommu_groups/15/devices/0000:01:00.0
/sys/kernel/iommu_groups/15/devices/0000:01:00.1
/sys/kernel/iommu_groups/16/devices/0000:02:00.0
/sys/kernel/iommu_groups/17/devices/0000:03:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.1
Drivers KVM e VFIO carregados.
lsmod | grep -e kvm -e vfio kvm_amd 94208 0
ccp 90112 1 kvm_amd
kvm 622592 1 kvm_amd
vfio_pci 45056 0
vfio_virqfd 16384 1 vfio_pci
irqbypass 16384 2 vfio_pci, kvm
vfio_iommu_type1 24576 0
vfio 28672 2 vfio_iommu_type1, vfio_pci
Placa de vídeo para o sistema operacional convidado capturada pelo VFIO.
lspci -nnk04: 00.0 Controlador compatível com VGA [0300]: NVIDIA Corporation GT218 [GeForce 210] [ 10de: 0a65 ] (rev a2)
Driver de kernel em uso: vfio-pci
Módulos do kernel: nvidiafb, nouveau
04: 00.1 Dispositivo de áudio [0403]: Controlador de áudio de alta definição NVIDIA Corporation [ 10de: 0be3 ] (rev a1)
Driver de kernel em uso: vfio-pci
Módulos do kernel: snd_hda_intel
4. Configure o QEMU e inicie o SO convidado
Instalar, se ainda não estiver instaladosudo apt instala o qemu-kvm qemu-utils seabios ovmf virt-viewer
Crie um disco em que o sistema operacional convidado será instaladoqemu-img create -f raw -o pré-posicionamento = hóspede completo.img 50G
ou
fallocate -l 50G guest.img
Iniciamos a máquina virtual sem encaminhar a placa de vídeo para instalar o SO convidado. Como existe uma visão do Looking Glass, vale a pena escolher o Windows 10. Para o hóspede, o Windows 10. O Windows 8 / 8.1 de acordo com os dados mais recentes também é suportado.
vga_qxl.sh#! / bin / bash
tempero de visualizador remoto: //127.0.0.1: 5900 &
sudo qemu-system-x86_64 \
-máquina q35, accel = kvm \
-enable-kvm \
-cpu host, kvm = desativado, marque \
-smp cpus = 2, soquetes = 1, núcleos = 2, threads = 1 \
-m 6G \
-rtc base = hora local, relógio = host \
-dispositivo piix3-usb-uhci \
-dispositivo usb-tablet \
-drive if = pflash, formato = bruto, somente leitura, arquivo = / usr / share / OVMF / OVMF_CODE.fd \
-drive arquivo = 'w10.iso', se = ide, formato = bruto, índice = 2, mídia = cdrom, cache = nenhum \
-drive arquivo = 'virtio-win-0.1.141_st.iso', se = ide, formato = bruto, índice = 3, mídia = cdrom, cache = nenhum \
-drive arquivo = 'guest.img', se = ide, formato = bruto, índice = 4, mídia = disco, cache = write-back \
-vga qxl \
-spice port = 5900, addr = 127.0.0.1, disable-ticketing \
-monitor stdio \
-netdev user, id = n1, ipv6 = off, smb = "/ media / user / data" \
-dispositivo e1000, netdev = n1, mac = 67: 77: 78: 88: 89: 99 \
"$ @"
5. Encaminhamos a placa de vídeo para o SO convidado
Para começar, inicialize com duas placas de vídeo. Observamos que a placa encaminhada apareceu no sistema, colocamos os drivers e garantimos que eles funcionem.
vga_qxl_pass.sh#! / bin / bash
tempero de visualizador remoto: //127.0.0.1: 5900 &
sudo qemu-system-x86_64 \
-máquina q35, accel = kvm \
-enable-kvm \
-cpu host, kvm = desativado, marque \
-smp cpus = 2, soquetes = 1, núcleos = 2, threads = 1 \
-m 6G \
-rtc base = hora local, relógio = host \
-dispositivo piix3-usb-uhci \
-dispositivo usb-tablet \
-drive if = pflash, formato = bruto, somente leitura, arquivo = / usr / share / OVMF / OVMF_CODE.fd \
-drive arquivo = 'virtio-win-0.1.141_st.iso', se = ide, formato = bruto, índice = 3, mídia = cdrom, cache = nenhum \
-drive arquivo = 'guest.img', se = ide, formato = bruto, índice = 4, mídia = disco, cache = write-back \
-vga qxl \
-spice port = 5900, addr = 127.0.0.1, disable-ticketing \
- dispositivo ioh3420, barramento = pcie.0, endereço = 1c.0, multifuncional = ativado, porta = 1, chassi = 1, id = root \
-device vfio-pci, host = 04: 00.0, barramento = raiz, endereço = 00.0, multifuncional = ativado \
-dispositivo vfio-pci, host = 04: 00.1, barramento = raiz, endereço = 00.1 \
-monitor stdio \
-netdev user, id = n1, ipv6 = off, smb = "/ media / user / data" \
-dispositivo e1000, netdev = n1, mac = 67: 77: 78: 88: 89: 99 \
"$ @"
Depois de como a placa de vídeo encaminhada funcionou, e no gerenciador de dispositivos escrever “O dispositivo está funcionando bem”, iniciamos a máquina virtual apenas com a placa de vídeo encaminhada.
vga_pass.sh#! / bin / bash
sudo qemu-system-x86_64 \
-máquina q35, accel = kvm \
-enable-kvm \
-cpu host, kvm = desativado, marque \
-smp cpus = 2, soquetes = 1, núcleos = 2, threads = 1 \
-m 6G \
-rtc base = hora local, relógio = host \
-dispositivo piix3-usb-uhci \
-dispositivo usb-tablet \
-drive if = pflash, formato = bruto, somente leitura, arquivo = / usr / share / OVMF / OVMF_CODE.fd \
-drive arquivo = 'virtio-win-0.1.141_st.iso', se = ide, formato = bruto, índice = 3, mídia = cdrom, cache = nenhum \
-drive arquivo = 'guest.img', se = ide, formato = bruto, índice = 4, mídia = disco, cache = write-back \
-vga nenhum \
- dispositivo ioh3420, barramento = pcie.0, endereço = 1c.0, multifuncional = ativado, porta = 1, chassi = 1, id = root \
-device vfio-pci, host = 04: 00.0, barramento = raiz, endereço = 00.0, multifuncional = ativado \
-dispositivo vfio-pci, host = 04: 00.1, barramento = raiz, endereço = 00.1 \
-monitor stdio \
-netdev user, id = n1, ipv6 = off, smb = "/ media / user / data" \
-dispositivo e1000, netdev = n1, mac = 67: 77: 78: 88: 89: 99 \
"$ @"
Conectamos um monitor a ele e admiramos a imagem da área de trabalho do sistema operacional convidado.
O lugar onde as decisões simples terminam
E então a diversão começa. Alguém, está tudo bem, a imagem desapareceu e tudo é simples. Minha experiência tropeçou duas vezes no estágio de ausência de imagem. A primeira vez foi o encaminhamento da placa de vídeo integrada do processador Intel 6700T HD 530, as saídas de vídeo estavam vazias e a falha foi atribuída ao fato de os plug-ins não funcionarem bem. Na segunda vez que a Nvidia GF210 externa foi lançada, que já havia sido comprada especialmente para experimentos. O resultado foi ainda mais interessante. No modo não EFI, a placa de vídeo foi encaminhada com sucesso e até mostrou uma imagem, mas
desativou o sistema operacional convidado.
O encaminhamento subsequente pode simplesmente travar o host. Algumas horas de fácil busca no Google levam ao fato de que o problema de congelar uma placa de vídeo é bastante comum. Isso leva ao desligamento incorreto da máquina virtual e, com alguma chance, até ao desligamento correto. Como saída, é recomendável encaminhar no modo EFI. Mas o VBIOS Nvidia GF210 não suporta EFI ...
Costurar ou não costurar, eis a questão
Não costure. O QEMU suporta falsificação VBIOS ao encaminhar uma placa de vídeo. Mas o VBIOS ainda precisa ser ensinado a suportar o modo EFI. Geralmente é recomendável verificar isso antes de começar a encaminhar a placa de vídeo, por exemplo aqui
[2] . Mas é preciso lidar com o que é e não queremos procurar uma nova placa de vídeo com suporte à EFI. Então você precisa corrigir o VBIOS.
Todas as operações realizadas com o VBIOS são feitas por sua conta e risco. Eu usei um pacote de software e instruções para ele daqui
[3] . Depois de ler o VBIOS, obtemos o arquivo
gt210.rom
, patch e, na saída, temos
gt210_uefi.rom
. É aqui que você precisa deslizar a placa de vídeo ao carregar a máquina virtual.
vga_pass_rom.sh#! / bin / bash
sudo qemu-system-x86_64 \
-máquina q35, accel = kvm \
-enable-kvm \
-cpu host, kvm = desativado, marque \
-smp cpus = 2, soquetes = 1, núcleos = 2, threads = 1 \
-m 6G \
-rtc base = hora local, relógio = host \
-dispositivo piix3-usb-uhci \
-dispositivo usb-tablet \
-drive if = pflash, formato = bruto, somente leitura, arquivo = / usr / share / OVMF / OVMF_CODE.fd \
-drive arquivo = 'virtio-win-0.1.141_st.iso', se = ide, formato = bruto, índice = 3, mídia = cdrom, cache = nenhum \
-drive arquivo = 'guest.img', se = ide, formato = bruto, índice = 4, mídia = disco, cache = write-back \
-vga nenhum \
- dispositivo ioh3420, barramento = pcie.0, endereço = 1c.0, multifuncional = ativado, porta = 1, chassi = 1, id = root \
-dispositivo vfio-pci, host = 04: 00.0, barramento = raiz, endereço = 00.0, multifuncional = ativado , romfile = gt210_uefi.rom \
-dispositivo vfio-pci, host = 04: 00.1, barramento = raiz, endereço = 00.1 \
-monitor stdio \
-netdev user, id = n1, ipv6 = off, smb = "/ media / user / data" \
-dispositivo e1000, netdev = n1, mac = 67: 77: 78: 88: 89: 99 \
"$ @"
Começamos a máquina virtual e olhamos.
Escuridão
As saídas da placa de vídeo brilhavam no escuro. Mais uma vez, a moralidade passou no teste do fracasso. A primeira coisa que vem à mente é que o sistema operacional convidado trava na inicialização. Logs, preciso dos logs dela. Para fazer isso, execute
vga_qxl.sh
. Nós olhamos para o lançamento anterior. E está tudo bem, exceto que a comida foi cortada com força. Acontece que funciona, embora não funcione. A primeira idéia foi conectar via RDP e ver o que acontece lá, mas ainda é melhor usar o VNC, por exemplo, tightvnc
[4] . Instalamos o VNC, configuramos a porta
5600
e encaminhamos essa porta para acesso do host.
vga_vnc_pass_rom.sh#! / bin / bash
sudo qemu-system-x86_64 \
-máquina q35, accel = kvm \
-enable-kvm \
-cpu host, kvm = desativado, marque \
-smp cpus = 2, soquetes = 1, núcleos = 2, threads = 1 \
-m 6G \
-rtc base = hora local, relógio = host \
-dispositivo piix3-usb-uhci \
-dispositivo usb-tablet \
-drive if = pflash, formato = bruto, somente leitura, arquivo = / usr / share / OVMF / OVMF_CODE.fd \
-drive arquivo = 'virtio-win-0.1.141_st.iso', se = ide, formato = bruto, índice = 3, mídia = cdrom, cache = nenhum \
-drive arquivo = 'guest.img', se = ide, formato = bruto, índice = 4, mídia = disco, cache = write-back \
-vga nenhum \
- dispositivo ioh3420, barramento = pcie.0, endereço = 1c.0, multifuncional = ativado, porta = 1, chassi = 1, id = root \
-dispositivo vfio-pci, host = 04: 00.0, barramento = raiz, endereço = 00.0, multifuncional = ativado, romfile = gt210_uefi.rom \
-dispositivo vfio-pci, host = 04: 00.1, barramento = raiz, endereço = 00.1 \
-monitor stdio \
-netdev user, id = n1, hostfwd = tcp: 127.0.0.1: 5600-: 5600, ipv6 = off, smb = "/ media / user / data" \
-dispositivo e1000, netdev = n1, mac = 67: 77: 78: 88: 89: 99 \
"$ @"
Conectamos e vemos a máquina em funcionamento, apenas o monitor possui um Monitor Genérico Não-PnP estranho (o Universal Monitor não é PnP). Há uma imagem, para que você possa tentar executar o Looking Glass.
Espelho
Embora essa tecnologia use o OpenGL, não é necessário espaço após o gl. Mas você precisa ler as instruções
[5] no site do projeto. Para o sistema operacional convidado, faça o download da tela
- capture o aplicativo
olhando-glass-host.exe [6] , faça o download e instale o Microsoft Visual C ++ 2015 Redistributable
[7] , faça o download do driver do dispositivo IVSHMEM
[8] . Adicionamos dependências para o host, baixamos e construímos o aplicativo cliente.
build_looking_glass_a12.sh#! / bin / bash
sudo apt-get install cmake libsdl2-dev libsdl2-ttf-dev nettle-dev libspice-protocol-dev libfontconfig1-dev libx11-dev fontes-freefont-ttf libconfig-dev
wget github.com/gnif/LookingGlass/archive/a12.tar.gz
tar -xf a12.tar.gz
cd LookingGlass-a12
cliente / compilação mkdir
cliente / construção de cd
cmake ../
fazer
Iniciamos a máquina virtual com o dispositivo IVSHMEM. O tamanho da memória de 32 Mb é selecionado para uma resolução de 1920x1080.
vga_vnc_lg_pass_rom.sh#! / bin / bash
se [! -f / dev / shm / espelho]; então
toque / dev / shm / espelho
chown `whoami`: kvm / dev / shm / espelho
chmod 660 / dev / shm / espelho
fi
sudo qemu-system-x86_64 \
-máquina q35, accel = kvm \
-enable-kvm \
-cpu host, kvm = desativado, marque \
-smp cpus = 2, soquetes = 1, núcleos = 2, threads = 1 \
-m 6G \
-rtc base = hora local, relógio = host \
-dispositivo piix3-usb-uhci \
-dispositivo usb-tablet \
-drive if = pflash, formato = bruto, somente leitura, arquivo = / usr / share / OVMF / OVMF_CODE.fd \
-drive arquivo = 'virtio-win-0.1.141_st.iso', se = ide, formato = bruto, índice = 3, mídia = cdrom, cache = nenhum \
-drive arquivo = 'guest.img', se = ide, formato = bruto, índice = 4, mídia = disco, cache = write-back \
-vga nenhum \
- dispositivo ioh3420, barramento = pcie.0, endereço = 1c.0, multifuncional = ativado, porta = 1, chassi = 1, id = root \
-dispositivo vfio-pci, host = 04: 00.0, barramento = raiz, endereço = 00.0, multifuncional = ativado, romfile = gt210_uefi.rom \
-dispositivo vfio-pci, host = 04: 00.1, barramento = raiz, endereço = 00.1 \
-device ivshmem-plain, memdev = ivshmem, barramento = pcie.0 \
-objeto de arquivo de back-end de memória, id = ivshmem, compartilhamento = ativado, caminho de mem = / dev / shm / espelho, tamanho = 32M \
-monitor stdio \
-netdev user, id = n1, hostfwd = tcp: 127.0.0.1: 5600-: 5600, ipv6 = off, smb = "/ media / user / data" \
-dispositivo e1000, netdev = n1, mac = 67: 77: 78: 88: 89: 99 \
"$ @"
Nós nos conectamos via VNC, instalamos o driver no dispositivo IVSHMEM, talvez um driver padrão seja instalado nele, localizado em "Dispositivos do sistema". Começamos a
olhar-glass-host.exe . No host, execute
./LookingGlass-a12/client/build/looking-glass-client
.
Com isso, um sistema com NVidia GF210 funcionou para mim e, em seguida, o Intel HD530 foi lançado na mesma rota. Houve um pequeno problema com a resolução da tela. Para mudar para uma resolução rara, por exemplo 2048x1152, tive que usar o Custom Resolution Utility
[9] .
Outra nuance, ao adicionar o
aplicativo olhando-espelho-host.exe ao carregamento automático, você precisa configurar o login automático do usuário; por motivos de segurança, o sistema operacional convidado não permite capturar a tela de login.
Posfácio
Se você não definir uma tarefa, obtendo uma imagem em uma saída de vídeo físico, esse resultado será suficiente para obter uma máquina virtual em funcionamento com uma placa de vídeo física e controle responsivo. O gerenciamento é realizado a partir do host em uma janela separada ou em tela cheia. No entanto, existem nuances.
Performance . Os recursos indiretos para virtualização e não o sistema operacional convidado mais eficiente não permitirão que você trabalhe confortavelmente em hardware fraco e médio-baixo. Isso exigirá um processador poderoso de pelo menos 6 a 8 núcleos, uma boa placa gráfica para um sistema operacional convidado, 16 GB + RAM, pelo menos 8 GB para cada sistema operacional. E dançando com um pandeiro para aproveitar ao máximo o ferro.
Paciência . Se não funcionar imediatamente, você terá que gastar tempo e tempo decentemente. Pesquise, leia, tente. Mais uma vez, olhe, leia e tente novamente. Deixarei mais alguns links que encontrei, talvez haja mais informações úteis.
[10] [11] [12]ReferênciasCuidado, os links são abertos nesta janela.
0. https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF1. https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware2. https://www.techpowerup.com/vgabios/3. https://www.win-raid.com/t892f16-AMD-and-Nvidia-GOP-update-No-requests-DIY.html4. https://www.tightvnc.com/download.php5. https://looking-glass.hostfission.com/quickstart6. https://github.com/gnif/LookingGlass/releases7. https://www.microsoft.com/en-us/download/details.aspx?id=481458. https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/upstream-virtio/9. https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU10. https://heiko-sieger.info/running-windows-10-on-linux-using-kvm-with-vga-passthrough11. https://ycnrg.org/vga-passthrough-with-ovmf-vfio/12. https://www.reddit.com/r/VFIO/comments/8h352p/guide_running_windows_via_qemukvm_and_intel_gvtg/