CN115167988A - Virtual machine live migration method and device, electronic equipment and storage medium - Google Patents

Abstract

The disclosure provides a virtual machine live migration method, and relates to the field of finance. The method comprises the following steps: if the types of the source middleware and the target middleware are different, executing the following operations to migrate the source virtual machine with the running state to the target host: transforming a data store of the source virtual machine to adapt to the type of the target middleware, the data store including source middleware configuration data and application storage data; starting the target middleware at the target host according to the converted data storage; transferring the memory of the source virtual machine to the target host; and enabling the memory of the virtual machine referenced by the target middleware to point to the memory of the source virtual machine. The present disclosure also provides a virtual machine live migration apparatus, device, storage medium, and program product.

Description

Virtual machine live migration method and device, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of finance, and more particularly, to a virtual machine live migration method, apparatus, device, medium, and program product.

Background

The virtual machine live migration refers to a process of migrating a running virtual machine from one host to another host, wherein services are not interrupted in the migration process, and a user does not perceive the virtual machine. The storage and memory of a target host aiming at the existing virtual machine hot migration technology are basically consistent with those of a source host, and the type of the middleware is also consistent. Existing methods of migration across middleware types typically do cold migration, such as manually modifying a configuration file on an interface or directly, or configuring and deploying by executing automation scripts using command line tools provided by the middleware product.

Disclosure of Invention

In carrying out the inventive concept of the present disclosure, the inventors have found that there are at least the following problems in the related art:

the virtual machine migration method in the related art cannot achieve the purpose of smoothness and imperceptibility to a user, that is, cannot achieve the cross-middleware type hot migration effect.

In view of the above-mentioned problem in the related art that the migration method cannot implement the live migration, a live migration method, apparatus, device, medium, and program product for a stateful virtual machine across middleware types are provided.

One aspect of the disclosed embodiments provides a virtual machine live migration method, where a source middleware and a target middleware are Web application servers in a source host and a target host, respectively, and the source middleware is installed on a source virtual machine in the source host, the method including: if the type of the source middleware is different from that of the target middleware, executing the following operations to migrate the source virtual machine with the running state to the target host: transforming a data store of the source virtual machine to adapt to the type of the target middleware, the data store including source middleware configuration data and application storage data; according to the converted data storage, starting the target middleware at the target host; transmitting the memory of the source virtual machine to the target host; and enabling the memory of the virtual machine referenced by the target middleware to point to the memory of the source virtual machine.

According to an embodiment of the present disclosure, the converting the data storage of the source virtual machine to adapt to the type of the target middleware includes: extracting information to be converted in the data storage of the source virtual machine according to the type of the source middleware; writing the information to be converted into a universal template; and extracting the information to be converted from the universal template for conversion according to the type of the target middleware.

According to an embodiment of the present disclosure, after extracting the information to be converted from the generic template for conversion, the method further includes: mounting the storage of the source virtual machine to the target host, wherein the storage of the source virtual machine comprises the converted data storage; the source host and the target host are made to share the storage of the source virtual machine.

According to an embodiment of the present disclosure, the starting the target middleware at the target host includes: and enabling the memory of the target middleware during the running to use the memory of the target middleware during the starting.

According to an embodiment of the present disclosure, the causing the memory of the virtual machine referenced by the target middleware to point to the memory of the source virtual machine includes: and enabling the memory of the source virtual machine to cover the memory of the virtual machine quoted by the target middleware.

According to an embodiment of the present disclosure, the transferring the memory of the source virtual machine to the target host includes: transferring the memory of the source virtual machine to a first memory space of the target host; the causing the virtual machine memory referenced by the target middleware to point to the memory of the source virtual machine comprises: and modifying the memory of the virtual machine referenced by the target middleware to point to the memory of the source virtual machine in the first memory space.

According to an embodiment of the present disclosure, before migrating the source virtual machine having an on-the-fly state to the target host, the method further comprises: respectively acquiring a first installation path of the source middleware and a second installation path of the target middleware; determining the type of the source middleware according to the first installation path, and determining the type of the target middleware according to the second installation path; and comparing the types of the source middleware and the target middleware.

