A vhost-user authentication and I / O authorization method for distributed systems

Abstract

This invention discloses a vhost-user authentication and I / O authorization method for distributed systems, comprising: establishing a Unix Domain Socket connection between a front-end virtual machine process and a back-end vhost-user target process; the front-end sending an identity registration message to the back-end; constructing a VHOST_USER_SET_CONN_IDENTITY message, wherein the payload field of the message includes a digest identifier generated based on node identifier, network identifier, and process identifier; sending the message through the Socket connection; the back-end performing identity authentication; the back-end only processing I / O requests from successfully registered virtual machine processes; and performing distributed access control for cross-node I / O conflict scenarios. The above-mentioned vhost-user authentication and I / O authorization method for distributed systems ensures the accuracy of vhost-user identity authentication and avoids identity confusion through protocol extension and mapping table mechanisms. Simultaneously, it avoids data conflicts through distributed access control and migration control, and ensures system availability and stability by combining heartbeat synchronization and consistency algorithms.

Description

Technical Field

[0001] This invention relates to the field of distributed system data processing, and in particular to a vhost-user authentication and I / O authorization method for distributed systems. Background Technology

[0002] Vhost / Vhost-user Protocol: To improve the efficiency of virtual machine processes accessing I / O devices, the industry has proposed various optimization mechanisms. Among them, the vhost protocol, as a communication mechanism for accessing high-performance virtualization devices, has been widely used in high-speed paths for virtual machines to access block and network devices. Vhost itself is an implementation framework for accelerating the virtio backend. Its core goal is to bypass the traditional virtualization I / O stack, offloading the I / O processing logic from the virtual machine program itself to a program in the host kernel space or user space (storage service). This is implemented as vhost in kernel space and vhost-user in user space. The virtual machine and vhost share virtqueue memory. Vhost can directly access the virtual machine's physical memory without being forwarded by the virtual machine program. The event notification mechanism (eventfd) replaces traditional interrupt notification, reducing context switching.

[0003] Vhost-user, as a derivative protocol of vhost, can be considered a storage protocol. It uses Unix domain sockets (a means of inter-process communication where processes on the same machine can directly interact by reading and writing to the same file descriptor; compared to TCP / IP, Unix domain sockets are more concise and efficient as they do not rely on the network) to handle inter-process event notifications and data exchange. Compared to vhost in kernel mode, virtual machine processes can share memory with user-mode storage device processes instead of the host kernel, reducing the overhead of switching between kernel and user modes and achieving zero-copy communication between the virtual machine and the host. Event notification is also one of vhost-user's advantages. In this architecture, the virtual machine process acts as the communication front-end, and the back-end is the vhost-user server process, which can be integrated into the storage service process, as follows: Figure 1 As shown:

[0004] The Vhost-user protocol achieves control semantics through control messages. By defining various message types, it enables front-end and back-end state synchronization and function configuration, including block device creation, network device initialization, device feature negotiation, memory mapping management, and virtqueue configuration. These messages are transmitted via Unix Domain Sockets to ensure efficient and reliable communication. Vhost-user messages are an important control mechanism of the Vhost-user protocol.

[0005] The vhost-user protocol was initially designed for local virtualization scenarios. However, with the development of cloud infrastructure and virtual machine scheduling capabilities, vhost-user has also been introduced into distributed systems. The vhost-user server that a virtual machine connects to does not necessarily have to be local to the host machine, and the virtual machine may be moved between various nodes in the distributed system at any time. Therefore, the high availability of the vhost-user server has become particularly important. In the vhost-user architecture, the target usually refers to the device in the vhost-user server. The virtual machine mounts the vhost-user target, and from the virtual machine's internal perspective, it may be a block device.

[0006] In distributed systems, to achieve high availability of business virtual machines, the following mechanisms are typically used:

[0007] Primary / standby failover. The primary vhost-user target server typically handles all requests continuously. An external service constantly monitors the health of the primary server via heartbeats. When the primary server fails, the standby vhost-user target server is quickly started and switched over. This method is called live recovery within the same node, as follows: Figure 2 As shown:

[0008] Failover. When the host machine fails (e.g., hardware failure), the virtual machine is quickly rebuilt on other nodes. This is cross-node failover, as follows: Figure 3 The current vhost-user protocol suffers from significant problems in high-availability scenarios within distributed systems due to the lack of an effective connection authentication mechanism and fine-grained I / O permission control during connection establishment.

[0009] Establishing multiple vhost-user connections and binding them to a virtqueue simultaneously on the same client can cause data pollution: Vhost-user clients often have automatic reconnection or multi-channel concurrency capabilities to improve fault tolerance and throughput. However, because the vhost-user protocol itself is not secure in protecting connection identities or has insufficient authentication, the same client instance (i.e., the same virtual machine process or its agent process) may initiate multiple connections in a short period of time. Multiple duplicate connections to the virtqueue can lead to multiple threads or processes consuming and writing to the same virtqueue, causing data overlap, disordered ordering, memory races, and other problems, ultimately resulting in data pollution. In severe cases, this can cause the virtual machine or vhost-user target to crash.

[0010] I / O conflicts and data consistency risks in cross-node failover: Cross-node failover refers to the rapid reconstruction of a virtual machine on another physical node after the host node fails. If the vhost-user target does not have reasonable I / O permission control, because the virtual machine process instances on the old node cannot be 100% shut down, the vhost-user target may simultaneously accept I / O requests from virtual machine processes on both the old and new nodes. This conflict can easily lead to data inconsistency, compromising the data integrity and transaction atomicity of the virtual machine, especially in storage virtualization scenarios.

[0011] Therefore, the vhost-user protocol urgently needs to introduce identity recognition and connection uniqueness verification mechanisms, as well as design fine-grained I / O permission control mechanisms in the vhost-user server to ensure that each virtqueue can only be exclusively bound by one trusted client at any given time, thereby eliminating the risk of duplicate binding and data inconsistency from the source. Summary of the Invention

[0012] The purpose of this invention is to provide a vhost-user authentication and I / O authorization method for distributed systems, which solves the above-mentioned technical problems pointed out in the prior art.

[0013] This invention provides a vhost-user authentication and I / O authorization method for distributed systems, comprising the following steps:

[0014] S1. Establish a Unix DomainSocket connection between the front-end virtual machine process and the back-end vhost-user target process;

[0015] S2. The frontend sends the identity registration message to the backend:

[0016] S21. Construct a VHOST_USER_SET_CONN_IDENTITY message. The payload field of the message includes a digest identifier (cgid) generated based on the node identifier, network identifier, and process identifier. That is, it should be noted that the message payload includes a globally unique digest value (cgid) with a length of 32 bytes generated based on the physical host ID, the host network card MAC address, and the SHA-256 digest algorithm.

[0017] S22. Send the message via the Socket connection;

[0018] S3, Backend performs identity authentication:

[0019] S31. Verify whether the digest identifier (cgid) already exists in the mapping table;

[0020] S32. If the mapping table entry does not exist, add the mapping table entry and return success; otherwise, return failure.

[0021] S4. The backend only handles I / O requests from successfully registered virtual machine processes;

[0022] S5. For cross-node I / O conflict scenarios, implement distributed access control:

[0023] S51. Before processing the target I / O for the first time, the vhost-user server requests vhost-io-permission from the leader node; S52. The leader node decides on permission allocation based on the global permission table; S53. The vhost-user server processes or rejects the I / O based on the permission status.

[0024] Preferably, as one possible implementation, the structure of the message's payload field consists of 3 header fields and 1 payload field.

[0025] Preferably, as one possible implementation; S31, before verifying whether the digest identifier (cgid) already exists in the mapping table, the method further includes:

[0026] The backend connection management module maintains a mapping table between vhost-user targets and digest identifiers of registered connections. This mapping table is stored in the memory address space of the backend process. If it is the first time the frontend attempts to register, the backend will add a new entry and return a successful registration message to the frontend.

[0027] Preferably, as one possible implementation, the backend only processes I / O requests from successfully registered virtual machine processes, specifically including:

[0028] For subsequent identity registration requests to the vhost-user target, the backend compares them with the already registered mappings. If a match is found, the backend identifies the request as a duplicate connection and returns a registration failure to the frontend.

[0029] The backend guarantees that it will only process I / O requests from registered frontends;

[0030] When the backend listens for a disconnection (virtual machine shutdown) in the socket connection (socket event) from the frontend, it removes all mappings for that frontend.

[0031] That is, the backend only processes I / O requests for digest identifiers (cgids) that have been registered in the mapping table, and at the same time listens for virtual machine process disconnection events and removes the corresponding digest identifier (cgid) mapping table entries.

[0032] Preferably, as one possible implementation, S5 also includes a permission synchronization mechanism:

[0033] S54. Each node's vhost-user server requests the leader node to synchronize and update the locally cached permission table via heartbeat.

[0034] S55. The leader node broadcasts changes to the permission table to all nodes in real time.

[0035] Preferably, as one possible implementation, the following is performed during virtual machine migration across nodes:

[0036] Before the virtual machine is rebuilt, the S56 and Monitor programs send a request to the leader to revoke the original node's permissions.

[0037] S57. The leader deletes all permission entries of the original node and broadcasts the change.

[0038] S58, after the original node vhost-user server detects the change, cancel all Inflight I / O.

[0039] Preferably, as one possible implementation, the global permission table in S52 maintains consistency based on the Raft or Paxos algorithm, and the leader node is generated through election.

[0040] Preferably, as one possible implementation, the VHOST_USER_SET_CONN_IDENTITY message structure in step S21 includes:

[0041] 32-bit request field (value = 44);

[0042] The 32-bit flags field (where the lowest two bits represent the version number and the third bit indicates whether a response is required from the backend).

[0043] The 32-bit size field indicates the payload length;

[0044] The payload field is used to carry the digest identifier (cgid).

[0045] Preferably, as one possible implementation; before the leader node decides on permission allocation based on the global permission table, the leader node checks the global permission table.

[0046] Before processing I / O for the current target for the first time, the vhost-user server on a node requests vhost-io-permission for that target from the leader. The request should include the node's machine ID, virtual machine UUID, and target UUID.

[0047] ;

[0048] If the machine ID in the target UUID table does not match the requested node, a permission error will be returned.

[0049] It should be noted that if the corresponding target table entry is empty, it means that no other node is currently accessing that target. In this case, a new entry is added and persisted, and a success message is returned. The vhost-user server receives the response and caches `vhost-io-permission` locally, continuing to process I / O. If the corresponding target table entry is not empty and the `machineID` in the entry is not equal to the requesting node's machine ID, an error is returned. The vhost-user server receives the response and returns a permission error, refusing to process the current I / O.

[0050] On the other hand, the present invention also provides a computer storage medium storing a computer program, which, when executed by a computer, implements the above-mentioned vhost-user authentication and I / O authorization method for distributed systems.

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

[0052] Analysis of the vhost-user authentication and I / O authorization method for distributed systems provided by this invention reveals that, in practical applications, a UnixDomain Socket connection is first established between the front-end virtual machine process and the back-end vhost-user target process. The front-end sends an identity registration message to the back-end: a VHOST_USER_SET_CONN_IDENTITY message is constructed, the payload field of which includes a digest identifier (cgid) generated based on the node identifier, network identifier, and process identifier; this message is then sent via the Socket connection.

[0053] Furthermore, the backend performs identity authentication: verifying whether the digest identifier (cgid) already exists in the mapping table; if it does not exist, add a mapping table entry and return success, otherwise return failure; the backend only processes I / O requests from successfully registered virtual machine processes;

[0054] To address cross-node I / O conflict scenarios, distributed access control is implemented: before processing the target I / O for the first time, the vhost-user server requests vhost-io-permission from the leader node; the leader node decides on permission allocation based on the global permission table; the vhost-user server processes or rejects the I / O based on its permission status; this embodiment of the invention provides a vhost-user authentication and I / O authorization method for distributed systems, which enhances the vhost-user protocol by adding identity recognition for vhost-user connections and fine-grained I / O permission control. Attached Figure Description

[0055] Figure 1 This is a schematic diagram of one of the existing system architectures;

[0056] Figure 2 This is a schematic diagram of another existing technology system architecture;

[0057] Figure 3 This is a schematic diagram of another existing system architecture;

[0058] Figure 4 This is a schematic diagram of the overall process of a vhost-user identity authentication and I / O authorization method for a distributed system according to Embodiment 1 of the present invention;

[0059] Figure 5 This is a schematic diagram of the message structure in a vhost-user identity authentication and I / O authentication method for a distributed system according to Embodiment 1 of the present invention;

[0060] Figure 6This is a schematic diagram illustrating the cross-node failover process of a virtual machine in a vhost-user authentication and I / O authentication method for distributed systems according to Embodiment 1 of the present invention.

[0061] Figure 7 This is a schematic diagram of the state synchronization mechanism in a vhost-user identity authentication and I / O authentication method for distributed systems according to Embodiment 1 of the present invention.

[0062] Figure 8 This is a schematic diagram of the process of canceling all inflight I / O in a vhost-user identity authentication and I / O authorization method for distributed systems according to Embodiment 1 of the present invention. Detailed Implementation

[0063] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0064] The present invention will now be described in further detail with reference to specific embodiments and accompanying drawings.

[0065] Example 1

[0066] like Figure 4 As shown, this invention provides a vhost-user authentication and I / O authorization method for distributed systems, including the following steps:

[0067] S1. Establish a Unix DomainSocket connection (hereinafter referred to as Socket connection) between the front-end virtual machine process and the back-end vhost-user target process.

[0068] S2. The frontend sends the identity registration message to the backend:

[0069] S21. Construct a VHOST_USER_SET_CONN_IDENTITY message (wherein, the VHOST_USER_SET_CONN_IDENTITY message can be simply referred to as the connection identifier message). The payload field of the connection identifier message includes a digest identifier (cgid) generated based on the node identifier, network identifier, and process identifier. That is to say, the message payload includes a globally unique digest value (cgid) of 32 bytes in length generated based on the physical host ID, the host network card MAC address, and the SHA-256 digest algorithm.

[0070] S22. Send the message via the Socket connection;

[0071] S3, Backend performs identity authentication:

[0072] S31. Verify whether the digest identifier (cgid) already exists in the mapping table;

[0073] S32. If the mapping table entry does not exist, add the mapping table entry and return success; otherwise, return failure.

[0074] S4. The backend only handles I / O requests from successfully registered virtual machine processes;

[0075] S5. For cross-node I / O conflict scenarios, implement distributed access control:

[0076] S51. Before processing the target I / O for the first time, the vhost-user server requests vhost-io-permission (i.e., the virtual machine vhost I / O permission cache) from the leader node; S52. The leader node decides on permission allocation based on the global permission table; S53. The vhost-user server processes or rejects I / O based on the permission status.

[0077] In practical applications, a Unix Domain Socket connection is first established between the front-end virtual machine process and the back-end vhost-user target (i.e., the back-end) process; the front-end sends an identity registration message to the back-end: construct a VHOST_USER_SET_CONN_IDENTITY message, the payload field of which contains a digest identifier (cgid) generated based on the node identifier, network identifier, and process identifier; and send the message through the Socket connection.

[0078] Furthermore, the backend performs identity authentication: verifying whether the digest identifier (cgid) already exists in the mapping table; if it does not exist, add a mapping table entry and return success, otherwise return failure; the backend only processes I / O requests from successfully registered virtual machine processes;

[0079] To address cross-node I / O conflict scenarios, distributed access control is implemented: before processing the target I / O for the first time, the vhost-user server requests vhost-io-permission (i.e., virtual host I / O permission information) from the leader node; the leader node decides on permission allocation based on the global permission table; the vhost-user server processes or rejects I / O based on its permission status; the vhost-user authentication and I / O authorization method for distributed systems provided in this embodiment of the invention enhances the vhost-user protocol by adding identity recognition for vhost-user connections and fine-grained I / O permission control.

[0080] Preferably, as one possible implementation, the message payload field consists of three header fields and one payload field. See also Figure 5 The first 32-bit field, `request`, represents an enumeration value for the request type. The protocol defines a unique enumeration value for each message type, with `VHOST_USER_SET_CONN_IDENTITY` defined as 44. The second 32-bit field, `flags`, is a flag field. The lowest two bits represent the version number, and the third bit indicates whether a backend response is required. 0x5 means the message version number is 1, and a backend response is required. The third 32-bit field, `size`, represents the size of the payload field. The payload field has different meanings depending on the message type.

[0081] The specific structure of the VHOST_USER_SET_CONN_IDENTITY message includes header fields (request, flags, size) and payload fields, and clearly defines the meaning and value of each field (e.g., request=44, flags=0x5, etc.), so that the message has a clear format in the protocol, which makes it easy for the front-end and back-end to parse and process it according to a unified specification.

[0082] Preferably, as one possible implementation; S31, before verifying whether the digest identifier (cgid) already exists in the mapping table, the method further includes:

[0083] The backend connection management module maintains a mapping table between vhost-user targets and digest identifiers of registered connections. This mapping table is stored in the memory address space of the backend process. If it is the first time the frontend attempts to register, the backend will add a new entry and return a successful registration message to the frontend.

[0084] The steps described above illustrate that the backend needs to maintain a mapping table before verifying the cgid, which associates vhost-usertarget with the registered cgid. Entries are added during the initial registration, providing the storage foundation for subsequent authentication and ensuring the backend can track registered connections.

[0085] Preferably, as one possible implementation, the backend only processes I / O requests from successfully registered virtual machine processes, specifically including:

[0086] For subsequent identity registration requests to the vhost-user target, the backend compares them with the already registered mappings. If a match is found, the backend identifies the request as a duplicate connection and returns a registration failure to the frontend.

[0087] The backend guarantees to only process I / O requests from registered frontends; when the backend listens for a disconnection in the socket connection (socket event) between the frontend and the socket, or when the virtual machine is shut down, it removes all mappings for that frontend.

[0088] In other words, the backend only processes I / O requests with registered digest identifiers (cgids) in the mapping table, and simultaneously listens for virtual machine process disconnection events, removing the corresponding digest identifier (cgid) from the mapping table. Regarding the backend's I / O request processing procedure, it explicitly states that the backend only processes I / O requests from successfully registered virtual machine processes, and removes mapping table entries by listening for connection disconnection events. This ensures that the backend only serves legitimate, currently active connections, preventing invalid or duplicate connections from consuming resources, and also promptly cleans up resources.

[0089] The identity verification mechanism ensures that in real-time recovery scenarios, the vhost-user target will not submit I / O requests from two front-ends simultaneously. However, if a cross-node failover occurs, such as... Figure 6 As shown: During cross-node failover of virtual machines, to prevent a rollback to the old node if the virtual machine fails to start on the new node, the hypervisor typically does not immediately kill the virtual machine processes on the old node. Furthermore, to minimize business interruption, it usually does not wait for inflight I / O requests submitted but not yet completed on the old node. Therefore, inflight I / O may overwrite new I / O, resulting in double writes (in the example diagram, the next read result is data B, but the expected result should be data C). Authentication mechanisms cannot effectively handle this scenario, requiring a fine-grained distributed I / O access control mechanism.

[0090] Preferably, as one possible implementation, S5 also includes a permission synchronization mechanism:

[0091] S54. Each node's vhost-user server requests the leader node to synchronize and update the locally cached permission table via heartbeat.

[0092] S55. The leader node broadcasts changes to the permission table to all nodes in real time. It's important to note that the aforementioned state synchronization mechanism—where the vhost-user server uses heartbeats to continuously request updates to its local vhost-io-premission cache from the leader—ensures the real-time nature and consistency of permission information across all nodes. This technical solution synchronizes the permission table through a heartbeat mechanism, ensuring real-time consistency of permission information across all nodes. Thus, even if the leader node changes or the network partitions, each node can update its permission status promptly, avoiding I / O conflicts caused by inconsistent permission information.

