CN114416148A

CN114416148A - Hot upgrading method, device and storage medium for virtual machine management program

Info

Publication number: CN114416148A
Application number: CN202111484402.XA
Authority: CN
Inventors: 李凡
Original assignee: Sangfor Technologies Co Ltd
Current assignee: Sangfor Technologies Co Ltd
Priority date: 2021-12-07
Filing date: 2021-12-07
Publication date: 2022-04-29

Abstract

The application discloses a method and a device for hot upgrading of a virtual machine management program and a storage medium. The method for hot upgrading of the virtual machine management program comprises the following steps: and updating the first QEMU process of the virtual machine management program to be a second QEMU process through the setting service. After updating the first QEMU process to the second QEMU process, the first KVM driver of the virtual machine manager is unloaded and the second KVM driver is loaded, by the setup service, if it is determined that the first KVM driver is not used. And starting a second QEMU process through the setting service, wherein the starting of the second QEMU process depends on the second KVM drive.

Description

Hot upgrading method, device and storage medium for virtual machine management program

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for hot-upgrading a virtual machine management program, and a storage medium.

Background

The Hypervisor is a program running on a physical Host system and implementing Virtual functions, and includes a simulator QEMU process and a Kernel-Based Virtual Machine (KVM) driver.

In the related technology, when the Hypervisor is subjected to hot upgrade, the QEMU process and the KVM drive are usually separated to perform hot upgrade, and the performance of the virtual machine is greatly influenced by the hot upgrade process of the QEMU process; the hot upgrade process of the KVM driver requires a great modification to the KVM driver, which presents a modification risk, and the hot upgrade process cannot adapt to the native KVM driver of the non-open-source third-party Linux kernel. Therefore, the related art has a problem of low upgrading efficiency when the Hypervisor is upgraded in a hot mode.

Disclosure of Invention

In view of the above, embodiments of the present disclosure provide a method, an apparatus, and a storage medium for hot-upgrading a virtual machine hypervisor, so as to solve the problem of low upgrading efficiency when the virtual machine hypervisor is hot-upgraded in the related art.

In order to achieve the above purpose, the technical solution of the embodiment of the present application is implemented as follows:

the embodiment of the application provides a method for hot upgrading of a virtual machine management program, which comprises the following steps:

updating a first QEMU process of the virtual machine management program into a second QEMU process through the setting service;

after updating the first QEMU process to a second QEMU process, through the provisioning service, unloading a first KVM driver of the virtual machine manager if it is determined that the first KVM driver is not used and loading a second KVM driver;

starting the second QEMU process through the setting service; wherein the launching of the second QEMU process is dependent on the second KVM driver.

In the foregoing solution, the updating the first QEMU process of the virtual machine hypervisor to the second QEMU process by the setting service includes:

sending a first instruction to the first QEMU process through the setting service; the first instruction is used for indicating the first QEMU process to adjust the working state to be an exit state;

updating, by the provisioning service, the first QEMU process to a second QEMU process upon receiving a first response by the first QEMU process with respect to the first instruction; the first response characterizes that the first QEMU process has adjusted the working state to an exit state.

In the foregoing solution, the determining, by the provisioning service, that the first KVM driver of the virtual machine hypervisor is not used includes:

judging whether the second QEMU process is in an exit state through the setting service to obtain a judgment result;

and under the condition that the judgment result represents that the second QEMU process is in the exit state, determining that the first KVM drive is not used.

In the foregoing solution, the starting the second QEMU process by the setting service includes:

sending a second instruction to the second QEMU process through the setting service program; the second instruction is used for indicating the second QEMU process to call the first file and load the second file; the first file comprises a memory file of each virtual machine in at least one virtual machine corresponding to the first QEMU process; the second file is used for recording the running state of each virtual machine in at least one virtual machine corresponding to the first QEMU process;

determining to start the second QEMU process in case of receiving a second response of the second QEMU process with respect to the second instruction; and the second response represents that the second QEMU process successfully calls the first file and successfully loads the second file.

In the above solution, before the updating the first QEMU process of the virtual machine hypervisor to the second QEMU process by the setting service, the method includes:

acquiring a memory file of at least one virtual machine corresponding to the first QEMU process through the setting service;