Another aspect of the disclosed embodiments provides a virtual machine live migration apparatus, where a source middleware and a target middleware are Web application servers in a source host and a target host, respectively, the source middleware is installed on a source virtual machine in the source host, the apparatus is configured to migrate the source virtual machine having an operating state to the target host when types of the source middleware and the target middleware are different, and the apparatus includes: a data conversion module for converting a data store of the source virtual machine to adapt to the type of the target middleware, the data store including source middleware configuration data and application storage data; the middleware starting module is used for starting the target middleware at the target host according to the converted data storage; the memory transfer module is used for transferring the memory of the source virtual machine to the target host; and the memory reference module is used for enabling the memory of the virtual machine referenced by the target middleware to point to the memory of the source virtual machine.

According to an embodiment of the present disclosure, the virtual machine live migration apparatus includes modules respectively configured to perform the steps of the method described in any one of the above.

Another aspect of the disclosed embodiments provides an electronic device, including: one or more processors; a storage device to store one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method as described above.

Yet another aspect of the embodiments of the present disclosure provides a computer-readable storage medium having stored thereon executable instructions, which when executed by a processor, cause the processor to perform the method as described above.

Yet another aspect of the disclosed embodiments provides a computer program product comprising a computer program that when executed by a processor implements the method as described above.

One or more of the above embodiments have the following advantageous effects: based on the different types of the source middleware and the target middleware, the data storage of the source virtual machine is converted to adapt to the type of the target middleware, and then the target middleware can be started at the target host according to the converted data storage. After the memory of the source virtual machine is transferred to the target host machine, the memory of the virtual machine referenced by the target middleware points to the memory of the source virtual machine. Therefore, the purpose of cross-middleware hot migration is achieved by combining the process of cross-middleware conversion, application interruption is not required to be arranged for planned server maintenance, the virtual machine can be migrated in real time under the condition that the use of a user is not influenced, the service program can still run smoothly in the migration process, and the high availability ratio is improved.

Drawings

The foregoing and other objects, features and advantages of the disclosure will be apparent from the following description of embodiments of the disclosure, which proceeds with reference to the accompanying drawings, in which:

fig. 1 schematically illustrates an application scenario diagram of a virtual machine live migration method according to an embodiment of the present disclosure;

FIG. 2 schematically illustrates a flow diagram of a virtual machine live migration method according to an embodiment of the present disclosure;

FIG. 3 schematically illustrates a flow diagram of a comparison middleware type according to an embodiment of the present disclosure;

FIG. 4 schematically illustrates a flow diagram for converting data storage according to an embodiment of the disclosure;

FIG. 5 schematically illustrates a flow diagram for a source host sharing storage with a target host according to an embodiment of the disclosure;

FIG. 6 schematically illustrates a flow diagram for modifying virtual machine memory pointing of target middleware references, according to an embodiment of the disclosure;

FIG. 7 schematically illustrates a flow diagram of a virtual machine live migration method according to another embodiment of the present disclosure;

FIG. 8 is a block diagram schematically illustrating a configuration of a virtual machine live migration apparatus according to an embodiment of the present disclosure; and

fig. 9 schematically illustrates a block diagram of an electronic device adapted to implement a virtual machine live migration method according to an embodiment of the present disclosure.

Detailed Description

In order to facilitate understanding of technical solutions of the embodiments of the present application, some technical terms related to the present application are first described.

Java Virtual Machine (JVM): the Java language runtime environment is created and runs management by the JVM.

Live Migration (Live Migration): also called dynamic migration and real-time migration, that is, virtual machine storage/recovery, generally stores the running state of the entire virtual machine completely, and can be quickly recovered to the original hardware platform or even different hardware platforms. After recovery, the virtual machine is still running smoothly and the user does not perceive any differences.

A middleware: i.e., the Web application server, is the product of the combination of the Web server and the application server. The application server middleware is a software infrastructure, integrates application software into a certain cooperative work environment by using a component technology, and provides a plurality of communication mechanisms, transaction processing capability and development management functions of applications. The development of three-layer or multi-layer application systems is directly supported, and the J2EE architecture is a mainstream standard in the aspect of application servers.

