A virtual machine hot migration method, device, electronic device and storage medium

Abstract

The present application discloses a virtual machine hot migration method, device, electronic device and computer-readable storage medium, the method comprising: generating an initial bitmap based on a target write granularity corresponding to a first virtual machine; migrating the data to be migrated of the first virtual machine to a data location corresponding to a second virtual machine; using the initial bitmap to record the incremental dirty data of the first virtual machine during the data migration process to obtain a valid bitmap; determining the full transmission time of the incremental dirty data, and judging whether the full transmission time is within a preset interval; if it is not within the preset interval, migrating the incremental dirty data to the data location using the valid bitmap, and updating the target write granularity according to the write data granularity distribution of the first virtual machine, so as to generate a new initial bitmap using the updated target write granularity; the method can reduce the degree of amplification of dirty data, while avoiding the problem of excessive bitmap space occupation and maintenance overhead.

Description

Technical Field

[0001] The present application relates to the field of virtual machine technology, and in particular to a virtual machine hot migration method, a virtual machine hot migration device, an electronic device, and a computer-readable storage medium. Background Art

[0002] Live migration of virtual machines involves migrating a virtual machine from one host to another, thereby balancing the host load and ensuring uninterrupted service for the migrated virtual machine. Live migration can be implemented in two scenarios: intra-storage live migration and cross-storage live migration. For cross-storage live migration, a fixed blank bitmap is used to mark newly added dirty data during each round of data migration. However, dirty data is continuously generated, and the generation rate may exceed the disk's read performance. This can make virtual machine data migration take a long time, or even difficult to complete. Summary of the Invention

[0003] In view of this, the purpose of the present application is to provide a virtual machine hot migration method, a virtual machine hot migration device, an electronic device and a computer-readable storage medium, so as to improve the migration efficiency of the virtual machine.

[0004] To solve the above technical problems, the present application provides a virtual machine hot migration method, comprising:

[0005] generating an initial bitmap based on a target write granularity corresponding to the first virtual machine;

[0006] Migrating the to-be-migrated data of the first virtual machine to a data location corresponding to the second virtual machine;

[0007] Using the initial bitmap to record incremental dirty data of the first virtual machine during data migration to obtain a valid bitmap;

[0008] Determine the full transmission time of the incremental dirty data, and determine whether the full transmission time is within a preset interval;

[0009] If it is not in the preset interval, the incremental dirty data is migrated to the data location using the valid bitmap, and the target write granularity is updated according to the write data granularity distribution of the first virtual machine, so as to generate a new initial bitmap using the updated target write granularity.

[0010] Optionally, the write data granularity distribution includes multiple write operations acquired by the first virtual machine, and updating the target write granularity according to the write data granularity distribution of the first virtual machine includes:

[0011] Determining the data volumes corresponding to the respective write operations;

[0012] Determine the volume intervals corresponding to the respective data volumes, and determine a maximum proportion interval in each volume interval; the number of write operations corresponding to the maximum proportion interval is not less than the number of write operations corresponding to other volume intervals;

[0013] An upper limit of the maximum ratio interval is determined as the target write granularity.

[0014] Optionally, generating an initial bitmap based on a target write granularity corresponding to the first virtual machine includes:

[0015] Determine whether the valid bitmap currently exists;

[0016] If the valid bitmap does not currently exist, determining a preset granularity as the target write granularity, and generating the initial bitmap using the target write granularity;

[0017] If the valid bitmap currently exists, the initial bitmap is generated using the updated target write granularity.

[0018] Optionally, determining the full transmission time of the incremental dirty data includes:

[0019] Obtaining a preset bandwidth between a first host to which the first virtual machine belongs and a second host to which the second virtual machine belongs;

[0020] The data volume corresponding to the incremental dirty data is determined, and the full transmission time is generated using the data volume and the preset bandwidth.

[0021] Optionally, if it is within the preset range, including:

[0022] Shut down the first virtual machine, and migrate the incremental dirty data to the data location using the valid bitmap;

[0023] After migrating the incremental dirty data to the data location, migrating the device state data of the first virtual machine to the second virtual machine;

