We talked about two important contents in "KVM Virtualization Solution Series: KVM Architecture", one of which is "To realize a KVM virtualization solution that can run and maintain, two problems need to be solved. The first One is the implementation of virtualization technology, and the second is the management of cluster virtual machines. " The other content is " the KVM module, as the core of the entire virtualization environment, works in the kernel space and is responsible for CPU and memory scheduling. QEMU serves as a simulated The server works in the user space and is responsible for the I/O simulation of the virtual machine. The creation and operation of the KVM virtual machine is a process in which the KVM module in the kernel mode and the QEMU program in the user mode cooperate with each other. "
The first content actually talks about the problem of "KVM virtualization" and the problem of "KVM management tools". The second content actually talks about how to solve the "KVM virtualization" problem mentioned in the first content. Through the cooperation of KVM+QEMU, the KVM virtualization problem is perfectly solved. However, we still have a problem of "KVM management tools" that has not been solved. If we also solve the problem of "KVM management tools", then a complete KVM solution will be solved, so we start from these two contents It can be concluded that the KVM virtualization solution is generally divided into three layers, as shown in Figure 1.
1. The first layer of KVM
The first layer of KVM is basically built into the Linux kernel. Starting from version 2.6.20 of Linux, KVM has been fully included in the Linux kernel. KVM exists as a module in the Linux kernel, so as long as you use Linux 2.6. For Linux version 20 or higher than Linux 2.6.20, the KVM module has been loaded when the system is installed, so we only need to enable the KVM module in the CLI command line mode.
2. The second layer QEMU
The second layer of QEMU , in 2012, the qemu-kvm branch was merged into the mainstream QEMU. Since then, you don’t need a special qemu-kvm to realize KVM virtualization (you can also continue to use it, the current CentOS is in use), and only need to add the "-enable-kvm" option to the general QEMU command, which is equivalent to using the KVM function, and KVM drives the virtual machine, that is, QEMU can call the KVM kernel, so the efficiency is Much higher than pure QEMU.
3. The third layer KVM management tool
3.1. Different methods of KVM management tools
After the first layer of KVM and the second layer of QEMU are solved, the rest is the KVM management tool. There are many ways to play the KVM management tool. If your enterprise cloud computing team only has 40-50 people, then play Management tools such as WebVirtMgr and Proxmox VE are more suitable. If your enterprise has a cloud computing team with hundreds of people and a rich father, you can use a cloud computing management platform such as OpenStack.
KVM management tools have many different levels, different ranks, and different positioning methods. This depends on your company's product positioning, business direction, and whether you have a sponsor, as shown in Figure 2.
In Figure 2, we can see that KVM management tools have five types of gameplay: native, primary, intermediate, advanced, and super. To realize the commercialization of KVM virtualization solutions, it is necessary to solve the problem of virtual machine cluster management, but this is not the case. It does not mean that the three ranks of native, elementary and intermediate are useless, on the contrary, they are the underlying technology of advanced and super ranks.
3.2. KVM virtualization solution architecture
In order to let everyone see it more clearly, I reconstructed a more concrete architecture diagram based on the content in Figure 2—the KVM virtualization solution architecture diagram, as shown in Figure 3.
A virtual machine is an ordinary Linux process. Through the management of this process, the management of the virtual machine can be realized. We can see from Figure 3 that Proxmox VE, Kimchi, and the native management tool QEMU all directly manage the virtual machine through the management of the KVM process.
However, because the direct management of the process is very troublesome, RedHat and Proxmox each released an open source project Libvirt and Proxmox VE to reduce the difficulty of KVM management. Libvirt is currently the most widely used tool and application program interface for managing KVM virtual machines. That is to say, Libvirt has an API and a set of command line management tools to complete the management of virtual machines. The same is true for Proxmox VE, which has a REST API, a set of command line tools and a WebGUI management tool, which can also complete the management of virtual machines.
3.2.1. Ecology of Libvirt
Libvirt is an open source project created by predators such as RedHat and IBM. Backed by the two big trees of RedHat and IBM, Libvirt's ecological chain is very good, from the underlying Linux operating system to the virtualization of the middle layer, to the upper layer The Libvirt API does:
-
The underlying Linux system , Libvirt supports RHEL, CentOS, Fedora, Ubuntu, Debian, ... and other Linux operating systems;
-
For the virtualization of the middle layer , Libvirt supports platform virtualization solutions including KVM/QEMU, Xen, VMware, VirtualBox, Hyper-V, etc.
-
The Libvirt tool comes with the virsh command line tool. The virsh command line tool can only implement stand-alone management mode. Simply relying on virsh to manage virtual machines cannot become a mature KVM virtualization solution.
-
Libvirt API , Libvirt provides a set of API lib libraries to support KVM management tools of ecological partners to manage virtual machines by calling Libvirt API. Currently, there are command-line tools (virt-install), graphical tools (virt-manager, virt-viewer, virt-top), web management tools (WebVirtMgr, oVirt), and cloud management platform tools (OpenStack, ZStack, OpenNebula, Eucalyptus , CloudStack) and other tools are Libvirt-based management tools.
3.2.2. Ecology of Proxmox VE
Proxmox VE is both a KVM management tool and an application programming interface similar to the Libvirt middle layer. Proxmox VE is an open source product of Proxmox Server Solutions, an Austrian commercial company. Proxmox VE software and community support are free, and enterprise users can obtain paid commercial support through a subscription system. The main disadvantage of Proxmox VE is that this open source product is only maintained by Proxmox Server Solutions, and its ecology is not as good as Libvirt.
- The underlying Linux system , Proxmox VE only supports the Debian Linux operating system and does not support other Linux operating systems.
- For the virtualization of the middle layer , Proxmox VE only supports KVM/QEMU as a virtualization solution.
- The Proxmox VE tool comes with an embedded WebGUI management interface tool and a command-line management tool. The WebGUI management interface can complete more than 98% of configurations, and very few functions require command-line management tool configuration. These two built-in tools of Proxmox VE can realize small-scale cluster management. Together with KVM/QEMU, they can become a mature KVM virtualization solution.
- REST API , Proxmox VE uses a RESTful API. Third-party developers choose JSON as the main data format. All API definitions use JSON syntax. Third-party management tools can easily integrate Proxmox VE API. However, the ecology of Proxmox VE is not very good. So far, no third-party partners have used Proxmox VE API to manage KVM virtualization. There may be two reasons for this. On the one hand, Proxmox VE itself does not have much underlying operating system and middle-layer virtualization support. In addition, Proxmox VE is only suitable for small-scale cluster management, so there are no third-party partners to develop based on Management tool for Proxmox VE API. On the other hand, the WebGUI management interface tool that comes with Proxmox VE is already a commercial-grade management tool comparable to VMware. Customers can directly use the WebGUI management interface of Proxmox VE, and third-party partners can no longer find too many commercial There is room for imagination.
Next, I will introduce Libvirt (libvirt tools, libvirt API) and management tools based on Libvirt API one by one in subsequent chapters, and introduce Proxmox VE, Kimchi tools based on KVM process management, etc., so I won’t go into details here.