Come suggerito altrove, VMWare ESXi è ciò che è disponibile in termini di hypervisor bare metal gratuiti, in cui "bare metal" implica che ciò che alla fine è stato caricato è inferiore a un sistema operativo completo.
Xen ha anche una modalità HVM in cui viene utilizzata la virtualizzazione a livello hardware; in questa modalità è in grado di eseguire guest Windows. Xen ha chiaramente un hypervisor "bare metal" - poiché anche il sistema operativo Dom0 funziona sotto di esso - ma è sostanzialmente complesso da configurare e mantenere e pone vincoli sui kernel che è possibile eseguire in domini non HVM (di cui Dom0 , il kernel principale che passa attraverso l'accesso hardware agli altri e ha diritti amministrativi, è uno). HVM richiede una CPU e una scheda madre con supporto per la virtualizzazione dell'hardware; vedere l'elenco delle schede madri compatibili con HVM nella wiki di Xen .
Detto questo, potresti trovare KVM più interessante. Invece di usare Linux per gestire un kernel hypervisor proprietario separato (come fa ESX), KVM sviluppa le capacità dell'hypervisor in Linux stesso. Quanto "bare metal" dipende dalla tua interpretazione, ma se il tuo host che esegue KVM non è altro che un initrd da 40 MB che non ha altro che kvm + libvirt + toolage correlato (diciamo, qualcosa come l' oVirt di Red Hat ), tu ' ho qualcosa che in pratica non è del tutto diverso da ESX. Il componente userspace di KVM è derivato da QEMU, che lo rende potente e flessibile - qualcosa che non è necessariamente necessario per un desktop, ma che è molto interessante nella simulazione di sistemi embedded (con, diciamo, solo I / O seriale e nessun adattatore VGA), impostazione catene complesse di immagini COW per il back-end dell'archiviazione o l'impostazione di topologie di reti virtuali interessanti. Come Xen HVM, KVM richiede un'accelerazione hardware. KVM esegue ragionevolmente bene i guest Windows (incluso Vista), ma al momento ha solo i driver di rete paravirtual per Windows; altri driver devono usare hardware emulato, che è un po 'più lento. (Qumranet sta finanziando lo sviluppo di altri driver per Windows, quindi aspettati di vederli alla fine. Le versioni più recenti del kernel Linux hanno molti altri driver paravirtuali compatibili con KVM - per I / O del disco, clock e altri dispositivi - inclusi a monte ).
Per l'utilizzo desktop, VirtualBox è adatto, sebbene non sia affatto adatto all'uso "bare metal". A causa della sua mancanza di supporto per libvirt , lo considero anche inadatto per gli usi dell'automazione del QA. VirtualBox ha un driver video paravirt tra le sue "utility guest" che fornirà il ridimensionamento automatico delle finestre e una "modalità senza soluzione di continuità" a volte buggy in cui le finestre dei tuoi ospiti verranno visualizzate tra l'host, rendendo (in teoria) un'esperienza più integrata.
Se stai usando un "sistema operativo primario" che non è stato creato appositamente per la virtualizzazione, non stai realizzando la virtualizzazione "bare metal" e una soluzione minimalista e completamente "bare metal" in cui il (micro) kernel in primario il controllo è costruito rigorosamente allo scopo di virtualizzare sarà seriamente non ottimale se si desidera che il desktop di Windows venga visualizzato sullo stesso componente hardware. Se ciò che si desidera non è "bare metal" ma virtualizzazione assistita da hardware , tutto ciò che viene suggerito qui lo offre, anche se per VirtualBox è un'opzione di configurazione selezionabile dalla casella di controllo; per impostazione predefinita utilizza metodi più tradizionali.