Method, device and server for hot updating of vhost device manager

Abstract

The application provides a hot updating method, device and server of a vhost device management program; the method comprises the following steps: performing an upgrading procedure on an original vHost device management program, and sending a request of a new version of the vHost device management program; the new version of the vHost device management program receives connection state information sent by the original vHost device management program, and establishes a connection transmission. The hot updating procedure is completed through the creation of the new version of the vHost management process, the resource transfer and the dynamic reconstruction of the virtual machine vHost device connection, so that the time can be saved more quickly.

Description

Methods, devices, and servers for hot-updating vhost device management programs Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a method, apparatus, and server for hot updating a vhost device management program. Background Technology

[0002] To address issues such as virtual machine I / O channel disconnection and device state loss caused by software updates or runtime anomalies, the vHost protocol introduces a reconnection mechanism. This mechanism allows for the re-establishment of connections and restoration of service capabilities after a storage service disconnection, thus achieving self-healing of the communication link. Through communication interruption detection, connection persistence, and state reconstruction, this mechanism resolves the problems of communication channel interruption and unrecoverable state during storage service upgrades.

[0003] The vHost device manager can restore vHost connections through the vHost reconnection function. However, the connection context stored by the vHost device management service itself cannot be passed to the new version process through this mechanism. This causes the new management process to fail to understand the reconnection request initiated by the virtual machine, resulting in reconnection failure and preventing a complete hot update.

[0004] Hot updates of the vHost device manager via live migration include: The virtual machine program and the vHost device manager can be migrated from the old virtual machine to a node with updated virtual machine program and vHost device manager by triggering a live migration of the virtual machine program, or by using local live migration to migrate memory and device states between two virtual machine programs simulating the same device set to complete the hot upgrade. The relationships between the components are shown in the following diagram:

[0005] The vHost device manager update process based on hot migration is as follows: The binary file of the new version of the vHost device manager is updated, and the new version process is started. At this point, there are both old and new versions of the vHost device manager process. A hot migration of virtual machine program 1 is initiated. This hot migration can occur between multiple server nodes or be completed within the same node. The newly started virtual machine program is assigned to connect to the new version of the vHost device manager process. After the virtual machine is hot-migrated to the new virtual machine process, the communication-related file descriptors (FDs) and communication links are rebuilt according to the vHost device creation process, and all vHost devices are rebuilt.

[0006] Upgrading the vHost device manager via virtual machine hot migration does not solve the problems of virtual machine I / O channel disconnection and restoring the old connection after the vHost device manager service restarts. Instead, it completely rebuilds the connection between the vHost device and the vHost device manager, as well as the I / O connection between the virtual machine and the storage service, through the device initialization process of the virtual machine hot migration. After the connection is established, it further utilizes the state switching mechanism of virtual machine hot migration to disconnect the old version of the vHost device manager and enable the new version connection while the source virtual machine is paused.

[0007] Research has found that vHost device management process updates based on hot migration have the following drawbacks:

[0008] 1. The hot migration process involves two QEMU processes, resulting in double the memory usage during the upgrade phase. For example, migrating a virtual machine with 16GB of memory requires at least 32GB of available physical memory for the upgrade. This operation may fail on resource-constrained nodes.

[0009] 2. Hot migration requires copying and rebuilding the virtual machine's memory, storage, and CPU running state, a process that can take anywhere from a few seconds to several minutes. During this process, some stages require the handover of control between the old and new virtual machine processes, which may lead to service interruptions.

[0010] 3. Hot migration of virtual machines across storage nodes reduces the memory requirements of a single node, but places higher demands on network bandwidth and latency; at the same time, it relies on storage services to handle data consistency issues when different nodes access the same vHost device. Summary of the Invention

[0011] This invention provides a hot update method for a vhost device management program, comprising the following steps:

[0012] The upgrade process for the original vHost device management program sends a request for a new version of the vHost device management program;

[0013] The new version of the vHost device manager receives the connection status information sent by the original vHost device manager and establishes a connection.

[0014] Preferably, the new version of the vHost device management program receives the connection status information sent by the original vHost device management program and establishes a connection. The specific operation steps are as follows:

[0015] Start the new version of the vHost device management program and connect it to the old program service in the original vHost device management program;

[0016] The cached information of the original vHost device management program is transmitted through this connection;