Data storage: refers to both middleware configuration files (including middleware configuration data) and application files (including application storage data).

Storage of the source virtual machine: the method refers to allocating storage space in a disk (or a data storage carrier such as a database, a hard disk, or the like) for a source virtual machine based on the disk of a source host.

Sharing storage: both the source host and the target host can access the disk (or data storage carrier such as a database and a hard disk) of the virtual machine, namely, the data storage in the disk of the virtual machine is simultaneously associated to the source host and the target host.

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that these descriptions are illustrative only and are not intended to limit the scope of the present disclosure. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the disclosure. It may be evident, however, that one or more embodiments may be practiced without these specific details. Moreover, in the following description, descriptions of well-known structures and techniques are omitted so as to not unnecessarily obscure the concepts of the present disclosure.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The terms "comprises," "comprising," and the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.

All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It is noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of this specification and should not be interpreted in an idealized or overly formal sense.

Where a convention analogous to "A, B and at least one of C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include, but not be limited to, systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.).

It should be noted that, the virtual machine live migration method, apparatus, device, medium, and program product in the embodiments of the present disclosure may be used in the financial field, and may also be used in any field other than the financial field.

Fig. 1 schematically illustrates an application scenario diagram of a virtual machine live migration method according to an embodiment of the present disclosure.

As shown in fig. 1, the application scenario 100 according to this embodiment may include a source host 110 and a target host 120. Source host 110 and target host 120 may be virtual hosts or physical hosts. A source virtual machine is installed in the source host, and a Web application server is installed in the source virtual machine to deploy an application to provide application service for a user. To implement the migration across the middleware types, the whole machine can be subjected to live migration, that is, both the data storage and the virtual machine memory need to be subjected to live migration, for example, the source virtual machine JVM memory (i.e., the memory of the source virtual machine), the source middleware configuration, and the application file (i.e., the data storage) in fig. 1.

Illustratively, the source host and the target host may be in the same cluster (e.g., a server cluster) or across clusters before migration is initiated. The source host and the target host may use the same shared storage (e.g., the same disk space). The state of the source virtual machine is running. The network of the source host and the network of the target host are intercommunicated, namely, the uplink of the distributed switch in which the port group to which the virtual machine network card belongs is simultaneously associated to the source host and the target host.

The virtual machine live migration method according to the embodiment of the present disclosure will be described in detail below with reference to fig. 2 to 7 based on the scenario described in fig. 1.

Fig. 2 schematically shows a flowchart of a virtual machine live migration method according to an embodiment of the present disclosure.

The source middleware and the target middleware are respectively Web application servers in a source host and a target host, the source middleware is installed on a source virtual machine in the source host, and if the types of the source middleware and the target middleware are different, as shown in fig. 2, operations S210 to S240 are performed to migrate the source virtual machine having a running state to the target host.

In operation S210, a data store of the source virtual machine is transformed to adapt to a type of the target middleware, the data store including source middleware configuration data and application storage data.

Illustratively, the virtual machine may be a JVM virtual machine, a KVM virtual machine, or a VMware virtual machine, among others. The type of middleware is the type of Web application server, such as Apache, nginx, jboss, tomcat, and so on. The source middleware can be deployed with an application program, and a user can generate application storage data in the process of using the application program. The source middleware configuration data is configured for the source middleware to operate normally, and the configuration data of different middleware types and the content or data format of the application storage data may be different. Thus, the purpose of the transformation data store is to transform configuration data and application store data generated under the type of source middleware (e.g., nginx) into data that can be used by the target middleware (e.g., tomcat).

In operation S220, target middleware is started at the target host according to the converted data storage.

Illustratively, the converted application storage data can be adapted to the type of the target middleware, and can be used as a target middleware start reference.

In operation S230, the memory of the source virtual machine is transferred to the target host.

