Los hipervisores de escritorio son una tecnología popular entre los tecnófilos. Tenemos todo tipo de razones para utilizarlos. Algunos de nosotros necesitamos probar el software que otras personas escribieron para ver si es bueno. Algunos necesitamos probar el software que escribimos para ver si es bueno. A veces, necesitamos restringir la actividad a un entorno temporal. Otras veces, simplemente queremos mantener nuestro entorno primario fuera de las garras de un instalador invasivo. Encontrar razones para utilizar un hipervisor de escritorio es sencillo. Decidir qué hipervisor de escritorio utilizar puede ser más complicado. Este artículo comparará y contrastará el cliente Hyper-V de Microsoft con VirtualBox de Oracle.

Descargue Altaro VM Backup

Descargue Altaro VM Backup

Inicie su prueba gratuita de 30-días de prueba de Altaro VM Backup hoy mismo y compruebe por qué confían en él más de 40 000 organizaciones de todo el mundo. Comience ahora y ejecute su primera copia de seguridad en menos de 15 minutos!

Como regla, no le digo a la gente qué producto usar. Creo que deben elegir lo que mejor se adapte a sus necesidades. Si no hay nada disponible que se alinee perfectamente, mezclar y combinar hasta que se acerque lo más posible. No me gusta que la gente elija primero su producto y luego lance justificaciones convenientes para esa elección. Dos ejemplos comunes son: «Nunca han despedido a nadie por comprar IBM» y «Este producto es el más popular». Mi propósito aquí no es dictar qué producto es superior, sino guiarle hacia una decisión informada. Esa decisión podría ser utilizar ambos hipervisores.

Client Hyper-V v Virtualbox

Client Hyper-V v Virtualbox

Client Hyper-V y VirtualBox: Una visión general de la tecnología

Todos somos gente de tecnología aquí, así que vamos a empezar por ver estos dos hipervisores desde un punto de vista tecnológico.

No son del tipo del otro

La diferencia más obvia entre los dos productos es que Client Hyper-V es un hipervisor de tipo 1 y VirtualBox es un hipervisor de tipo 2. Ahora bien, cada vez que digo «Hyper-V es un hipervisor de tipo 1» y luego trato de explicar lo que es un hipervisor de tipo 1, invariablemente recibo al menos unos cuantos comentarios que me dicen que mi descripción es totalmente errónea y que, «Hyper-V es…», y luego el comentarista procede a describir Hyper-V como un hipervisor de tipo 2. O bien mis explicaciones no son muy buenas o simplemente la gente no cree que Hyper-V sea un hipervisor de tipo 1. Espero que la mayor parte de ella es que la línea entre el tipo 1 y el tipo 2 no es casi tan sólida como algunas personas quieren hacer creer, y por lo tanto estos comentaristas sólo ven las cosas de manera diferente.

De todos modos, voy a intentar un nuevo método de explicar el tipo 1 vs. tipo 2, pero restringirlo a este contexto.

Proceso de inicio del hipervisor: Oracle VirtualBox

Voy a empezar explicando cómo se inicia VirtualBox. Es un hipervisor de tipo 2 y el más fácil de entender.

  1. Se inicia el ordenador físico
  2. El sistema de arranque del ordenador físico (BIOS o UEFI) cede el control al sistema operativo instalado en el hardware. En el caso de VirtualBox, puede ser Windows, Linux, OSX o Solaris
  3. El usuario (es decir, usted) inicia la aplicación VirtualBox.
  4. El usuario (es decir, usted) selecciona qué máquina(s) virtual(es) desea iniciar. VirtualBox genera los procesos de alojamiento

Simple, ¿verdad?

Proceso de inicio del hipervisor: Client Hyper-V

Como hipervisor de tipo 1, la rutina de inicio de Client Hyper-V es bastante diferente a la de VirtualBox a nivel fundamental.

  1. El ordenador físico se inicia
  2. El sistema de arranque del ordenador físico (BIOS o UEFI) cede el control a Hyper-V
  3. Hyper-V inicia el sistema operativo de gestión. El sistema operativo de gestión sólo puede ser Windows, Windows Server o Hyper-V Server
  4. En respuesta a las configuraciones automáticas o a las instrucciones manuales del usuario (es decir, usted), Hyper-V genera particiones para las máquinas virtuales

Hay variaciones en la forma en que los diferentes hipervisores de tipo 1 y de tipo 2 logran sus objetivos, por lo que no puedo hacer unas cuantas afirmaciones generales y marcharme. Vamos a echar un vistazo a algunas de las diferencias genéricas.

La importancia de las diferencias de tipo

