Como sugerido em outros lugares, VMWare ESXi é o que está disponível em termos de hipervisores de metal descoberto gratuitos, onde "bare metal" implica que o que você acabou de carregar é menor que um SO completo.
Xen também tem um HVM , no qual a virtualização em nível de hardware é usada; nesse modo, ele pode executar convidados do Windows. O Xen tem claramente um hipervisor "bare metal" - como até mesmo o SO Dom0 é executado sob ele - mas é substancialmente complexo para configurar e manter, e coloca restrições nos kernels que você pode rodar sob domínios não-HVM (dos quais o Dom0 , o kernel principal que passa pelo acesso de hardware aos outros e tem direitos administrativos, é um deles). O HVM requer uma CPU e placa-mãe com suporte a virtualização de hardware; veja a lista de do wiki Xen motherboards compatíveis com HVM .
Dito isso, você pode achar o KVM mais interessante. Em vez de usar o Linux para gerenciar um kernel de hipervisor proprietário e separado (como o ESX), o KVM cria os recursos do hipervisor no próprio Linux. Como o "bare metal" depende da sua interpretação - mas se o seu host executando o KVM não é nada além de um initrd de 40MB que não tem nada além de kvm + libvirt + ferramentas relacionadas no local (digamos algo como o da Red Hat oVirt ), você tem algo que na prática não é totalmente diferente do ESX. O componente userspace do KVM é derivado do QEMU , que torna todos os tipos de recursos poderosos e flexíveis - algo que você não precisa necessariamente uma área de trabalho, mas que é muito interessante na simulação de sistemas embarcados (com, digamos, apenas E / S serial e nenhum adaptador VGA), configurando cadeias complexas de imagens COW para back-end do armazenamento ou configurando topologias de rede virtual interessantes. Como o Xen HVM, o KVM requer aceleração de hardware. O KVM administra razoavelmente bem os hóspedes do Windows (incluindo o Vista), mas somente os drivers de rede paravirtuais do Windows estão disponíveis no momento; outros drivers precisam usar hardware emulado, o que é um pouco mais lento. (A Qumranet está financiando o desenvolvimento de outros drivers para o Windows, então espere vê-los eventualmente. As versões mais recentes do kernel Linux têm muitos outros drivers paravirtuais compatíveis com KVM - para E / S de disco, relógio e outros dispositivos - incluídos upstream ).
Para uso em desktop, o VirtualBox é um bom ajuste, embora não seja passível de uso "bare-metal". Devido à falta de suporte ao libvirt , também considero inadequado para usos de automação de QA. O VirtualBox tem um driver de vídeo paravirt entre seus "utilitários convidados" que fornecerá redimensionamento automático de janelas e um "modo contínuo" às vezes com erros, onde as janelas de seus convidados aparecerão entre os hosts, criando (em teoria) uma experiência mais integrada.
Se você estiver usando um "sistema operacional primário" que não é feito especificamente para a virtualização, você não está fazendo virtualização "bare-metal" e uma solução minimalista totalmente "bare-metal" na qual o (micro) O kernel no controle primário é construído estritamente para fins de virtualização que ficará seriamente abaixo do ideal se você quiser que a área de trabalho do Windows seja exibida na mesma peça de hardware. Se o que você quer não é virtualização "bare-metal", mas assistida por hardware , tudo que é sugerido aqui oferece isso - embora, para o VirtualBox, seja uma opção de configuração selecionável por caixa de seleção; Por padrão, ele usa métodos mais tradicionais.