[0024] The second virtual machine is started so that the second virtual machine runs using the device state data.

[0025] Optionally, it also includes:

[0026] After the data is migrated using the valid bitmap, the valid bitmap is marked as being in a dirty state.

[0027] Optionally, the using the initial bitmap to record incremental dirty data of the first virtual machine during the data migration process to obtain a valid bitmap includes:

[0028] Acquire the incremental dirty data, and determine the dirty data block to which the incremental dirty data belongs;

[0029] The flag bit corresponding to the dirty data block in the initial bitmap is updated to a dirty state to obtain the valid bitmap.

[0030] The present application also provides a virtual machine hot migration device, comprising:

[0031] An initial generation module, configured to generate an initial bitmap based on a target write granularity corresponding to the first virtual machine;

[0032] A migration module, configured to migrate the to-be-migrated data of the first virtual machine to a data location corresponding to the second virtual machine;

[0033] a recording module, configured to use the initial bitmap to record incremental dirty data of the first virtual machine during data migration to obtain a valid bitmap;

[0034] A judgment module, configured to determine a full transmission time of the incremental dirty data and determine whether the full transmission time is within a preset interval;

[0035] An update module is used to migrate the incremental dirty data to the data location using the valid bitmap if it is not in the preset interval, and to update the target write granularity according to the write data granularity distribution of the first virtual machine, so as to generate a new initial bitmap using the updated target write granularity.

[0036] The present application also provides an electronic device, including a memory and a processor, wherein:

[0037] The memory is used to store computer programs;

[0038] The processor is used to execute the computer program to implement the above-mentioned virtual machine hot migration method.

[0039] The present application also provides a computer-readable storage medium for storing a computer program, wherein the computer program implements the above-mentioned virtual machine hot migration method when executed by a processor.

[0040] The virtual machine hot migration method provided in the present application generates an initial bitmap based on the target write granularity corresponding to the first virtual machine; migrates the data to be migrated of the first virtual machine to the data location corresponding to the second virtual machine; uses the initial bitmap to record the incremental dirty data of the first virtual machine during the data migration process to obtain a valid bitmap; determines the full transmission time of the incremental dirty data, and determines whether the full transmission time is within a preset interval; if it is not within the preset interval, migrates the incremental dirty data to the data location using the valid bitmap, and updates the target write granularity according to the write data granularity distribution of the first virtual machine, so as to generate a new initial bitmap using the updated target write granularity.

[0041] It can be seen that before each round of data migration, the method uses the target write granularity to generate an initial bitmap, and during the data migration process, the incremental dirty data is recorded to obtain a valid bitmap. After a round of data migration, it is determined whether the full transmission time of the incremental dirty data is within the preset interval. If it is not within the preset interval, the incremental dirty data is migrated to the data location using the bitmap. During the migration process, new incremental dirty data is generated, and the target write granularity is updated based on the write data granularity distribution of the first virtual machine. The granularity of the newly generated new initial bitmap can be updated so that the appropriate granularity of the initial bitmap can be selected according to the write data granularity distribution, so that the granularity of the subsequently generated initial bitmap matches the write granularity normally used by the first virtual machine, reducing the degree of dirty data amplification while recording incremental dirty data, and avoiding the problem of excessive bitmap space occupation and maintenance overhead.

[0042] In addition, the present application also provides a virtual machine hot migration device, an electronic device, and a computer-readable storage medium, which also have the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0044] Figure 1 A schematic diagram of starting a hot migration of a virtual machine provided in an embodiment of the present application;

[0045] Figure 2 A schematic diagram of terminating a virtual machine live migration according to an embodiment of the present application;

[0046] Figure 3 A schematic diagram of a valid bitmap provided in an embodiment of the present application;

[0047] Figure 4A schematic diagram of another valid bitmap provided in an embodiment of the present application;

[0048] Figure 5 A flowchart of a virtual machine hot migration method provided in an embodiment of the present application;

[0049] Figure 6 A schematic diagram of the structure of a virtual machine hot migration device provided in an embodiment of the present application;

[0050] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0052] Virtual machine live migration includes two scenarios: same-storage live migration and cross-storage live migration. In the same-storage live migration scenario, the disk data corresponding to the migrated virtual machine will not be migrated. Only the virtual machine's memory data, device status data, etc. will be migrated. The migrated virtual machine will still use the original disk data. In the cross-storage live migration scenario, the disk data also needs to be migrated. For details, please refer to Figure 1 , Figure 1 This is a schematic diagram of the start of a virtual machine hot migration provided by the embodiment of the present application. After the migration begins, the storage image file (i.e. the disk data mentioned above) corresponding to the first virtual machine being migrated also needs to be migrated to another data storage location to obtain another image file. After the migration is completed, please refer to Figure 2 The original first virtual machine and its corresponding image file in storage device A are deleted, and the newly migrated virtual machine, namely the second virtual machine, runs using the image file in storage device B. The migration process can be controlled and executed by the virtual machine's QEMU, an open source emulator and virtual machine monitor (VMM).

[0053] During the disk data migration process, since the first virtual machine does not stop working, the migrated data may be changed. The changed data is called incremental dirty data. Generally, a bitmap can be used to record the incremental dirty data and identify its location on the disk. After the disk data migration is completed, the incremental dirty data is selected according to the bitmap that records the previous migration process and migrated. After the incremental dirty data on the bitmap is migrated, the migration is determined to be complete. Of course, during this migration process, it is also necessary to use a bitmap to record the incremental dirty data.

[0054] Each bitmap is generated based on a granularity, which indicates how large a data range a flag bit in the bitmap corresponds to on the disk. When a data bit in the data range (or data block) is changed, that is, when incremental dirty data appears in the data range, the corresponding flag bit in the bitmap is set to the dirty state to identify the incremental dirty data. The size of the granularity can be selected at will. When a larger granularity is selected, for example, you can refer to Figure 3 When the selected granularity is 1M, if the virtual machine's business is mainly based on small-block random write operations, the size of each incremental dirty data is small. For example, Oracle performs random writes in 8K lengths. In this way, when 8K in a 1M data block is encoded, the flag corresponding to the 1M data block will be updated to a dirty state. In the next round of migration, all 1M data blocks corresponding to the flag need to be migrated. It can be seen that in order to migrate 8K of valuable data, 1M of data actually needs to be migrated. When the generation rate of incremental dirty data is high, it may exceed the disk's read performance, making it difficult to complete the migration of the virtual machine. Even if it can be completed, it will take a lot of time.

[0055] Through experiments, we can obtain the following experimental results:

[0056]

[0057] It can be seen that in extreme cases, the magnification of dirty data can reach 190 times.

[0058] In order to avoid serious dirty data amplification, you can choose a smaller granularity to generate the bitmap, for example, please refer to Figure 4 Using 8KB granularity can alleviate the problem of dirty data amplification, but the size of the bitmap increases exponentially. For example, in scenarios where large blocks are written, the overhead of traversing and maintaining the bitmap is high, and the bitmap also consumes too much memory.

[0059] To address this issue, this application flexibly adjusts the bitmap granularity based on the size distribution of incremental dirty data. When necessary, the granularity can be reduced to prevent excessive amplification of dirty data, or increased to reduce bitmap maintenance overhead and memory usage. Each step in this application can be performed by a designated electronic device, the specific identity and number of which are not limited. For example, the steps can be performed by the first host to which the first virtual machine being migrated belongs.

[0060] For details, please refer to Figure 5 , Figure 5 A flowchart of a virtual machine live migration method provided in an embodiment of the present application. The method includes:

[0061] S101: Generate an initial bitmap based on a target write granularity corresponding to a first virtual machine.

[0062] The target write granularity refers to the granularity used when generating the initial bitmap, and its specific size is not limited. The initial bitmap refers to a brand new bitmap in which each flag bit is in a non-dirty state. The size of the initial bitmap is related to the size of the full data to be migrated by the first virtual machine and the target write granularity. The target write granularity multiplied by the number of flag bits in the initial bitmap equals the full data to be migrated by the first virtual machine. The first virtual machine refers to the virtual machine to be migrated, and the physical host to which it belongs is the first host.

[0063] It should be noted that before each data migration (including the initial migration of the full data of the first virtual machine and the migration of incremental dirty data after the initial migration), an initial bitmap must be generated to record the incremental dirty data during the upcoming data migration. The process of generating the initial bitmap is not limited and can be referenced by related technologies.

[0064] For the migration of incremental dirty data after the first migration, the granularity of the corresponding initial bitmap is related to the granularity distribution of the write data of the first virtual machine. The granularity distribution of the write data is the data block size distribution of the incremental dirty data, so its specific size cannot be determined. For the first migration of the full data of the first virtual machine, it is the first migration, and the granularity size of the initial bitmap used has little impact on the subsequent process (because the entire migration process is usually multiple rounds, that is, multiple migrations), so the size of the target write granularity used can be flexibly set. For example, in one embodiment, when the first virtual machine starts running, its write data granularity distribution is counted, and when the data is migrated for the first time, the target write granularity is determined according to the write data granularity distribution.

[0065] Since the business status of the first virtual machine may fluctuate in the short term, and it takes a lot of resources to collect statistics on the distribution of the granularity of written data in the long term. Therefore, in another embodiment, when the initial bitmap is generated for the first time, a preset granularity can be used as the target write granularity. Specifically, when generating the initial bitmap, it can be determined whether there is a valid bitmap. If there is no valid bitmap at present, the preset granularity is determined as the target write granularity, and the initial bitmap is generated using the target write granularity. If there is a valid bitmap at present, the updated target write granularity is used to generate the initial bitmap. The updated target write granularity can be the same as or different from the preset granularity, and the size of the preset granularity is not limited.

[0066] S102: Migrate the to-be-migrated data of the first virtual machine to a data location corresponding to the second virtual machine.

[0067] The data to be migrated refers to the entire data of the first VM during the first data migration, which may include disk data or memory data. Due to the size of the data to be migrated and the bandwidth between the first host and the second host, data migration may take some time. During this time, incremental dirty data may appear.

[0068] It should be noted that this step is only performed once during the entire migration process of the first virtual machine. Subsequent migrations are all migrations of incremental data, and this migration does not need to be based on the valid bitmap. The valid bitmap refers to the bitmap that records the addition of incremental dirty data.

[0069] S103: Using the initial bitmap to record incremental dirty data of the first virtual machine during the data migration process, to obtain a valid bitmap.

[0070] During the migration process, whether it's the first full migration or subsequent migrations of incremental dirty data, the initial bitmap must be used to record all incremental dirty data. The bitmap that records the addition of new incremental dirty data is the valid bitmap. It should be noted that during a migration, incremental dirty data may not appear. This will cause the valid bitmap to have the same content as the initial bitmap, but its identity will change because the valid bitmap records the absence of new incremental dirty data.

[0071] In addition, step S103 must be performed simultaneously with the data migration step, including step S102 and the step of migrating the incremental dirty data to the data location using the valid bitmap in S106. Specifically, when recording, the incremental dirty data is obtained and the dirty data block to which the incremental dirty data belongs is determined. The number of dirty data blocks is not limited and is related to the size of the incremental dirty data and the granularity of the initial bitmap. After determining which data block, the flag corresponding to the dirty data block in the initial bitmap is updated to the dirty state to obtain a valid bitmap. For example, the flag can be changed from 0 to 1, where 1 is the dirty state.

[0072] S104: Determine the full transmission time of the incremental dirty data, and judge whether the full transmission time is within a preset range.

[0073] After a data migration is completed, a new valid bitmap will be generated regardless of whether the last migration was a full data migration or a migration of incremental dirty data. Before the next migration begins, it is necessary to determine the migration plan. Specifically, the first virtual machine must stop running during the last migration to avoid the emergence of new dirty data. The maximum duration of the stoppage is the upper limit of the preset interval, and the specific size is not limited. By judging whether the full transmission time of the incremental dirty data is within the preset interval, it can be judged whether the next migration is the last migration. If so, execute step S105, otherwise execute step S106.

[0074] This embodiment does not limit the specific method for determining the full transfer time. For example, in one embodiment, the preset bandwidth between the first host to which the first virtual machine belongs and the second host to which the second virtual machine belongs can be obtained to determine the data volume corresponding to the incremental dirty data. The data volume and the preset bandwidth are then used to generate the full transfer time. The preset bandwidth is not limited and can be set according to actual conditions. The data volume of the incremental dirty data can be determined by analyzing the number and granularity of dirty data bits in the most recently generated valid bitmap.

[0075] S105: Preset operation.

[0076] When the full transfer time is within the preset interval, it means that the data migration that is about to begin is the last data migration. In this case, the preset operation can be performed. The specific content of the preset operation is not limited. In one embodiment, the first virtual machine is shut down, and the incremental dirty data is migrated to the data location using a valid bitmap. It should be noted that since this migration is the last migration, there is no need to generate an initial bitmap before the migration. After migrating the incremental dirty data to the data location, the device status data of the first virtual machine is migrated to the second virtual machine. The device status data is used to describe the status of the first virtual machine before the shutdown process, and its quantity and content are not limited. Start the second virtual machine so that the second virtual machine can run using the device status data. When the second virtual machine starts running, it can be regarded as the first virtual machine being migrated to the second host. The first virtual machine and its corresponding related data can be deleted or destroyed.

[0077] S106: Migrate the incremental dirty data to the data location using the valid bitmap, and update the target write granularity according to the write data granularity distribution of the first virtual machine, so as to generate a new initial bitmap using the updated target write granularity.

[0078] When the full transfer time is not in the preset interval, it means that the data migration that is about to begin is not the last migration. In this case, the target write granularity needs to be updated, and the incremental dirty data needs to be migrated to the data location using the valid bitmap. It should be noted that in this step, before migrating the incremental dirty data, a new initial bitmap needs to be generated using the target write granularity, and step S103 needs to be executed during the migration process. This embodiment does not limit the execution timing of updating the target write granularity. In one embodiment, when it is determined that the full transfer time is not in the preset interval, the target write granularity is first updated, and then the initial bitmap is generated using the updated target write granularity, and finally the incremental dirty data is migrated using the valid bitmap. While migrating, the newly generated initial bitmap is used to execute step S103. In another embodiment, the initial bitmap can be generated first, and then the incremental dirty data is migrated using the valid bitmap. While migrating, the newly generated initial bitmap is used to execute step S103, and finally the target write granularity is updated.

[0079] This embodiment does not limit the specific method for updating the target write granularity. In one embodiment, multiple write operations obtained by the first virtual machine can be counted, for example, all write operations, or write operations obtained after the migration of the first virtual machine begins. The data block size of each write operation is determined, and the data block sizes are sorted by number. The data block size ranked first is determined as the target write granularity. In another embodiment, because the largest data block size may account for a small proportion, and the sum of multiple smaller data block sizes of similar sizes is much larger than the largest data block size, determining the target write granularity based on multiple similar data block sizes can actually more accurately represent the write operation size of the first virtual machine's business under normal circumstances. Therefore, the data volume corresponding to each write operation can be determined, and the volume interval corresponding to each data volume can be determined. The write data granularity distribution includes the multiple write operations obtained by the first virtual machine. There are multiple volume intervals, each of which is adjacent. The length and upper and lower limits of each volume interval are not limited. For example, the upper limit of each volume interval can be twice the lower limit. Determine the maximum proportion interval in each volume interval, and the number of write operations corresponding to the maximum proportion interval is not less than the number of write operations corresponding to other volume intervals, that is, it covers the interval with the most write operations. When there are multiple intervals whose number of write operations is not less than the number of write operations of other volume intervals, the maximum proportion interval can be any one of them. By counting the number of intervals, data volumes of similar sizes can be regarded as the same volume, which can more accurately determine the data volume that occupies the largest proportion in the first virtual machine's write data business. The upper limit of the maximum proportion interval is determined as the target write granularity. The initial bitmap generated with the target write granularity has the maximum probability of modifying a data bit each time the incremental dirty data is obtained, and the amount of incremental dirty data occupies a larger part of the data block corresponding to the data bit, which can effectively avoid serious dirty data amplification and effectively reduce the bitmap maintenance overhead and memory usage.