[0017] The new version of the vHost device management program transmits the cached information via a hot update process.

[0018] Preferably, the hot update process includes the creation of a new version of the vHost management process and the dynamic reconstruction of resource transfer and virtual machine vHost device connection.

[0019] Preferably, the cache information of the original vHost device management program is transmitted through this connection, and the specific operation steps are as follows:

[0020] The new version of the vHost device management program is used to receive communication services.

[0021] When the new version of the vHost device management program starts, it transmits the connection status information of the original vHost device management program to the new version of the vHost device management program.

[0022] Preferably, the creation and resource transfer of the new version of the vHost management process are performed using the following specific steps:

[0023] The original vHost device management program that is already running will be notified to upload the new version of the vHost device management program.

[0024] When the original vHost device management program receives a notification, it initiates the takeover service for the hot update process;

[0025] The original vHost device management program process starts the process of the new version of the vHost device management program;

[0026] When the process of the new version of the vHost device manager detects the FD listening of the original vHost device manager, it establishes a Unix Domain Socket connection to the original vHost device manager through path SP1;

[0027] Once the new version of the vHost device manager detects a new connection being established, it stops accepting new connections.

[0028] The original vHost device manager is sent to the process of the new version of the vHost device manager via the Unix Domain Socket;

[0029] When the new version of the vHost device management program receives a new connection, it uses the FD to listen for the new connection.

[0030] Preferably, the dynamic reconstruction of the virtual machine vHost device connection includes:

[0031] A confirmation receipt acknowledging the start of listening to the FD is sent to the process of the original vHost device manager via the Unix Domain Socket connection;

[0032] Determine whether the new version of the vHost device management program can monitor the original vHost device management program for file descriptors (FDs); and then execute the subsequent steps.

[0033] Restore the FD listening service to the original vHost device management program;

[0034] Shut down the process service of the new version of the vHost device management program and end the upgrade of the original vHost device management program;

[0035] If the new version of the vHost device management program successfully listens to the FD, then it determines all connection status information of the original vHost device management program;

[0036] The new version of the vHost device management program is re-requested to send the new version of the connection status information for FD monitoring;

[0037] The new version of the vHost device management program re-receives and processes connection status information;

[0038] When the new version of the vHost device manager re-establishes a connection, the process of the new version of the vHost device manager is re-stored for connection.

[0039] When the process of the new version of the vHost device manager re-stores the connection, the process of the original vHost device manager checks whether the process of the new version of the vHost device manager has stored the connection and then closes the original vHost device manager.

[0040] Preferably, if the new version of the vHost device management program successfully listens to the FD, it determines all connection status information of the original vHost device management program. The specific operation steps are as follows:

[0041] The new version of the vHost device manager sends a connection request to the original vHost device manager;

[0042] Once the original vHost device management program establishes a connection with the new version of the vHost device management program, wait for the connection to be rebuilt, and then execute the subsequent steps.

[0043] Once the new version of the vHost device management program receives the connection establishment, it updates the connection status information of the original vHost device management program and repeats the above steps.

[0044] Once all connection status information has been established, proceed with the next steps.

[0045] Accordingly, a hot update device for a vhost device management program has also been invented, characterized in that it includes: a request module; and an establishment module;

[0046] The request module is used to upgrade the original vHost device management program and send a request for a new version of the vHost device management program.

[0047] The establishment module is used by the new version of the vHost device management program to receive connection status information sent by the original vHost device management program and establish a connection.

[0048] Thirdly, a computer server stores a computer program, which, when executed by a computer, implements a hot update method for a vhost device management program as described above.

[0049] Compared with the prior art, the embodiments of the present invention have at least the following technical advantages:

