April 14, 2019 at 11:22Import substitution in practice. Part 2. The beginning. Hypervisor
In a previous article , options were considered for which existing systems can be replaced as part of the implementation of the import substitution order. Further articles will focus on the selection of specific products to replace currently deployed. Let's start from the starting point - virtualization systems.
So what can you choose from? In the registry of the Ministry of Communications there is a choice :
You can also take into account hypervisors that are part of the OS delivery, or are 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. The fact that “what can be used in the framework of import substitution and what is not” was discussed in the previous article , so I will not dwell on this issue.
Upon closer examination, we conclude that we will have to deal with only a few well-known hypervisors, namely:
QEMU is a free open-source program for emulating hardware of various platforms that can work without using KVM, but the use of 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 product environment. It can be used with KVM, but in this case, QEMU will be used as a KVM management tool.
bhyve - hypervisions of the second type. It is marked.
Using the original VirtualBox in commerce is in fact a violation of the license: “Starting with version 4, released in December 2010, the bulk of the product is distributed free of charge under the GPL v2 license. The additional package installed on top of it, which supports USB 2.0 and 3.0 devices, Remote Desktop Protocol (RDP), drive encryption, boot from NVMe and PXE, is distributed under a special PUEL license (“for personal use and familiarization”), under which the system free for personal use, for training 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 its pure form we have only KVM .
If you still need to switch to a “domestic” hypervisor, you have, frankly, a small choice. It will be KVM in one or another wrapper, with various modifications, but it will still be KVM. For better or worse - the question is different, anyway there is no alternative.
If the conditions are not so strict, then, as stated in the previous article : “We need to bring the indicators to the established limits. In fact, this means that we must replace the existing operating systems with products from the registry of the Ministry of Communications and Communications 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 are faced with a choice: Microsoft Hyper-V or KVM .KVM may be with controls “bolted” to it, but it will still remain the same KVM .
These products were compared far more than once , not twice , not three times ... Well, you understand ...
About the deployment and configuration of KVM, it was also written more than once , not twice , not three times and not four times ... In a word, they made it out .
The same goes for 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 disrespect for the authors, I think. Who has to choose - he 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 bunch of Corosync + Pacemaker, for example. (Almost all domestic OSs have this bunch ... maybe everyone has, but I did not check 100%.) There are also plenty of manuals for configuring clustering.
Well, as usual, our Kulibins did not bother, they took what happened, screwed a little of their own, and gave out a “product”, which according to the documents is domestic, but in fact - OpenSource. Does it make sense to spend money from the budget for “separate” virtualization systems (read not included in the OS)? I don’t think so. Since you will still receive the same KVM, you will only have to pay for it.
Thus, the choice of replacement for the hypervisor comes down to which server OS you intend to purchase and operate for the Enterprise. Or, as in my case, you’ll stay on what you already have (Hyper-V \ ESXi \ enter_necessary).
You can also read on the topic:
Previous article about import substitution planning.
And further on:
Articleabout "domestic" operating systems.
An article about systems and services.
And about the QP OS in addition.
1. Flour of choice
So what can you choose from? In the registry of the Ministry of Communications there is a choice :
- Server virtualization system " R-Virtualization " (libvirt, KVM, QEMU)
- The software package " Brest Virtualization Tools " (libvirt, KVM, QEMU)
- Management and monitoring platform for the Sharx Stream virtualization environment (a cloud solution that is not suitable for public sector in 95% of cases (privacy, etc.)
- HOST virtualization software for servers, desktops and applications (KVM x86)
- The system of secure management of the virtualization environment " Z | virt " (aka oVirt + KVM)
- The ROSA Virtualization virtualization environment management system (aka oVirt + KVM)
- QP VMM Hypervisor (too similar to Oracle Virtual Box to be anything else)
You can also take into account hypervisors that are part of the OS delivery, or are 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. The fact that “what can be used in the framework of import substitution and what is not” was discussed in the previous article , so I will not dwell on this issue.
In fact, here is a list of Astra Linux virtualization tools
ROSA Linux does not have such a list, but in the wiki you can find the following packages:
Alt Linux in the repository found:
Calculate found the following:
Ulyanovsk.BSD
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 open-source program for emulating hardware of various platforms that can work without using KVM, but the use of 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 product environment. It can be used with KVM, but in this case, QEMU will be used as a KVM management tool.
bhyve - hypervisions of the second type. It is marked.
Using the original VirtualBox in commerce is in fact a violation of the license: “Starting with version 4, released in December 2010, the bulk of the product is distributed free of charge under the GPL v2 license. The additional package installed on top of it, which supports USB 2.0 and 3.0 devices, Remote Desktop Protocol (RDP), drive encryption, boot from NVMe and PXE, is distributed under a special PUEL license (“for personal use and familiarization”), under which the system free for personal use, for training 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 its pure form we have only KVM .
2. The rest: KVM or KVM?
If you still need to switch to a “domestic” hypervisor, you have, frankly, a small choice. It will be KVM in one or another wrapper, with various modifications, but it will still be KVM. For better or worse - the question is different, anyway there is no alternative.
If the conditions are not so strict, then, as stated in the previous article : “We need to bring the indicators to the established limits. In fact, this means that we must replace the existing operating systems with products from the registry of the Ministry of Communications and Communications 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 are faced with a choice: Microsoft Hyper-V or KVM .KVM may be with controls “bolted” to it, but it will still remain the same KVM .
These products were compared far more than once , not twice , not three times ... Well, you understand ...
About the deployment and configuration of KVM, it was also written more than once , not twice , not three times and not four times ... In a word, they made it out .
The same goes for 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 disrespect for the authors, I think. Who has to choose - he 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 bunch of Corosync + Pacemaker, for example. (Almost all domestic OSs have this bunch ... maybe everyone has, but I did not check 100%.) There are also plenty of manuals for configuring clustering.
3. Conclusion
Well, as usual, our Kulibins did not bother, they took what happened, screwed a little of their own, and gave out a “product”, which according to the documents is domestic, but in fact - OpenSource. Does it make sense to spend money from the budget for “separate” virtualization systems (read not included in the OS)? I don’t think so. Since you will still receive the same KVM, you will only have to pay for it.
Thus, the choice of replacement for the hypervisor comes down to which server OS you intend to purchase and operate for the Enterprise. Or, as in my case, you’ll stay on what you already have (Hyper-V \ ESXi \ enter_necessary).
You can also read on the topic:
Previous article about import substitution planning.
And further on:
Articleabout "domestic" operating systems.
An article about systems and services.
And about the QP OS in addition.