Puede encontrar una gran cantidad de material escrito sobre las diferencias entre los hipervisores de tipo 1 y 2. A la luz de las capacidades del hardware, el software de virtualización y los sistemas operativos modernos, la mayor parte de ese material tiene un valor cuestionable. Voy a omitir las partes cuestionables y sólo trataré lo que podemos verificar.

Para esta discusión, la distinción más importante entre el tipo 1 y el 2 es que un hipervisor de tipo 1 está siempre encendido. La única forma de «parar» el Hyper-V del cliente es apagar el equipo o eliminar el rol. Claro que se puede detener el servicio «Hyper-V Virtual Machine Management», pero eso no es Hyper-V. Es un servicio de gestión. Supongo que por eso le dieron ese nombre en particular. Detenerlo impide gestionar cualquiera de las máquinas virtuales, pero no afecta a las máquinas virtuales ni al hipervisor. No puedes ver Hyper-V hurgando en el sistema operativo de gestión.

Por otro lado, VirtualBox se puede abrir y cerrar a voluntad. Puede localizar la aplicación VirtualBox, su servicio y sus máquinas virtuales en el Administrador de tareas del sistema operativo de gestión. Si cierras la interfaz principal, todas las máquinas virtuales activas seguirán funcionando porque VirtualBox dejará su kernel de hipervisor en la memoria. Si detienes la última máquina virtual de VirtualBox, ya no habrá más VirtualBox. Tendrás que iniciarlo de nuevo para que cualquier máquina virtual se ejecute.

Las diferencias de tipo de Cliente Hyper-V y VirtualBox tienen varias consecuencias:

  • El SO de gestión de Client Hyper-V utiliza vCPU como las máquinas virtuales
  • Hay que utilizar los contadores de rendimiento de Hyper-V para ver algo sobre el uso de recursos de Client Hyper-V, y eso no lo dice todo
  • La asignación de hardware funciona de forma diferente
  • La prioridad de los recursos funciona de forma diferente

Hyper-V vs. VirtualBox: Acceso al hardware

Cuando leo las quejas sobre Client Hyper-V, los problemas de hardware saltan a la cabeza. Inevitablemente, se hacen comparaciones con VirtualBox, VMware Workstation/Player y otros hipervisores de tipo 2. Los reclamantes rara vez dejan de mencionar que los problemas con los dispositivos son casi inexistentes en esos productos. La raíz del problema se encuentra en el tipo de hipervisor.

Cuando VirtualBox (o cualquier otro hipervisor de tipo 2) genera una máquina virtual, su contenedor se ejecuta dentro del sistema operativo de gestión donde viven las aplicaciones. Al igual que otras aplicaciones, no tienen acceso directo al hardware; deben solicitar el acceso al dispositivo a través del sistema operativo.

Por ejemplo, veamos la asignación de mi hardware de sonido en el escritorio de Windows 10:

Asignación de hardware de sonido

Asignación de hardware de sonido

Tengo múltiples dispositivos de hardware de sonido y múltiples aplicaciones. Todo el acceso y asignación de hardware ocurre a través del sistema operativo. Nota: Lo anterior es sólo para fines ilustrativos. No se utiliza el Mezclador de Volumen para conectar a los invitados de VirtualBox con el hardware de sonido.

Así, cuando se enciende un invitado de VirtualBox, se puede utilizar su contenedor de aplicaciones para solicitar el acceso al hardware.

Ahora, piense en Client Hyper-V. El sistema operativo de gestión se ejecuta en su propia partición separada de los sistemas operativos invitados. A diferencia de VirtualBox, los sistemas operativos invitados de Client Hyper-V no tienen ninguna proyección en el sistema operativo de gestión. No pueden llamar a la API en el sistema operativo de gestión de la forma en que los invitados de VirtualBox pueden hacerlo porque no pueden alcanzarlo. Hay características en el cliente Hyper-V que pueden ayudarle a abordar esta diferencia, pero todo esto es causado por las diferencias fundamentales en las tecnologías del hipervisor.

Lo que hay que saber de esta sección: si quiere utilizar hardware conectado por USB y discos externos con sus máquinas virtuales invitadas, lo tendrá más fácil con VirtualBox.

Hyper-V vs. VirtualBox: Presentación del hardware

Esta sección conecta fuertemente con la anterior. Si usted hojea las pestañas de configuración de una máquina virtual en VirtualBox, va a encontrar un montón de cosas que no verá en Hyper-V. Debes decidir entre un chipset PIIX3 o uno ICH9. Debes elegir entre un controlador de audio Intel, un controlador de audio ICH AC97 y un controlador de audio SoundBlaster 16. Si permite que una máquina virtual tenga un controlador USB, debe elegir entre un dispositivo 1.1, 2.0 o 3.0. Hyper-V no le pide que haga ninguna elección como esa.