Illustratively, the memory of the source virtual machine comprises data in a memory space allocated for the source virtual machine, wherein the memory of the source virtual machine is used in the running process of the application program. The transferring may include synchronizing data in the memory before the migration begins and the memory written after the migration begins to the target host.

Memory transfers may be implemented using iterative migration and memory fragmentation techniques. Iterative migration refers to a process of multiple migrations in a manner similar to the iterative updating of an application. The memory fragmentation means: for the first memory fragment, the memory used at the time point is locked as the read-only permission at the moment when the migration starts, and a new memory space is opened up for writing new data, wherein the permission is read-write. For the second memory fragment, after the memory migration before the migration is started is completed, the first memory fragment is locked as a read-only memory, and then the second memory fragment is created to write new data, wherein the authority is read-write. And suspending data until the last memory slice is very small, and migrating the last memory slice. And finally, the service mapping is changed to the new virtual machine.

In operation S240, the virtual machine memory referenced by the target middleware is made to point to the memory of the source virtual machine.

Illustratively, based on a complete machine live migration mode, application storage data after the target middleware is started and a referenced virtual machine memory come from a source virtual machine, so that live migration of a cross-middleware type with a state can be realized, and a user does not feel.

According to the embodiment of the disclosure, the purpose of cross-middleware live migration is realized by combining the process of cross-middleware conversion, application interruption is not required to be arranged for planned server maintenance, and the virtual machine can be migrated in real time under the condition of not influencing the use of a user, so that a service program can still run smoothly in the migration process, and the high availability is improved.

FIG. 3 schematically shows a flow diagram of a comparison middleware type according to an embodiment of the present disclosure.

Before migrating the source virtual machine with the running state to the target host, as shown in fig. 3, comparing the middleware types to identify whether the source middleware and the target middleware are the same in type may include operations S310 to S330.

In operation S310, a first installation path of a source middleware and a second installation path of a target middleware are respectively obtained.

In operation S320, a type of the source middleware is determined according to the first installation path, and a type of the target middleware is determined according to the second installation path.

For example, if source middleware and target middleware are already installed on storage (e.g., disk), the middleware type and version can be identified at the corresponding middleware installation path.

In operation S330, the types of the source middleware and the target middleware are compared.

Illustratively, if the source middleware and the target middleware are the same type, the live migration technique already existing in the related art is used, and if the source middleware and the target middleware are different types, operations S210 to S240 are performed.

According to the embodiment of the disclosure, the type of the middleware is automatically identified, the corresponding hot migration technology can be flexibly selected, and the user experience and the migration efficiency are improved.

FIG. 4 schematically shows a flow diagram for converting data storage according to an embodiment of the disclosure.

As shown in fig. 4, converting the data storage of the source virtual machine to adapt to the type of the target middleware in operation S210 includes operations S410 to S430.

In operation S410, information to be converted in a data storage of the source virtual machine is extracted according to the type of the source middleware.

Illustratively, the information to be converted may include source middleware configuration data and/or application storage data, such as one or more of log configuration, jvm parameter configuration, HTTP channel thread pool, data source configuration, and application deployment configuration.

In operation S420, information to be converted is written in the universal template.

Illustratively, the generic template serves as a transit file for both middleware types. For example, a data store from the source virtual machine may be parsed to extract key information and written to the generic template in the form of key-value pairs (by way of example only).

In operation S430, information to be converted is extracted from the generic template for conversion according to the type of the target middleware.

Illustratively, the information to be converted is extracted from the generic template, and a new data store, such as middleware configuration data and application storage data adapted to the type of the target middleware, is generated according to the data store format of the target middleware.

According to the embodiment of the disclosure, the types of the Web application servers are various, a mode of using a universal template as a transfer file can be applied to data storage conversion between any two types, the application range is wide, and the method has higher convenience and conversion efficiency.

FIG. 5 schematically shows a flow diagram for a source host sharing storage with a target host, according to an embodiment of the disclosure.

After extracting information to be converted from the common template for conversion, as shown in fig. 5, the source host and the target host sharing storage of the embodiment includes operations S510 to S520.

In operation S510, mount the storage of the source virtual machine to the target host, where the storage of the source virtual machine includes the converted data storage.

Illustratively, the storage of the source virtual machine may be a disk of the source virtual machine with the translated source middleware configuration data and application storage data in the disk.

In operation S520, the source host and the target host are caused to share storage of the source virtual machine.

According to an embodiment of the present disclosure, the target host may access the translated source middleware configuration data and application storage data, such that the target middleware may be launched at the target host.

According to an embodiment of the present disclosure, the starting of the target middleware at the target host in operation S220 includes: and enabling the memory of the target middleware to use the memory of the target middleware during starting.

Illustratively, the middleware memory is distinct from the application memory (i.e., virtual machine memory) for use by the middleware runtime. The target middleware server program (e.g., tomcat server program) may allocate memory for it at the target host when it is started.

In some embodiments, causing the virtual machine memory referenced by the target middleware to point to the memory of the source virtual machine in operation S240 includes: and enabling the memory of the source virtual machine to cover the memory of the virtual machine quoted by the target middleware.

Illustratively, according to the memory of the virtual machine referenced by the target middleware, the memory data in the memory of the source virtual machine is used for covering the memory data, for example, covering is performed based on a memory fragmentation technology, so as to achieve an effect that the target middleware can access the memory of the source virtual machine.

According to the embodiment of the disclosure, the target middleware refers to the memory of the source virtual machine in a covering mode, so that the application memory state in the running of the target host is ensured to be consistent with that of the source host, and the purpose of hot migration is achieved.

In other embodiments, the virtual machine memory referenced by the target middleware may be pointed to the memory of the source virtual machine according to the following contents shown in fig. 6.

FIG. 6 schematically illustrates a flow diagram for modifying virtual machine memory references referenced by target middleware in accordance with an embodiment of the disclosure.

As shown in fig. 6, the virtual machine memory reference of the modification target middleware of this embodiment includes operations S610 to S620. Operation S610 is one of the embodiments of operation S230, and operation S620 is one of the embodiments of operation S240.

In operation S610, a memory of a source virtual machine is transferred to a first memory space of a target host.

For example, when transferring the memory of the source virtual machine, a new memory space may be opened up as the first memory space at the target host to accommodate the memory data in the memory of the source virtual machine.

In operation S620, the virtual machine memory referenced by the target middleware is modified to point to the memory of the source virtual machine in the first memory space.

For example, the virtual machine memory referenced when the target middleware is started points to the second memory space, or the virtual machine memory referenced when the target middleware is started is empty. In the process of transferring the memory fragmentation of the source virtual machine or after the memory of the source virtual machine is transferred, the direction of the memory of the virtual machine quoted by the target middleware is modified, and the memory of the source virtual machine quoted by the target middleware is enabled.

According to the embodiment of the disclosure, the target middleware refers to the memory of the source virtual machine by modifying the reference mode, so that the application memory state in the running of the target host is ensured to be consistent with that of the source host, and the purpose of hot migration is achieved.

FIG. 7 schematically shows a flowchart of a virtual machine live migration method according to another embodiment of the present disclosure.

As shown in fig. 7, the virtual machine live migration method of this embodiment includes operations S701 to S713.

In operation S701, a connection is established between a source host and a target host: the network intercommunication of the source host and the target host is that the uplink of the distributed switch where the port group to which the virtual machine network card belongs is associated to the source host and the target host at the same time.

In operation S702, the virtual machine configuration and device information is transmitted: the part carries the information in the registry, informs the target server of the resources required by the virtual machine, and allocates the required resources.

In operation S703, source host and target host middleware types are identified: source host middleware and target host middleware are installed on the storage, and the type and version of the middleware are identified in a middleware installation path.

In operation S704, the copy application stores data: a copy of the application data file is used as a target middleware start reference.

In operation S705, it is determined whether the source host middleware and the target host middleware are the same in type, and if they are the same, no conversion storage is needed, and operation S711 is performed by using the existing virtual machine live migration technique to directly perform the complete machine migration. If not, the storage needs to be converted, and operation S706 is performed.

In operation S706, the middleware configuration data and the application storage data, for example, include the data copied in operation S704.

In operation S707, the notification storage mounts the storage to the target server: to start the middleware server at the target host, the storage needs to be mounted to the target host while the source host still shares the storage.

In operation S708, the target host middleware service is launched: the memory used when the middleware server program starts up is used as the memory when the middleware runs.

In operation S709, the source virtual machine JVM memory is transferred using iterative migration and memory fragmentation techniques. The JVM virtual machine used herein is an example only.

In operation S710, the segment of the change of the memory data of the virtual machine JVM is overwritten, and the operation is ended.

Illustratively, operation S709 and operation S710 may be performed synchronously in a process using the iterative migration and memory fragmentation techniques.

In operation S711, the JVM memory referenced by the modified middleware memory points to the JVM memory migrated in the previous step, and the operation is ended.

In some embodiments, operation S710 may be performed first, and then operation S711 may be performed, and the modification operation may be performed after the overlay is completed. In some embodiments, operations S710 and S711 may be two parallel schemes of selecting one. The implementation in the above embodiment can be flexibly selected according to the functions supported by the type of the target middleware.

In operation S712, if the middleware type is the same, the storage is directly notified to mount the storage to the target host.

In operation S713, the source vm memory change segment is directly transferred (without memory change), and the operation ends.

According to the embodiment of the disclosure, the application server can be automatically migrated across middleware types, and the trouble caused by manual configuration errors is avoided. The purpose of cross-middleware live migration is achieved by utilizing a virtual machine live migration technology and combining a cross-middleware conversion process, so that a service program can still run smoothly in the migration process, and the high availability is improved.

Based on the virtual machine live migration method, the disclosure also provides a virtual machine live migration device. The apparatus will be described in detail below with reference to fig. 8.

Fig. 8 schematically shows a block diagram of a virtual machine live migration apparatus according to an embodiment of the present disclosure.

The apparatus is configured to migrate a source virtual machine having an operating state to a target host when types of source middleware and target middleware are different, as shown in fig. 8, a virtual machine live migration apparatus 800 of this embodiment includes a data conversion module 810, a middleware start module 820, a memory transfer module 830, and a memory reference module 840.

The data conversion module 810 may perform operation S210 for converting a data storage of the source virtual machine to adapt to a type of the target middleware, the data storage including source middleware configuration data and application storage data.

For example, the data conversion module 810 may perform operations S410 to S430, which are not described herein.

The middleware starting module 820 may perform operation S220 for starting the target middleware at the target host according to the converted data storage.

The memory transfer module 830 may perform operation S230 for transferring the memory of the source virtual machine to the target host.

For example, the memory transfer module 830 may perform operations S610 through S620, which are not described herein.

The memory reference module 840 may perform operation S240 for pointing the virtual machine memory referenced by the target middleware to the memory of the source virtual machine.

Virtual machine live migration apparatus 800 may include modules for performing the steps of any one of the embodiments described above with respect to fig. 2-7, respectively.

For example, the virtual machine live migration apparatus 800 includes a type comparison module, which is configured to perform operations S310 to S330, and is not described herein again.

For example, the virtual machine live migration apparatus 800 includes a shared storage module, which is configured to perform operations S310 to S330, and is not described herein again.

It should be noted that the implementation, solved technical problems, implemented functions, and achieved technical effects of each module/unit/subunit and the like in the apparatus part embodiment are respectively the same as or similar to the implementation, solved technical problems, implemented functions, and achieved technical effects of each corresponding step in the method part embodiment, and are not described herein again.

According to an embodiment of the present disclosure, any plurality of the data conversion module 810, the middleware start module 820, the memory transfer module 830, and the memory reference module 840 may be combined into one module to be implemented, or any one of them may be split into a plurality of modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in one module.

