A method and device for hot upgrade of KVM virtualization software

Abstract

The purpose of the present application is to provide a hot upgrade method and device for KVM virtualization software. Compared with the prior art, the present application upgrades the KVM virtualization software deployed on the target physical machine, wherein the running source cloud host continues to run on the un-upgraded KVM virtualization software, and a container is deployed on the target physical machine based on a preset setting, wherein the container is kept in mirror image with the file system of the target physical machine, then the running source cloud host is migrated from the target physical machine to the container to become a target cloud host, wherein the container contains the upgraded KVM virtualization software, and the target cloud host running in the container is migrated back to the target physical machine to complete the upgrade of the KVM virtualization software deployed on the target physical machine. This method realizes the local hot upgrade of KVM virtualization software without crossing the physical host, reduces the cost of hot upgrade, and improves the efficiency of hot upgrade.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a hot-upgrade technology for KVM virtualization software. Background Technology

[0002] KVM (Kernel-based Virtual Machine) virtualization software, as one of the most important underlying foundations of cloud computing, is widely used in modern data centers. A KVM-based hypervisor includes the hardware and software that constitute the host machine, working together to provide high-performance CPU, memory, and I / O resources for applications within virtual machines. In large-scale production environments, ensuring the maintainability of the hardware and software has always been a key concern for cloud service providers.

[0003] To provide users with stable, secure, efficient, and feature-rich cloud resources, the underlying software of IaaS must be able to support various hardware and software operation and maintenance needs. For example, in the event of unavoidable hardware failures, it needs to be able to promptly hot-migrate virtual machines to healthy host machines; or, after software security vulnerabilities or functional defects are fixed, it needs to be able to be hot-upgraded and deployed to the production environment in a timely manner.

[0004] However, achieving seamless hot upgrades for users is an extremely complex systems engineering project. Currently, various open-source communities (such as Linux, QEMU, CloudHypervisor, etc.) and major cloud computing vendors are actively trying to support hot upgrades for KVM. The main solutions include:

[0005] 1. QEMUCare: This solution uses live patching technology to repair CVEs in KVM virtualization software. However, due to the inherent limitations of live patching, it has several drawbacks: 1) It is limited to function-level patching, and cannot change data structures, parameter types, or return value semantics; 2) The software requires a symbol table, and the patched function must be in this table; 3) The system needs a debugger to monitor software task status and look up the symbol table; 4) The software process must be paused before patching, ensuring the function to be patched is not being called during the pause; 5) The same function cannot be patched multiple times; 6) Patching will render performance tracing tools unusable. Therefore, this solution is only suitable for function-level CVE repair and is ineffective for more complex defects, let alone major software version upgrades.

[0006] Nutanix: The KVM virtualization software upgrade solution based on libvirt local migration will lead to changes in the UUID of the cloud host. However, in the cloud computing platform, the UUID is the main identifier of the cloud host. Once it is changed, it will inevitably affect the cloud platform's control over the cloud host and ultimately affect the user's business.

[0007] Intel: KVM virtualization software seamless upgrade technology, which utilizes non-volatile memory and IOMMU hardware-assisted virtualization technology, relies on specific hardware and cannot be applied to general scenarios.

[0008] Oracle: KVM virtualization software hot upgrade based on CPR (checkpoint restore). During the upgrade process, the device state of the cloud host is saved to a specified file in advance, and the memory pages used by the cloud host are retained. After switching to the new KVM process through the execve system call, its execution is first paused, and then the previously retained cloud host memory pages are remapped to the new KVM process. At the same time, the saved cloud host device state is loaded from the previously retained file, and then the execution of the cloud host is resumed. Its main drawbacks are: 1) It does not support rollback in case of hot upgrade failure, which will directly cause the cloud host to crash; 2) It lacks support for libvirt. When KVM software is hot upgraded, it will close the libvirt monitor channel, causing the libvirt monitor channel to receive an EOF event. libvirt will assume that the cloud host has crashed and send SIGTERM to clean up the KVM process, which will directly cause the cloud host to crash; 3) Hot upgrade requires the cloud host configuration parameters to be set in advance. Due to the lack of libvirt support, it is impossible to obtain the corresponding cloud host configuration parameters required for hot upgrade. If the parameters are set incorrectly, it will cause the cloud host to crash; 4) The default values ​​of various parameters will change in different versions of KVM software, and the machine types supported by different versions may also be inconsistent. All of these can cause the cloud host to crash during the upgrade process.

