In the previous
1. The agony of choice
So what can you choose from? IN
- Server virtualization systemR-VirtualizationΒ» (libvirt, KVM, QEMU)
- Software package "Brest virtualization toolsΒ» (libvirt, KVM, QEMU)
- Virtualization environment management and monitoring platform "Sharx Stream" (cloud solution that is not suitable for government agencies in 95% of cases (secrecy, etc.)
- Software suite for virtualization of servers, desktops and applicationsHOST" (KVM x86)
- Secure Virtualization Environment Management System Β«Z|virtΒ» (aka oVirt+KVM)
- Virtualization environment management system Β«ROSA VirtualizationΒ» (aka oVirt+KVM)
- hypervisor QP VMM (too similar to Oracle Virtual Box to be anything else)
You can also take into account the hypervisors included in the delivery of the OS, or located in their repository. For example, the same Astra Linux has KVM support. And since it is included in the OS repositories, it can be considered "legitimate" for installation and use. About "what can be used as part of import substitution and what is not" was discussed in the previous
In fact, here
- VirtualBox
- virt-manager (KVM) Eagle current
- libvirt over KVM
ROSA Linux does not have such a list, but you can find it in the wiki
- ROSA Virtualization over oVirt over KVM
- QEMU over KVM
- oVirt3.5 over KVM
Do Calculate it
Alt Linux has the same
1.2. There is one BUT
Upon closer examination, we conclude that we will have to deal with only a few well-known hypervisors, namely:
QEMU is a free and open source program for emulating hardware of various platforms that can work without using KVM, but using hardware virtualization significantly speeds up guest systems, so using KVM in QEMU (-enable-kvm) is the preferred option. (c) That is, QEMU is a type 2 hypervisor, which is unacceptable in a production environment. With KVM it can be used, but in this case QEMU will be used as a KVM management toolβ¦
Using the original VirtualBox in commerce is actually
Total: in pure form we have only KVM.
2. The rest: KVM or KVM?
In case you still need to switch to a βdomesticβ hypervisor, you have, frankly, little choice. It will be KVM in one wrapper or another, with some modifications, but still it will be KVM. Whether this is good or bad is another question, there is still no alternative.
If the conditions are not so strict, then, as mentioned in the previous
These products have not been compared far
About deployment and configuration KVM also written not
Same thing about
I see no reason to repeat and describe these systems, compare, etc. You can, of course, pull out key points from the articles, but this will be disrespectful to the authors, I think. Whoever has to choose will read not only this, but also a mountain of information to decide.
The only difference I want to focus on is failover clustering. If Microsoft has this built into the OS and the functionality of the hypervisor, then in the case of KVM, you will have to use third-party software, which should be included in the OS repositories. The same Corosync + Pacemaker bundle, for example. (Almost all domestic operating systems have this bundle ... maybe everyone has it, but I didnβt check all 100%.) There are also plenty of manuals for setting up clustering.
3. Conclusion
Well, as usual, our Kulibins did not bother, they took what they had, screwed in a little bit of their own, and issued a βproductβ that, according to the documents, is domestic, but in reality it is OpenSource. Does it make sense to spend money from the budget for "separate" virtualization systems (read, not included in the OS)? Don't think. Since you still get the same KVM, only you still have to pay for it.
So choosing a replacement for a hypervisor comes down to what server operating systems you're going to buy for the Enterprise and run. Or, as in my case, stay with what you already have (Hyper-VESXi fill in_required).
Source: habr.com