[0050] In summary, the hot update method for the vHost device manager provided by the above-mentioned technical solution of this invention includes the following steps: The core of this solution is to seamlessly switch between the old and new versions of the vHost device manager through a hot update mechanism, thereby achieving a smooth upgrade of the virtual machine device management service. Without interrupting existing virtual machine connections, the new version of the vHost device manager can take over some management functions of the old version, thus ensuring the continuous operation of the virtual machine device. Specifically, the solution uses file descriptors (FDs) and Unix Domain Sockets to achieve communication between the old and new versions, ensuring that virtual machine connections are not interrupted during the upgrade process. During the implementation of the solution, after receiving the hot update notification, the original vHost device manager starts the takeover service through the Unix Domain Socket and establishes a connection with the new version program. At this time, the old version program still handles the connections of existing virtual machines, while the new version begins to take over new virtual machine connections. When the new version of the vHost device manager receives the connection status information, it first cleans up the old connections and initiates a reconnection between the virtual machine and the storage service. The virtual machine will detect the planned disconnection and retry to establish a connection with the new version program. After the new version of the program restores the connection, the virtual machine can continue to work normally, ensuring the high availability of the system. The key advantage of this solution is that it allows the vHost device management program to be upgraded without interrupting the service, avoiding the risk of virtual machine access being unavailable due to service interruption during traditional upgrades. Through precise FD transfer and connection state management, the old and new versions of the program can smoothly hand over management responsibilities, and the connection between the virtual machine and the storage service can be quickly restored, ensuring the stability and reliability of the system.

[0051] Furthermore, this scheme describes the dynamic reconstruction process of virtual machine vHost devices, focusing on solving the problem of smooth transition and upgrade between the original vHost device manager and the new version. Through detailed step design, it ensures seamless upgrade of virtual machine device management, does not affect the stability of existing connections, and guarantees high system availability. First, the communication protocol through Unix Domain Sockets ensures a smooth handover between the old and new versions of the vHost device manager. The original vHost device manager waits for the new version to confirm the completion of the listening task before sending the current connection status information to the new version. This process effectively avoids the risk of data loss and connection state asynchrony, ensuring the accuracy of state migration. During hot update, the original vHost device manager continuously checks whether the new version has successfully taken over file descriptor (FD) listening. If the new version fails to complete listening in time, the system will automatically restore the old version service to avoid service interruption. During this phase, the original vHost device manager ensures that no new virtual machine connections are accepted, while promptly transmitting the status information of existing connections to the new version for seamless takeover. Next, if the new version successfully listens for and takes over the file descriptor (FD), the original vHost device manager gradually closes existing connections and begins transmitting connection information to the new version via UnixDomain Sockets. During this process, the virtual machine device is aware of the connection closure and automatically initiates a reconnection request to the new version, ensuring data continuity and system stability. Upon receiving the reconnection request, the new version of the vHost device manager re-establishes the connection and restores the I / O connection between the virtual machine and the storage service. This process ensures that virtual machine storage data access is unaffected. Finally, after confirming that all connections have been successfully migrated to the new version, the original vHost device manager shuts down its process, completing the hot update process. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0053] Figure 1 is a flowchart of a hot update method for a vhost device management program according to Embodiment 1;

[0054] Figure 2 is a schematic diagram illustrating the creation of a hot update method for a vhost device management program according to Embodiment 1;

[0055] Figure 3 is a schematic diagram of the reconstruction of a hot update method for a vhost device management program according to Embodiment 1;

[0056] Figure 4 is a flowchart of a hot update system for a vhost device management program according to Embodiment 2.

[0057] Labels: Request module 10; Build module 20.

[0058] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0059] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0060] To address the problems in the prior art, the following embodiments of the present invention provide a hot update method for vhost device management programs, aiming to solve the problem of quickly detecting faults and quickly performing disaster recovery switching in the above-mentioned load balancing scenario, thereby improving the high availability of the system.

[0061] Example 1

[0062] To achieve the above objectives, Embodiment 1 of the present invention provides a hot update method for a vhost device management program, comprising the following steps:

[0063] S10: Upgrade the original vHost device management program (i.e., the old version of the vHost management process) by sending a request for the new version of the vHost device management program;

[0064] S20: The new version of the vHost device management program receives the connection status information sent by the original vHost device management program and establishes a connection.

[0065] Specifically, in step S20, the new version of the vHost device management program receives the connection status information sent by the original vHost device management program and establishes a connection. The specific operation steps are as follows:

[0066] S21: Start the new version of the vHost device management program and connect it with the old program service in the original vHost device management program;

[0067] The original vHost device management program's cache information (i.e., connection status information) is transmitted through this connection.

[0068] It should be noted that during the initialization phase, the virtual machine device communication service establishes a connection with the old program upgrade service; after the new version of the vHost device manager starts, it will first establish a connection with the old program upgrade service, which is used to transmit some information cached by the old version of the device manager.

[0069] S22: The new version of the vHost device management program transmits the cached information through a hot update process;