[0080] For example, in one embodiment, assuming that the first virtual machine corresponds to two virtual disks, namely VDISK1 and VDISK2, the data volumes of each virtual disk are detected within the volume range, and the following detection results are obtained:

[0081] VDISK1:

[0082] Write operation block size range Number of write operations Distribution percentage Optimal BITMAP granularity <＝16K 20 10％ 16K 16K-32K 30 15％ 32K 32K-64K 100 50％ 64K 64K-128K 15 7.5％ 128K 128K-256K 15 7.5％ 256K 256K-512K 10 5％ 512K 512K-1M 10 5％ 1M

[0083] VDISK2:

[0084] Write operation block size range Number of write operations Distribution percentage Optimal BITMAP granularity <＝16K 100 50％ 16K 16K-32K 30 15％ 32K 32K-64K 20 10％ 64K 64K-128K 15 7.5％ 128K 128K-256K 15 7.5％ 256K 256K-512K 10 5％ 512K 512K-1M 10 5％ 1M

[0085] For VDISK1, the maximum ratio range is 32K-64K, and the corresponding target write granularity is 64K. For VDISK2, the maximum ratio range is <=16K, and the corresponding target write granularity is 16K.

[0086] It can be seen from this that the number of target write granularities can be one or more, and its number is related to the number of virtual disks of the first virtual machine. Each virtual disk corresponds to a target write granularity. Each time the initial bitmap is generated, the target write granularity of each virtual disk is needed to generate the corresponding initial bitmap for each virtual disk.

[0087] In addition, in order to avoid excessive memory space occupation, after the data is migrated using the valid bitmap, the valid bitmap is marked as dirty so that it can be cleaned up.

[0088] The virtual machine hot migration method provided by the embodiment of the present application is applied. Before each round of data migration, the target write granularity is used to generate an initial bitmap, and during the data migration process, the incremental dirty data is recorded to obtain a valid bitmap. After a round of data migration, it is determined whether the full transmission time of the incremental dirty data is within the preset interval. If it is not within the preset interval, the incremental dirty data is migrated to the data location using the bitmap. During the migration process, new incremental dirty data is generated, and the target write granularity is updated based on the write data granularity distribution of the first virtual machine. The granularity of the newly generated new initial bitmap can be updated so that the appropriate granularity of the initial bitmap can be selected according to the write data granularity distribution, so that the granularity of the subsequently generated initial bitmap matches the write granularity normally used by the first virtual machine, reducing the degree of dirty data amplification while recording incremental dirty data, and avoiding the problem of excessive bitmap space occupation and maintenance overhead.

[0089] The following is an introduction to a virtual machine hot migration device provided in an embodiment of the present application. The virtual machine hot migration device described below and the virtual machine hot migration method described above can be referenced to each other.

[0090] Please refer to Figure 6 , Figure 6 A schematic diagram of the structure of a virtual machine hot migration device provided in an embodiment of the present application includes:

[0091] An initial generation module 110 is configured to generate an initial bitmap based on a target write granularity corresponding to the first virtual machine;

[0092] A migration module 120 is configured to migrate the to-be-migrated data of the first virtual machine to a data location corresponding to the second virtual machine;

[0093] A recording module 130 is configured to use an initial bitmap to record incremental dirty data of the first virtual machine during the data migration process to obtain a valid bitmap;

[0094] A determination module 140 is configured to determine a full transmission time of incremental dirty data and determine whether the full transmission time is within a preset interval;

[0095] The update module 150 is used to migrate the incremental dirty data to the data location using the valid bitmap if it is not in the preset interval, and update the target write granularity according to the write data granularity distribution of the first virtual machine, so as to generate a new initial bitmap using the updated target write granularity.

[0096] Optionally, the write data granularity distribution includes multiple write operations acquired by the first virtual machine, and the update module 150 includes:

[0097] A data volume determination unit, configured to determine the data volume corresponding to each write operation;

[0098] a maximum proportion interval determination unit, configured to determine volume intervals corresponding to respective data volumes, and to determine a maximum proportion interval among the volume intervals; the number of write operations corresponding to the maximum proportion interval being no less than the number of write operations corresponding to the other volume intervals;

[0099] The granularity determination unit is configured to determine an upper limit of the maximum ratio interval as a target write granularity.

[0100] Optionally, the initial generation module 110 includes:

[0101] An existence judgment unit is used to judge whether there is a valid bitmap currently;

[0102] A first generating unit is configured to determine a preset granularity as a target write granularity if no valid bitmap currently exists, and generate an initial bitmap using the target write granularity;

[0103] The second generating unit is configured to generate an initial bitmap using the updated target write granularity if a valid bitmap currently exists.

[0104] Optionally, the judgment module 140 includes:

[0105] Obtaining a preset bandwidth between a first host to which the first virtual machine belongs and a second host to which the second virtual machine belongs;

[0106] Determine the data volume corresponding to the incremental dirty data, and use the data volume and preset bandwidth to generate the full transmission time.

[0107] Optionally, it also includes:

[0108] A shutdown processing module, configured to shut down the first virtual machine if the virtual machine is within a preset interval, and migrate incremental dirty data to a data location using a valid bitmap;

[0109] a state migration module, configured to migrate the device state data of the first virtual machine to the second virtual machine after migrating the incremental dirty data to the data location;

[0110] The running module is used to start the second virtual machine so that the second virtual machine runs using the device state data.

[0111] Optionally, it also includes:

[0112] The bitmap marking module is used to mark the valid bitmap as dirty after completing data migration using the valid bitmap.

[0113] Optionally, the recording module 130 includes:

[0114] a dirty data block determining unit, configured to obtain incremental dirty data and determine the dirty data block to which the incremental dirty data belongs;

[0115] The flag bit updating unit is used to update the flag bit corresponding to the dirty data block in the initial bitmap to a dirty state to obtain a valid bitmap.

[0116] The electronic device provided in the embodiment of the present application is introduced below. The electronic device described below and the virtual machine hot migration method described above can refer to each other.

[0117] Please refer to Figure 7 , Figure 7 The electronic device 100 may include a processor 101 and a memory 102, and may further include one or more of a multimedia component 103, an information input / output (I / O) interface 104, and a communication component 105.

[0118] The processor 101 is used to control the overall operation of the electronic device 100 to complete all or part of the steps in the above-mentioned virtual machine hot migration method; the memory 102 is used to store various types of data to support the operation of the electronic device 100. For example, these data may include instructions for any application or method operating on the electronic device 100, as well as application-related data. The memory 102 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0119] The multimedia component 103 may include a screen and an audio component. The screen may be, for example, a touch screen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signal may be further stored in the memory 102 or sent through the communication component 105. The audio component also includes at least one speaker for outputting audio signals. The I / O interface 104 provides an interface between the processor 101 and other interface modules. The above-mentioned other interface modules may be a keyboard, a mouse, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 105 is used for wired or wireless communication between the electronic device 100 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G or 4G, or a combination of one or more of them, so the corresponding communication component 105 may include: a Wi-Fi component, a Bluetooth component, an NFC component.

[0120] The electronic device 100 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the virtual machine hot migration method provided in the above embodiment.

[0121] The computer-readable storage medium provided in an embodiment of the present application is introduced below. The computer-readable storage medium described below and the virtual machine hot migration method described above can be referenced to each other.

[0122] The present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned virtual machine hot migration method are implemented.

[0123] The computer-readable storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., which can store program codes.

[0124] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0125] Those skilled in the art may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0126] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0127] Finally, it should be noted that, in this document, relationships such as first and second, etc., are used solely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms include, comprise, or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0128] This document uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. At the same time, for those skilled in the art, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting this application.

Claims