and mapping the memory file of each virtual machine in the at least one virtual machine to the first file.

In the foregoing solution, before the updating the first QEMU process of the virtual machine hypervisor to the second QEMU process by the provisioning service, the method further includes:

sending a third instruction to the first QEMU process through the setting service program; the third instruction is used for indicating the first QEMU process to adjust the working state to a pause state;

under the condition that a third response of the first QEMU process about the third instruction is received, the running state of at least one virtual machine corresponding to the first QEMU process is obtained through the setting service; the third response characterizes that the first QEMU process has adjusted the working state to a suspended state;

and saving the running state of each virtual machine in the at least one virtual machine to a second file.

In the foregoing solution, after the determining to start the second QEMU process, the method includes:

deleting the second file through the provisioning service.

The embodiment of the present application further provides a device for hot upgrading of a virtual machine hypervisor, where the device includes:

the updating unit is used for updating the first QEMU process of the virtual machine management program into a second QEMU process through the setting service;

a loading unit, configured to, after updating the first QEMU process to a second QEMU process, unload, by the provisioning service, the first KVM driver of the virtual machine manager if it is determined that the first KVM driver is not used, and load a second KVM driver;

the starting unit is used for starting the second QEMU process through the setting service; wherein the launching of the second QEMU process is dependent on the second KVM driver.

An embodiment of the present application further provides an electronic device, including: a processor and a memory for storing a computer program capable of running on the processor, wherein,

the processor is adapted to perform the steps of any of the above methods when running the computer program.

Embodiments of the present application further provide a storage medium on which a computer program is stored, where the computer program is executed by a processor to implement the steps of any one of the above methods.

In the embodiment of the application, the first QEMU process of the virtual machine management program is updated to the second QEMU process through the setting service. After updating the first QEMU process to the second QEMU process, the first KVM driver of the virtual machine manager is unloaded and the second KVM driver is loaded, by the setup service, if it is determined that the first KVM driver is not used. And starting a second QEMU process through the setting service, wherein the starting of the second QEMU process depends on the second KVM drive. Therefore, in the process of updating the virtual machine management program through the setting service, after the QEMU process is updated, if the KVM drive is detected not to be used, the KVM drive is continuously updated, so that the QEMU process and the KVM drive can be updated in one updating process of updating the virtual machine management program, the virtual machine management program is completely updated in one updating process, and the upgrading efficiency of the thermal upgrading of the virtual machine management program is improved.

Drawings

FIG. 1 is a block diagram of a hypervisor;

FIG. 2 is a diagram illustrating a KVM drive hot upgrade in the related art;

fig. 3 is a schematic flowchart illustrating an implementation flow of a method for hot upgrading a hypervisor provided in an embodiment of the present application;

fig. 4a and fig. 4b are schematic diagrams of a starting process of a second QEMU process according to an embodiment of the present application;

FIG. 5 is a schematic diagram of determining a first file according to an embodiment of the present application;

FIG. 6 is a diagram illustrating saving a second file according to an embodiment of the present application;

fig. 7 is a schematic diagram of deleting a second file according to an embodiment of the present application;

fig. 8 is a schematic diagram of a virtual machine hypervisor hot upgrade apparatus according to an embodiment of the present application;

fig. 9 is a schematic diagram of a hardware component structure of an electronic device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

The technical means described in the embodiments of the present application may be arbitrarily combined without conflict.

In addition, in the embodiments of the present application, the terms "first", "second", and the like are used for distinguishing similar objects, and are not necessarily used for describing a particular order or sequence. The term "and/or" is merely an associative relationship that describes an associated object, meaning that three relationships may exist, e.g., a and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the term "at least one" means any combination of at least two of any one or more of a plurality, for example, including at least one of A, B, C, and may mean including any one or more elements selected from the group consisting of A, B and C.

Before further detailed description of the embodiments of the present application, terms and expressions referred to in the embodiments of the present application will be described, and the terms and expressions referred to in the embodiments of the present application will be used for the following explanation.

Virtual machine GUEST is a virtual machine running on a virtualization platform.

HOST-the physical HOST running the virtual machine.

QEMU is an open source simulator and Virtual Machine Monitor (VMM). It is primarily a virtual machine supervisor that simulates the entire system, utilizes the KVM driver to use the virtualization support provided by the hardware, and creates virtual machines that approach the performance of the host.