[0070] The hot update process includes the creation of a new version of the vHost management process and the dynamic reconstruction of resource transfer and virtual machine vHost device connection;

[0071] Specifically, as shown in Figure 2, in step S21, the cache information of the original vHost device management program is transmitted through this connection. The specific operation steps are as follows:

[0072] S211: Use FD to accept communication services for the new version of the vHost device management program;

[0073] S212: When the new version of the vHost device management program starts, the connection status information of the original vHost device management program is transferred to the new version of the vHost device management program;

[0074] It should be noted that the virtual machine device communication service uses a service listening file descriptor (FD), which is sent to the new device communication service via Unix domain sockets. The new version of the device manager inherits this FD and starts the service based on hot update mode. This means that the new program can take over some of the old version's management functions without interrupting the service.

[0075] During this phase, existing virtual machine connections will continue to be handled by the old version of the program, while newly created virtual machine connections will be directly managed by the new vHost device management program. This operation ensures that existing virtual machines will not experience interruptions or connection problems during the upgrade process, and new connections will be handled by the new version of the program.

[0076] The old version of the vHost device manager transmits connection status information. Once the new device manager has completed initialization and confirmed that the virtual machine device communication service has started, the old version will begin to transmit connection status information to the new device manager. The connection status information includes each virtual machine's: virtual machine ID (used to identify the virtual machine), vhost connection ID (connection identifier), connection status (current connection status), and peer identity information (peer device identity information). This information helps the new version of the device manager understand the connection status of the virtual machines managed by the old version and ensures that it can continue to manage and process these connections.

[0077] When the virtual machine closes the vHost protocol connection to the storage service, the new version of the device manager receives the connection status information and begins to process the connection update. It closes the existing vHost protocol connection to the storage service and disables the related memory sharing in order to reinitialize the connection. This step is to clean up the old connection and ensure that the new connection can be established correctly.

[0078] When a virtual machine detects a planned disconnection, it attempts to re-handshake with the vhost device management service. This re-handshake process ensures that the virtual machine can restore its connection with the device management service, preventing the virtual machine from being unable to access the device due to upgrade interruption.

[0079] The new version of the program restores device connectivity and I / O communication. The new version of the device management program will detect the virtual machine's connection request and begin to restore the device connection. Once the connection is restored, the new program will continue to manage I / O communication with the virtual machine to ensure that the virtual machine can work normally and transmit data. This marks the restoration of normal virtual machine device communication and the completion of the upgrade process.

[0080] Specifically, in step S22, the creation and resource transfer of the new version of the vHost management process are carried out through the following steps:

[0081] S221: Notify the original vHost device management program to upload the new version of the vHost device management program to the already running original vHost device management program;

[0082] It should be noted that the new version of the vHost management program file will be uploaded to the node running the old version (the original vHost device management program); during the upload process, the original vHost device management program will be notified to start the hot update process through a preset interface or protocol; the notification content includes the file path of the new version program;

[0083] The new version of the binary file may be transferred to the original vHost device manager via a file transfer protocol (such as SCP or FTP); at the same time, after receiving the notification, the original vHost device manager begins to prepare for the upgrade, starts the hot update service, and prepares to switch processes; the notification request contains the file address of the new version of the vHost device manager.

[0084] S222: When the original vHost device management program receives a notification, it starts the hot update process takeover service (that is, the service listens to an agreed fixed file SP1 and provides a Unix Domain Socket Server).

[0085] It should be noted that the original vHost device manager starts a hot update takeover service, which manages connections to the process of the new version of the vHost device manager through Unix Domain Socket; the service listens on an agreed path (such as the SP1 file path) and waits for new processes (the new version of the vHost device manager) to connect;

[0086] The original vHost device manager creates and binds a Unix domain socket server, listening on a specific file path SP1. This socket will serve as a communication bridge between subsequent new versions of the vHost device manager and the original vHost device manager.

[0087] S223: The process of the original vHost device management program starts the process of the new version of the vHost device management program;

[0088] It should be noted that the original vHost device manager starts a new version of the vHost device manager process. At this point, the new version of the vHost device manager is still an independent process and has not yet communicated with the original vHost device manager. The original vHost device manager starts the new version of the vHost device manager process through a fork or similar mechanism. The new version of the vHost device manager will run the new version of the program and begin communicating with the original vHost device manager through Unix Domain Sockets.