According to an embodiment of the present disclosure, at least one of the data conversion module 810, the middleware activation module 820, the memory transfer module 830, and the memory reference module 840 may be implemented at least partially as a hardware circuit, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a system on a chip, a system on a substrate, a system on a package, an Application Specific Integrated Circuit (ASIC), or may be implemented in hardware or firmware in any other reasonable manner of integrating or packaging a circuit, or may be implemented in any one of three implementations of software, hardware, and firmware, or in a suitable combination of any of them. Alternatively, at least one of the data conversion module 810, the middleware activation module 820, the memory transfer module 830, and the memory reference module 840 may be implemented at least in part as a computer program module that, when executed, may perform a corresponding function.

Fig. 9 schematically illustrates a block diagram of an electronic device adapted to implement a virtual machine live migration method according to an embodiment of the present disclosure.

As shown in fig. 9, an electronic apparatus 900 according to an embodiment of the present disclosure includes a processor 901 which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM) 902 or a program loaded from a storage portion 908 into a Random Access Memory (RAM) 903. Processor 901 may comprise, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor and/or associated chipset, and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), among others. The processor 901 may also include on-board memory for caching purposes. The processor 901 may comprise a single processing unit or a plurality of processing units for performing the different actions of the method flows according to embodiments of the present disclosure.

In the RAM 903, various programs and data necessary for the operation of the electronic apparatus 900 are stored. The processor 901, ROM 902, and RAM 903 are connected to each other by a bus 904. The processor 901 performs various operations of the method flows according to the embodiments of the present disclosure by executing programs in the ROM 902 and/or the RAM 903. Note that the program may also be stored in one or more memories other than the ROM 902 and the RAM 903. The processor 901 may also perform various operations of the method flows according to embodiments of the present disclosure by executing programs stored in the one or more memories.

Electronic device 900 may also include input/output (I/O) interface 905, input/output (I/O) interface 905 also connected to bus 904, according to an embodiment of the present disclosure. The electronic device 900 may also include one or more of the following components connected to the I/O interface 905: an input section 906 including a keyboard, mouse, and the like. Including an output portion 907 such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker and the like. A storage section 908 including a hard disk and the like. And a communication section 909 including a network interface card such as a LAN card, a modem, or the like. The communication section 909 performs communication processing via a network such as the internet. The drive 910 is also connected to the I/O interface 905 as necessary. A removable medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 910 as necessary so that a computer program read out therefrom is mounted into the storage section 908 as necessary.

The present disclosure also provides a computer-readable storage medium, which may be embodied in the devices/apparatuses/systems described in the above embodiments. Or may exist separately and not be assembled into the device/apparatus/system. The computer-readable storage medium carries one or more programs which, when executed, implement a method according to an embodiment of the disclosure.

According to embodiments of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example but is not limited to: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, according to embodiments of the present disclosure, a computer-readable storage medium may include the ROM 902 and/or the RAM 903 described above and/or one or more memories other than the ROM 902 and the RAM 903.

Embodiments of the present disclosure also include a computer program product comprising a computer program containing program code for performing the method illustrated by the flow chart. When the computer program product runs in a computer system, the program code is used for causing the computer system to realize the method provided by the embodiment of the disclosure.

The computer program performs the above-described functions defined in the system/apparatus of the embodiments of the present disclosure when executed by the processor 901. The systems, apparatuses, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the present disclosure.

In one embodiment, the computer program may be hosted on a tangible storage medium such as an optical storage device, a magnetic storage device, or the like. In another embodiment, the computer program may also be transmitted in the form of a signal over a network medium, distributed, and downloaded and installed via the communication section 909 and/or installed from the removable medium 911. The computer program containing program code may be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 909, and/or installed from the removable medium 911. The computer program, when executed by the processor 901, performs the above-described functions defined in the system of the embodiment of the present disclosure. The above described systems, devices, apparatuses, modules, units, etc. may be implemented by computer program modules according to embodiments of the present disclosure.

In accordance with embodiments of the present disclosure, program code for executing computer programs provided by embodiments of the present disclosure may be written in any combination of one or more programming languages, and in particular, these computer programs may be implemented using high level procedural and/or object oriented programming languages, and/or assembly/machine languages. The programming language includes, but is not limited to, programming languages such as Java, C + +, python, the "C" language, or the like. The program code may execute entirely on the user computing device, partly on the user device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Those skilled in the art will appreciate that various combinations and/or combinations of features recited in the various embodiments and/or claims of the present disclosure can be made, even if such combinations or combinations are not expressly recited in the present disclosure. In particular, various combinations and/or combinations of the features recited in the various embodiments of the present disclosure and/or the claims may be made without departing from the spirit and teachings of the present disclosure. All such combinations and/or associations are within the scope of the present disclosure.