[0009] The QEMU / libvirt open-source community offers a KVM virtualization software hot upgrade solution based on cross-physical machine cloud host hot migration. This solution requires cross-physical machine hot migration, necessitating a separate idle physical machine as the target machine. After starting a cloud host with the same UUID on the target machine, its operation is paused. Dirty pages from the source cloud host are recursively transferred to the target cloud host until the number of dirty pages falls below a predetermined threshold. At this point, the source cloud host is paused, and the remaining dirty pages are synchronously transferred to the target cloud host. The device status of the source cloud host is then synchronized to the target cloud host. Finally, the source cloud host is shut down, and the target cloud host is restored to continue running user services. However, this solution is not efficient for scenarios where cloud hosts use local storage. For PCI passthrough devices, matching hardware support is required on both the source and target physical machines. Summary of the Invention

[0010] The purpose of this application is to provide a hot-upgrade method for KVM virtualization software. The method includes:

[0011] Upgrade the KVM virtualization software deployed on the target physical machine, while the source cloud host that is already running continues to run on the un-upgraded version of KVM virtualization software;

[0012] A container is deployed on the target physical machine based on specific settings, wherein the container maintains a mirror image of the file system of the target physical machine;

[0013] Migrating the existing source cloud host from the target physical machine to a container to become the target cloud host requires modifying the virtual network interface card (NIC) configuration of the target cloud host to avoid conflicts with the NIC configuration of the source cloud host. The container contains upgraded KVM virtualization software.

[0014] The target cloud host running inside the container is migrated back to the target physical machine to complete the upgrade of the KVM virtualization software deployed on the target physical machine.

[0015] Furthermore, specific settings for deploying containers include enabling privileged mode for the container, setting the network to host mode, and setting the IPC mode to host for Ceph distributed storage.

[0016] Furthermore, when running the libvirtd service within a container, the listening port and hostuuid configuration of the libvirtd service must be different from the configuration of the libvirtd service running on the target physical host to ensure smooth hot migration of the cloud host between the physical machine and the container.

[0017] Furthermore, to ensure smooth migration of cloud hosts between physical machines and containers, this invention enables the Hypervisor within the container to access the storage paths used by the cloud host. After the cloud host is migrated into the container, it can still access various types of storage normally, including local storage, network storage, and distributed storage.

[0018] Compared to existing technologies, this application achieves local hot upgrades of KVM virtualization software deployed on the target physical machine. This approach offers several advantages: 1) it eliminates the need to cross physical machines and requires no additional physical machine resources; 2) it avoids the migration of dirty memory pages and device states across physical machine networks, resulting in superior migration performance; 3) it supports rollback in case of hot upgrade failure, ensuring uninterrupted cloud server operations even if the upgrade fails; and 4) it supports efficient migration when the cloud server uses local storage. This method enables local hot upgrades of KVM virtualization software without requiring cross-physical machine connections, reducing the cost and improving the efficiency of hot upgrades. Furthermore, it provides a seamless hot upgrade experience for users without impacting their business operations. Attached Figure Description

[0019] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0020] Figure 1 This diagram illustrates a hot-upgrade method for KVM virtualization software according to one aspect of this application;

[0021] Figure 2 The diagram illustrates a hot-upgrade method for KVM virtualization software according to a preferred embodiment of this application.

[0022] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0023] The present invention will now be described in further detail with reference to the accompanying drawings.

[0024] In a typical configuration of this application, the terminal, the device of the service network, and the trusted party all include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0025] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0026] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0027] To further illustrate the technical means adopted and the effects achieved in this application, the technical solution of this application will be clearly and completely described below with reference to the accompanying drawings and preferred embodiments. In this application, the KVM virtualization software is deployed on the target physical machine.

[0028] Figure 1 This application illustrates a hot-upgrade method for KVM virtualization software, comprising:

