Як запропоновано в іншому місці, VMWare ESXi - це доступне з точки зору безкоштовних гіпервізорів з голим металом, де "голий метал" означає, що те, що ви зрештою завантажили, менше, ніж повноцінна ОС.
Xen також має режим HVM, в якому використовується віртуалізація на апаратному рівні; у цьому режимі він може запускати гостей Windows. У Xen явно є гіпервізор "голого металу" - як навіть операційна система Dom0 працює під ним - але це конфігурація та підтримка суттєво складних ядер та розміщує обмеження на ядрах, які можна запускати в доменах, що не належать до HVM (з яких Dom0 , первинне ядро, яке проходить через апаратний доступ до інших і має адміністративні права, одне). HVM потребує процесора та материнської плати з підтримкою апаратної віртуалізації; дивіться список Xen wiki-систем із материнськими платами, сумісними з HVM .
Однак, вам може бути цікавішим KVM . Замість того, щоб використовувати Linux для управління окремим власним ядром гіпервізора (як це робить ESX), KVM вбудовує можливості гіпервізора в сам Linux. Наскільки "голий метал", це залежить від вашої інтерпретації, - але якщо ваш хост, що працює на KVM, є не що інше, як initrd 40 Мб, у якого немає нічого, крім kvm + libvirt + пов'язаного з ним занадто великого місця (скажімо, щось на кшталт oVirt Red Hat ), Ви отримали щось, що на практиці не зовсім схоже на ESX. Компонент простору користувачів KVM походить від QEMU, що робить його всілякими потужними та гнучкими - те, що вам не обов’язково потрібно для робочого столу, але що дуже цікаво моделювати вбудовані системи (з, скажімо, лише послідовним введенням-виведенням та відсутністю адаптера VGA), налаштуванням складні ланцюги зображень COW, щоб повернути сховище або налаштувати цікаві топології віртуальної мережі. Як і Xen HVM, KVM вимагає апаратного прискорення. KVM працює досить невимогливими гостями Windows (включаючи Vista), але наразі доступні лише паравіртуальні мережеві драйвери для Windows; іншим драйверам потрібно користуватися емуляційним обладнанням, яке дещо повільніше. (Qumranet фінансує розробку інших драйверів для Windows, тому розраховуйте побачити їх з часом. Новіші версії ядра Linux мають багато інших паравіртуальних драйверів, сумісних з KVM - для вводу / виводу диска, годинника та інших пристроїв - включених вище за течією ).
Для використання на робочому столі VirtualBox добре підходить, хоча взагалі не піддається використанню «голого металу». Зважаючи на відсутність підтримки libvirt , я також вважаю його непридатним для автоматизованого використання QA. VirtualBox має паравіртний відеодрайвер серед своїх «гостьових утиліт», який забезпечить автоматичну зміну вікон і іноді глючно «безшовний режим», де вікна вашого гостя з’являться серед господарів, роблячи (теоретично) для більш інтегрованого досвіду.
Якщо ви використовуєте "первинну ОС", яка не призначена для віртуалізації, ви не займаєтеся віртуалізацією "голого металу", а мінімалістичним, повністю "голим металом" рішення, в якому (мікро) ядро в первинному контроль побудований строго з метою віртуалізації буде серйозно неоптимальним, якщо ви хочете, щоб ваш робочий стіл Windows відображався на одній і тій же апаратній частині. Якщо ви хочете, це не «голий метал», а віртуалізація за допомогою апаратних засобів , все, що пропонується тут, пропонує це - хоча для VirtualBox це варіант конфігурації, який можна вибрати; за замовчуванням він використовує більш традиційні методи.