En el anterior
1. La agonía de la elección
Entonces, ¿entre qué puedes elegir? EN
- Sistema de virtualización de servidores "R-Virtualización» (libvirt, KVM, QEMU)
- Paquete de software "Herramientas de virtualización de Brest» (libvirt, KVM, QEMU)
- Plataforma para la gestión y seguimiento del entorno de virtualización. "Corriente Sharx" (una solución en la nube que no es adecuada para oficinas gubernamentales en el 95% de los casos (secreto, etc.)
- Paquete de software para virtualización de servidores, escritorios y aplicaciones "HOST" (KVMx86)
- Sistema de gestión segura del entorno de virtualización "Z|virtud"(también conocido como oVirt+KVM)
- Sistema de gestión del entorno de virtualización "Virtualización ROSA"(también conocido como oVirt+KVM)
- Hipervisor VMM QP (demasiado similar a Oracle Virtual Box para ser otra cosa)
También puede tener en cuenta los hipervisores incluidos en la distribución del sistema operativo o ubicados en sus repositorios. Por ejemplo, Astra Linux tiene soporte KVM. Y dado que está incluido en los repositorios del sistema operativo, puede considerarse “legítimo” para su instalación y uso. “Qué se puede utilizar como parte de la sustitución de importaciones y qué no” se discutió en el anterior
De hecho, aquí
- VirtualBox
- gerente virtual (KVM) Corriente de águila
- libvirt sobre KVM
ROSA Linux no tiene dicha lista, pero puede encontrarla en la wiki
- Virtualización ROSA sobre oVirt sobre KVM
- QEMU sobre KVM
- oVirt 3.5 sobre KVM
Calcular tiene esto
Alt Linux tiene lo mismo
1.2. Hay uno PERO
Tras un examen más detenido, llegamos a la conclusión de que solo tendremos que lidiar con unos pocos hipervisores conocidos, a saber:
QEMU es un programa gratuito y de código abierto para emular hardware de varias plataformas, que puede funcionar sin usar KVM, pero el uso de la virtualización de hardware acelera significativamente el rendimiento de los sistemas invitados, por lo que usar KVM en QEMU (-enable-kvm) es la opción preferida. (c) Es decir, QEMU es un hipervisor de tipo 2, lo cual es inaceptable en un entorno de producto. Con KVM se puede utilizar, pero en este caso se utilizará QEMU como herramienta de gestión de KVM...
Usando el original VirtualBox en el comercio es en realidad
Total: en su forma pura solo tenemos KVM.
2. El resto: ¿KVM o KVM?
Si aún necesita cambiar a un hipervisor "doméstico", su elección, francamente, es pequeña. Será KVM en un contenedor u otro, con ciertas modificaciones, pero seguirá siendo KVM. Si esto es bueno o malo es otra cuestión; todavía no hay alternativa.
Si las condiciones no son tan estrictas, entonces, como se discutió en el punto anterior
Estos productos están lejos de ser comparables.
Acerca de la implementación y la configuración KVM no fue escrito de la misma manera
Lo mismo va para
No veo ningún sentido en repetirme y describir estos sistemas, comparar, etc. Por supuesto, se pueden extraer puntos clave de los artículos, pero creo que esto sería una falta de respeto para los autores. Quien tenga que elegir leerá no sólo esto, sino también una montaña de información para decidirse.
La única diferencia en la que quiero centrarme es en el clustering de conmutación por error. Si Microsoft tiene esto integrado en el sistema operativo y la funcionalidad del hipervisor, entonces, en el caso de KVM, tendrá que utilizar software de terceros, que debe incluirse en los repositorios del sistema operativo. La misma combinación de Corosync+Pacemaker, por ejemplo. (Casi todos los sistemas operativos domésticos tienen esta combinación... tal vez todos, pero no revisé el 100% de ellos). También hay disponibles en abundancia manuales para configurar la agrupación en clústeres.
3. Conclusión
Bueno, como de costumbre, nuestros Kulibins no se molestaron, tomaron lo que tenían, agregaron un poco de lo suyo y produjeron un "producto" que, según los documentos, es nacional, pero en realidad es OpenSource. ¿Tiene sentido gastar dinero del presupuesto en sistemas de virtualización "separados" (léase: no incluidos en el sistema operativo)? No pienses. Como seguirás recibiendo el mismo KVM, sólo tendrás que pagar por él.
Por lo tanto, elegir un reemplazo para un hipervisor depende del sistema operativo de servidor que vaya a comprar y operar para Enterprise. O, como en mi caso, te quedarás con lo que ya tienes (Hyper-VESXi insert_needed).
Fuente: habr.com