Import substitution in practice. Part 2. Beginning. hypervisor

In the previous article Options were considered for replacing existing systems as part of the implementation of the import substitution order. Later in the articles, we will discuss the selection of specific products to replace those currently deployed. Let's start with a reference point - virtualization systems.

1. The agony of choice

So what can you choose from? IN register of the Ministry of Telecom and Mass Communications there is a choice:

• 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 article, so I will not dwell on this issue.

In fact, here list of Astra Linux virtualization tools:

• 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 following packages:

• ROSA Virtualization over oVirt over KVM
• QEMU over KVM
• oVirt3.5 over KVM

Do Calculate it QEMU over KVM

Alt Linux has the same KVM

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:

1. KVM
2. VirtualBox
3. QEMU

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 license violation: “Starting with version 4, released in December 2010, the main part of the product is distributed free of charge under the GPL v2 license. An add-on package installed on top of it that provides support for USB 2.0 and 3.0 devices, Remote Desktop Protocol (RDP), drive encryption, NVMe boot and PXE boot, is distributed under a special PUEL (“For Personal Use and Evaluation”) license, under which the system free for personal use, for educational purposes, or for evaluation before deciding to purchase a commercial version." (c) Plus, VirtualBox is also a type 2 hypervisor, so it also disappears.

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 article: “We need to bring the indicators to the established limits. In fact, this means that we have to replace existing OSes with products from the Ministry of Telecom and Mass Communications registry and bring the number of replaced operating systems to 80%.… So, we can safely leave the cluster on Hyper-V, since we already have it and we like it… "(c) So we have a choice: Microsoft Hyper-V or KVM. KVM maybe with controls “screwed” to it, but it will still remain the same KVM.

These products have not been compared far onceNot twiceNot three times… Well, you get the idea…

About deployment and configuration KVM also written not onceNot twiceNot three times and four times… In a word, vyponeli.

Same thing about Microsoft Hyper V..

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