A virtual machine snapshot simplification and safe rollback method based on configuration map and difference storage

Abstract

The present application relates to the technical field of computer virtualization and cloud computing management, and discloses a virtual machine snapshot simplification and safe rollback method based on configuration atlas and differential storage. The method obtains virtual machine static configuration information and runtime dynamic device state through a virtual machine monitoring protocol at a preset silent opportunity, forms a state set and cleanses and serializes the state set into a state document, constructs a version node and manages version derivation relationships in a directed acyclic graph, generates a configuration incremental package through differential comparison and stores the configuration incremental package differentially, and realizes lightweight saving and rapid retrieval of configuration versions. When rolling back, external resource dependencies are verified first, consistency risk assessment is performed based on a rule set, the target version static configuration is restored according to an atomized process and the dynamic device state is injected, and the virtual machine is started, thereby improving rollback reliability and safety.

Description

Technical Field

[0001] This invention relates to the fields of computer virtualization and cloud computing management technology, specifically to a snapshot simplification and secure rollback method for virtual machine configuration version management and snapshot storage optimization, particularly to version organization and retrieval based on configuration graphs, incremental snapshot saving based on differential storage, and rollback consistency control technology combined with runtime state capture. Background Technology

[0002] With the development of cloud computing and data center technologies, virtual machines based on mainstream virtualization platforms such as Qemu / KVM and Hyper-V have been widely used in scenarios such as business support, development testing, and operation and maintenance management. To achieve the preservation and recovery of virtual machine runtime environments and ensure business continuity, existing technologies mainly rely on the following solutions: First, static management of configuration files, such as storing parameters like the number of vCPUs and memory size in configuration files under the Libvirt architecture, and using external version control systems such as Git and SVN or manual backups for version management. This method mainly focuses on the text content of the configuration files. Second, command-line parameter recording, in scenarios where virtual machines are started directly through the Qemu command line, simple version rollback is achieved by saving the startup script or parameter text. During rollback, historical parameters need to be re-executed. Third, virtual machine snapshot technology, used to capture disk data, memory status, and some device status of virtual machines at specific points in time to support rapid recovery of the runtime environment, but its core is more focused on runtime data preservation rather than versioned management of configuration metadata.

[0003] However, existing solutions still have shortcomings in the "virtual machine snapshot simplification and secure rollback" scenario, mainly in the following aspects: (1) Incomplete version information, static configuration and runtime state are easily disconnected. External version control or configuration file backup can usually only manage static text information, which is difficult to cover the key runtime state dynamically allocated or negotiated by the virtualization layer after the virtual machine starts, such as some device identification information, device negotiation parameters, virtual hardware topology, etc. The above dynamic state is related to the static configuration. Rolling back the static configuration without synchronously restoring the matching runtime device state may lead to abnormal virtual machine startup, inconsistent device identification, and thus affect the accuracy and stability of environment reproduction.

[0004] (2) Snapshot storage is inefficient and redundant data consumes resources. Traditional snapshot technology often uses a near "full save" method to save data on disk, memory, etc. The snapshot size is large and the storage and transmission costs are high. At the same time, even if only a few configuration items change between different versions, the same or similar configuration metadata may be saved repeatedly, which can easily lead to a waste of storage resources in scenarios with frequent changes or large-scale deployments.

[0005] (3) The recovery operation has a large overhead and it is difficult to achieve lightweight rollback of configuration. Traditional snapshot recovery often requires loading and processing large snapshot data files. Even if you only want to roll back to a certain historical configuration version, it may require high I / O and memory overhead, and the recovery time is long, which is not conducive to agile verification and rapid fault repair.

[0006] (4) Lack of effective configuration dependency management affects rollback reliability. Existing technologies focus more on the internal state of virtual machines and lack unified dependency records and state management for external resources on which virtual machines depend (such as backend disk files, network bridging devices, and related network configurations). When external resources change, are migrated, or are missing, rollback may fail to start or run abnormally, reducing the controllability of rollback operations.

[0007] (5) Lack of consistency verification and risk warning mechanism before rollback. Existing solutions usually lack checks on the differences and potential conflicts between the target version and the current running state before performing rollback. For example, compatibility risks caused by key configuration changes such as the number of devices and resource quotas may lead to instability or even failure after rollback, increasing operation and maintenance risks.

[0008] Therefore, there is an urgent need for a technical solution that can balance configuration integrity, storage efficiency, and rollback security, in order to achieve streamlined storage of virtual machine snapshots, efficient organization and retrieval of historical versions, and improve consistency and reliability during the rollback process. Summary of the Invention

[0009] The purpose of this invention is to overcome the problems of incomplete version information, serious redundant snapshot storage, low recovery efficiency, uncontrollable external dependencies, and lack of consistency verification and risk warning in existing virtual machine configuration version management and snapshot rollback. It provides a virtual machine snapshot simplification and secure rollback method based on configuration graphs and differential storage. This method captures the key runtime dynamic states of the virtual machine at specific silent times using the QMP protocol, merges them with static configuration, and serializes and saves them. Version relationships are organized and managed based on a directed acyclic graph (DAG) of configuration versions, and version data is stored differentially. Simultaneously, external resource dependencies are verified and a consistency risk assessment based on rule sets is conducted before rollback. Static configuration and dynamic device states are restored synchronously through an atomic rollback process, ultimately achieving lightweight storage, rapid location, and secure and reliable rollback of historical versions.

[0010] To achieve the above objectives, the technical solution adopted by this invention is as follows: a method for virtual machine snapshot simplification and secure rollback based on configuration graphs and differential storage, comprising the following steps: S1. Intercept and receive configuration change requests for the target virtual machine; S2. At a preset silent time, interact with the virtual machine process corresponding to the target virtual machine through the virtual machine monitoring protocol to obtain the static configuration information and runtime dynamic device status information of the target virtual machine, forming a state set S; S3. Perform data cleaning on the state set S to filter out temporary fields that do not need to be persisted, and serialize the cleaned state set to generate a structured state document Vs. S4. Construct a version node based on the status document Vs, and attach metadata to the version node. The metadata includes at least a version identifier, a timestamp, and a parent version reference pointer. S5. Persistently store the version nodes in the version database in a transactional manner, and construct a directed acyclic graph of configuration versions based on the parent version reference relationship between version nodes to manage the derivative relationships of each version node; S6. Based on the state document Vs and the state document corresponding to the parent version, perform a difference comparison to generate a configuration incremental package containing only the change items, and store the configuration incremental package using a difference storage mechanism. S7. After receiving the rollback request to roll back to the target version, retrieve the status document Vs_target corresponding to the target version from the directed acyclic graph of the configuration version or the version database; S8. Perform availability verification on the external resources on which the target version depends, and perform consistency assessment on the state conflict risk of rolling back from the current version to the target version based on a preset rule set to generate verification and assessment results; when external resources are unavailable, stop the rollback and output unavailable resource information; when the consistency assessment result is that the risk is unacceptable, stop the rollback and output risk assessment information; when the consistency assessment result is that the risk is acceptable but needs to be confirmed, output risk warning and proceed to the subsequent rollback steps after confirmation.

[0011] S9. If external resources are available and the consistency assessment is passed or confirmed as per permission, perform an atomic rollback operation. The atomic rollback operation includes: shutting down the target virtual machine, applying the static configuration of the target version, rebinding or mounting the external resources that the target version depends on according to the target version, injecting the runtime dynamic device state in the state document Vs_target into the corresponding device of the target virtual machine through the state injection interface, and starting the target virtual machine and outputting the rollback result information.

[0012] Furthermore, the configuration change request includes configuration change requests initiated through the virtualization management interface or a custom interface, as well as configuration change requests initiated through the command line; the preset silent timing includes any one or more of the following: the period after the virtual machine is gracefully shut down and the virtual machine process has not exited, the consistency checkpoint when the virtual machine is in a silent pause state, and the period when it is confirmed that there are no frequent device input / output configuration operations.

[0013] Furthermore, the static configuration information includes machine type, processor model, memory slot layout, and firmware path; the runtime dynamic device status information includes at least one or more of the following: Network device status information, including network interface card physical address, virtual LAN identifier, link status, speed, and the name of the virtual network interface or user-space backend socket path of the backend connection; Block device status information, including disk image path, format, read-only attribute, media insertion status, and dirty page bitmap used to record incremental changes; Virtual hardware status information includes the expansion or contraction size of the virtual balloon device, the depth and enable status of the input / output queues, the processor activation feature flags, the input / output memory management unit mapping table, and the interrupt controller routing configuration.

[0014] Furthermore, the data cleaning and serialization includes: filtering temporary fields in the state set S that do not need to be persisted; organizing the serialization results according to the device type of processor, memory, storage controller, network device and bus; uniformly converting numerical values, strings, boolean values ​​and enumeration types into standardized serialization types; and maintaining the parent-child relationship, bus dependency relationship and backend resource binding relationship between devices through unique identifiers or path strings; wherein, the version identifier is obtained by calculating the hash value of the content of the state document Vs.

[0015] Furthermore, after obtaining the state set S, a dynamic state consistency check is performed on the state set S to confirm that there is no conflict in the interrupt line allocation and to confirm that the peripheral interconnect bus device matches the driver's expected state, thereby ensuring that there is no logical contradiction within the state set S.

[0016] Furthermore, the version database is an embedded relational version database; the serialized content, metadata, and binary large object of the status document Vs are stored in different data tables, and indexes are established on the version identifier, timestamp, and parent version identifier fields to support fast retrieval.

[0017] Furthermore, the difference comparison includes: using the status document corresponding to the parent version or the previous baseline version as a reference, generating a configuration incremental package containing only the change items and storing only the configuration incremental package; and calculating the complete configuration data corresponding to any version node based on the initial configuration and the associated configuration incremental package.

[0018] Furthermore, the external resources include disk image files, network bridging devices, and virtual LAN configurations; the availability verification includes verifying the existence of external resources, the correctness of paths, and the fulfillment of access permissions; the preset rule set includes at least: when the number of disk devices defined in the target version is less than that in the current version, it is determined to be high risk; when the memory size of the target version is less than that of the current version and the operating system in the virtual machine occupies a large amount of memory, it is determined to be medium risk; for medium-risk or high-risk rollback operations, the rollback process is paused and administrator confirmation is required before execution; and a risk assessment log is generated when the rollback is stopped or paused to wait for confirmation, the risk assessment information including the risk level, the rule identifier that triggered the risk, and a summary of the differences.

[0019] Furthermore, the atomic rollback operation includes: sending a graceful shutdown command to the virtual machine while it is running and waiting for the shutdown to complete; performing a forced shutdown and recording the event if there is no response after a timeout; applying the static configuration of the target version, which is achieved by redefining the configuration file in the virtualization management environment; rebinding or mounting external resources such as disk image files according to the target version; starting the virtual machine and outputting the rollback result information.

[0020] Furthermore, the state injection interface is used to inject the runtime dynamic device state of the target version into the corresponding device of the target virtual machine. The dynamic device state injection includes at least: setting the physical address of the network card of the target version to the network device, restoring the input / output queue depth and enable state, and / or restoring the input / output memory management unit mapping table to ensure that the hardware identifier is consistent with the record inside the virtual machine after rollback.

[0021] Compared with the prior art, the present invention has at least the following beneficial effects: This invention separates "configuration metadata" from "core data" and adopts a lightweight expression and differential storage strategy for configuration metadata. This avoids the redundancy caused by traditional snapshots repeatedly saving a large amount of unchanging configuration content in addition to large amounts of data on disk and in memory. It is suitable for long-term, high-frequency version maintenance scenarios.

[0022] This invention captures the dynamic device state during virtual machine runtime at a preset silent time and merges it with static configuration to form complete version data. This allows rollback recovery to not only restore static parameters but also synchronously restore key dynamic states that are strongly associated with them, thereby reducing the probability of problems such as device identification anomalies and inconsistent network / storage connections caused by "rolling back only static configuration".

[0023] By constructing a directed acyclic graph of configuration versions to manage version derivation relationships, this invention can efficiently locate the target version under complex version histories such as multiple changes and branch evolutions, and combine incremental packages to reconstruct the target configuration version data, thereby improving version retrieval and recovery efficiency.

[0024] This invention performs availability verification on external resources that the target version depends on before rollback execution, and conducts consistency risk assessment and early warning based on rule sets, transforming the traditional "blind rollback" into "predictable and controllable rollback", reducing rollback failures and operational accidents caused by missing dependencies or configuration conflicts from the source.

[0025] 1. This invention performs rollback according to a strict and orderly atomic process, sequentially completing safe shutdown, static configuration of the application target, rebinding of external resources, injection of the target version's dynamic device state, and starting the virtual machine, so that the virtual machine is restored to a known and internally consistent historical state point, thereby improving the startup success rate and operational stability. Attached Figure Description

[0026] 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 these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of the virtual machine snapshot simplification and secure rollback system architecture based on configuration graphs and differential storage according to the present invention; Figure 2 This is a flowchart illustrating the virtual machine secure rollback process and the atomic rollback execution sequence of the present invention. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0029] Example 1 This embodiment provides a method for virtual machine snapshot simplification and secure rollback based on configuration graphs and differential storage, including the following steps: S1. Intercept and receive configuration change requests for the target virtual machine; In this embodiment, this step corresponds to the starting point of version creation, and is used to incorporate each configuration modification into a unified version management process to avoid configuration changes being "unrecorded" and causing a missing version chain, thereby improving the reliability of version traceability and rollback.

[0030] S2. At a preset silent time, the system interacts with the virtual machine process corresponding to the target virtual machine through the virtual machine monitoring protocol to obtain the static configuration information and runtime dynamic device status information of the target virtual machine, forming a state set S. In this embodiment, the static configuration information is used to describe the basic resources and startup mode of the virtual machine, and the runtime dynamic device status information is used to describe the key device identifier, device negotiation parameters, and resource binding information of the virtual machine at the time of capture. By capturing at a preset silent time, the impact of runtime fluctuations on the acquisition results can be reduced, making the state set S more stable and consistent, thereby solving the problem that simply rolling back the static configuration can easily lead to the loss of dynamic status and inaccurate environment reproduction.

[0031] Furthermore, by directly extracting device and status information from the virtual machine process side through the virtual machine monitoring protocol, runtime status that is difficult to fully express by configuration files alone can be obtained, making the "configuration metadata" more complete and providing a basis for subsequent secure rollback.

[0032] S3. Perform data cleaning on the state set S to filter out temporary fields that do not need to be persisted, and serialize the cleaned state set to generate a structured state document Vs. In this embodiment, data cleaning is used to remove fields that only reflect runtime transients (such as statistical counters, cache handles, etc.) to avoid meaningless data entering the version library and reduce storage overhead. Serialization is used to encapsulate the state set S into a structured and persistent data representation, making it easy to index, compare and reconstruct, thereby improving version retrieval efficiency and difference storage efficiency.

[0033] The state document Vs is a self-contained structured document used to completely and unambiguously describe the non-disk hardware configuration state of the virtual machine at the moment of capture, thereby providing a basis for quickly locating the target version and restoring the target state.

[0034] S4. Construct version nodes based on the state document Vs and attach metadata to the version nodes. The metadata includes at least a version identifier, a timestamp, and a parent version reference pointer. In this embodiment, the version node is used to incorporate the state document Vs into the version management system. The parent version reference pointer is used to explicitly establish version derivation relationships, providing a basis for connecting edges in the subsequent construction of a directed acyclic graph of configuration versions. The version identifier and timestamp are used to support fast retrieval by version or by time and facilitate the formation of a traceable version chain.

[0035] Optionally, metadata may also include user comments to record the reasons for changes, making version management more in line with operational habits and facilitating a quick understanding of the sources of version differences.

[0036] S5. The version nodes are persistently stored in the version database using a transactional approach, and a configuration version directed acyclic graph is constructed based on the parent version reference relationship between version nodes to manage the derivative relationships of each version node. In this embodiment, the transactional persistence is used to ensure that the writing of version nodes, status documents Vs and their metadata has atomic consistency, avoiding the version database inconsistency problem caused by partial writes. The configuration version directed acyclic graph is used to organize and express the version evolution relationship, so that the target version path can still be quickly determined and the retrieval efficiency can be improved in scenarios of multiple configuration changes, rollbacks or branch evolutions.

[0037] Furthermore, the version database can index version identifiers, timestamps, and parent version identifiers to support rapid location of the target version based on hash or link tracing, thereby improving rollback location speed.

[0038] S6. Based on the difference comparison between the status document Vs and the status document corresponding to the parent version, a configuration incremental package containing only the changed items is generated, and the configuration incremental package is stored using a difference storage mechanism. In this embodiment, the difference comparison is used to extract the configuration items and status items that have changed between adjacent versions. Only the changed items are written into the configuration incremental package and stored, thereby avoiding the repeated saving of unchanged configurations and realizing snapshot-based simplified storage. In long-term, high-frequency version maintenance scenarios, this can significantly reduce redundancy accumulation and save storage resources.

[0039] The configuration incremental package can also be used to quickly generate a summary of changes between versions, providing operations and maintenance personnel with intuitive change information and providing input for differences in subsequent consistency risk assessments.

[0040] S7. After receiving the rollback request to the target version, retrieve the status document Vs_target corresponding to the target version from the configured version directed acyclic graph or the version database. In this embodiment, the target version is located by configuring the version directed acyclic graph, which can maintain a clear location path and stable retrieval efficiency even in the presence of branches or multiple rollbacks. Furthermore, the complete version data corresponding to the target version can be quickly assembled by combining the version nodes and incremental package information recorded in the version database, thereby improving recovery efficiency.

[0041] S8. Perform availability verification on the external resources on which the target version depends, and perform a consistency assessment on the state conflict risk of rolling back from the current version to the target version based on a preset rule set to generate verification and assessment results; when external resources are unavailable, abort the rollback and output unavailable resource information; when the consistency assessment result is that the risk is unacceptable, abort the rollback and output risk assessment information; when the consistency assessment result is that the risk is acceptable but needs confirmation, output a risk warning and proceed to the subsequent rollback steps after confirmation. In this embodiment, the external resource availability verification is used to check one by one whether the resources on which the target version depends still exist and are accessible, such as checking whether the disk image file path recorded by the target version is available, whether the network bridging device exists, etc.; when the verification fails, it is immediately aborted and the missing information is reported, which can avoid entering a rollback operation that will inevitably fail and improve the controllability of the rollback.

[0042] Consistency risk assessment is used to compare the differences between the current version and the target version, and to apply preset rules to identify state conflict risks that may lead to startup failure or abnormal operation. The assessment results are output in the form of risk level, trigger rule identifier and difference item summary and generate risk assessment log, so that risk prompts are interpretable and traceable, thereby reducing the probability of operation and maintenance accidents caused by blind rollback.

[0043] S9. If external resources are available and the consistency assessment passes or is confirmed as per permission, perform an atomic rollback operation. This atomic rollback operation includes: shutting down the target virtual machine, applying the static configuration of the target version, rebinding or mounting the external resources that the target version depends on according to the target version, injecting the runtime dynamic device state from the state document Vs_target into the corresponding device of the target virtual machine through the state injection interface, and starting the target virtual machine, then outputting the rollback result information. In this embodiment, the atomic rollback operation adopts a "pre-verification—atomic execution" process: after verification passes or is confirmed, the safe shutdown, static configuration restoration, external resource rebinding or mounting, and dynamic device state injection are completed in a strictly ordered manner, and finally the virtual machine is started. Because the static configuration and dynamic state are synchronously restored to a known and historically verified consistency point, the startup success rate and operational stability after rollback can be significantly improved.

[0044] Dynamic device state injection is used to restore the identification and negotiation state of critical devices, such as forcibly restoring the physical address of the network card of a network device, thereby ensuring that the hardware identification is consistent with the records inside the virtual machine and reducing the probability of network / device identification anomalies after rollback.

[0045] As one implementation method, the configuration change request in this embodiment includes configuration change requests initiated through the virtualization management interface or a custom interface, as well as configuration change requests initiated through the command line. The preset silent timing includes any one or more of the following: the period after the virtual machine is gracefully shut down and the virtual machine process has not exited, the consistency checkpoint when the virtual machine is in a silent pause state, and the period when it is confirmed that there are no frequent device input / output configuration operations. By covering both interface and command line entry points, configuration changes under different operation and maintenance methods can be uniformly managed, improving the integrity of version records. By selecting silent timings such as graceful shutdown and pause checkpoints to capture states, the impact of runtime noise and fluctuations on the state set S can be reduced, thereby improving the consistency and reproducibility of version data.

[0046] As one implementation method, the static configuration information in this embodiment includes machine type, processor model, memory slot layout, and firmware path; the runtime dynamic device status information includes at least one or more of the following: Network device status information, including network interface card physical address, virtual LAN identifier, link status, speed, and the name of the virtual network interface or user-space backend socket path of the backend connection; Block device status information, including disk image path, format, read-only attribute, media insertion status, and dirty page bitmap used to record incremental changes; Virtual hardware status information includes the expansion or contraction size of the virtual balloon device, the depth and enable status of the input / output queues, the processor activation feature flags, the input / output memory management unit mapping table, and the interrupt controller routing configuration.

[0047] Incorporating static configurations and runtime dynamic device states into "configuration metadata" and managing them in a versioned manner can compensate for the shortcomings of relying solely on configuration file version control, which cannot cover dynamic states, thereby improving the accuracy of environment reproduction after rollback; the dirty page bitmap can be used to characterize incremental changes on the storage side, providing auxiliary information for difference analysis and change tracking.

[0048] As one implementation method, the data cleaning and serialization in this embodiment includes: filtering temporary fields in the state set S that do not require persistence; organizing the serialization results according to the device type of processor, memory, storage controller, network device, and bus; uniformly converting numerical values, strings, boolean values, and enumeration types into standardized serialization types; and maintaining the parent-child relationship, bus dependency relationship, and backend resource binding relationship between devices through unique identifiers or path strings; wherein, the version identifier is obtained by calculating the hash value of the content of the state document Vs. Organizing by device type and maintaining the reference relationship makes the state document Vs self-descriptive and unambiguous, facilitating subsequent difference comparison and complete configuration reconstruction; obtaining the version identifier by calculating the hash of the Vs content can achieve content-based consistency identification, facilitate quick retrieval and prevent version confusion, and can be used to verify the consistency of version data.

[0049] As one implementation method, in this embodiment, after obtaining the state set S, a dynamic state consistency check is performed on the state set S to confirm that there are no conflicts in the interrupt line allocation and that the peripheral interconnect bus device matches the driver's expected state, thereby ensuring that there are no logical contradictions within the state set S. By performing consistency checks before the version is written to the repository, conflicts within the state set S can be detected in advance, avoiding the writing of unreproducible or self-contradictory states to the version repository, thereby reducing the risk of rollback failure and lowering subsequent troubleshooting costs.

[0050] As one implementation method, the version database in this embodiment is an embedded relational version database. The serialized content, metadata, and binary large object of the status document Vs are stored in different data tables, and indexes are established on the version identifier, timestamp, and parent version identifier fields to support fast retrieval. Through structured storage and index optimization, the query efficiency by version identifier, by time, or by parent-child link can be improved, thereby supporting the rapid location of the target version even with a large number of version nodes. The embedded version database is easy to deploy and migrate, reducing the complexity of system integration.

[0051] As one implementation method, the difference comparison in this embodiment includes: using the status document corresponding to the parent version or the previous baseline version as a reference, generating a configuration incremental package containing only the changed items and storing only the configuration incremental package; and calculating the complete configuration data corresponding to any version node based on the initial configuration and the associated configuration incremental package. Storing only the incremental package can fundamentally avoid the repeated saving of full configuration data, making the version node size significantly smaller than that of a traditional snapshot; calculating the complete configuration data by combining the initial configuration and the incremental package can maintain high storage efficiency while ensuring the integrity of recovery, taking into account both "simplified storage" and "recoverability".

[0052] As one implementation method, the external resources in this embodiment include disk image files, network bridging devices, and virtual LAN configurations; the availability verification includes verifying the existence of external resources, the correctness of paths, and the fulfillment of access permissions; the preset rule set includes at least: when the number of disk devices defined in the target version is less than that of the current version, it is determined to be high risk; when the memory size of the target version is less than that of the current version and the operating system in the virtual machine occupies a large amount of memory, it is determined to be medium risk; for medium-risk or high-risk rollback operations, the rollback process is paused and administrator confirmation is required before execution; and a risk assessment log is generated when the rollback is stopped or paused for confirmation, the risk assessment information including the risk level, the rule identifier that triggered the risk, and a summary of the difference items. External resource verification is used to exclude the situation of "resource deficiency leading to inevitable failure" before rollback execution; rule set risk assessment is used to identify typical conflict risks such as "disk reduction, memory shrinkage" and form interpretable logs, so that rollback is transformed from blind execution into a safe process that can be warned and confirmed, thereby improving rollback reliability and operational security.

[0053] As one implementation method, the atomic rollback operation in this embodiment includes: sending a graceful shutdown command to the virtual machine while it is running and waiting for the shutdown to complete; performing a forced shutdown and recording the event if there is no response after a timeout; applying the static configuration of the target version, which is achieved by redefining the configuration file in the virtualization management environment; rebinding or mounting external resources such as disk image files according to the target version; starting the virtual machine and outputting the rollback result information. The strategy of graceful shutdown and forced shutdown with timeout balances data security and rollback timeliness; by redefining the configuration file and rebinding external resources, the virtual machine startup parameters and backend dependencies are made consistent with the target version, creating conditions for subsequent dynamic state injection and stable startup.

[0054] As one implementation method, the state injection interface described in this embodiment is used to inject the runtime dynamic device state of the target version into the corresponding device of the target virtual machine. The dynamic device state injection includes at least: setting the physical address of the network interface card (NIC) of the target version to the network device, restoring the input / output queue depth and enable state, and / or restoring the input / output memory management unit (IMMU) mapping table, to ensure that the hardware identifier after rollback is consistent with the records inside the virtual machine. By injecting critical dynamic device state, the virtual hardware identifier after rollback is kept consistent with the historical version, reducing the probability of network configuration failures and device identification anomalies caused by changes in device identifiers, thereby improving the startup success rate and operational stability after rollback.

[0055] This embodiment addresses the need for version saving and rollback recovery after virtual machine configuration changes, proposing an implementation process for snapshot simplification and secure rollback. The process first intercepts configuration change requests and incorporates them into version management. At a preset silent time, it acquires the virtual machine's static configuration and runtime dynamic device status via the virtual machine monitoring protocol, forming a state set, which is then cleaned and serialized to obtain a state document Vs. Subsequently, version nodes are constructed based on the state document, with attached metadata such as version identifiers, timestamps, and parent version references. Version node transactions are written to the version database, and a directed acyclic graph of configuration versions is constructed based on parent-child reference relationships to manage version derivation relationships. At the storage level, differences between adjacent versions are compared, and only changed items are saved to form a configuration increment package to achieve simplified storage. During rollback, the system retrieves the target version status document Vs_target from the version graph or version database. It first verifies the availability of external resources such as disk images, network bridges, and virtual LANs that the target version depends on, and conducts consistency risk assessment and log recording based on preset rule sets. After the verification is passed or confirmed as allowed, the system completes the virtual machine shutdown, static configuration restoration, external resource rebinding or mounting, dynamic device status injection, and startup according to the atomic rollback process, thereby achieving rapid location, lightweight preservation, and secure and reliable rollback of historical versions.

[0056] Example 2 like Figure 1 As shown, this embodiment proposes a snapshot simplification and secure rollback method based on configuration graphs and differential storage. This method separates the virtual machine's configuration metadata from its runtime data (such as large volumes of data like disk and memory). By establishing a configuration version graph and storing only incremental changes between versions, it achieves significant simplification of snapshot storage space and rapid configuration recovery.

[0057] It should be noted that in this embodiment, "snapshot" can be understood as a "photo" of the virtual machine environment at a certain moment, corresponding to the virtual machine version record at that time. Traditional virtual machine snapshots contain far more information than required for version control. Therefore, the snapshot in this embodiment is technically simplified compared to a traditional snapshot, but the functional goals are similar. To avoid confusion, the term "version" will be used below to refer to the simplified snapshot formed in this embodiment.

[0058] like Figure 1 As shown, this system is located between the user / management layer and the virtualization layer. The user / management layer can be a virtualization management interface or a custom interface, for example... Figure 1 The Libvirt / custom API is shown. When a user / management system initiates a configuration change request, the request enters... Figure 1 The version control engine shown is responsible for coordinating the creation of versions (miniature snapshots), version graph management, and rollback operations.

[0059] like Figure 1 As shown, the version control engine comprises four cooperating sub-modules: 1) Version Modeler: As the starting point for version creation, it is responsible for intercepting all configuration modification requests to the virtual machine (whether via API or command line) and creating a corresponding version node data structure for each change. The version modeler saves the necessary information of the virtual machine environment, rather than saving the entire disk snapshot, thus significantly reducing the size of the version node compared to traditional snapshot files.

[0060] The version modeler also performs a difference comparison, which compares the current configuration with the configuration of the previous baseline version and generates a lightweight "configuration increment package" that only contains the changes, instead of storing the entire configuration file, thereby further reducing storage overhead.

[0061] In addition, the version modeler directs... Figure 1 The state capture agent shown "provides static configuration" to assist the state capture agent in integrating with the static configuration when capturing runtime dynamic state.

[0062] 2) Atlas Manager: Maintenance Figure 1 The configuration version is shown as a directed acyclic graph (DAG), where each node corresponds to a configuration version. It records the derivative relationships between each version and its parent version, supporting rapid version location and rollback. The graph manager can calculate the complete configuration data corresponding to a specific version based on the initial configuration and a series of incremental packages, providing a data source for rapid location and rollback to historical configurations.

[0063] like Figure 1 As shown, the Graph Manager can initiate a "Query Dependencies" to interact with the Dependency Manager and obtain information about the external resources that the target version depends on.

[0064] 3) Rollback Executor: Acting as the executor for rapid recovery. When recovery from a historical version is required, the rollback executor quickly retrieves and assembles the corresponding complete configuration based on the target version identifier using a graph. It then drives the virtualization management layer to apply this configuration and, in conjunction with the target version, rebinds or mounts external resources, thereby completing a lightweight recovery. This design transforms the configuration recovery process from loading full data from traditional snapshots to lightweight core data recovery, and, combined with a simplified version design, improves recovery speed.

[0065] 4) Consistency Verifier: As a security control component of the system, it performs a proactive risk assessment before the rollback executor takes action. Based on the configuration graph of the target version and dependency information, this module verifies the availability of external resources it depends on in the current environment. It also analyzes the potential state conflict risks that rollback may cause based on a predefined set of rules, issuing warnings or confirmation requests to users or the management system. This ensures the security of the rollback operation and reduces the risk of virtual machine anomalies or further crashes after rollback.

[0066] In addition to the modules mentioned above, such as Figure 1 As shown, this system also includes: (5) State Capture Agent: Running as a lightweight background service on the host machine, this agent is used to obtain dynamically generated, non-preset runtime states within the virtual machine, addressing the question of "what is the current state of the system?". The state capture agent obtains state states through... Figure 1 The "communication via QMP / internal interface" shown interacts with the virtual machine process in the virtualization layer, targeting... Figure 1 The virtualization layer and virtual machine instance are shown to perform state queries and extractions to obtain detailed device status information. To minimize the impact on virtual machine performance, capture actions are typically triggered at preset silent times, such as after the virtual machine is gracefully shut down, just before a process exits, or at a consistency checkpoint when the virtual machine is in a silent pause state.

[0067] (6) Dependency Manager: This provides the system with environment awareness, addressing the question of "what configuration is a safe and reliable state," and providing a mechanism for version rollback security. The dependency manager can parse the static configuration of the virtual machine, automatically identify all dependent external resources on the host machine, and allocate them accordingly. Figure 1 The program executes a "scan host machine resources" function to check if external resources exist, if the paths are correct, and if permissions are satisfied. Figure 1 The external resources indicated include at least "disk images, network bridges, etc." Meanwhile, Figure 1 The virtual machine instance is shown to have a "dependency" relationship with external resources. Therefore, verifying the availability of external resources is an important prerequisite for rollback reliability.

[0068] 2. Simplified version creation process (corresponding to) Figure 1 (Version control engine and state capture agent collaboration) When a user or management system initiates a configuration change (such as increasing virtual machine memory from 4GB to 8GB), the version control engine starts the version creation process. The basic idea of ​​this process is to save "configuration metadata" by capturing and saving granular system information, rather than simply saving a snapshot of the entire disk, in order to reduce the size of the version file and provide a complete basis for subsequent safe rollback.

[0069] 2.1 Trigger Timing Control (Silent Timing) State capture is not suitable for execution at all times during system operation; it must wait for an appropriate "quiet" period to ensure that the captured state is stable, consistent, and reproducible. Recklessly capturing states during periods of high system load or configuration changes may lead to internal state inconsistencies, rendering the version unusable for reliable recovery. Optimal triggering times may include, but are not limited to: After a graceful shutdown: the virtual machine operating system has shut down, applications have terminated, device drivers have completed state saving, and the virtual machine process has not yet exited; at this time, dynamic states are more easily solidified, making it the moment to capture a relatively clean and complete state; Silent paused checkpoint: A consistency checkpoint in which the virtual machine is in a paused state; Close critical desktop activity processes: Ensure that no frequent device input / output configuration operations are in progress, such as hot-plugging peripherals, adjusting image quality, or modifying display configurations, to avoid periods of frequent changes.

[0070] 2.2 State Extraction (Forming a State Set S) When the triggering conditions are met, the state extraction routine is triggered. The state capture agent connects to the target virtual machine process through a secure virtual machine monitoring protocol connection channel, and then issues state query commands in a predetermined order to systematically extract the key device and resource binding information of the virtual machine, forming a state set S. It is important to emphasize that the state set S is not the huge disk data of a traditional snapshot, but rather the core essential data that defines "how to build and restore this virtual machine".

[0071] The capture process can follow the principles of moving from static to dynamic and from global to local, including, for example: (1) Extract static configuration: Obtain relatively stable basic hardware definitions, such as machine type, processor model, memory slot layout, firmware path, etc., as the virtual machine hardware skeleton; (2) Enumerate and extract the device tree: Traverse the device model inside the virtual machine to obtain the configuration details of each virtual device, including: network device status: network card physical address, virtual LAN identifier, link status, speed, virtual network interface name or user-mode backend socket path, etc. Block device status: disk image path, format, read-only attribute, media insertion status; and can obtain a dirty page bitmap for incremental backup to record the range of disk sectors where data has changed since the last backup; Virtual hardware status: such as the expansion / contraction size of the virtual balloon device, the depth and enable status of the input / output queue, the processor activation feature flag, the input / output memory management unit mapping table, the interrupt controller routing configuration, etc.

[0072] 2.3 Dynamic state consistency check (ensuring no contradictions within S) For the extracted dynamic states (such as interrupt routing, inter-device dependencies, etc.), the version control engine can perform consistency checks to confirm that there are no logical contradictions within the state set S. The checks may include verifying that interrupt line allocations are conflict-free and confirming that peripheral interconnect bus devices match the expected states of the drivers. By performing consistency checks before the version is written to the repository, conflicts can be detected in advance, preventing the writing of unreproducible or contradictory states to the repository, thereby reducing the risk of rollback failures.

[0073] 2.4 State Encapsulation and Serialization (S→Vs) The extracted raw state S is typically a complex data structure in memory, making direct storage and versioning inconvenient. The purpose of state encapsulation is to transform it into a standardized, persistent, and easily comparable intermediate representation Vs, including: (1) Data cleaning: Traverse the device status data structure and filter out temporary fields that are purely runtime and do not require persistence, such as statistical counters and cache handles; (2) Serialization: Serialize the cleaned state object S into a structured state document Vs. The serialization process may include: Organize by device type: categorize and organize the status of processors, memory, storage controllers, network devices, buses, etc. Standardized data format: Convert numeric, string, boolean, and enumeration types into standardized serializable types; Maintain referencing relationships: Use unique identifiers or path strings to express parent-child relationships, bus dependency relationships, and backend resource binding relationships between devices (e.g., which controller a block device belongs to, or which bridge a network card is connected to).

[0074] The final generated Vs is a self-contained, unambiguous structured document used to fully describe the non-disk hardware configuration state of the virtual machine at the time of capture, providing a basis for difference comparison, retrieval and location, and version reconstruction.

[0075] Version 2.5 saves registration and differentiated management The packaged Visual Studio needs to be incorporated into a version management system to create traceable version nodes. Specifically, this may include: (1) Construct version node: Create a version node object, which contains a status document Vs and additional metadata, such as: a globally unique version identifier (which can be generated based on a timestamp and a random number, or obtained by hashing the content of Vs), a precise timestamp, a parent version node reference pointer (used to construct version derivation relationships), and optional user comments (such as reasons for changes). (2) Persistent storage: Write version nodes to a dedicated version database (e.g., an embedded relational database) in a transactional manner to ensure atomic consistency of the write; (3) Structured storage and index optimization: The serialized content, metadata, and binary large objects of Vs can be stored in different tables, and indexes can be created in fields such as version identifier, timestamp, and parent version identifier to improve the efficiency of tracing by time, by link, or by identifier. (4) Differential storage: Compare the differences between adjacent versions Vs, generate and store configuration incremental packages containing only the changed items, thereby avoiding the duplication of full configuration data; the complete configuration corresponding to any version can be calculated from the initial configuration and associated incremental packages. Through differential management, the accumulated storage overhead in long-term, high-frequency version maintenance scenarios can be further reduced.

[0076] 3. Safe rollback process like Figure 2 As shown, when a user initiates a rollback request, the system completes the safe rollback in the manner of "first verification and evaluation, then atomic execution". The logical nodes and process are as follows.

[0077] 3.1 User-initiated rollback request and target version retrieval like Figure 2 As shown, the user first initiates a rollback request, and the system executes "retrieve target version S_V_target", which means retrieving the complete state version corresponding to the target version from the version database or configuration version map, and obtaining the configuration and state data of the target version, providing input for subsequent verification and execution.

[0078] 3.2 Dependency Resource Validation (Success / Failure Branches) like Figure 2 As shown, after retrieving the target version, the process proceeds to "Dependency Resource Verification". The rollback executor calls the dependency manager to verify the availability of each external resource that the target version depends on, such as checking whether the disk image file recorded in the graph still exists in the specified path and is accessible, and whether the network bridging device exists.

[0079] If the verification fails, then... Figure 2 The system will enter the "Alarm and Stop Process" state and report detailed resource loss information to the user to avoid entering a rollback operation that will inevitably fail. If the verification is successful, proceed to the next step of consistency risk assessment.

[0080] 3.3 Consistency Risk Assessment and User Confirmation (Branch: Acceptable Risk / Excessive Risk) like Figure 2As shown, after successful dependency resource verification, the process proceeds to "Consistency Risk Assessment." The consistency verifier analyzes potential state conflicts that may arise from rolling back from the current version to the target version, compares the differences between the current and target configurations, and performs an assessment according to predefined rules, such as: Rule 1 (Disk Reduction): If the number of disk devices defined in the target version is less than that in the current version, the virtual machine may experience "disk loss" after rollback, which may lead to startup failure or data loss and is assessed as high risk. Rule 2 (Memory Reduction): If the target version's memory size is much smaller than the current version and the operating system within the virtual machine consumes a large amount of memory, a forced rollback may lead to insufficient memory and a crash, which is assessed as medium risk.

[0081] The verifier can generate a risk assessment log. For medium- to high-risk operations, such as... Figure 2 The system shown will "require user confirmation": If the user cancels, the process will proceed to "Alert and halt process"; If the user confirms, or if the risk itself is deemed "acceptable," then the atomic rollback execution sequence will be entered.

[0082] 3.4 Atomized Rollback Execution Sequence and Rollback Completion Notification like Figure 2 As shown, once the verification passes or is confirmed, the system enters the "atomic rollback execution sequence" and executes according to a strictly ordered set of steps: 1) Safely shut down the virtual machine: If the virtual machine is running, send a graceful shutdown command through the virtualization management layer and wait for it to shut down completely; if there is no response after a timeout, you can force shutdown and log the event; 2) Apply static configuration C_static(target): Apply the static configuration corresponding to the target version to the virtual machine, so that its startup parameters return to the target version (in the Libvirt environment, the virtual machine can be redefined by using the target version configuration). 3) Inject dynamic state S_dynamic(target): Before startup, the dynamic device state of the target version recorded in the database is set to each device of the virtual machine through the state injection interface. For example, a specific network card physical address is forcibly set to the network device to ensure that the hardware identifier is consistent with the records inside the virtual machine. 4) Start the virtual machine: Start the virtual machine after completing the static configuration and dynamic state recovery.

[0083] Because both static configuration and dynamic state are restored to a known and historically verified point of consistency, the virtual machine's startup success rate and operational stability are guaranteed. After execution, as follows... Figure 2 The output will show "Rollback Successful Notification" and then proceed to "Process End".

[0084] Existing virtual machine snapshot technology saves complete state points, typically recording massive amounts of data, including disk images and memory images, without differentiation. This data contains a large amount of unchanged configuration metadata, resulting in wasted storage space. This invention separates the processing of "configuration metadata," consisting of static configuration and runtime device states, from "core data" such as disk data. It employs a configuration version graph based on state capture and a differential storage mechanism to fundamentally reduce redundancy. Specifically, during version creation, the virtual machine monitoring protocol captures and serializes the state of critical devices (S→Vs), storing lightweight state documents and incremental change information in a dedicated version database. Compared to the GB / TB scale of traditional snapshot files, this achieves significant volume compression. Simultaneously, differential management supports storing only incremental changes between versions, avoiding duplicate saving of full configuration data, and offering a more significant cumulative storage advantage in long-term, high-frequency version maintenance scenarios.

[0085] In existing technologies, traditional snapshot recovery requires loading and parsing massive data files, a slow process that consumes significant resources. Configuration rollback based on external version control systems often leads to virtual machine startup failures or operational anomalies due to the lack of management of runtime states and external dependencies. This invention systematically solves these problems using a secure rollback process of "pre-rollback verification and evaluation, and in-process atomic execution": Before rollback, the dependency manager verifies the availability of external resources (such as disk files and network devices) that the target version depends on, avoiding inevitable failures due to resource loss; the consistency checker assesses the potential state conflict risks of rollback based on a preset rule set and outputs warnings, transforming rollback from blind execution to predictable and controllable. During the execution phase, the rollback executor performs a safe shutdown, applies the target static configuration, injects the target version's runtime dynamic device state, and starts the virtual machine according to an ordered atomic operation sequence. This not only restores the static configuration but also the critical dynamic state, enabling the virtual machine to start from a known and internally consistent historical state point, significantly improving rollback success rate and operational stability.

[0086] Existing configuration file-based management methods typically only record startup parameters, making it difficult to capture critical states dynamically generated internally during virtual machine runtime, resulting in incomplete version information. This invention introduces a state capture agent, which extracts a runtime state set S, including network device status, block device status, and virtual hardware characteristics, through the virtual machine monitoring protocol at an appropriate time after the virtual machine has silently or gracefully shut down. This S is then merged with the static configuration and serialized into a self-describing, standardized state document Vs. This state document fully defines the non-disk metadata required to rebuild the virtual machine, ensuring that each saved version corresponds to a reproducible state blueprint, thereby overcoming the shortcomings of existing technologies in terms of state completeness and consistency.

[0087] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for virtual machine snapshot simplification and secure rollback based on configuration graphs and differential storage, characterized in that: Includes the following steps: S1. Intercept and receive configuration change requests for the target virtual machine; S2. At a preset silent time, interact with the virtual machine process corresponding to the target virtual machine through the virtual machine monitoring protocol to obtain the static configuration information and runtime dynamic device status information of the target virtual machine, forming a state set S; S3. Perform data cleaning on the state set S to filter out temporary fields that do not need to be persisted, and serialize the cleaned state set to generate a structured state document Vs. S4. Construct a version node based on the status document Vs, and attach metadata to the version node. The metadata includes at least a version identifier, a timestamp, and a parent version reference pointer. S5. Persistently store the version nodes in the version database in a transactional manner, and construct a directed acyclic graph of configuration versions based on the parent version reference relationship between version nodes to manage the derivative relationships of each version node; S6. Based on the state document Vs and the state document corresponding to the parent version, perform a difference comparison to generate a configuration incremental package containing only the change items, and store the configuration incremental package using a difference storage mechanism. S7. After receiving the rollback request to roll back to the target version, retrieve the status document Vs_target corresponding to the target version from the directed acyclic graph of the configuration version or the version database; S8. Perform availability verification on the external resources on which the target version depends, and perform consistency assessment on the state conflict risk of rolling back from the current version to the target version based on a preset rule set, so as to generate verification and assessment results. S9. If external resources are available and the consistency assessment is passed or confirmed as per permission, perform an atomic rollback operation. The atomic rollback operation includes: shutting down the target virtual machine, applying the static configuration of the target version, rebinding or mounting the external resources that the target version depends on according to the target version, injecting the runtime dynamic device state in the state document Vs_target into the corresponding device of the target virtual machine through the state injection interface, and starting the target virtual machine and outputting the rollback result information.

2. The method according to claim 1, characterized in that: The configuration change request includes configuration change requests initiated through the virtualization management interface or a custom interface, as well as configuration change requests initiated through the command line; the preset silent timing includes any one or more of the following: the period after the virtual machine is gracefully shut down and the virtual machine process has not exited, the consistency checkpoint when the virtual machine is in a silent pause state, and the period when it is confirmed that there are no frequent device input / output configuration operations.

3. The method according to claim 2, characterized in that: The static configuration information includes machine type, processor model, memory slot layout, and firmware path; the runtime dynamic device status information includes at least one or more of the following: Network device status information, including network interface card physical address, virtual LAN identifier, link status, speed, and the name of the virtual network interface or user-space backend socket path of the backend connection; Block device status information, including disk image path, format, read-only attribute, media insertion status, and dirty page bitmap used to record incremental changes; Virtual hardware status information includes the expansion or contraction size of the virtual balloon device, the depth and enable status of the input / output queues, the processor activation feature flags, the input / output memory management unit mapping table, and the interrupt controller routing configuration.

4. The method according to claim 3, characterized in that: The data cleaning and serialization includes: filtering temporary fields in the state set S that do not need to be persisted; organizing the serialization results according to the device type of processor, memory, storage controller, network device and bus; uniformly converting numerical values, strings, boolean values ​​and enumeration types into standardized serialization types; and maintaining the parent-child relationship, bus dependency relationship and backend resource binding relationship between devices through unique identifiers or path strings; wherein, the version identifier is obtained by calculating the hash value of the content of the state document Vs.

5. The method according to claim 4, characterized in that: After obtaining the state set S, a dynamic state consistency check is performed on the state set S to confirm that there is no conflict in the interrupt line allocation and that the peripheral interconnect bus device matches the driver's expected state, thereby ensuring that there is no logical contradiction within the state set S.

6. The method according to claim 5, characterized in that: The version database is an embedded relational version database; the serialized content, metadata, and binary large objects of the status document Vs are stored in different data tables, and indexes are built on the version identifier, timestamp, and parent version identifier fields to support fast retrieval.

7. The method according to claim 6, characterized in that: The difference comparison includes: using the status document corresponding to the parent version or the previous baseline version as a reference, generating a configuration incremental package containing only the change items and storing only the configuration incremental package; and calculating the complete configuration data corresponding to any version node based on the initial configuration and the associated configuration incremental package.

8. The method according to claim 7, characterized in that: The external resources include disk image files, network bridging devices, and virtual LAN configurations; The availability verification includes verifying whether external resources exist, whether the path is correct, and whether the access permissions are satisfied. The preset rule set includes at least the following: when the number of disk devices defined in the target version is less than that in the current version, it is judged as high risk; when the memory size of the target version is less than that in the current version and the operating system in the virtual machine occupies a large amount of memory, it is judged as medium risk; for medium-risk or high-risk rollback operations, the rollback process is paused and the administrator is required to confirm before execution; A risk assessment log is generated when the rollback is aborted or paused to await confirmation. The risk assessment information includes the risk level, the rule identifier that triggered the risk, and a summary of the differences.

9. The method according to claim 8, characterized in that: The atomic rollback operation includes: sending a graceful shutdown command to the virtual machine while it is running and waiting for the shutdown to complete; performing a forced shutdown and recording the event if there is no response after a timeout; applying the static configuration of the target version, which is achieved by redefining the configuration file in the virtualization management environment; rebinding or mounting external resources such as disk image files according to the target version; starting the virtual machine and outputting the rollback result information.

10. The method according to claim 9, characterized in that: The state injection interface is used to inject the runtime dynamic device state of the target version into the corresponding device of the target virtual machine. The dynamic device state injection includes at least: setting the physical address of the network card of the target version to the network device, restoring the input / output queue depth and enable state, and / or restoring the input / output memory management unit mapping table to ensure that the hardware identifier is consistent with the record inside the virtual machine after rollback.

Images