Un hipervisor es una combinación de software, hardware o firmware que crea, ejecuta y gestiona máquinas virtuales (VM). El ordenador que ejecuta un hipervisor se conoce como su anfitrión, mientras que cada VM en el anfitrión se conoce como invitado. Un hipervisor proporciona a los invitados una plataforma operativa virtual que gestiona sus sistemas operativos (SO), permitiendo que varios SO compartan recursos virtualizados en el mismo host.
La capacidad de compartir recursos es una de las razones más significativas para que una empresa implemente hipervisores. Sin embargo, la variedad de hipervisores disponibles actualmente puede hacer que este proceso de decisión sea un reto. La selección de un hipervisor a menudo se reduce a una elección entre VMware y Kernel-based Virtual Machine (KVM). VMware es el nombre de una empresa que desarrolla una serie de hipervisores, entre los que se encuentra el ESXi de clase empresarial. KVM es una infraestructura para el kernel de Linux que le proporciona las capacidades de un hipervisor.
Los siguientes puntos de comparación pueden ayudar a las organizaciones que necesitan un hipervisor a elegir entre VMware y KVM.
- Rendimiento
- Integración
- Coste
- Complejidad
- Madurez
- Escalabilidad
- Soporte de funcionalidades
Resumen
Un hipervisor virtualiza un entorno informático, lo que significa que los huéspedes de ese entorno comparten recursos físicos como la capacidad de procesamiento, la memoria y el almacenamiento que engloban una nube privada. Cada invitado ejecuta su propio sistema operativo, lo que hace que parezca que tiene sus propios recursos, aunque no sea así. La compartición eficiente de recursos requiere que el procesador físico soporte la virtualización, que se denomina AMD-V para los procesadores AMD y VT-x para los procesadores Intel.
Un hipervisor necesita aislar eficazmente a cada huésped, de forma que el funcionamiento de un huésped no pueda afectar a los demás huéspedes que se ejecutan en el host. Este requisito significa que un hipervisor debe emular con precisión el hardware físico para evitar que los huéspedes accedan a él, excepto en circunstancias cuidadosamente controladas. El método que utiliza un hipervisor para hacer esto es un factor clave en su rendimiento.
Los hipervisores suelen utilizar controladores «paravirtualizados» (PV) para emular el hardware físico, que actúan como hardware como discos de almacenamiento y tarjetas de red. Estos controladores son específicos del sistema operativo y, a menudo, específicos de un hipervisor concreto. Los controladores PV pueden mejorar el rendimiento de un hipervisor en un orden de magnitud.
Rendimiento
Los hipervisores pueden clasificarse en dos tipos, lo que puede afectar a su rendimiento. Los hipervisores de tipo 1, también conocidos como hipervisores «bare metal», se ejecutan directamente sobre el hardware físico, y el SO de cada huésped se ejecuta sobre el hipervisor. Estos hipervisores suelen permitir que algunos invitados controlen el hipervisor. La mayoría de las empresas utilizan hipervisores de tipo 1.
Un hipervisor de tipo 2, también conocido como hipervisor alojado, se ejecuta dentro de un SO que se ejecuta en el hardware físico. El SO de cada invitado se ejecuta entonces sobre el hipervisor. Los hipervisores de escritorio suelen ser hipervisores de tipo 2.
Xen es probablemente el mejor ejemplo de un hipervisor de tipo 1 puro, aunque ESXi es claramente un hipervisor de tipo 1 también porque no es una aplicación que se instala en un SO. ESXi incluye un kernel y otros componentes del SO que integra en el SO nativo.
La clasificación de KVM es más difícil porque comparte características de ambos tipos de hipervisor. Se distribuye como un componente de Linux, lo que significa que un usuario de Linux puede iniciar KVM desde una línea de comandos o una interfaz gráfica de usuario (GUI). Estos métodos de inicio de KVM hacen que parezca que el hipervisor se ejecuta en el SO anfitrión, aunque en realidad KVM se ejecuta en el metal desnudo.
El SO anfitrión proporciona a KVM un mecanismo de lanzamiento y establece una relación de coprocesamiento con él, lo que permite a KVM compartir el control sobre el hardware físico con el núcleo de Linux. KVM utiliza las instrucciones de virtualización del procesador cuando se ejecuta en hardware x86, lo que permite que el hipervisor y todos sus invitados se ejecuten directamente en el metal desnudo. El hardware físico realiza la mayor parte de las traducciones de recursos, por lo que KVM cumple los criterios tradicionales de un hipervisor de tipo 1.
Un hipervisor de tipo 1 debería superar a un hipervisor de tipo 2, a igualdad de otros factores. Los hipervisores de tipo 1 evitan la sobrecarga en la que incurre un hipervisor de tipo 2 cuando solicita acceso a los recursos físicos del SO anfitrión. Sin embargo, hay otros factores que también juegan un papel importante en el rendimiento de un hipervisor. Por ejemplo, ESXi generalmente requiere más tiempo para crear e iniciar un servidor que KVM. ESXi también tiene un rendimiento más lento cuando ejecuta servidores, aunque esta diferencia puede ser insignificante para las cargas típicas.
Integración
Los hipervisores utilizan diferentes métodos para comunicarse con el hardware físico del host. KVM utiliza un agente instalado en el host para comunicarse con el hardware, mientras que ESXi utiliza el plano de gestión de VMware para comunicarse con el hardware. El proceso ofrece la ventaja de permitir que ESXi acceda a otros productos de VMware que utilizan este plano de gestión. Sin embargo, también requiere que ESXi utilice la pila de control de VMware, lo que puede aumentar los requisitos de hardware.
La estrecha integración con el sistema operativo anfitrión es la principal razón por la que los desarrolladores de Linux suelen preferir KVM, que se incorporó al núcleo de Linux poco después de su lanzamiento en 2007. En comparación, Xen no se convirtió oficialmente en parte del núcleo de Linux hasta 2011, ocho años después de su lanzamiento inicial. Los desarrolladores de Linux también son más propensos a utilizar KVM porque Red Hat y otros distribuidores de Linux lo han adoptado con preferencia a otros hipervisores. Illumos es un sistema operativo de código abierto basado en OpenSolaris que también eligió KVM frente a otros hipervisores cuando añadió soporte para la virtualización de hardware.
Coste
KVM gana claramente a VMware en base al coste. KVM es de código abierto, por lo que no supone ningún coste adicional para el usuario. Además, se distribuye de diversas maneras, a menudo como parte de un sistema operativo de código abierto.
VMware cobra una licencia para utilizar sus productos, incluido ESXi. Puede hacerlo porque VMware fue la primera empresa en lanzar un software de virtualización de clase empresarial y sigue siendo el líder del mercado en este segmento. Por tanto, su marca sigue siendo relevante para los usuarios finales de una empresa, independientemente de lo que piensen los desarrolladores. Un usuario de ESXi también debe adquirir una licencia para utilizar vSphere, el conjunto de herramientas de VMware para la computación en la nube que utiliza ESXi. Es posible que se necesiten licencias de software adicionales, lo que aumentará aún más el coste de implantación de ESXi.
IBM realizó algunos cálculos relativos al coste total de propiedad (TCO) de KVM y VMware en 2012. Estos cálculos mostraron que el TCO de KVM era normalmente un 39 por ciento menos que el de VMware, aunque el TCO real dependerá de factores específicos del sitio, como el entorno operativo y la carga de trabajo. Esta diferencia en el TCO indica que los proveedores de servicios en la nube probablemente querrán implementar KVM en al menos un clúster, independientemente de los otros factores a considerar.
Complejidad
La comparación de KVM y VMware también muestra una clara diferencia en el tamaño de la base de código, que afecta a los costes de mantenimiento de un hipervisor. KVM se lanzó inicialmente para aprovechar las extensiones de los procesadores que les permitían virtualizar huéspedes sin traducir el código binario. Este origen hizo que la primera versión estable de KVM fuera esencialmente un controlador de virtualización ligero, con poco más de 10.000 líneas de código (LOC).
Se cree que VMware tiene más de 6 millones de LOC, aunque este dato no se puede verificar ya que su código fuente no está disponible públicamente. Este total no afecta directamente al rendimiento, ya que VMware utiliza extensiones de hardware para virtualizar a los huéspedes. No obstante, su código original nunca ha sido reescrito por completo, lo que da lugar a una base de código más compleja que la de KVM.
Madurez
KVM y ESXi son ambos altamente maduros y estables. KVM ha sido parte del kernel de Linux durante más de una década, y ESXi ha estado disponible públicamente desde 2006. Sin embargo, KVM está más extendido ya que es de código abierto y se incluye en muchos paquetes como Redhat Enterprise Virtualization (RHEV). KVM también soporta más características que cualquier otro hipervisor.
Escalabilidad
KVM es generalmente más escalable que VMware, principalmente porque vSphere tiene algunas limitaciones en los servidores que puede gestionar. Además, VMware ha añadido un gran número de redes de área de almacenamiento (SAN) para dar soporte a varios proveedores. Esta característica significa que VMware tiene más opciones de almacenamiento que KVM, pero también complica el soporte de almacenamiento de VMware al escalar.
Soporte de funcionalidad
Los hipervisores varían mucho en su soporte de funcionalidad. El soporte de red y de almacenamiento son especialmente importantes y son probablemente más importantes que cualquier otro factor además de la integración del SO. No debería ser una sorpresa saber que el soporte de ESXi para otros productos de VMware no tiene comparación con ningún otro hipervisor. Por otro lado, KVM ofrece más opciones de soporte de red que VMware.
Resumen
KVM suele ser la opción más popular para los usuarios preocupados por el coste de funcionamiento de cada VM y menos interesados en las características de nivel empresarial. Esta regla se aplica principalmente a los proveedores de servicios en la nube y de host, que son especialmente sensibles al coste y a la densidad de sus servidores. Estos usuarios son muy propensos a elegir hipervisores de código abierto, especialmente KVM.
La estrecha integración con el sistema operativo anfitrión es una de las razones más comunes para que los desarrolladores elijan KVM, especialmente los que utilizan Linux. La inclusión de KVM en muchas distribuciones de Linux también lo convierte en una opción conveniente para los desarrolladores. KVM también es más popular entre los usuarios que no se preocupan por los nombres de las marcas.
También vea VMWare vs Proxmox