The KVM is a kernel-based virtual machine which is a loadable module of a Linux kernel. The KVM realizes the bottom layer virtualization of the CPU and the memory virtualization of the CPU by calling the kernel function of the Linux itself, so that the Linux kernel becomes a virtualization layer. KVM relies on the x86 architecture, and hardware supporting virtualization functions (such as Intel-VT and AMD-V) is a fully virtualized architecture. In its present form, a KVM includes two kernel modules: ko and kvm _ intel.ko (or kvm _ amd.ko).

QEMU-KVM A complete set of virtualization technical scheme is formed by combining QEMU and KVM.

Hypervisor is a virtual machine management program which runs on the HOST system and is used for realizing a software program with a virtualization function. The Hypervisor in the embodiment of the present application includes a QEMU process and a KVM driver.

UPDATE _ MGR is a hot upgrade management module which is responsible for the hot upgrade of the whole Hypervisor.

Fig. 1 is a schematic diagram of a virtual machine hypervisor, as shown in fig. 1:

the architecture comprises three parts, namely a virtual machine, a physical host user space and a physical host kernel. Wherein the content of the first and second substances,

the virtual machine includes a virtual user space and a virtual kernel.

The physical host user space includes a QEMU process, an Input/Output Control (IOCTL) module, and a handle module. The IOCTL module is a system call dedicated to input and output operations of the device. The IOCTL modules comprise a System IOCTL, a virtual machine VM IOCTL and a virtual central processing unit VCPU IOCTL, and each IOCTL module corresponds to one KVM handle.

The physical host kernel comprises a KVM Driver module and the physical host kernel.

The KVM driver is responsible for virtualization of the CPU and the memory, and after the KVM driver is loaded, a user can further create a virtual machine through a setting tool, which is equivalent to providing an interface for the KVM driver. However, with only the KVM driver, the user cannot directly control the virtual machine kernel. That is, the KVM driver merely provides an interface, and cannot implement functions such as creation of a virtual machine, allocation of a VCPU, and the like. Therefore, a tool running in the physical host user space needs to be provided, and a KVM driver developer selects a relatively mature open source virtualization software QEMU process as the tool and adjusts the QEMU process, so as to finally form a QEMU-KVM architecture, i.e., a virtual machine hypervisor architecture. In the framework, a KVM drive runs in a physical host kernel, and a QEMU process runs in a physical host user space, so that various virtual machines are created and managed in an actual simulation mode.

According to industry related statistics, over 90% of defects and security holes are located on the hypervisor in the field of virtual machines. In order to avoid defects and security holes as much as possible, the virtual machine management program needs to be continuously upgraded.

For upgrading of a virtual machine management program, a traditional mode is cold upgrading, namely, the virtual machine is closed for upgrading. However, shutting down the virtual machine may result in interruption of virtual machine traffic. Therefore, a hot upgrade that upgrades the hypervisor of the virtual machine without shutting down the virtual machine is more popular.

In the related art, when the virtual machine management program is upgraded in a hot mode, the QEMU process and the KVM driver are usually upgraded in a hot mode separately. The method comprises the following specific steps:

1. a hot upgrade for QEMU process. Currently, the main QEMU process hot upgrade scheme in the industry is realized by directly multiplexing the hot migration function of the QEMU process. In the live migration process, the copy of the memory file of the virtual machine occupies a certain memory bandwidth and network bandwidth, and meanwhile, in order to avoid that the memory copy cannot be completed due to the excessively high speed of the dirty page generation, the CPU needs to be limited in speed, which inevitably causes the performance degradation of the virtual machine service in the live migration process.

And the larger the memory file of the virtual machine is and the higher the memory writing frequency is, the longer the time required by the thermal migration is. For high-end services such as finance, big data and the like, the memory file of the virtual machine is usually hundreds of GB big, and if the requirement on the service performance of the virtual machine is higher, the requirement of a user can not be met based on a thermal migration upgrading mode.