[0029] S11 upgrades the KVM virtualization software deployed on the target physical machine, while the source cloud host that is already running continues to run on the un-upgraded KVM virtualization software;

[0030] S12 Deploys a container on the target physical machine based on preset settings, wherein the container maintains a mirror image of the file system of the target physical machine;

[0031] S13 migrates the running source cloud host from the target physical machine to the container to become the target cloud host, wherein the container contains upgraded KVM virtualization software;

[0032] S14 migrates the target cloud host running inside the container back to the target physical machine to complete the upgrade of the KVM virtualization software deployed on the target physical machine.

[0033] In this embodiment, in step S11, the KVM virtualization software on the target physical machine is first upgraded, but this will not affect the already running source cloud host. The already running source cloud host will continue to run on the old (i.e., unupgraded) Hypervisor.

[0034] Continuing with this embodiment, in step S12, a container is deployed on the target physical machine based on preset settings, wherein the container maintains a mirror image of the file system of the target physical machine. That is, in this step, an additional container is deployed on the physical machine where KVM virtualization software is deployed, and the file system of the container is mirrored with the file system of the target physical machine, thus maintaining consistency between the KVM software version within the container and the physical host.

[0035] Preferably, the preset settings include opening the container in a privileged manner, setting the network to host mode, and setting the IPC mode to host for Ceph distributed storage.

[0036] Specifically, in this embodiment, privileged mode is enabled in the container to support the hypervisor within the container to operate the KVM kernel module; the network is set to host mode to support the hypervisor within the container to configure the network for the cloud host; for Ceph distributed storage, IPC mode needs to be set to host to support communication between the container and the Ceph service. Simultaneously, the container shares the hardware configuration of the target physical machine, and cloud host migration does not cross physical machines, thus supporting PCI pass-through devices.

[0037] Preferably, the method further includes: S15 (not shown) starting a libvirtd service within the container, wherein the service listening port is different from the listening port of the libvirtd service running on the target physical host, and the hostuuid is different from the configuration on the target physical host. However, other configurations remain consistent with the configuration of the physical host.

[0038] Continuing in this embodiment, in step S13, the running source cloud host is migrated from the target physical machine to a container to become the target cloud host, wherein the container contains upgraded KVM virtualization software. Storage migration is not required here.

[0039] Preferably, the method further includes: changing the network configuration of the target cloud host. Specifically, during migration, the network VNIC configuration on the target cloud host needs to be changed to prevent the Hypervisor inside the container from being unable to configure the network for the cloud host due to device occupation during the migration. After the migration is completed, it can be seen that the cloud host is running on the Hypervisor inside the container, and the Hypervisor inside the container can also access the storage path used by the cloud host.

[0040] Preferably, after step S13, the method further includes: accessing the storage path used by the target cloud host through the KVM virtualization software within the container. a) Therefore, after the virtual machine is migrated into the container, it can still access various types of storage normally, including local storage, network storage, distributed storage, etc. At this time, the cloud host has been migrated to the upgraded Hypervisor. If the hot migration fails here, the cloud host will remain on the physical machine and continue to run, without interrupting business operations.

[0041] Continuing in this embodiment, in step S14, the target cloud host running in the container is migrated back to the target physical machine to complete the upgrade of the KVM virtualization software deployed on the target physical machine.

[0042] Specifically, since the source and target cloud hosts are running the exact same version of KVM virtualization software, this migration is between hypervisors of the same version. After the migration is complete, the cloud host returns to running on the physical machine, but the hypervisor it uses is now the upgraded version. Thus, the KVM virtualization software hot upgrade is completed without interrupting cloud host services.

[0043] This application utilizes container technology to enable both physical machines and containers to access the backend storage used by the cloud host. It also allows for hot upgrades even for local storage. Furthermore, it significantly improves performance by eliminating the need for dirty page migration across physical machines via the real network. Additionally, since the physical machines and containers use identical hardware configurations, it offers better support for PCI passthrough devices, avoiding migration failures caused by hardware differences when migrating across physical machines.