[0093] Regarding the aforementioned state synchronization mechanism, it should be noted that the vhost-user server uses heartbeats to continuously request the leader to synchronize and update the local vhost-io-premission cache, ensuring the real-time nature and consistency of permission information on each node.

[0094] See the diagram for the above process. Figure 7 ; Figure 7 The cluster shown contains three nodes: A, B, and C. C is the leader, and the vhost-user server is integrated as a sub-service within the storage service process. The leader synchronizes vhost-io-permisson information with other nodes via heartbeats. Additionally, each node runs a separate management program called Monitor, which uses heartbeats to monitor the current node's storage service status.

[0095] Preferably, as one possible implementation, the following is performed during virtual machine migration across nodes:

[0096] Before the virtual machine is rebuilt, the S56 and Monitor programs send a request to the leader to revoke the original node's permissions.

[0097] S57. The leader deletes all permission entries of the original node and broadcasts the change.

[0098] S58. After the original node vhost-user server detects the change, cancel all Inflight I / O (i.e., incomplete I / O operations).

[0099] Utilizing the I / O permission control mechanism of vhost-io-permission, in scenarios involving cross-node hot migration or rebuilding of virtual machines, the monitoring program must first initiate a request to the leader node to revoke the original node's I / O permissions. This request should be completed before the virtual machine is rebuilt on other nodes. Upon receiving the request, the leader immediately deletes all VhostIOPermissionEntries related to the old node from the permission table and synchronizes the changes to all other nodes. When the original node's vhost-user server detects the changes, it will cancel all inflight I / O. See the flowchart. Figure 8 .

[0100] Preferably, as one possible implementation, the global permission table in S52 maintains consistency based on the Raft or Paxos algorithm, and the leader node is generated through election.

[0101] It should be noted that using Raft or Paxos algorithms to maintain the consistency of the global permission table and electing a leader node ensures high availability and strong consistency of the permission table in a distributed environment, avoiding single points of failure.

[0102] Preferably, as an implementation method, the VHOST_USER_SET_CONN_IDENTITY message structure in step S21 includes: a 32-bit request field (value = 44); a 32-bit flags field (where the lowest two bits represent the version number and the third bit represents whether the backend needs to reply); a 32-bit size field indicating the payload length; and a payload field used to carry the digest identifier (cgid).

[0103] Preferably, as one possible implementation; before the leader node decides on permission allocation based on the global permission table, the leader node checks the global permission table.

[0104] Before processing I / O for the current target for the first time, the vhost-user server on a node requests vhost-io-permission for that target from the leader. The request should include the node's machine ID, virtual machine UUID, and target UUID.

[0105] ;

[0106] If the machine ID in the target UUID table does not match the requested node, a permission error will be returned.

[0107] It should be noted that if the corresponding target table entry is empty, it means that no other node is currently accessing that target. In this case, a new entry is added and persisted, and a success message is returned. The vhost-user server receives the response and caches `vhost-io-permission` locally, continuing to process I / O. If the corresponding target table entry is not empty and the `machineID` in the entry is not equal to the requesting node's machine ID, an error is returned. The vhost-user server receives the response and returns a permission error, refusing to process the current I / O.

[0108] Example 2

[0109] Embodiment 2 of the present invention also provides a computer storage medium storing a computer program. When the computer program is executed by a computer, it implements the vhost-user authentication and I / O authorization method for distributed systems provided in Embodiment 1 above.

[0110] In summary, the vhost-user authentication and I / O authorization method for distributed systems proposed in this invention ensures the accuracy of vhost-user authentication and avoids identity confusion through protocol extension and identity mapping table mechanisms. At the same time, it avoids data conflicts through distributed permissions and migration control, and ensures system availability and stability by combining heartbeat synchronization and consistency algorithms.

