No anterior
1. A agonía da elección
Entón, que podes escoller? EN
- Sistema de virtualización de servidores "R-Virtualización» (libvirt, KVM, QEMU)
- paquete de software"Ferramentas de virtualización de Brest» (libvirt, KVM, QEMU)
- Plataforma de xestión e seguimento do contorno de virtualización "Sharx Stream" (unha solución na nube que non é adecuada para oficinas gobernamentais no 95 % dos casos (segredo, etc.)
- Paquete de software para virtualización de servidores, escritorios e aplicacións "HOST" (KVM x86)
- Sistema de xestión segura do entorno de virtualización "Z|virt"(tamén coñecido como oVirt+KVM)
- Sistema de xestión de entornos de virtualización "Virtualización ROSA"(tamén coñecido como oVirt+KVM)
- Hipervisor QP VMM (demasiado semellante a Oracle Virtual Box para ser outra cousa)
Tamén podes ter en conta os hipervisores incluídos na distribución do SO ou localizados nos seus repositorios. Por exemplo, Astra Linux ten soporte KVM. E dado que está incluído nos repositorios do SO, pódese considerar "lexítimo" para a súa instalación e uso. "O que se pode usar como parte da substitución de importacións e o que non" foi discutido no anterior
De feito, aquí
- VirtualBox
- Virt-xestor (KVM) Corrente de aguia
- libvirt a través de KVM
ROSA Linux non ten esa lista, pero podes atopala na wiki
- Virtualización ROSA sobre oVirt sobre KVM
- QEMU a través de KVM
- oVirt 3.5 a través de KVM
Calcular ten isto
Alt Linux ten o mesmo
1.2. Hai un PERO
Tras un exame máis detallado, concluímos que só teremos que tratar con algúns hipervisores coñecidos, a saber:
QEMU é un programa gratuíto e de código aberto para emular hardware de varias plataformas, que pode funcionar sen utilizar KVM, pero o uso da virtualización de hardware acelera significativamente o rendemento dos sistemas convidados, polo que usar KVM en QEMU (-enable-kvm) é a opción preferida. (c) É dicir, QEMU é un hipervisor de tipo 2, que é inaceptable nun ambiente de produto. Con KVM pódese usar, pero neste caso QEMU empregarase como ferramenta de xestión KVM...
Usando o orixinal VirtualBox no comercio é en realidade
Total: na súa forma pura só temos KVM.
2. O resto: KVM ou KVM?
Se aínda necesitas cambiar a un hipervisor "doméstico", a túa elección, francamente, é pequena. Será KVM nun wrapper ou noutro, con certas modificacións, pero seguirá sendo KVM. Se isto é bo ou malo é outra cuestión; aínda non hai alternativa.
Se as condicións non son tan estritas, entón, como se comentou no anterior
Estes produtos están lonxe de ser comparables
Acerca da implantación e configuración KVM non estaba escrito da mesma maneira
O mesmo ocorre
Non vexo sentido repetirme e describir estes sistemas, comparar, etc. Por suposto, podes sacar puntos clave dos artigos, pero creo que sería unha falta de respecto aos autores. Quen teña que escoller lerá non só isto, senón tamén unha montaña de información para decidirse.
A única diferenza na que quero centrarme é no clustering de failover. Se Microsoft ten isto integrado no sistema operativo e na funcionalidade do hipervisor, no caso de KVM terás que usar software de terceiros, que debería incluírse nos repositorios do sistema operativo. A mesma combinación de Corosync+Pacemaker, por exemplo. (Case todos os sistemas operativos domésticos teñen esta combinación... quizais todos, pero non comprobei o 100 % deles.) Tamén están dispoñibles en abundancia os manuais para configurar a agrupación.
3. Conclusión
Ben, como é habitual, os nosos Kulibins non se molestaron, colleron o que tiñan, engadiron un pouco de seu e elaboraron un "produto" que, segundo os documentos, é doméstico, pero en realidade é OpenSource. Ten sentido gastar cartos do orzamento en sistemas de virtualización "separados" (léase: non incluído no SO)? Non penses. Dado que seguirás recibindo o mesmo KVM, só terás que pagar por el.
Así, a elección dun substituto para un hipervisor depende do sistema operativo do servidor que vai mercar para o Enterprise e operar. Ou, como no meu caso, quedarás co que xa tes (Hyper-VESXi insert_needed).
Fonte: www.habr.com