[0089] S224: When the process of the new version of the vHost device manager detects the FD listening of the original vHost device manager, it establishes a Unix DomainSocket connection to the original vHost device manager through path SP1;

[0090] It should be noted that after the new version of the vHost device manager process starts, it detects that the original vHost device manager has already started the Unix Domain Socket service on the SP1 path; the new version of the vHost device manager connects to the original vHost device manager through this path.

[0091] The new version of the vHost device manager uses the socket() function to create a Unix domain socket and connects to the original vHost device manager's listening socket (path SP1) via the connect() method. Once the connection is established, the new version of the vHost device manager can exchange information with the original vHost device manager.

[0092] S225: When the new version of the vHost device management program detects a new connection being established, it stops accepting new connections;

[0093] It should be noted that after the original vHost device management program's context monitoring service detects the establishment of a new connection, its virtual machine vHost device management module service will no longer accept new connections, but will not close the listening FD for accepting virtual machine vHost device connections. At the same time, the old virtual machine vHost device connections that are already in service will be maintained and continue to be served.

[0094] When the native vHost device manager detects a new Unix Domain Socket connection, it switches to takeover mode. The native vHost device manager stops accepting new virtual machine vHost device connections, but still maintains connections with the current virtual machine to ensure that the virtual machine being served is not interrupted.

[0095] The original vHost device manager will close the acceptance of new connections through the accept() method. Old connections will remain in the original vHost device manager's file descriptor and continue to be served. The connection management part of the virtual machine vHost device will be suspended from accepting new connections, but existing connections will continue to be maintained.

[0096] S226: Send the original vHost device manager to the process of the new version of the vHost device manager via the Unix Domain Socket;

[0097] It should be noted that the original vHost device manager will immediately send its existing vHost management service module service FD to the new version of the vHost device manager process via the sendmsg and CMSG methods of the Unix Domain Socket;

[0098] The original vHost device manager uses the sendmsg() and CMSG methods to send its own virtual machine vHost device management service file descriptor (FD) to the new version of the vHost device manager via the established UnixDomain Socket. This step allows the new version of the vHost device manager to take over the vHost service and continue to handle virtual machine device connections.

[0099] The original vHost device manager uses sendmsg() to send a message with additional data, including the file descriptor of the currently managed virtual machine device; CMSG is used to embed the file descriptor as auxiliary data into the message, ensuring that the new version of the vHost device manager can start listening for virtual machine connections through this FD;

[0100] S227: When the new version of the vHost device management program receives a new connection, it uses the FD to listen for the new connection;

[0101] It should be noted that after the new version of the vHost device management program process receives the Socket FD related to the vHost management service, it will start listening to the FD in order to obtain subsequent new connections to the virtual machine vHost device;

[0102] After receiving the file descriptor for the vHost management service from the original vHost device manager, the new version of the vHost device manager starts listening to that FD, preparing to take over new connections to the virtual machine vHost device;

[0103] The new version of the vHost device manager uses the accept() or similar method to start listening for new connections on file descriptors passed by the original vHost device manager; once a new virtual machine vHost device connection arrives, the new version of the vHost device manager can take over and handle these connections, continuing to provide services for the virtual machine device;

[0104] Specifically, as shown in Figure 3, the dynamic reconstruction of the virtual machine vHost device connection in step S22 includes:

[0105] S221': Send an acknowledgment to the process of the original vHost device manager via the Unix Domain Socket connection, confirming that listening to the FD has begun;

[0106] It should be noted that the original vHost device manager waits for the new version of the vHost device manager process to send an acknowledgment to the original vHost device manager process via a Unix Domain Socket connection to confirm that it has started listening to the FD; after receiving the response that the original vHost device manager has completed listening, it will further send existing connection status information.

[0107] During a hot update, the original vHost device manager waits for the new version to send an acknowledgment via the Unix Domain Socket, indicating that the new version has started listening for and is preparing to take over the file descriptors (FDs) for virtual machine device management. Once the original vHost device manager receives the acknowledgment response, it sends the status information of the existing connections to the new version. This status information includes the virtual machine ID, connection ID, connection status, and process information of the current connection (i.e., the original vHost device manager) for each connection.

[0108] After receiving confirmation from the new version of the vHost device manager, the original vHost device manager sends the status of all current virtual machine connections (such as connection ID and status) to the new version of the vHost device manager via the Unix Domain Socket to ensure that the new version can obtain information about all existing connections.