La diferencia aquí también está relacionada con toda esa discusión de tipo 1 vs. tipo 2. Los hipervisores de tipo 2 están diseñados para funcionar en una gama mucho más amplia de entornos, lo que presenta cualquier número de problemas. Para resolver estos problemas, los hipervisores de tipo 2 utilizan ampliamente la emulación. La emulación es cuando una construcción de software imita las interfaces de un dispositivo de hardware. VirtualBox emula todas las cosas que he enumerado en el párrafo anterior y más. El cliente Hyper-V emula muy poco – lo más notable es su controlador IDE y el adaptador de red heredado.

La emulación resuelve los problemas de aplicabilidad generalizada. Como se puede imaginar, esta versatilidad tiene un coste. Todo el propósito del hardware especializado, como las tarjetas de red y los adaptadores de vídeo, es que se encarguen de sus respectivas cargas de trabajo para que la carga no recaiga en otra parte. Como están construidos específicamente para sus tareas, (presumiblemente) lo hacen mejor que otros componentes construidos con otros objetivos en mente. Con el hardware emulado, su CPU de propósito general asume toda la responsabilidad del hardware dedicado.

Lo que hay que decir de esta sección: VirtualBox funciona con una gama más amplia de hardware en una gama más amplia de sistemas a costa de una sobrecarga que afecta al rendimiento.

Hyper-V vs. VirtualBox: Prioridad de recursos

Como VirtualBox sólo se ejecuta dentro del sistema operativo instalado en el hardware, está a merced del programador de ese sistema operativo. Una de las razones por las que me salté cualquier discusión típica sobre los anillos de CPU es que VirtualBox incluye este diálogo:

Configuración de la aceleración de VirtualBox

Configuración de la aceleración de VirtualBox

Lo que esto significa es que VirtualBox puede acceder a las mismas características que mucha gente sólo asocia con el anillo de CPU -1 y las extensiones del monitor de la máquina virtual utilizadas por los hipervisores «verdaderos» de tipo 1.

Sin embargo, VirtualBox sigue estando limitado por las restricciones impuestas por el sistema operativo instalado en el hardware. Si usted tiene un juego de Flash corriendo absorbiendo la memoria y la CPU en su sistema operativo instalado por hardware, el sistema operativo puede y hará que el rendimiento de sus máquinas virtuales VirtualBox sufra en el grado que quiera. Si es necesario, puede utilizar el Administrador de tareas para matar cualquier proceso o huésped de VirtualBox.

En cambio, Client Hyper-V proporciona los mismos controles de priorización que su hermano mayor basado en el servidor. Puede priorizar la CPU y la memoria, habilitar la calidad de servicio de almacenamiento y establecer limitaciones de ancho de banda de red para todas sus máquinas virtuales.

Lo que hay que saber de esta sección: El cliente Hyper-V otorga un control de grano fino sobre la priorización de recursos; VirtualBox no lo hace.

Hyper-V vs. VirtualBox: Aceleración de vídeo

Esta sección es un poco diferente de la discusión anterior porque nada aquí será universalmente cierto. Voy a contar cómo las diferencias en los dos hipervisores influyeron en mis experiencias. Su kilometraje puede variar.

Tanto el cliente Hyper-V como VirtualBox emulan vídeo. En mis experiencias, no he podido distinguir que uno sea mejor que el otro en cuanto a aceleración 2D. No creo que le pida mucho a la aceleración 2D, pero también sé que la mayoría de los sistemas operativos de escritorio modernos utilizan la aceleración 2D de maneras que no siempre son obvias hasta que no están disponibles. Dos ejemplos principales son el suavizado de fuentes y las animaciones de ventanas. Con la reserva expresa de que su kilometraje puede variar, no creo que la aceleración 2D deba ser un factor importante a favor de ninguno de los dos hipervisores.

La aceleración 3D es una historia diferente. El cliente Hyper-V ofrece RemoteFX. En mi experimentación, funciona muy bien dentro de los límites de lo que está diseñado para hacer. RemoteFX no proyecta el adaptador de vídeo en el sistema operativo invitado, por lo que no se puede acceder a toda su funcionalidad. RemoteFX también ha funcionado en todos los sistemas con los que he intentado utilizarlo, siempre y cuando contuvieran el controlador requerido de aceleración 3D compatible con WDDM.

