Estou fazendo uma pesquisa sobre QEMU/KVM e Firecracker/KVM. Pelo que entendi, tanto o Firecracker quanto o QEMU se comunicam com o KVM para eventualmente beneficiar a virtualização assistida por hardware, alterando o modo da CPU para convidado para host e vice-versa.
No modo convidado da CPU, o convidado pode executar diretamente até mesmo suas instruções privilegiadas, então por que também precisamos de paravirtualização?
No Firecracker, apenas 5 dispositivos emulados, como
- virtio-net,
- bloco virtio,
- virtio-vsock e assim por diante.
Mesmo neste design minimalista, temos que colocar drivers de paravirtualização. Não podemos depender apenas da virtualização assistida por hardware?
Considere apenas o caso da rede.
Para ser realmente útil na maioria dos casos, uma VM precisa ser capaz de se comunicar pela rede. Para isso, o convidado obviamente precisa ver algum tipo de interface de rede. Mas VT-x, AMD-V e ARM VHE e praticamente todas as outras implementações de virtualização de hardware não fornecem NICs, apenas fornecem uma maneira de segregar e particionar com segurança os recursos da CPU. Portanto, a virtualização de hardware não faz nada para fornecer uma interface de rede.
Agora, você poderia passar por uma interface de rede física do sistema host, mas isso apresenta vários problemas:
Obviamente, você precisa emular uma interface de rede de alguma forma. A escolha óbvia seria apenas escolher uma NIC física comumente usada e emular isso. Mas isso tem seu próprio conjunto de problemas:
virtio-net resolve esses problemas, cobre apenas o que é realmente necessário para mover pacotes de rede entre o sistema operacional convidado e a camada de rede host, e nada mais. E resolver esses problemas proporciona uma enorme melhoria de desempenho. Não testei recentemente, mas da última vez que comparei usando QEMU, o virtio-net forneceu mais que o dobro da largura de banda efetiva de uma placa e1000 emulada e aproximadamente 1/10 da latência, tudo com menor uso de CPU no lado do host .
A mesma lógica se aplica à maioria dos outros dispositivos. Algumas coisas podem ser emuladas de forma relativamente barata ou não são críticas para o desempenho e, portanto, não precisam ser eficientes (é por isso que não há temporizador de watchdog VirtIO, por exemplo, não é crítico para o desempenho e é trivial emular na maioria dos casos), mas para a maioria das coisas que não se enquadram nesses critérios, existe uma opção paravirt porque a diferença de desempenho é enorme e a complexidade reduzida tende a tornar as coisas mais confiáveis.
E às vezes a paravirtualização permite fazer coisas que você realmente não poderia fazer com hardware “normal”. VirtIOFS e o transporte VirtIO para 9P2000 são excelentes exemplos disso, eles não possuem análogos de hardware, mas fornecem uma maneira razoavelmente eficiente de compartilhar arquivos entre o host e o convidado sem a necessidade de emular uma rede ou um dispositivo de bloco.
Resposta curta: quando aumentada com drivers do lado convidado, a virtualização de hardware moderna usa alguma forma de paravirtualização para as operações de maior desempenho. Conseqüentemente, os hipervisores modernos reúnem suporte de hardware dedicado e paravirtualização.
Versão longa: o arco X86 original era bastante difícil de virtualizar e usar corretamente com sistema operacional não modificado. Uma solução foi traduzir dinamicamente os fragmentos de código problemáticos, recompilando-os rapidamente. Isso permitiu que o convidado não modificado fosse executado, mas as desvantagens eram a alta sobrecarga e a complexidade do próprio tradutor. Além disso, cada tipo de kernel convidado precisava de tratamento especial.
Por esta razão, os projetos começaram a modificar o kernel do Linux para evitar os casos difíceis - ou seja: quando uma instrução/chamada não é facilmente virtualizada, vamos chamar uma hiperchamada do hipervisor subjacente. Uma hiperchamada é a base da paravirtualização e você pode considerá-la equivalente ao syscall do espaço do usuário. Em outras palavras, o kernel Linux subjacente era o sistema operacional host onde outro kernel Linux seria executado como um aplicativo "espaço de usuário" convidado.
Essa abordagem minimiza a sobrecarga de virtualização, mas precisa de um kernel convidado modificado para funcionar. A instalação padrão do Windows não funcionará. Assim, foi introduzida a virtualização completa de hardware, onde anéis de privilégios adicionais foram adicionados ao microprocessador. Isso permitiu que o sistema operacional host fosse executado em um nível especificamente privilegiado (ou seja: -1, espaço do hipervisor), com o sistema operacional convidado executando inalterado no anel 0 (ou seja: 0, espaço do kernel). No entanto, a emulação de dispositivos virtuais permanece problemática e/ou com alta sobrecarga, portanto, foram criadas unidades convidadas personalizadas. Essas unidades reintroduziram a paravirtualização direcionada para os dispositivos mais sensíveis ao desempenho – disco e rede, especificamente. Isso nos leva à situação atual, onde os hipervisores assistidos por hardware são aumentados com unidades paravirtualizadas direcionadas.
Também fiz algumas pesquisas e acho que isso pode ajudá-lo a entender o assunto, mas pode não abordar o assunto diretamente (talvez). Além da resposta do shodanshok, posso explodir sua resposta "estendida", talvez com uma pegada um pouco enorme
A paravirtualização (pode) permanece relevante por vários motivos:
Wikipedia diz sobre isso:
Acho que, embora possamos consultar o artigo da Wikipedia, pode haver razões pelas quais você não gostaria de expor o hardware diretamente ao convidado, especialmente se estiver vendendo máquinas virtuais alugadas.
Além disso e normalmente, precisamos de padrões e drivers padronizados, bem como interfaces.
Normalmente não queremos lidar com drivers como fizemos ao tentar instalar o Windows 9x/nt/VIST/XP. Mas mais ou menos também 10/07/11 em hardware padrão (a maioria deles já possui, às vezes o suporte VirtIO já incluído). (Especialmente antes do período do Windows 7).
É por isso que precisamos aprender mais sobre a história:
A seção de história do artigo da Wikipedia diz:
Isso me lembra que também o suporte no núcleo dele foi abandonado no passado, por volta de 2011, enquanto a partir de 2008 o VirtIO foi introduzido (talvez como um sucessor)
E um IMHO:
Referências):
Outra resposta contém:
Como contra-argumento, a Single Root IO Virtualization (SR-IOV) pode ser usada para permitir que um dispositivo PCIe físico se apresente várias vezes através do barramento PCIe. Na página NVIDIA (ex Mellanox) vinculada acima:
Como exemplo de provedor de hospedagem de VM, a página Rede aprimorada da Amazon Web Services no Linux contém: