TWI453669B - Method of virtual machine migration and cloud server system - Google Patents

Description

Virtual machine migration method and cloud servo system

The present invention relates to an application of a virtual machine, and more particularly to a method of migrating a virtual machine and a cloud server system supporting the method.

The server has high computing power and is therefore the core computer that serves each computer in the network system. With the rapid development of cloud computing and virtual machines, several servers are routed through the network to perform several arithmetic processing, and it is easy to expand, can quickly deploy resources to provide services, and can be reduced. The cloud servo system, which has the advantages of the computing burden of the user terminal, is also receiving more and more attention.

Each node in the cloud servo system can simulate more than one virtual machine through the operation of a hypervisor. In other words, in addition to the host operating system, the guest operating system corresponding to each virtual machine can also be executed simultaneously in the same set of hardware devices. However, for most cloud server systems that currently provide Infrastructure as a Service (IaaS), each node in the container runs the same type of hypervisor. Therefore, when the user needs to migrate the existing virtual machine from the hypervisor being used to a cloud server, if the cloud server does not support the same type of hypervisor, it must take extra time to convert the object. The image format of the system, and the configuration file to be referenced by the simulated virtual machine must be set by the node to which the migration is performed, so that the migration of the virtual machine can be completed. However, setting the configuration file by itself is likely to cause the migration of the guest operating system to fail, and it takes a lot of time to test the re-establishment of the virtual machine on the node and execute the guest operating system and the software on the node, which is easy for the user to feel inconvenience. And will reduce the user's willingness to use this cloud servo system.

In view of this, the present invention provides a virtual machine migration method and a cloud server system, which can select an appropriate node to complete the migration of the virtual machine, so as to reduce the time required for migrating the virtual machine.

The invention provides a virtual machine migration method for a cloud server system. The cloud server system comprises a container, the container comprises a service node, a storage node and a plurality of computing nodes. The method includes dividing, by the service node, all of the compute nodes into at least one compute node group, wherein each compute node group is one-to-one corresponding to a particular hypervisor type. Then, the service node receives an image file and a configuration file corresponding to the virtual machine, and stores the image file and the configuration file in the storage node, and simulates the virtual image according to the image file identification. The type of super manager of the machine. Determine if there is the same type of hypervisor that emulates this virtual machine in all of the specific hypervisor types. If so, a particular compute node is selected from a group of compute nodes corresponding to the particular hypervisor type, and the virtual machine is simulated by the particular compute node based on the image file and the configuration file.

In an embodiment of the invention, the step of identifying the type of hypervisor emulating the virtual machine based on the image file includes identifying the type of the hypervisor based on the content of the header of the image file.

In an embodiment of the present invention, the virtual machine migration method further includes analyzing the content of the configuration file to identify the type of the hypervisor if the type of the hypervisor cannot be identified according to the content of the header.

In an embodiment of the invention, wherein it is determined whether there is a step of the same type as the hypervisor simulating the virtual machine in all of the specific hypervisor types, the method further includes if there is no such hypervisor The specific hypervisor type, selects a specific group of computing nodes from all the computing node groups, and generates an equivalent image of the image file and the configuration file according to the specific hypervisor type corresponding to the specific computing node group. File and equivalent configuration file. And selecting a particular compute node in a particular group of compute nodes, and thereby the particular compute node emulates the virtual machine based on the equivalent image file and the equivalent configuration file.

In an embodiment of the present invention, the image file and the configuration file corresponding to the virtual machine are transmitted by the second cloud server system to the cloud server system through a public network.

From another point of view, the present invention provides a cloud servo system including a container including a plurality of computing nodes and a service node and a storage node. The storage node is coupled to the computing node through the area network. The service node is coupled to the computing node and the storage node through the area network, and divides the computing node into at least one computing node group, wherein each computing node group corresponds to a specific hypervisor type. The service node receives the image file and the configuration file corresponding to a virtual machine, stores the image file and the configuration file in the storage node, identifies the type of the hypervisor that simulates the virtual machine according to the image file, and determines the specific hyper management in all the virtual machines. Is there a specific hypervisor type of the same type as this hypervisor? If so, the service node selects a particular compute node from the group of compute nodes corresponding to the particular hypervisor type, and then the particular compute node emulates the virtual machine based on the image file and the configuration file.

In an embodiment of the invention, the service node identifies the type of hypervisor emulating the virtual machine based on the content of the header of the image file.

In an embodiment of the present invention, if the service node cannot identify the type of the hypervisor of the simulated virtual machine according to the content of the header, the content of the configuration file is analyzed to identify the type of the hypervisor.

In an embodiment of the invention, wherein if there is no specific hypervisor type of the same type as the hypervisor in all of the specific hypervisor types, the serving node selects a particular compute node group from all of the compute node groups Grouping, and generating an equivalent image file and an equivalent configuration file of the image file and the configuration file according to a specific hypervisor type corresponding to the specific computing node group, and selecting a specific computing node in the specific computing node group, The virtual machine is simulated by the specific computing node according to the equivalent image file and the equivalent configuration file.

In an embodiment of the invention, the image file and the configuration file corresponding to the virtual machine are transmitted by the second cloud server system to the cloud server system through the public network.

Based on the above, the container of the cloud servo system of the present invention includes computing nodes running different types of hypervisors. When a virtual machine is to be migrated to the cloud server system, the hypervisor type that originally executed the virtual machine is first identified, so that the appropriate computing node is found in the container to complete the virtual machine migration action. In this way, the efficiency and quality of the migrated virtual machine is improved by providing compute nodes running the same type of hypervisor.

The above described features and advantages of the present invention will be more apparent from the following description.

FIG. 1 is a schematic diagram of a cloud servo system according to an embodiment of the invention. Referring to FIG. 1, the cloud server system 100 of the present embodiment is, for example, a container type data center that provides Infrastructure as a Service (IaaS), and includes one or more containers. In an example the container 10, which has n racks (rack) 20 ₁ to 20 is _n (n is a positive integer), and each rack having a plurality of slots (slot). For example, rack 20 ₁ has i slots (ie, slots S _1-1 through S _1-i ), while rack 20 _n has j slots (ie, slots Sn _-1 to S _nj), where i, j is a positive integer. Each slot includes a plurality of nodes, for example, slot S _1-1 in rack 20 ₁ includes node N ₁₁₀ and node N ₁₁₁ . Each node is provided with an electronic device including a central processing unit and a physical hardware device such as a microcontroller. In addition, a switch 30 is provided in the container 10, and the switch 30 is coupled to the electronic devices provided in the respective nodes to form a regional network in the container 10.

The detailed description of the virtual machine migration method of the present invention will be described below with reference to FIGS. 2 and 3. Referring first to FIG. 2, the cloud servo systems 100 and 200 can transmit data through a public network 220. In this embodiment, the cloud server systems 100 and 200 are provided by different vendors, for example, but the invention is not limited thereto.

Wherein a computing node in the cloud server system 200 of the container 210 210 _a running a hypervisor (hypervisor) 27. The hypervisor 27 emulates a virtual machine 25 based on setting information recorded in a configuration file regarding various virtual hardware, virtual firmware, and virtual boot device. Further, hypervisor 27 will emulate virtual machine 25 for guest operating system 23 to operate.

All the nodes in the container 10 of the cloud server system 100 are connected to the area network 130 formed by the switch 30, and the nodes are divided into a service resource pool 110 and a storage resource pool according to their functions. Pool) 120, and a computing resource pool 140. Among them, the nodes belonging to the service resource pool are called service nodes, which can provide various services such as physical installation, record management, or database. In particular, the service node of the present embodiment can be used to migrate virtual machines executing containers of other cloud server systems to the container 10. A node belonging to a computing resource pool is called a computing node and is responsible for various computing operations to produce processing results that are provided to the user terminal. The node belonging to the storage resource pool is called a storage node, and is responsible for the backup or copying of data and the image file and configuration file for storing the virtual machine.

FIG. 3 is a flow chart of a virtual machine migration method according to an embodiment of the invention. Please refer to FIG. 2 and FIG. 3 at the same time. The following are detailed steps to explain how to migrate an existing virtual machine to different cloud servo systems. For convenience of explanation, embodiment-based Suppose you want to run on the computing node _A hypervisor 210 of the present embodiment 27 simulated virtual machine 25, the servo system to migrate from the container 200 of the cloud 210 into the container 100 of the cloud server system 10 performs.

First, as shown in step S310, the container 100 of the cloud server system service nodes 10 110 _a calculation of all the computing nodes in a resource pool 140 is divided into at least one group of computing nodes, wherein each computing node corresponding to one group of lines To a specific hypervisor type. Specifically, the service node 110 _a packet is performed according to the type of running hypervisor of each computing node. For example, compute nodes N ₁₁ through N _1k run the same type of hypervisor and are therefore divided into the same compute node group G ₁ , while compute nodes N _m1 through N _mp are partitioned into the same type of hypervisor The same computing node group G _m (where m, k, p are positive integers). For convenience of explanation, the specific hypervisor types corresponding to the respective calculation of the node groups G ₁ to G _m are hereinafter referred to as hypervisor types T ₁ to T _m .

In step S320, the service node 110a receives the image file and the configuration file corresponding to the existing virtual machine 25, wherein the image file is generated according to the object operating system 23. In the present embodiment, the corresponding virtual machine image file and the configuration file 25 is transmitted by the cloud server system 200 through a public Internet cloud 220 to the service node 100. The servo system 110 _a. Wherein the image file and configuration file are stored in the storage node 120 _a.

Next, as shown in step S330, the service node 110 _a based image file (or image file and a configuration file) to identify the simulated virtual machine hypervisor 25 of type 27. Specifically, since the format of the image file generated by most hypervisors varies with the type of hypervisor, the service node 110a can identify the hyper management according to the content of the header of the image file. The type of the controller 27, for example, identifies the type of hypervisor 27 based on the particular field content in the header of the image file. For another example, if the value of the 4 bytes of the magic field in the header of the image file is 'Q''F''I'fb, then the format of the image file is determined to be qcow, and since KVM is super-managed The image format of the virtual machine supported by the device is qcow, so it can be determined that its super manager is KVM hypervisor. The following table lists the correspondence between several popular hypervisors today and the virtual machine image format they support:

However, because there are several types hypervisor will generate the same image file format, so when not only the type of surplus to correctly identify the manager 27 according to the contents of the file header, the service node 110 _a further analysis of the configuration file Content to identify the type of hypervisor 27. For example, since the XEN hypervisor and hypervisor are KVM support this raw image file format, so if the serving node 110 _a received image file format is such, can not only speed up according to the image file It is explicitly determined that the hypervisor 27 belongs to the XEN hypervisor or the KVM hypervisor. However, since the description of the virtual memory in the configuration file corresponding to the XEN hypervisor and the KVM hypervisor is different, the memory of the size of 512 MB is taken as an example in the configuration file of the XEN hypervisor. Department recorded as "memory = 512", and the KVM hypervisor's configuration file is recorded as "<memory> 512000 </ memory>", so the service node 110 _a can by content analysis configuration file to further The type of hypervisor 27 is identified.

After identifying the type of the hypervisor 27, as shown in step S340, the serving node determines 110 _a particular type of hypervisor ₁ to G _m corresponding to all the respective groups of nodes in G is calculated, and whether there hypervisor 27 A specific hypervisor type of the same type.

Assuming that the type of the hypervisor 27 is the hypervisor type T ₁ which is the same as the specific hypervisor type corresponding to the computing node group G ₁ , the result of the determination in step S340 is YES. Then as shown in step 110 _a service node corresponding to this selected from S350 hypervisor type T computing node group ₁ (i.e., computing node group G1) in a particular computing nodes. And as shown in step S360, the virtual machine 25 is simulated by the particular computing node based on the image file and the configuration file.

For example, if a particular computing node to the computing _{node. 11} N, N due to the operation in the computing node hypervisor and hypervisor ₁₁₂₇ on the same type, and therefore no need to change the image file from the set of computing nodes 210 _a The profile can be simulated directly from the hypervisor running the compute node N ₁₁ according to the configuration file to the same virtual machine as the virtual machine 25, and the image file is deployed to execute the corresponding guest operating system to the compute node N ₁₁ .

Go back to step S340, the specific type if the hypervisor and hypervisor type computing node ₁ of group G 27 to G _m are not the same as the respective corresponding indicating lack of cloud computing in the container 100 of the servo system 10 computing node 210 _a similar run node hypervisor. Since the determination result of step S340 is NO, then as shown in step 110 _a node serving a particular computing node group selected from the group computing node G ₁ to G _m in S370. And in step S380, according to the specific hypervisor type corresponding to the specific computing node group, the equivalent image file and the equivalent configuration file of the image file and the configuration file are respectively generated. Next, as shown in step S390, the computing node 210 _a particular computing node selects a particular computing nodes in the group, and thereby a particular computing node configuration file, though different but equivalent to the analog image file according to the equivalent equivalents The virtual machine of the virtual machine 25.

For example, if a particular computing node group for computing node group G _m, which corresponds to the particular type of hypervisor hypervisor type T _m, the service node 110 _a will be notified in accordance with a configuration file from the computing nodes 210 _a Various virtual environment parameters (eg, virtual hard disk controller, virtual central processing unit, virtual memory, and virtual network interface, etc.) associated with the hypervisor 27 emulating the virtual machine 25, and then information acquisition mode is set belonging to a hypervisor type of hypervisor T _m using the same parameters of the virtual environment to simulate virtual machines should be used, and thus to establish the equivalent configuration file image file information based on these settings. In addition, the service node 110 _a 210 _a node will calculate from the image file format conversion process, thereby generating an equivalent image file. If a particular computing node 110 _a selected service node to the computing node N _m1, N _m1 computing node configuration file will be equivalent in accordance with the virtual machine simulates the equivalent virtual machine 25, and deploy equivalent to the corresponding image file The object operating system is executed at the compute node N _m1 .

In summary, the present invention first determines the type of hypervisor that simulates the virtual machine when it is executed in a container that migrates an existing virtual machine to another cloud server. If the node to be migrated has a node running the same type of hypervisor, the node directly simulates the same virtual environment to execute the guest operating system, thereby avoiding the need to transfer the virtual machine to different hypervisors for execution. Elapsed time to improve the efficiency and quality of the migration virtual machine. However, if there is a lack of nodes running the same type of hypervisor in the container to which the migration is to be made, the virtual machine can still be migrated to different containers equivalently through the conversion of the image file and the configuration file.

Although the present invention has been disclosed in the above embodiments, it is not intended to limit the invention, and any one of ordinary skill in the art can make some modifications and refinements without departing from the spirit and scope of the invention. The scope of the invention is defined by the scope of the appended claims.

100, 200. . . Cloud servo system

10, 210. . . Container

20 ₁ , 20 _n . . . frame

S _1-1 , S _1-2 , S _1-i , S _n-1 , S _nj . . . Slot

N ₁₁₀ , N ₁₁₁ , N ₁₂₀ , N ₁₂₁ , N _1i0 , N _n10 , N _n11 , N _nj0 . . . node

30. . . switch

110. . . Service resource pool

110 _a. . . Service node

120. . . Storage resource pool

120 _a . . . Storage node

130. . . Regional network

140. . . Computing resource pool

G ₁ , G _m . . . Compute node group

N ₁₁ , N _1k , N _m1 , N _mp , 210 _a . . . calculate node