In addition, in the live migration process, an extra memory space is required to store the memory file of the virtual machine during migration, and the migration thread also needs to occupy extra CPU, memory bandwidth, network bandwidth, and the like. The additional consumption of hardware resources causes that a heat transfer mode is difficult to be performed at high concurrency, and for a cluster with a higher load, only one-by-one upgrading of virtual machines can be realized, so that the requirement for large-scale upgrading of the virtual machines is difficult to meet.

2. Hot upgrade for KVM drivers.

FIG. 2 is a diagram illustrating a KVM drive hot upgrade in the related art, as shown in FIG. 2:

two KVM driver instances are maintained simultaneously: ko and KVM-intel.ko, and encapsulates two KVM drive instances. When upgrading a KVM drive, the two KVM drives are alternately switched.

However, this upgrading method is complex to implement, requires a great modification to the KVM driver, and involves a risk of modification. Due to the change of the KVM drive, the native KVM drive of a non-open source third-party Linux kernel cannot be adapted, and the existing old version KVM drive cannot be upgraded thermally.

That is to say, in the related art, when the virtual machine management program is thermally upgraded, only the QEMU process and the KVM driver can be thermally upgraded respectively, and there are many limitations in the process of thermally upgrading the QEMU process and the KVM driver respectively, which results in very low efficiency of thermally upgrading the virtual machine management program.

Based on this, the embodiment of the application provides a method, a device and a storage medium for hot upgrade of a virtual machine management program, and a first QEMU process of the virtual machine management program is updated to a second QEMU process through a setting service. After updating the first QEMU process to the second QEMU process, the first KVM driver of the virtual machine manager is unloaded and the second KVM driver is loaded, by the setup service, if it is determined that the first KVM driver is not used. And starting a second QEMU process through the setting service, wherein the starting of the second QEMU process depends on the second KVM drive. Therefore, in the process of updating the virtual machine management program through the setting service, after the QEMU process is updated, if the KVM drive is detected not to be used, the KVM drive is continuously updated, so that the QEMU process and the KVM drive can be updated in one updating process of updating the virtual machine management program, the virtual machine management program is completely updated in one updating process, and the upgrading efficiency of the thermal upgrading of the virtual machine management program is improved.

The present application will be described in further detail with reference to the following drawings and examples.

Fig. 3 is a schematic flowchart of an implementation process of the method for hot upgrading of a hypervisor provided in the embodiment of the present application. As shown in fig. 3, the method includes:

step 301: and updating the first QEMU process of the virtual machine management program to be a second QEMU process through the setting service.

Here, the provisioning service is a service that is provisioned exclusively for taking charge of hot upgrade of the virtual machine hypervisor. In practical applications, the provisioning service may be a thermal upgrade management service UPDATE _ MGR.

And updating the first QEMU process of the virtual machine management program to be a second QEMU process through the setting service.

In an embodiment, the updating the first QEMU process of the virtual machine hypervisor to the second QEMU process by the setup service includes:

Here, a first instruction is sent to the first QEMU by the setup service, the first instruction being used to instruct the first QEMU process to adjust the operating state to the exit state. And under the condition of receiving a first response that the first QEMU process has adjusted the working state to the exit state, updating the first QEMU process to be a second QEMU process through the setting service.

In practical application, the first instruction may be sent to the first QEMU process through UPDATE _ MGR. And replacing the binary program corresponding to the first QEMU process with the binary program corresponding to the second QEMU process to complete the updating of the QEMU process of the virtual machine management program.

Under the condition that the first QEMU process is determined to be in the quitting state, the first QEMU process is updated to be the second QEMU process, the influence of the updating process on the normal working state of the first QEMU process is avoided, and the running stability of the virtual machine management program is improved when the first QEMU process is updated.

Step 302: after updating the first QEMU process to a second QEMU process, with the setup service, uninstalling the first KVM driver and loading a second KVM driver if it is determined that the first KVM driver of the virtual machine manager is not used.

Here, after updating the first QEMU process to the second QEMU process, whether the first KVM driver of the virtual machine manager is used is continuously confirmed through the setup service, and if it is confirmed that the first KVM driver is not currently used, the first KVM driver is uninstalled through the setup service and the second KVM driver is loaded, thereby implementing the update of the KVM driver.

