Como se sugiere en otra parte, VMWare ESXi es lo que está disponible en términos de hipervisores de metal desnudo gratuitos, donde "metal desnudo" implica que lo que finalmente ha cargado es menos que un sistema operativo completo.
Xen también tiene un modo HVM en el que se usa la virtualización a nivel de hardware; en este modo puede ejecutar invitados de Windows. Xen claramente tiene un hipervisor "básico", ya que incluso el sistema operativo Dom0 se ejecuta debajo de él, pero es sustancialmente complejo de configurar y mantener, y establece restricciones en los núcleos que puede ejecutar en dominios no HVM (de los cuales el Dom0 , el núcleo primario que pasa a través del acceso de hardware a los demás y tiene derechos administrativos, es uno). HVM requiere una CPU y una placa base con soporte de virtualización de hardware; vea la lista de placas base compatibles con HVM de la wiki de Xen .
Dicho esto, es posible que encuentre KVM más interesante. En lugar de usar Linux para administrar un núcleo de hipervisor propietario y separado (como lo hace ESX), KVM integra las capacidades del hipervisor en el propio Linux. Cómo "bare metal" eso depende de su interpretación, pero si su host que ejecuta KVM no es más que un initrd de 40MB que no tiene nada más que kvm + libvirt + relacionado con el trabajo en el lugar (digamos, algo así como el oVirt de Red Hat ), usted ' Tengo algo que en la práctica no es del todo diferente a ESX. El componente de espacio de usuario de KVM se deriva de QEMU, lo que lo hace todo tipo de potente y flexible, algo que no necesariamente necesita para un escritorio, pero que es muy interesante para simular sistemas integrados (con, por ejemplo, solo E / S en serie y sin adaptador VGA), configuración cadenas complejas de imágenes COW para respaldar el almacenamiento o configurar interesantes topologías de red virtual Al igual que Xen HVM, KVM requiere aceleración de hardware. KVM ejecuta invitados de Windows poco exigentes (incluida Vista) razonablemente bien, pero solo tiene controladores de red paravirtuales para Windows disponibles en este momento; otros controladores necesitan usar hardware emulado, que es algo más lento. (Qumranet está financiando el desarrollo de otros controladores para Windows, así que espere verlos eventualmente. Las versiones más nuevas del kernel de Linux tienen muchos otros controladores paravirtuales compatibles con KVM - para E / S de disco, reloj y otros dispositivos - incluidos en sentido ascendente )
Para el uso de escritorio, VirtualBox es una buena opción, aunque no es apto para el uso "bare metal" en absoluto. Debido a su falta de soporte de libvirt , también lo considero inadecuado para los usos de automatización de control de calidad. VirtualBox tiene un controlador de video paravirtido entre sus "utilidades para invitados" que proporcionará un cambio automático de tamaño de la ventana y un "modo transparente" a veces con errores donde las ventanas de su invitado se mostrarán entre las del host, lo que hace (en teoría) una experiencia más integrada.
Si está utilizando un "SO primario" que no está diseñado específicamente para la virtualización, no está haciendo una virtualización "básica" y una solución minimalista y totalmente "básica" en la que el (micro) núcleo en el primario el control se construye estrictamente con el propósito de que la virtualización sea muy subóptima si desea que su escritorio de Windows se muestre en la misma pieza de hardware. Si lo que quiere no es "bare metal" sino virtualización asistida por hardware , todo lo sugerido aquí ofrece eso, aunque para VirtualBox es una opción de configuración seleccionable por casilla de verificación; Por defecto utiliza métodos más tradicionales.