[0044] Figure 2 This diagram illustrates a flowchart of a hot-upgrade method for KVM virtualization software according to a preferred embodiment of this application. In this flowchart, Physical Machine refers to the target physical machine, Docker refers to a container deployed on the target physical machine, and the Virtual Machine to the left of arrow 1 is the source cloud host, while the Virtual Machine to the right is the target cloud host.

[0045] Arrow 1 indicates a hot migration of a running cloud host from the target physical machine to the container, while arrow 2 indicates a migration of a cloud host running inside the container back to the physical machine. Since the source and target cloud hosts run the exact same version of KVM virtualization software, this migration occurs between hypervisors of the same version. After the migration is complete, the cloud host returns to the physical machine, but it will be using an upgraded version of the hypervisor.

[0046] Compared to existing technologies, this application upgrades the KVM virtualization software deployed on the target physical machine. The existing source cloud host continues to run on the un-upgraded KVM virtualization software, while a container is deployed on the target physical machine based on preset settings. The container's file system is mirrored with that of the target physical machine. The existing source cloud host is then migrated from the target physical machine to the container, becoming the target cloud host. The container contains the upgraded KVM virtualization software. Finally, the target cloud host running within the container is migrated back to the target physical machine, thus completing the upgrade of the KVM virtualization software deployed on the target physical machine. This method achieves local hot upgrades of the KVM virtualization software without traversing physical hosts, reducing the cost and improving the efficiency of hot upgrades. Furthermore, it enables user-unobtrusive hot upgrades without impacting user services.

[0047] According to another aspect of this application, a computer-readable medium is also provided, the computer-readable medium storing computer-readable instructions that can be executed by a processor to implement the aforementioned method.

[0048] According to another aspect of this application, a hot-upgrade device for KVM virtualization software is also provided, wherein the device includes:

[0049] One or more processors; and

[0050] A memory storing computer-readable instructions, which, when executed, cause the processor to perform operations as described above.

[0051] For example, when executed, the computer-readable instructions cause the one or more processors to: upgrade the KVM virtualization software deployed on the target physical machine, wherein the existing source cloud host continues to run on the un-upgraded KVM virtualization software; deploy a container on the target physical machine based on preset settings, wherein the container maintains a mirror image of the file system of the target physical machine; migrate the existing source cloud host from the target physical machine to the container to become the target cloud host, wherein the container contains the upgraded KVM virtualization software; and migrate the target cloud host running in the container back to the target physical machine to complete the upgrade of the KVM virtualization software deployed on the target physical machine.

[0052] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the apparatus claims may also be implemented by a single unit or device in software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order.

Claims

1. A hot upgrade method for KVM virtualization software, wherein, The method comprises: Upgrading KVM virtualization software deployed on a target physical machine, wherein a running source cloud host continues to run on un-upgraded KVM virtualization software; Deploying a container on the target physical machine based on preset settings, wherein the container is kept in mirror consistency with a file system of the target physical machine; Migrating the running source cloud host from the target physical machine to the container to become a target cloud host, wherein the container contains upgraded KVM virtualization software; Migrating the target cloud host running in the container back to the target physical machine to complete the upgrading of the KVM virtualization software deployed on the target physical machine.

2. The method of claim 1, wherein, The method further comprises: Changing a network configuration of the target cloud host.

3. The method of claim 1, wherein, The preset settings include opening a privileged mode of the container, setting a network to a host mode, and setting an IPC mode for ceph distributed storage to a host.

4. The method of any one of claims 1 to 3, wherein, The method further comprises: Starting a libvirtd service in the container, wherein a listening port of the service is different from a listening port of a libvirtd service running on the target physical host, and a host uuid is different from a configuration on the target physical host.

5. The method of claim 1, wherein, After the running source cloud host is migrated from the target physical machine to the container to become the target cloud host, the method further comprises: Accessing a storage path used by the target cloud host through the KVM virtualization software in the container.

6. A computer readable medium having stored thereon computer readable instructions executable by a processor to implement the method of any one of claims 1 to 5.

7. A hot upgrade device for KVM virtualization software, wherein, The device comprises: one or more processors; and a memory having stored thereon computer readable instructions that, when executed, cause the processor to perform operations of the method of any one of claims 1 to 5.

Images