[0109] S222': Determine whether the new version of the vHost device management program can perform FD monitoring on the original vHost device management program;

[0110] If not, proceed to step S225.

[0111] If so, continue with step S223';

[0112] It should be noted that if the new version of the vHost device management program fails to complete the FD listening of the virtual machine vHost device management module as agreed, the old version will trigger the recovery execution step 3; otherwise, it will execute step 5.

[0113] If the new version of the vHost device manager fails to listen to and take over the FD (i.e., fails to complete the necessary initialization work), the original vHost device manager will trigger step 3 to restore the old version's listening service. If the new version of the vHost device manager completes listening, it will continue to step 5.

[0114] The original vHost device manager checks whether the new version of the vHost device manager has successfully connected to the FD to determine whether to restore the old service; if the new version of the vHost device manager does not complete the FD listening in time, the original vHost device manager will restart the old virtual machine device listening service to ensure that the system continues to remain available.

[0115] S223': Restore the FD listening service to the original vHost device management program;

[0116] It should be noted that if the new version of the vHost device manager fails to complete FD listening, the original vHost device manager will resume listening to the old version of the service and continue to accept new virtual machine device connections;

[0117] The original vHost device manager will call accept() again to resume listening for connections to the new virtual machine device, ensuring that the system continues to provide services;

[0118] S224': Close the process service of the new version of the vHost device management program and end the upgrade of the original vHost device management program;

[0119] It should be noted that if the new version of the vHost device manager cannot successfully complete the listening and takeover, the original vHost device manager will close the new version process, revert to the old version, and end the current hot update process.

[0120] The original vHost device manager sends a termination signal to the new version of the vHost device manager, closing the new version's process. Then, the original vHost device manager re-enables the old version of the virtual machine device management service to ensure the system returns to normal.

[0121] S225': If the new version of the vHost device management program successfully listens to the FD, then determine all connection status information of the original vHost device management program;

[0122] It should be noted that if the new version of the vHost device manager successfully inherits the FD of the virtual machine vHost device management module and starts listening, the original vHost device manager will begin to close all vHost device connections. Once the new version of the vHost device manager successfully inherits and starts listening to the FD, the original vHost device manager will enter the stage of closing virtual machine device connections. In this stage, the original vHost device manager will first pause accepting new virtual machine connections, while ensuring that old connections can be smoothly transitioned to the new version of the vHost device manager.

[0123] The original vHost device manager stops accepting new connections and sends the status information of all current connections to the new version of the vHost device manager via Unix Domain Socket; the new version of the vHost device manager will verify the status information of all connections to ensure that no connections are missed.

[0124] S226': Re-request the new version of the vHost device management program to send the new version of the connection status information for FD monitoring;

[0125] It should be noted that when the virtual machine device detects that the connection with the old version has been closed, it will automatically trigger a reconnection request. The reconnection request will be sent to the new version of the vHost device manager through the transfer of ownership of the FD.

[0126] Each virtual machine device will automatically detect the connection being closed and will proactively send a reconnection request to the new version of the vHost device manager.

[0127] S227': The new version of the vHost device management program re-receives and processes the connection status information;

[0128] It should be noted that the new version of the vHost device manager's virtual machine vHost device management service has started handling new connection requests;

[0129] The new version of the vHost device manager begins to receive and process reconnection requests from virtual machine devices; at this point, the new version of the vHost device manager has completely taken over the management of virtual machine devices.

[0130] The new version of the vHost device manager will accept virtual machine device connections by listening to FDs and start relevant services and manage resources as needed;

[0131] S228': When the new version of the vHost device management program re-establishes a connection, the process of the new version of the vHost device management program is re-stored for connection;

[0132] It should be noted that after a new connection is established between the virtual machine vHost device and the new version of the vHost device manager, the virtual machine vHost device management process of the new version of the vHost device manager will re-trigger the shared memory between the virtual machine and the storage service and restore the I / O connection.

[0133] After the virtual machine device successfully connects to the new version of the vHost device manager, the new version of the vHost device manager will restore the I / O connection with the storage service to ensure that the virtual machine's data access is restored to normal.

[0134] The new version of the vHost device manager will reconnect to the storage system and restore data access to the virtual machine to ensure that I / O operations are not interrupted;