It should be noted that, in the embodiment of the present application, the thermal upgrade of the KVM driver is implemented by unloading the first KVM driver and loading the second KVM driver, so that no modification needs to be performed on the KVM driver itself during the thermal upgrade process of the KVM driver, and therefore, the thermal upgrade method of the KVM driver provided in the embodiment of the present application can adapt to the thermal upgrade of the native KVM driver of the Linux kernel of a third party, and can also support the thermal upgrade of the existing old version of the KVM driver.

In one embodiment, the determining, by the provisioning service, that the first KVM driver of the virtual machine hypervisor is not used includes:

Here, it is determined by the setup service whether the second QEMU process is in an exited state, and if the second QEMU process is in the exited state, it is determined that the first KVM drive is not used.

After updating the first QEMU process to a second QEMU process, the virtual machine manager includes the second QEMU process and the first KVM driver. Since the QEMU process is launched dependent on the KVM driver, if the second QEMU process is in the active state, then the first KVM driver is in the used state, and if the second QEMU process is in the exit state, then no process uses the first KVM driver in the virtual machine manager. So in case the second QEMU process is in the exit state, it is determined that the first KVM driver is not used.

By determining that the first KVM driver is not used under the condition that the second QEMU process is determined to be in the exit state, the current use state of the first KVM driver can be accurately obtained.

Step 303: starting the second QEMU process through the setting service; wherein the launching of the second QEMU process is dependent on the second KVM driver.

Here, after updating both the QEMU process and the KVM driver, a second QEMU process is started by the setup service. Wherein the second QEMU process is launched dependent on the second KVM driver.

In this way, after the second QEMU process is started by relying on the second KVM driver, in the restarted virtual machine management program, both the QEMU process and the KVM driver are updated versions, so that the virtual machine management program is completely updated.

In an embodiment, the starting the second QEMU process by the setup service includes:

Here, a second instruction is sent to the second QEMU process through the setup service, the second instruction being used to instruct the second QEMU process to call the first file and load the second file. The first file comprises a memory file of each virtual machine in at least one virtual machine corresponding to the first QEMU process, and the second file is used for recording the running state of each virtual machine in at least one virtual machine corresponding to the first QEMU process. That is, when the second QEMU process is started, the memory file of the virtual machine corresponding to the first QEMU process before updating and the running state of the virtual machine corresponding to the first QEMU process before updating are needed.

And if a second response of the second QEMU process about the second instruction is received, the second QEMU process is proved to have successfully called the first file and successfully loaded the second file. In this case, it is determined to start the second QEMU process.

In practical application, a vm _ load instruction is sent to the second QEMU process through the UPDATE _ MGR, and the second QEMU process calls the first file and loads the second file after receiving the instruction. The first file may be named guest _ mem and the second file may be named dev _ state. The first file and the second file may be stored in a disk or a shared memory, in addition to the memory.

It should be noted that, when the second QEMU process is started, the second KVM driver needs to be used first, and then the second QEMU process calls the first file and loads the second file, so that after the first file is successfully called and the second file is successfully loaded, it is indicated that the second QEMU process has successfully called the memory file of the virtual machine corresponding to the first QEMU process before updating, and the running state of the virtual machine corresponding to the first QEMU process before updating is successfully loaded, so that the second QEMU process is started successfully.

It can be understood that, in the embodiment of the present application, updating the QEMU process refers to updating the binary program corresponding to the QEMU process, and the memory file and the running state of the virtual machine corresponding to the QEMU process are not updated.

Fig. 4a and 4b are schematic diagrams of a starting process of a second QEMU process according to an embodiment of the present application, as shown in fig. 4a and 4 b:

as shown in FIG. 4a, when the second QEMU process is started, the second KVM driver is first used.

At this time, the memory file of the virtual machine corresponding to the second QEMU process is blank, and the running state of the corresponding virtual machine is also blank. Therefore, a second instruction is sent to the second QEMU process by the setup service, instructing the second QEMU process to call the first file and load the second file. The first file comprises a memory file of each virtual machine corresponding to the first QEMU process, and the second file is used for recording the running state of each virtual machine corresponding to the first QEMU process.

As shown in fig. 4b, the second QEMU process calls the first file based on the second instruction, and loads the second file, at this time, the virtual machine corresponding to the second QEMU process obtains the memory file of the virtual machine corresponding to the first QEMU process before updating, and loads the running state of the virtual machine corresponding to the first QEMU process before updating, so that the second QEMU process has been started successfully.

