Comme suggéré ailleurs, VMWare ESXi est ce qui est disponible en termes d'hyperviseurs gratuits de bare-metal, où le "bare metal" implique que ce que vous avez finalement chargé est inférieur à un OS complet.
Xen dispose également d'un mode HVM dans lequel la virtualisation au niveau matériel est utilisée; dans ce mode, il est capable d'exécuter des invités Windows. Xen a clairement un hyperviseur "bare metal" - car même le système d'exploitation Dom0 s'exécute sous lui - mais il est substantiellement complexe à configurer et à maintenir, et impose des contraintes aux noyaux que vous pouvez exécuter sous des domaines non HVM (dont le Dom0 , le noyau principal qui passe par un accès matériel aux autres et qui a des droits administratifs, en est un). HVM nécessite un CPU et une carte mère avec prise en charge de la virtualisation matérielle; voir la liste des cartes mères compatibles HVM sur le wiki Xen .
Cela dit, vous pourriez trouver KVM plus intéressant. Plutôt que d'utiliser Linux pour gérer un noyau d'hyperviseur propriétaire distinct (comme le fait ESX), KVM intègre les capacités de l'hyperviseur dans Linux lui-même. Le "métal nu" qui dépend de votre interprétation - mais si votre hôte exécutant KVM n'est rien d'autre qu'un initrd de 40 Mo qui n'a rien d'autre que kvm + libvirt + un outil connexe en place (par exemple, quelque chose comme oVirt de Red Hat ), vous ' ai quelque chose qui, dans la pratique, n'est pas totalement différent d'ESX. Le composant espace utilisateur de KVM est dérivé de QEMU, ce qui en fait toutes sortes de fonctions puissantes et flexibles - quelque chose dont vous n'avez pas nécessairement besoin pour un ordinateur de bureau, mais qui est très intéressant pour simuler des systèmes embarqués (avec, disons, uniquement des E / S série et aucun adaptateur VGA), la configuration des chaînes complexes d'images COW pour soutenir le stockage ou la configuration de topologies de réseau virtuel intéressantes. Comme Xen HVM, KVM nécessite une accélération matérielle. KVM exécute raisonnablement bien les invités Windows peu exigeants (y compris Vista), mais ne dispose pour le moment que de pilotes réseau paravirtuels pour Windows; les autres pilotes doivent utiliser du matériel émulé, qui est un peu plus lent. (Qumranet finance le développement d'autres pilotes pour Windows, alors attendez-vous à les voir éventuellement. Les nouvelles versions du noyau Linux ont de nombreux autres pilotes paravirtuels compatibles KVM - pour les E / S disque, l'horloge et d'autres périphériques - inclus en amont. ).
Pour une utilisation de bureau, VirtualBox est un bon ajustement, bien qu'il ne se prête pas du tout à une utilisation "bare metal". En raison de son manque de prise en charge de libvirt , je considère également qu'il ne convient pas aux utilisations d'automatisation QA. VirtualBox a un pilote vidéo paravirt parmi ses "utilitaires invités" qui fournira un redimensionnement automatique des fenêtres et un "mode transparent" parfois bogué où les fenêtres de vos invités apparaîtront parmi celles de l'hôte, ce qui rendra (en théorie) une expérience plus intégrée.
Si vous utilisez un "système d'exploitation principal" qui n'est pas spécialement conçu pour la virtualisation, vous ne faites pas de virtualisation "bare metal" et une solution minimaliste entièrement "bare metal" dans laquelle le (micro) noyau en primaire le contrôle est construit strictement à des fins de virtualisation va être sérieusement sous-optimal si vous voulez que votre bureau Windows s'affiche sur le même matériel. Si ce que vous voulez n'est pas du "bare metal" mais de la virtualisation assistée par matériel, tout ce qui est suggéré ici offre cela - bien que pour VirtualBox, c'est une option de configuration sélectionnable par case à cocher; par défaut, il utilise des méthodes plus traditionnelles.