Virtualização: Windows em Linux KVM com drivers Virtio

Nemesis11

Power Member
kvm.png


Este é um pequeno guia de como, a meu ver, instalar Windows dentro de KVM.
KVM é um hypervisor tipo 1 que se encontra integrado no kernel de Linux.

O guia serve para mostrar como instalar Windows com os drivers VirtIO, que se pode dizer que são os drivers nativos de KVM.
São quatro os drivers. Controladora de discos, rede, ligação série e "balloon" que é algo um pouco diferente de um simples driver, como podem ver no guia.

Pessoalmente, gosto muito de KVM, mas a meu ver arranjar documentação nem sempre é simples, especialmente em funcionalidades mais avançadas, que não é propriamente o caso deste guia.
Espero que sirva a alguém. :)

Link
 
qual a diferença entre isto e o virtualbox? este e melhor?

São bastante diferentes.

O Kvm usa extensões de hardware e por isso só funciona com um processador com VT. Virtualbox usa binary translation. Dito assim pode parecer que Virtualbox só pode ser mais lento, mas a maior parte das vezes que se usa Vmware, ele faz binary translation e não falta sucesso à Vmware.

O Kvm é mais virado para o mercado servidor, apesar de começar a ser mais "frendly" em desktops, com Spice, suporte Usb2 recentemente. O Virtualbox é mais user frendly, apesar de ter algumas coisas interessantes para o mercado servidor, como um iscsi initiator integrado, ligações RDP, etc. Por outro lado, é preciso andar-se a instalar as "tools", que basicamente são drivers. Em Kvm também, mas só em Windows e são infs, não são setups.

O Kvm é muito mais poderoso que o Virtualbox. Desde criar um VM com 32 processadores, mesmo que só tenhas um real, escolher que funcionalidades do processador passas para a máquina virtual, reservar processadores físicos a virtuais, reservar cache L3 ou L2 para uma máquina virtual, storage distribuída com o sheepdog, multiplas redes com o virtualbricks, redirectionamento usb por rede, correr um hypervisor dentro de outro hypervisor (uma das coisas que mais gosto e que a documentação está desactualizada). Enfim, é "hacker" frendly, mas tem muita configuração por onde se mexer.
No entanto, para o utilizador comum isto pouco interessa. É um bocado matar uma formiga com um elefante.

Em relação à performance, não acho o Virtualbox nada de especial, mas é complicado comparar pela infinidade de cenários possíveis onde se podem correr benchmarks.
Pessoalmente, parece-me o produto de virtualização mais lento do mercado, mas não é que seja muito pior ou mau por isso.

O Kvm tem suporte principalmente da Red Hat. Penso que a IBM também suporta. Ubuntu suporta Kvm.
Mas isto é mais uma "guerra" entre o Kvm e o Xen.
Virtualbox é da Oracle. Por acaso é um dos projectos que a Oracle não tem influenciado negativamente depois de ser deles. Para empresas, em Linux, a Oracle suporta mais Xen, apesar da ferramenta de gestão deles também suporta Virtualbox.

Concluíndo, o Kvm pode ser usado para home/single user, mas o Virtualbox é mais fácil e simples. Para a maior parte das pessoas, o Virtualbox faz perfeitamente o trabalho.
 
Só um pormenor, que não coloquei no artigo, porque normalmente só uso o KVM para testes com máquinas a fazer de servidor e porque este driver que aqui vou adicionar, não está no ficheiro iso (não sei bem porquê......).
Uma das gráficas que se pode colocar para os guests, é qxl. Aqui encontram-se os drivers para ela -> http://spice-space.org/download/binaries/
Nesse repositório, parece-me que também tem os agentes do Spice, que penso que adicionará funcionalidades ao Spice, visto que ele funciona sem o agente. Deve ser mais para cenários de VDIs.
Para quem não sabe o que é o spice, é um protocolo semelhante ao rdp da Microsoft, por exemplo. É melhor que VNC (qualquer coisa é melhor que VNC......)

Por último, os drivers da Fedora são assinados digitalmente, para se poder instalar em Windows 64 bit, mas não são WHQL.
Para 99% das vezes, isso pouco importa, mas há situações (Failover cluster por exemplo) em que o Windows não gosta mesmo nada que estejam instalados drivers que não sejam WHQL, especialmente na parte de storage.

Existem drivers WHQL, mas penso que só existam no repositório do Red Hat e penso que não são públicos.
 
O Kvm é muito mais poderoso que o Virtualbox. Desde criar um VM com 32 processadores, mesmo que só tenhas um real...