The embodiments of the present disclosure are described above. However, these examples are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although the embodiments are described separately above, this does not mean that the measures in the embodiments cannot be used in advantageous combination. The scope of the disclosure is defined by the appended claims and equivalents thereof. Various alternatives and modifications can be devised by those skilled in the art without departing from the scope of the present disclosure, and such alternatives and modifications are intended to be within the scope of the present disclosure.

Claims (11)

1. A virtual machine hot migration method, wherein source middleware and target middleware are Web application servers in a source host and a target host respectively, the source middleware is installed on a source virtual machine in the source host, and the method comprises the following steps:

if the types of the source middleware and the target middleware are different, executing the following operations to migrate the source virtual machine with the running state to the target host:

transforming a data store of the source virtual machine to adapt to the type of the target middleware, the data store including source middleware configuration data and application storage data;

starting the target middleware at the target host according to the converted data storage;

transmitting the memory of the source virtual machine to the target host;

and enabling the memory of the virtual machine referenced by the target middleware to point to the memory of the source virtual machine.

2. The method of claim 1, wherein the transforming the data store of the source virtual machine to adapt to the type of the target middleware comprises:

extracting information to be converted in the data storage of the source virtual machine according to the type of the source middleware;

writing the information to be converted into a universal template;

and extracting the information to be converted from the universal template for conversion according to the type of the target middleware.

3. The method of claim 2, wherein after extracting the information to be converted from the generic template for conversion, the method further comprises:

mounting the storage of the source virtual machine to the target host, wherein the storage of the source virtual machine comprises the converted data storage;

the source host and the target host are made to share the storage of the source virtual machine.

4. The method of claim 1, wherein the initiating the target middleware at the target host comprises:

and enabling the memory of the target middleware during the running to use the memory of the target middleware during the starting.

5. The method of claim 4, wherein the directing the virtual machine memory referenced by the target middleware to the memory of the source virtual machine comprises:

and enabling the memory of the source virtual machine to cover the memory of the virtual machine quoted by the target middleware.

6. The method of claim 4, wherein:

the transferring the memory of the source virtual machine to the target host comprises:

transferring the memory of the source virtual machine to a first memory space of the target host;

the causing the virtual machine memory referenced by the target middleware to point to the memory of the source virtual machine comprises:

and modifying the memory of the virtual machine referenced by the target middleware to point to the memory of the source virtual machine in the first memory space.

7. The method of claim 1, wherein prior to migrating the source virtual machine having an on-the-fly state to the target host, the method further comprises:

respectively acquiring a first installation path of the source middleware and a second installation path of the target middleware;

determining the type of the source middleware according to the first installation path, and determining the type of the target middleware according to the second installation path;

and comparing the types of the source middleware and the target middleware.

8. A virtual machine live migration apparatus, wherein source middleware and target middleware are Web application servers in a source host and a target host, respectively, the source middleware is installed on a source virtual machine in the source host, the apparatus is configured to migrate the source virtual machine having an in-operation state to the target host when types of the source middleware and the target middleware are different, the apparatus comprising:

a data conversion module for converting a data store of the source virtual machine to adapt to a type of the target middleware, the data store including source middleware configuration data and application storage data;

the middleware starting module is used for starting the target middleware at the target host according to the converted data storage;

the memory transfer module is used for transferring the memory of the source virtual machine to the target host;

and the memory reference module is used for enabling the memory of the virtual machine referenced by the target middleware to point to the memory of the source virtual machine.

9. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method recited in any of claims 1-7.

10. A computer readable storage medium having stored thereon executable instructions which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

11. A computer program product comprising a computer program which, when executed by a processor, carries out the method according to any one of claims 1 to 7.

Images