The second QEMU process is started by calling the first file and loading the second file, so that the copying and transferring processes of the memory files of the corresponding virtual machine in the QEMU process hot upgrading process can be avoided, extra hardware resources are not consumed, concurrent hot upgrading of large-scale QEMU process instances can be carried out, and the updated second QEMU process can be started quickly.

In an embodiment, before the updating the first QEMU process of the virtual machine hypervisor to the second QEMU process by the setup service, the method includes:

Before the first QEMU process is updated to the second QEMU process through the setting service, the memory file of at least one virtual machine corresponding to the first QEMU process is obtained through the setting service, and the obtained memory file of each virtual machine is mapped to the first file.

Fig. 5 is a schematic diagram of determining a first file according to an embodiment of the present application. As shown in fig. 5:

and under the condition that the first QEMU process is in a normal working state and the virtual machines corresponding to the first QEMU process are in a normal running state, acquiring the memory file of each corresponding virtual machine of the first QEMU process through the setting service, and mapping the acquired memory file to the first file.

By mapping the memory file of the virtual machine corresponding to the first QEMU process to the first file, when the updated second QEMU process is started, the first file can be directly called to recover the memory file of the virtual machine corresponding to the second QEMU process, the memory file of the virtual machine is prevented from being copied, extra hardware resources are prevented from being consumed, and the starting efficiency of the second QEMU process is improved.

In an embodiment, before the updating the first QEMU process of the virtual machine hypervisor to the second QEMU process by the setup service, the method further comprises:

Here, before the first QEMU process is updated to the second QEMU process by the setup service, a third instruction is sent to the first QEMU process by the setup service, and the third instruction is used for instructing the first QEMU process to adjust the working state to the suspended state. And if a third response of the first QEMU process is received, the first QEMU process is proved to adjust the working state to a suspended state, at the moment, the running state of each virtual machine corresponding to the first QEMU process is obtained through the setting service, and the obtained running state of the virtual machine is stored in a second file.

In practical application, a vm _ save instruction is sent to the first QEMU process through the UPDATE _ MGR, and after the instruction is received by the first QEMU process, the working state is adjusted to be a suspension state. And after the first QEMU process is in the suspended state, saving the running state of each virtual machine corresponding to the first QEMU process to a second file through an UPDATE _ MGR.

Fig. 6 is a schematic diagram of saving a second file according to an embodiment of the present application, as shown in fig. 6:

and sending a third instruction to the first QEMU process through the setting service, and after the first QEMU process adjusts the working state to a pause state based on the third instruction, acquiring the running state of each virtual machine corresponding to the first QEMU process through the setting service at the moment, and storing the acquired running state of each virtual machine to a second file.

It should be noted that the determining process of the second file is subsequent to the determining process of the first file, that is, after the memory file of each virtual machine corresponding to the first QEMU process is mapped into the first file, the running state of each virtual machine corresponding to the first QEMU process is saved to the second file.

By setting the service to store the running state of each virtual machine corresponding to the first QEMU process to the second file under the condition that the first QEMU process is in the suspended state, the second file is directly loaded to restore the running state of the virtual machine corresponding to the second QEMU process in the starting process of the second QEMU process, the starting time of the second QEMU process is shortened, and the starting efficiency of the second QEMU process is improved.

In an embodiment, after the determining to launch the second QEMU process, the method includes:

deleting the second file through the provisioning service.

Here, if it is determined that the second QEMU process has been successfully started, it means that the virtual machine corresponding to the second QEMU process has acquired and restored to the corresponding running state in the second file, at this time, the second file does not exist necessarily, so the second file is deleted by the setting service.

Fig. 7 is a schematic diagram of deleting a second file according to an embodiment of the present application, as shown in fig. 7:

and if the second QEMU process is successfully started, deleting the second file through the setting service.

And the second file is deleted after the second QEMU process is successfully started through the set service, so that the memory space is saved.

To implement the method according to the embodiment of the present application, an embodiment of the present application further provides a device for hot upgrading of a hypervisor of a virtual machine, and fig. 8 is a schematic diagram of the device for hot upgrading of a hypervisor of a virtual machine according to the embodiment of the present application, please refer to fig. 8, where the device includes:

an updating unit 801, configured to update a first QEMU process of the virtual machine hypervisor to a second QEMU process through a setting service;

a loading unit 802, configured to, after updating the first QEMU process to a second QEMU process, unload, by the provisioning service, the first KVM driver of the virtual machine manager if it is determined that the first KVM driver is not used, and load a second KVM driver;

a starting unit 803, configured to start the second QEMU process through the setting service; wherein the launching of the second QEMU process is dependent on the second KVM driver.

In an embodiment, the updating unit 801 is further configured to send a first instruction to the first QEMU process through the setting service; the first instruction is used for indicating the first QEMU process to adjust the working state to be an exit state;

In one embodiment, the apparatus further comprises: the determining unit is used for judging whether the second QEMU process is in an exit state through the setting service to obtain a judgment result;

In an embodiment, the starting unit 803 is further configured to send a second instruction to the second QEMU process through the setting service program; the second instruction is used for indicating the second QEMU process to call the first file and load the second file; the first file comprises a memory file of each virtual machine in at least one virtual machine corresponding to the first QEMU process; the second file is used for recording the running state of each virtual machine in at least one virtual machine corresponding to the first QEMU process;

In one embodiment, the apparatus further comprises: the mapping unit is used for acquiring a memory file of at least one virtual machine corresponding to the first QEMU process through the setting service;

In one embodiment, the apparatus further comprises: the storage unit is used for sending a third instruction to the first QEMU process through the setting service program; the third instruction is used for indicating the first QEMU process to adjust the working state to a pause state;

In one embodiment, the apparatus further comprises: and the deleting unit is used for deleting the second file through the setting service.

In actual applications, the updating Unit 801, the loading Unit 802, the starting Unit 803, the determining Unit, the mapping Unit, the storing Unit, and the deleting Unit may be implemented by a Processor in a terminal, such as a Central Processing Unit (CPU), a Digital Signal Processor (DSP), a Micro Control Unit (MCU), or a Programmable Gate Array (FPGA).

It should be noted that: in the above embodiment, when the virtual machine management program hot upgrade apparatus displays information, only the division of each program module is illustrated, and in practical applications, the above processing distribution may be completed by different program modules according to needs, that is, the internal structure of the apparatus may be divided into different program modules to complete all or part of the above-described processing. In addition, the apparatus for thermally upgrading a hypervisor provided in the foregoing embodiment and the method for thermally upgrading a hypervisor provided in the foregoing embodiment belong to the same concept, and details of a specific implementation process thereof are referred to in the method embodiment and are not described herein again.

Based on the hardware implementation of the program module, in order to implement the method of the embodiment of the present application, an embodiment of the present application further provides an electronic device. Fig. 9 is a schematic diagram of a hardware component structure of an electronic device according to an embodiment of the present application, and as shown in fig. 9, the electronic device includes:

a communication interface 901 capable of performing information interaction with other devices such as a network device;

and the processor 902 is connected with the communication interface 901 to implement information interaction with other devices, and is configured to execute the method provided by one or more technical solutions of the terminal side when running a computer program. And the computer program is stored on the memory 903.

Specifically, the processor 902 is configured to update a first QEMU process of the virtual machine hypervisor to a second QEMU process through a setting service;

In an embodiment, the processor 902 is further configured to send a first instruction to the first QEMU process through the setup service; the first instruction is used for indicating the first QEMU process to adjust the working state to be an exit state;

In an embodiment, the processor 902 is further configured to determine, by the setting service, whether the second QEMU process is in an exit state, so as to obtain a determination result;

In an embodiment, the processor 902 is further configured to send a second instruction to the second QEMU process through the setup service; the second instruction is used for indicating the second QEMU process to call the first file and load the second file; the first file comprises a memory file of each virtual machine in at least one virtual machine corresponding to the first QEMU process; the second file is used for recording the running state of each virtual machine in at least one virtual machine corresponding to the first QEMU process;

In an embodiment, before the updating the first QEMU process of the virtual machine hypervisor to the second QEMU process by the setting service, the processor 902 is further configured to obtain, by the setting service, a memory file of at least one virtual machine corresponding to the first QEMU process;