Viva
Uso bastante VM. No meu PC uso virtualbox para as desenvolver e implemento nos clientes com vmware.
Nunca experimentei KVM. Como é a nível de licenciamento? Sem querer entrar em grandes discussões, este pormenor que expuseste de ter ter mais processadores virtuais que físicos não é contra-producente? Numa situação em que tens 2 ou 3 VM num PC esta situação não será insuportável?

Cump
 
Viva
Uso bastante VM. No meu PC uso virtualbox para as desenvolver e implemento nos clientes com vmware.
Nunca experimentei KVM. Como é a nível de licenciamento? Sem querer entrar em grandes discussões, este pormenor que expuseste de ter ter mais processadores virtuais que físicos não é contra-producente? Numa situação em que tens 2 ou 3 VM num PC esta situação não será insuportável?

Cump

Primeiro que tudo, não quero fazer um frente a frente de tecnologias de virtualização, porque a meu ver, hoje em dia não há maus produtos de virtualização. São apenas diferentes e virados mais para um certo mercado.
Há várias coisas interessantes no KVM, mas talvez a mais interessante é a quantidade "doida" de opções.

1- Licenciamento? Depende das partes, mas são todos GPL ou derivados de GPL. O Hypervisor está dentro do Kernel Linux. KVM - Kernel-based Virtual Machine.
Quanto às ferramentas que correm por cima, existem bastantes que são open source. Libvirt, virsh, Virt-manager, proxmox, opennode, virtual bricks, etc.
Depois tens produtos completos pagos, como o RHEV da Red Hat, que penso que ainda não é tudo open source. Eles foram buscar a tecnologia à qumranet, empresa que a Red Hat comprou.
De resto, acho que os drivers WHQL para Windows, não são públicos.

2 - Sim, ter mais processadores virtuais, em apenas uma máquina virtual, do que os totais físicos da máquina real, especialmente em load, é contra-producente.
Penso que ninguém faz isto em produção.
Só vejo isto ser interessante em situações de teste, a ver se um produto ou código, funciona ou escala em múltiplos processadores/cores/threads.
No Kvm há formas de optimizar a utilização de processador. Activar/desactivar instruções, topologia NUMA da máquina, "pinning" (relação directa) entre um processador virtual e um físico ou entre um processador virtual e a memória L2 ou L3 de um físico, etc.

3 - A quantidade de máquinas virtuais que se corre corre numa máquina depende de vários factores e diria que raramente o processador é o primeiro limite. Normalmente os limites aparecem primeiro em memória Ram e disco/storage. Depende muito do que se corre nas máquinas virtuais.
Tens cenários, normalmente VDIs (Desktops virtuais) em que tens um rácio enorme entre máquinas virtuais e físicas. Conheço um caso em que o rácio é 100 virtuais por 1 física, em que a física tem "apenas" 24 cores. No entanto, os servidores são muito mais poderosos do lado da ram e storage.
 
como se carrega o driver som no kvm?
ps: não consigo ter som no windows via kvm, só em ditros linux é que carregam.
 
1- Licenciamento? Depende das partes, mas são todos GPL ou derivados de GPL. O Hypervisor está dentro do Kernel Linux. KVM - Kernel-based Virtual Machine.

Esta parte é mais complicada. Licenciamento de que? Dos guests ou dos hosts? Os hosts em KVM é irrelevant, guests Windows ou Oracle pagam licenciamento independentemente do host. Por exemplo se for um Windows Server 2016 pagas licenciamento sob o numero de cores fisicos do host e tens que ter uma licença por cada VM. Para versoes anteriores é diferente, o licenciamento é sobre slots e nao cores e podes ter duas vm's com uma licença (salvo se tiveres um tipo de licença/acordo especial com a M$).

2 - Sim, ter mais processadores virtuais, em apenas uma máquina virtual, do que os totais físicos da máquina real, especialmente em load, é contra-producente.
Penso que ninguém faz isto em produção.

Virtualização nao é o meu forte, mas sobre VMware e em arquitecturas NUMA o processamento pode ser enviado para uma unidade remota (ex: outra blade). Existe em produção é nao é completamente desconhecido. Um dos casos em que isto acontece é por exemplo no processamento de imagens para mapas. Podes enviar o processamento para 'fora', por exemplo gerar X tiles de tamanhos diferentes de uma imagem e/ou conjunto.

No entanto, nenhum fornecedor de virtualização o recomenda por questoes obvias, a maior parte do pessoal vai por overbooking na plataforma apenas porque dá e sem compreender os potenciais problemas que podem surgir.
 
Back
Topo