[0135] S229': When the process of the new version of the vHost device management program re-stores the connection, the process of the original vHost device management program confirms whether the process of the new version of the vHost device management program has stored the connection, and closes the original vHost device management program.

[0136] It should be noted that the original vHost device management program process closes the old version of the original vHost device management program after confirming that all connection states have been taken over.

[0137] After confirming that all connections have been successfully migrated to the new version of the vHost device manager, the original vHost device manager shuts down its own process, completing the entire upgrade process.

[0138] The original vHost device manager will terminate itself by executing exit() or a similar operation after receiving confirmation from the new version of the vHost device manager that all connection migrations have been completed.

[0139] Specifically, in step S225', if the new version of the vHost device management program successfully listens to the FD, then it determines all connection status information of the original vHost device management program. The specific operation steps are as follows:

[0140] S2251': The new version of the vHost device management program sends a connection request to the original vHost device management program;

[0141] It should be noted that the new version of the vHost device manager sends a request to the original vHost device manager to confirm the closure of the relevant connections of virtual machine x;

[0142] The new version of the vHost device manager sends a request to the original vHost device manager to close virtual machine device connections, ensuring a smooth transition of old virtual machine connections to the new version;

[0143] The new version of the vHost device manager sends requests in batches according to the virtual machine ID, and closes the device connections associated with the virtual machine one by one;

[0144] S2252': After the original vHost device management program establishes a connection with the new version of the vHost device management program, wait for the connection reconstruction to complete, and execute steps S226' to S228'.

[0145] It should be noted that after the original vHost device manager closes the relevant virtual machine connection, it sends a response to the new version of the vHost device manager indicating that virtual machine X was successfully closed, and then waits for the message indicating that the rebuild is complete.

[0146] After closing the connection with virtual machine X, the original vHost device manager sends an acknowledgment message to the new version of the vHost device manager, indicating that the connection to the virtual machine has been successfully closed; the original vHost device manager then continues to wait for virtual machine X to complete the reconnection.

[0147] The original vHost device manager calls close() to close the connection with the virtual machine and sends a closure confirmation to the new version of the vHost device manager via the UnixDomain Socket;

[0148] At this time, virtual machine X will execute the following steps S226' to S228';

[0149] Virtual machine X will detect the connection being closed and actively attempt to reconnect to the new virtual machine device management service (the new version of the vHost device manager).

[0150] After virtual machine X detects that the connection has been lost, it will trigger a reconnection request and connect to the new vHost management process (the new version of the vHost device manager).

[0151] S2253': After the new version of the vHost device management program receives the connection establishment, it updates the connection status information of the original vHost device management program and repeats the above step S2251'.

[0152] It should be noted that after the new version of the vHost device manager receives the message that the connection to virtual machine X has been rebuilt, it updates the connection information and responds to the original vHost device manager to complete the rebuild, and requests that the connection to the next virtual machine be closed, repeating step 5.1;

[0153] After successfully handling the reconnection of virtual machine X, the new version of the vHost device manager updates the connection status and sends a reconstruction completion message to the original vHost device manager. Then, the new version of the vHost device manager will request to close the connection of the next virtual machine, gradually completing the migration of all virtual machine connections.

[0154] After receiving the message that virtual machine X has completed reconnection, the new version of the vHost device manager updates the connection information and marks its status as "connected to the new vHost management process"; the new version of the vHost device manager will continue to process the connection migration of the next virtual machine;

[0155] S2254': After all the connection status information has been established, proceed to step S229':

[0156] It should be noted that step S229' will be executed only after all virtual machines have switched their connection status to the new vHost management process;

[0157] Once all virtual machine connections have been successfully migrated to the new version of the vHost device manager, the new version of the vHost device manager sends a final reconstruction completion confirmation to the original vHost device manager, indicating that all connections have been successfully switched.

[0158] After all virtual machine connections have been migrated, the new version of the vHost device manager will send a confirmation message to the original vHost device manager indicating that the migration is complete, and request that the old version of the original vHost device manager be shut down.

[0159] Example 2

[0160] In addition, based on the same concept of the above method embodiments, the present invention also provides a hot update method system for vhost device management programs to implement the above method of the present invention. Since the principle and method of solving the problem in this system embodiment are similar, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, and will not be described in detail here.