In an embodiment, before the updating the first QEMU process of the virtual machine hypervisor to the second QEMU process by the setup service, the processor 902 is further configured to send a third instruction to the first QEMU process by the setup service; the third instruction is used for indicating the first QEMU process to adjust the working state to a pause state;

In an embodiment, after the determining starts the second QEMU process, the processor 902 is further configured to delete the second file through the setup service.

Of course, in practice, the various components in the electronic device are coupled together by a bus system 904. It is understood that the bus system 904 is used to enable communications among the components. The bus system 904 includes a power bus, a control bus, and a status signal bus in addition to a data bus. But for clarity of illustration the various buses are labeled as bus system 904 in figure 9.

The memory 903 in the embodiments of the present application is used to store various types of data to support the operation of the electronic device. Examples of such data include: any computer program for operating on an electronic device.

It will be appreciated that the memory 903 can be either volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. Among them, the nonvolatile Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a magnetic random access Memory (FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical disk, or a Compact Disc Read-Only Memory (CD-ROM); the magnetic surface storage may be disk storage or tape storage. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of illustration and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Enhanced Synchronous Dynamic Random Access Memory (Enhanced DRAM), Synchronous Dynamic Random Access Memory (SLDRAM), Direct Memory (DRmb Access), and Random Access Memory (DRAM). The memory 903 described in embodiments herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The method disclosed in the embodiments of the present application may be applied to the processor 902 or implemented by the processor 902. The processor 902 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 902. The processor 902 described above may be a general purpose processor, a DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. The processor 902 may implement or perform the methods, steps, and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium located in the memory 903, and the processor 902 reads the program in the memory 903 and performs the steps of the aforementioned methods in conjunction with its hardware.

The processor 902, when executing the program, implements the corresponding flow in the methods of the embodiments of the present application.

In an exemplary embodiment, the present application further provides a storage medium, i.e., a computer storage medium, specifically a computer readable storage medium, for example, a memory 903 storing a computer program, which can be executed by a processor 902 to perform the steps of the foregoing method. The computer readable storage medium may be Memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface Memory, optical disk, or CD-ROM.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus, terminal and method may be implemented in other manners. The above-described device embodiments are only illustrative, for example, the division of the unit is only one logical function division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic or optical disk, or various other media that can store program code.

Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or portions thereof that contribute to the prior art may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling an electronic device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic or optical disk, or various other media that can store program code.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for hot upgrading of a virtual machine hypervisor, the method comprising:

updating a first simulator QEMU process of the virtual machine management program into a second QEMU process through the setting service;

after updating the first QEMU process to a second QEMU process, with the provisioning service, uninstalling a first kernel-based virtual machine (KVM) driver of the virtual machine manager and loading a second KVM driver if it is determined that the first KVM driver is not used;

2. The method for hot upgrade of a virtual machine hypervisor of claim 1, wherein said updating a first QEMU process of the virtual machine hypervisor to a second QEMU process by a provisioning service comprises:

3. The virtual machine manager hot-upgrade method according to claim 1, wherein said determining, by the provisioning service, that the first KVM driver of the virtual machine manager is not in use comprises:

4. The method for hot-upgrading of a virtual machine hypervisor according to claim 1, wherein said initiating the second QEMU process by the provisioning service comprises:

5. The virtual machine hypervisor hot upgrade method according to claim 4, wherein prior to said updating a first QEMU process of a virtual machine hypervisor to a second QEMU process through a provisioning service, said method comprises:

6. The virtual machine hypervisor hot upgrade method of claim 4, wherein prior to said updating a first QEMU process of a virtual machine hypervisor to a second QEMU process through a provisioning service, the method further comprises:

7. The virtual machine hypervisor hot upgrade method of claim 4, wherein after said determining to launch said second QEMU process, said method comprises:

deleting the second file through the provisioning service.

8. An apparatus for hot-upgrading a hypervisor, the apparatus comprising:

9. An electronic device, comprising: a processor and a memory for storing a computer program capable of running on the processor, wherein,

the processor is adapted to perform the steps of the method of any one of claims 1 to 7 when running the computer program.

10. A storage medium on which a computer program is stored, which computer program, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.