La aceleración 3D en VirtualBox es una historia completamente diferente. He fracasado completamente en conseguir que funcione lo suficientemente bien como para mostrar incluso un escritorio básico de Windows correctamente. Nunca me acerqué a probar ninguna función de aceleración 3D. Por lo tanto, no puedo dar ninguna comparación significativa entre los dos.

Los resultados de esta sección: la aceleración 2D parece ser un lavado entre los dos. La aceleración 3D parece más fiable en el cliente Hyper-V.

Hyper-V Vs. VirtualBox: Compatibilidad con discos duros virtuales

VirtualBox soporta varios formatos de discos duros virtuales. Puede elegir entre:

  • VDI, el formato nativo de VirtualBox
  • VMDK, el formato de VMware
  • VHD, el formato de Microsoft
  • HDD, el formato de Parallel
  • QED y QCOW, utilizados en QEMU y otros hipervisores

No puede utilizar VHDX con VirtualBox. La capacidad de utilizar el formato de disco de otro hipervisor no significa necesariamente que usted será capaz de transición sin problemas un disco duro virtual de un hipervisor a otro, ya sea.

Takeaway de esta sección: esto es casi información general, porque la capacidad de utilizar múltiples formatos de disco duro virtual no es tan útil como podría parecer al principio. Si piensa intentar pasar un disco duro virtual de una plataforma a otra sin emplear un conversor, VirtualBox es su mejor opción.

Hyper-V vs. VirtualBox: Otras características de vídeo

VirtualBox proporciona unas cuantas características de vídeo con las que Client Hyper-V no compite directamente.

  • Client Hyper-V puede mostrar sólo en un monitor o en todos los monitores. Puede especificar entre uno y ocho monitores para VirtualBox.
  • VirtualBox proporciona un modo de servidor que permite a los ordenadores remotos conectarse al sistema operativo instalado por hardware para ver la consola de uno o más invitados específicos. Cada punto final permite múltiples conexiones remotas simultáneas. El cliente Hyper-V proporciona una funcionalidad similar con vmconnect.exe, pero no es tan versátil.
  • VirtualBox puede hacer una grabación de vídeo de un sistema operativo invitado.
  • VirtualBox permite poner una máquina virtual en modo «Seamless». Las aplicaciones que inicie en la máquina virtual aparecerán y funcionarán como si se estuvieran ejecutando en el sistema operativo instalado en el hardware.

Lo que hay que saber de esta sección: si alguna de estas características le atrae, VirtualBox es la única opción.

Hyper-V vs. VirtualBox: Acceso al código fuente

VirtualBox es un software de código abierto. Si no te gusta algo y crees que puedes hacerlo mejor, hazlo. Si sólo quiere saber cómo funciona, descargue el conjunto de códigos y profundice.

Microsoft se está acercando poco a poco a la noción de código abierto y ha sometido una gran cantidad de código a la comunidad. Windows es notoriamente ausente. Según tengo entendido, la base de código de Hyper-V está muy acoplada a Windows. Tengo mis dudas de que alguna vez veamos publicado el código de Hyper-V.

Lo que hay que saber de esta sección: si usar un hipervisor de código abierto es importante para usted, eso descalifica al cliente Hyper-V.

Hyper-V vs. VirtualBox: Licencia de uso

Client Hyper-V se envía como un componente de Windows 10 Professional y Enterprise SKUs. Si tienes licencia para usar uno de esos, entonces tienes licencia para usar Client Hyper-V.

Oracle licencia el paquete central actual de VirtualBox (versiones 5.x+) bajo GPLv2. También proporcionan algunas «extensiones» bajo una licencia separada llamada «VirtualBox Personal Use and Evaluation License». Personalmente no utilizo ninguna de estas características, aunque engloban algunas de las características de las que hablé anteriormente. No he investigado a fondo los términos de esta licencia, pero parece ser bastante generosa. Como siempre, le recomiendo que permita que un asesor legal capacitado responda a cualquiera de sus preguntas sobre licencias.

En cuanto a las licencias del sistema operativo invitado, esas son un cuento aparte. Ni Client Hyper-V ni VirtualBox proporcionan ninguna licencia de sistema operativo invitado. Si instalas cualquier sabor de Windows o Windows Server en un sistema operativo invitado bajo cualquiera de los dos hipervisores, debes licenciar adecuadamente el hardware.

Lo que debes saber de esta sección: el licenciamiento siempre es importante.

Adquirir Client Hyper-V y VirtualBox

Si estás ejecutando Windows 10 Professional o Enterprise, entonces sólo necesitas habilitar el rol de Hyper-V para comenzar a usarlo.

VirtualBox está disponible en su sitio web: https://www.virtualbox.org/

Deja una respuesta

Tu dirección de correo electrónico no será publicada.