[0161] Referring to Figure 4, the present invention provides a hot update device for a vhost device management program, comprising: a request module 10; and an establishment module 20.

[0162] The request module 10 is used to upgrade the original vHost device management program and send a request for a new version of the vHost device management program.

[0163] The establishment module 20 is used for the new version of the vHost device management program to receive the connection status information sent by the original vHost device management program and establish a connection.

[0164] Example 3

[0165] On the other hand, this third embodiment, based on the hot update method for a vhost device management program provided in the first embodiment, also provides a computer storage medium (hereinafter referred to as the storage medium). When the computer program of the computer storage medium provided in this third embodiment is executed by a computer, it implements the hot update method for a vhost device management program as described above.

[0166] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, and optical storage) containing computer-usable program code.

[0167] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0168] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0169] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0170] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, third, etc., does not indicate any order. These words can be interpreted as names.

[0171] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0172] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for hot-updating a vhost device management program, characterized in that, Includes the following steps: The process involves upgrading the original vHost device manager by sending a request for a new version. The new version of the vHost device manager receives connection status information from the original vHost device manager and establishes a connection. The specific steps are as follows: The new version of the vHost device manager is started and connects to the old program service in the original vHost device manager; the cached information of the original vHost device manager is transmitted through this connection; the new version of the vHost device manager transmits the cached information through a hot update process; the hot update process includes the creation of the new version of the vHost management process, resource transfer, and dynamic reconstruction of the virtual machine vHost device connection; the dynamic reconstruction of the virtual machine vHost device connection includes: sending a confirmation receipt to the process of the original vHost device manager via a Unix Domain Socket connection to begin listening for file descriptors (FDs); determining whether the new version of the vHost device manager can listen for FDs from the original vHost device manager; and executing subsequent steps; the new version of the vHost device manager then... The device management program resumes FD listening service; closes the process service of the new version of the vHost device management program, and terminates the upgrade of the original vHost device management program; if the new version of the vHost device management program successfully listens for FD, it determines all connection status information of the original vHost device management program; it re-requests the new version of the vHost device management program to send new version connection status information for FD listening; the new version of the vHost device management program re-receives and processes the connection status information; when the new version of the vHost device management program re-establishes a connection, it re-stores the connection for the process of the new version of the vHost device management program; when the process of the new version of the vHost device management program re-stores the connection, the process of the original vHost device management program confirms whether the process of the new version of the vHost device management program has stored the connection, and closes the original vHost device management program.

2. The hot update method for a vhost device management program according to claim 1, characterized in that, The cached information of the original vHost device management program is transmitted through this connection. The specific operation steps are as follows: FD is used to accept communication services for the new version of the vHost device management program; when the new version of the vHost device management program starts, the connection status information of the original vHost device management program is transmitted to the new version of the vHost device management program.

3. The hot update method for a vhost device management program according to claim 2, characterized in that, The creation and resource transfer of the new version of the vHost management process are specifically performed as follows: The original vHost device management program, which is already running, is uploaded to the new version of the vHost device management program, which then notifies the original vHost device management program. When the original vHost device management program receives the notification, it initiates the takeover service for the hot update process. The process of the original vHost device management program starts the process of the new version of the vHost device management program. When the process of the new version of the vHost device management program detects the FD listening of the original vHost device management program, it establishes a Unix Domain Socket connection to the original vHost device management program via path SP1. When the new version of the vHost device management program detects the establishment of a new connection, it stops accepting new connections. The original vHost device management program is sent to the process of the new version of the vHost device management program via the Unix Domain Socket. When the new version of the vHost device management program receives a new connection, it uses the FD listening service to detect the new connection.

4. The hot update method for a vhost device management program according to claim 3, characterized in that, If the new version of the vHost device management program successfully listens to the FD, it determines all connection status information of the original vHost device management program. The specific operation steps are as follows: The new version of the vHost device management program sends a connection request to the original vHost device management program; after the original vHost device management program and the new version of the vHost device management program establish a connection, it waits for the connection reconstruction to complete and executes subsequent steps; when the new version of the vHost device management program receives confirmation that the connection has been established, it updates the connection status information of the original vHost device management program and repeats the above steps; when all connection status information is complete, it executes subsequent steps.

5. A computer storage medium, characterized in that, The device stores a computer program, which, when executed by a computer, implements a hot update method for a vhost device management program as described in any one of claims 1 to 4.

Images