1. A method for hot migration of a virtual machine, characterized in that: include: generating an initial bitmap based on a target write granularity corresponding to the first virtual machine; Migrating the to-be-migrated data of the first virtual machine to a data location corresponding to the second virtual machine; Using the initial bitmap to record incremental dirty data of the first virtual machine during data migration to obtain a valid bitmap; Determine the full transmission time of the incremental dirty data, and determine whether the full transmission time is within a preset interval; If it is not in the preset interval, migrating the incremental dirty data to the data location using the valid bitmap, and updating the target write granularity according to the write data granularity distribution of the first virtual machine, so as to generate a new initial bitmap using the updated target write granularity; The write data granularity distribution includes multiple write operations acquired by the first virtual machine, and updating the target write granularity according to the write data granularity distribution of the first virtual machine includes: Determining the data volumes corresponding to the respective write operations; Determine the volume intervals corresponding to the respective data volumes, and determine a maximum proportion interval in each volume interval; the number of write operations corresponding to the maximum proportion interval is not less than the number of write operations corresponding to other volume intervals; An upper limit of the maximum ratio interval is determined as the target write granularity.

2. The virtual machine live migration method according to claim 1, wherein: Generating an initial bitmap based on the target write granularity corresponding to the first virtual machine includes: Determine whether the valid bitmap currently exists; If the valid bitmap does not currently exist, determining a preset granularity as the target write granularity, and generating the initial bitmap using the target write granularity; If the valid bitmap currently exists, the initial bitmap is generated using the updated target write granularity.

3. The virtual machine live migration method according to claim 1, wherein: The determining of the full transmission time of the incremental dirty data includes: Obtaining a preset bandwidth between a first host to which the first virtual machine belongs and a second host to which the second virtual machine belongs; The data volume corresponding to the incremental dirty data is determined, and the full transmission time is generated using the data volume and the preset bandwidth.

4. The method for hot migration of a virtual machine according to claim 1, wherein: If it is within the preset range, it includes: Shut down the first virtual machine, and migrate the incremental dirty data to the data location using the valid bitmap; After migrating the incremental dirty data to the data location, migrating the device state data of the first virtual machine to the second virtual machine; The second virtual machine is started so that the second virtual machine runs using the device state data.

5. The virtual machine live migration method according to any one of claims 1 to 4, characterized in that: Also includes: After the data is migrated using the valid bitmap, the valid bitmap is marked as being in a dirty state.

6. The virtual machine live migration method according to claim 1, wherein: The step of using the initial bitmap to record incremental dirty data of the first virtual machine during the data migration process to obtain a valid bitmap includes: Acquire the incremental dirty data, and determine the dirty data block to which the incremental dirty data belongs; The flag bit corresponding to the dirty data block in the initial bitmap is updated to a dirty state to obtain the valid bitmap.

7. A virtual machine hot migration device, characterized in that: include: An initial generation module, configured to generate an initial bitmap based on a target write granularity corresponding to the first virtual machine; A migration module, configured to migrate the to-be-migrated data of the first virtual machine to a data location corresponding to the second virtual machine; a recording module, configured to use the initial bitmap to record incremental dirty data of the first virtual machine during data migration to obtain a valid bitmap; A judgment module, configured to determine a full transmission time of the incremental dirty data and determine whether the full transmission time is within a preset interval; an updating module, configured to, if the incremental dirty data is not within the preset interval, migrate the incremental dirty data to the data location using the valid bitmap, and update the target write granularity according to the write data granularity distribution of the first virtual machine, so as to generate a new initial bitmap using the updated target write granularity; The update module includes: A data volume determination unit, configured to determine the data volume corresponding to each write operation; a maximum proportion interval determination unit, configured to determine volume intervals corresponding to respective data volumes, and to determine a maximum proportion interval among the volume intervals; the number of write operations corresponding to the maximum proportion interval being no less than the number of write operations corresponding to the other volume intervals; The granularity determination unit is configured to determine an upper limit of the maximum ratio interval as a target write granularity.

8. An electronic device, characterized in that: comprising a memory and a processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program to implement the virtual machine live migration method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that Used to store a computer program, wherein when the computer program is executed by a processor, the virtual machine hot migration method according to any one of claims 1 to 6 is implemented.

Images