[0111] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; those skilled in the art can modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for vhost-user authentication and I / O authorization in a distributed system, characterized in that, The following steps are included: S1. Establish a Unix Domain Socket connection between the front-end virtual machine process and the back-end vhost-user target process; S2. The frontend sends the identity registration message to the backend: S21. Construct a VHOST_USER_SET_CONN_IDENTITY message, wherein the payload field of the VHOST_USER_SET_CONN_IDENTITY message includes a digest identifier generated based on the node identifier, network identifier, and process identifier; S22. Send the VHOST_USER_SET_CONN_IDENTITY message via the Unix Domain Socket connection; S3, Backend performs identity authentication: S31. Verify whether the summary identifier already exists in the mapping table; S32. If the mapping table entry does not exist, add the mapping table entry and return success; otherwise, return failure. S4. The backend only handles I / O requests from successfully registered virtual machine processes; S5. For cross-node I / O conflict scenarios, implement distributed access control: S51. Before processing the target I / O for the first time, the vhost-user server requests vhost-io-permission from the leader node; S52. The leader node decides on permission allocation based on the global permission table; S53. The vhost-user server processes or rejects the I / O based on the permission status.

2. The vhost-user authentication and I / O authorization method for distributed systems according to claim 1, characterized in that, The payload field of the VHOST_USER_SET_CONN_IDENTITY message consists of three header fields and one payload field.

3. The vhost-user authentication and I / O authorization method for distributed systems according to claim 1, characterized in that, Before verifying whether the digest identifier already exists in the mapping table, the method further includes: The backend connection management module maintains a mapping table between vhost-user targets and digest identifiers of registered connections. This mapping table is stored in the memory address space of the backend process. If it is the first time the frontend attempts to register, the backend will add a new entry and return a successful registration message to the frontend.

4. The vhost-user authentication and I / O authorization method for distributed systems according to claim 1, characterized in that, The backend only handles I / O requests from successfully registered virtual machine processes, specifically including: For subsequent identity registration requests to the vhost-user target, the backend compares them with the already registered mappings. If a match is found, the backend identifies the request as a duplicate connection and returns a registration failure to the frontend. The backend guarantees that it will only process I / O requests from registered frontends; When the backend listens for a disconnected connection between the frontend and the Unix Domain Socket, it removes all mappings for that frontend. That is, the backend only processes I / O requests with registered digest identifiers in the mapping table, and at the same time listens for virtual machine process disconnection events and removes the mapping table entry with the corresponding digest identifier.

5. The vhost-user authentication and I / O authorization method for distributed systems according to claim 3, characterized in that, S5 also includes a permission synchronization mechanism for handling operations: S54. Each node's vhost-user server requests the leader node to synchronize and update the locally cached permission table via heartbeat. S55. The leader node broadcasts changes to the permission table to all nodes in real time.

6. The vhost-user authentication and I / O authorization method for distributed systems according to claim 3, characterized in that, Execute during virtual machine migration across nodes: Before the virtual machine is rebuilt, the S56 Monitor program sends a request to the leader node to revoke the original node's permissions. S57. The leader node deletes all permission entries from the original node and broadcasts the changes. S58, after the original node vhost-user server detects the change, cancel all Inflight I / O.

7. The vhost-user authentication and I / O authorization method for distributed systems according to claim 3, characterized in that, In S52, the global permission table is maintained for consistency based on the Raft or Paxos algorithm, and the leader node is elected.

8. The vhost-user authentication and I / O authorization method for distributed systems according to claim 3, characterized in that, The VHOST_USER_SET_CONN_IDENTITY message structure in step S21 includes: 32-bit request field; 32-bit flags field; The 32-bit size field indicates the payload length; The payload field is used to carry the digest identifier.

9. The vhost-user authentication and I / O authorization method for distributed systems according to claim 8, characterized in that, Before the leader node makes a decision on permission allocation based on the global permission table, it checks the global permission table, including the following steps: Before processing I / O for the current target for the first time, the vhost-user server of a node first requests vhost-io-permission for that target from the leader node. The request should include the node's machine ID, virtual machine UUID, and target UUID. If the target UUID table entry is empty, add a key-value pair (key=target UUID, value=node machine ID+virtual machine UUID) and persist it, then return success; If the machine ID in the target UUID table does not match the requested node, a permission error will be returned.

Images