220. . . Public network

twenty three. . . Object operating system

25. . . Virtual machine

27. . . Super manager

S310～S390. . . Steps of the virtual machine migration method described in one embodiment of the present invention

FIG. 1 is a schematic diagram of a cloud servo system according to an embodiment of the invention.

2 is a schematic diagram of a migration virtual machine according to an embodiment of the invention.

FIG. 3 is a flow chart of a virtual machine migration method according to an embodiment of the invention.

S310～S390. . . Steps of the virtual machine migration method described in one embodiment of the present invention

Claims (8)

A virtual machine migration method is used for a cloud server system, the cloud server system includes a container, the container includes a service node, a storage node, and a plurality of computing nodes, and the virtual machine migration method includes: the service node The computing nodes are divided into at least one computing node group, wherein the at least one computing node group is one-to-one corresponding to at least one specific hyper-manager type; receiving, by the serving node, one of the existing virtual machines (virtual machines) An image file and a configuration file, and storing the image file and the configuration file to the storage node; identifying, according to the image file, a type of a hypervisor simulating the virtual machine; determining Whether there is a specific hypervisor type of the same type as the hypervisor in the at least one specific hypervisor type; if so, a compute node corresponding to a specific hypervisor type of the same type as the hypervisor Selecting a specific computing node in the group; the specific computing node simulates the virtual machine according to the image file and the configuration file; if not, And selecting a specific computing node group from the at least one computing node group; generating an image file and an equivalent image file of the configuration file according to the specific hypervisor type corresponding to the specific computing node group An equivalent configuration file; selecting the particular compute node in the particular set of compute nodes; The virtual machine is simulated by the particular computing node based on the equivalent image file and the equivalent configuration file. The virtual machine migration method of claim 1, wherein the step of identifying the type of the hypervisor emulating the virtual machine according to the image file comprises: according to the content of a header of the image file Identify the type of hypervisor. The virtual machine migration method of claim 2, further comprising: if the type of the hypervisor cannot be identified according to the content of the header, analyzing the content of the configuration file to identify the super manager Types of. The virtual machine migration method of claim 1, wherein the image file corresponding to the virtual machine and the configuration file are a second cloud server system transmitted to the cloud through a public network. server system. A cloud server system includes: a container, comprising: a plurality of computing nodes; a storage node coupled to the computing nodes through a regional network; and a service node coupled to the computing nodes through the regional network The storage node, wherein the service node divides the computing nodes into at least one computing node group, and the at least one computing node group corresponds to at least one specific hypervisor type one-to-one; The service node receives an image file and a configuration file corresponding to one of the existing virtual machines, and stores the image file and the configuration file in the storage node, and identifies one of the virtual machines according to the image file. a type of hypervisor, and determining whether a specific hypervisor type of the same type as the hypervisor exists in the at least one specific hypervisor type, and if so, the service node is of the same type as the hypervisor Selecting a specific computing node from the group of computing nodes corresponding to the specific hypervisor type and simulating the virtual machine according to the image file and the configuration file by the specific computing node, if not in the at least one specific hypervisor type There is a specific hypervisor type of the same type as the hypervisor, the service node selects a specific group of computing nodes from the at least one group of computing nodes, and according to the specific super management corresponding to the specific computing node group The device type respectively generates an image file and an equivalent image file of the configuration file and an equivalent configuration file, and selects the specific in the specific computing node group Node count by the particular computing node profile based on the simulation of the virtual machine image files equivalent to the equivalent configuration. The cloud server system of claim 5, wherein the service node identifies the type of the hypervisor according to the content of the header of the image file. The cloud server system of claim 6, wherein if the service node cannot identify the type of the hypervisor according to the content of the header, analyzing the content of the configuration file to identify the hypervisor Types of. The cloud server system of claim 5, wherein the image file corresponding to the virtual machine and the configuration file are a second cloud server. The service system is transmitted to the cloud servo system via a public network.