Eu investiguei este tópico e aqui estão minhas conclusões (mas ainda tenho dúvidas e, por favor, corrija-me se cometi algum erro em minha conclusão):
VMware:
VMWare desenvolveu seu VM Hypervisor SW em 1999, mas era proprietário.
QEMU:
4 anos depois do VMWare, o desenvolvedor francês Fabrice Bellard desenvolveu o QEMU (Quick Emulator) Hyporvisor em 2003 e o tornou gratuito e de código aberto. O QEMU tornou-se então um hypervisor tipo 2 de "virtualização completa" após anos de desenvolvimento da comunidade.
- O QEMU é capaz de emular vários HWs, incluindo CPU e dispositivos de E/S.
- O QEMU é capaz de interpretar as instruções enviadas para a vCPU da VM em instruções reais e enviá-las para a CPU física.
- Alguns dispositivos emulados QEMU são amplamente utilizados pelos SWs de virtualização, como o VirtualBox.
- QEMU tem sua própria GUI e CLI.
QEMU é capaz de rodar independentemente sem qualquer outro VM SW.
Virtualização de HW:
Tanto a Intel quanto a AMD lançaram sua tecnologia de virtualização HW (VT-x e AMD-V) em 2006.
KVM:
Em 2006, uma pequena empresa (que foi adquirida pela Red Hat 2 anos depois, em 2008) desenvolveu um módulo kernal carregável para Linux chamado "KVM", que é capaz de criar VMs usando as tecnologias de virtualização de HW mencionadas anteriormente. Foi então oficialmente incorporado ao kernel do Linux em 2007.
- O KVM não emula vCPU, mas usa tecnologias de virtualização de HW fornecidas pela CPU física.
- Como um kernel do Linux, o KVM não possui GUI nem CLI. É preciso escrever, digamos, código C para chamar o módulo KVM para criar VM, tornando-o inútil para os usuários finais.
- O KVM é considerado um Hypervisor.
O KVM é capaz de criar VMs independentemente, sem qualquer suporte de hipervisores, como o QEMU.
libvirt:
Como existem muitos Hypervisors no mercado, o libvirt foi desenvolvido no final de 2005 para unificar a API e CLI de criação e gerenciamento de VMs. Do ponto de vista dos usuários finais, fornece ferramentas CLI como:
- virsh
- virt-manager
- virt-install
A própria libvirt não cria ou gerencia a máquina virtual, mas mapeia o comando emitido pelo usuário para uma ou uma série de chamadas de API para o hipervisor subjacente.
libvirt é gratuito e de código aberto.
virt-manager:
Quando as pessoas usam o KVM para criar VMs, elas provavelmente veem esta tela:
Eu costumava considerar este SW como a GUI do KVM, mas após minha investigação descobri que é outro SW chamado "Virtual Machine Manager", como o título mostra. Também é chamado virt-manager. virt-manager é apoiado pela Red Hat.
De acordo com seu site, virt-manager visa principalmente VMs KVM, mas também gerencia Xen e LXC. Consulte o site oficial do Virtual Machine Manager .
O virt-manager é construído sobre o libvirt. Ou seja, concentra-se em interfaces de usuário (GUI e CLI). Para o gerenciamento de VM subjacente, ele simplesmente chama libvirt, que finalmente chama o hipervisor subjacente, como KVM.
Minhas perguntas:
- Há algum erro na minha conclusão?
- Por que a GUI virt-manager mostra "localhost (QEMU)" ou "QEMU/KVM" em sua lista de VMs quando crio uma máquina virtual KVM?
- libvirt afirma que quase todas as ferramentas de virtualização que começam com virt-* são ferramentas libvirt, especialmente virt-manager e virt-install. Consulte as perguntas frequentes sobre lib-virt . Mas virt-manager alcal virt-install faz parte do virt-manager. Consulte o site do virt-manager . Então qual é o correto? A que exatamente o virt-install e o virt-manager pertencem?
- Alguns artigos falam sobre qemu-kvm, mas de acordo com minha investigação, eles são apenas dois hipervisores diferentes. Posso usar o KVM de forma independente para criar VMs, então por que devo usar o qemu-kvm? E o que é qemu-kvm? É um QEMU que usa alguns recursos KVM quando necessário ou um KVM que precisa usar alguns recursos QEMU, caso contrário, não será capaz de criar VMs?
Sim e não; ele pode criar VMs, mas não pode fornecer hardware diferente de CPU e RAM.
O KVM não funciona sozinho; é apenas uma API fornecida pelo kernel para o espaço do usuário. Assim como você observou: "Como um kernel do Linux, o KVM não tem GUI nem CLI. É preciso escrever, digamos, código C para chamar o módulo KVM para criar VM, tornando-o inútil para os usuários finais."
Portanto, os usuários finais geralmente usam o KVM por meio do QEMU (onde ele está presente como um método de aceleração). Você inicia a VM usando a CLI qemu já familiar e apenas adiciona
-accel kvmou-enable-kvm(versões mais antigas). Existem alguns outros gerenciadores de VM que usam KVM, comokvmtool, mas o QEMU é o mais popular.O mesmo se aplica ao libvirt – ele não gerencia o KVM diretamente, mas apenas inicia o QEMU com as opções corretas.
Além disso, o KVM não emula a maioria dos hardwares – ele não fornecerá à VM um disco ou uma placa de rede; ele fornece apenas os ganchos necessários para permitir que um programa de espaço de usuário faça isso. O próprio KVM lida principalmente com apenas as instruções privilegiadas da CPU.
Isso significa que há outra vantagem em usar o QEMU – você pode usar todo o hardware emulado (adaptadores SCSI, controladores Ethernet) que o QEMU já implementou, em vez de ter que fazer tudo do zero.
Tais reivindicações são inexequíveis. Se alguém quiser usar virt-* para o nome de seu programa (especialmente quando o programa gerencia principalmente libvirt de qualquer maneira), então eles podem apenas nomeá-lo virt-*.
Originalmente, era um fork do QEMU, com suporte de aceleração baseado em KVM adicionado. Mais tarde, ele foi mesclado novamente no QEMU da linha principal, então o
qemu-kvmcomando tornou-se apenasqemu -enable-kvm(e mais tarde foi ajustado paraqemu -accel=kvm).