CN114020419A

CN114020419A - Virtual machine startup method and device, electronic device, and storage medium

Info

Publication number: CN114020419A
Application number: CN202111452445.XA
Authority: CN
Inventors: 张严
Original assignee: Beijing Topsec Technology Co Ltd; Beijing Topsec Network Security Technology Co Ltd; Beijing Topsec Software Co Ltd
Current assignee: Beijing Topsec Technology Co Ltd; Beijing Topsec Network Security Technology Co Ltd; Beijing Topsec Software Co Ltd
Priority date: 2021-12-01
Filing date: 2021-12-01
Publication date: 2022-02-08

Abstract

The present application provides a method and apparatus for starting a virtual machine, an electronic device, and a computer-readable storage medium. The method includes: in response to a virtual machine starting instruction, determining multiple target virtual machines indicated by the virtual machine starting instruction; asynchronously loading all the target virtual machines. metadata corresponding to the multiple target virtual machines; after the metadata of any target virtual machine is loaded, the target virtual machine is started based on the loaded metadata. In the solution of the present application, the metadata of each target virtual machine is loaded by the asynchronous loading mechanism, which can avoid the blocking caused by loading the metadata of all the target virtual machines at the same time. After the metadata of any target virtual machine is loaded, the target virtual machine is started, thereby The startup timing of each target virtual machine is staggered, which improves the startup speed as a whole.

Description

Virtual machine starting method and device, electronic equipment and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for starting a virtual machine, an electronic device, and a computer-readable storage medium.

Background

The virtual machine of the super-fusion platform needs to consume too long time for starting, and an improvement scheme is urgently needed. In the scheme of the openstack architecture, a ceph system is selected as a rear-end storage component of a Nova module of the openstack, so that the read-write speed of a disk is increased. The Nova module generates a snapshot (snapshot) based on an image file of a virtual machine in a ceph image resource pool (ceph images pool), copies the snapshot (copy on write) to the ceph instances pool as a system disk, and starts the virtual machine with the system disk. However, the above scheme is only applicable to openstack architecture, and is not applicable to super-fusion architecture.

Disclosure of Invention

An object of the embodiment of the present application is to provide a method and an apparatus for starting a virtual machine, an electronic device, and a computer-readable storage medium, which are used for implementing fast start of a virtual machine on a hyper-convergence platform.

In one aspect, the present application provides a method for starting a virtual machine, including:

in response to a virtual machine starting instruction, determining a plurality of target virtual machines indicated by the virtual machine starting instruction;

asynchronously loading metadata corresponding to the plurality of target virtual machines;

after the metadata of any target virtual machine is loaded, starting the target virtual machine based on the loaded metadata.

In an embodiment, before the asynchronously loading the metadata corresponding to the plurality of target virtual machines, the method further comprises:

checking whether a preset node list is empty, if not, selecting a plurality of target nodes from a plurality of available nodes recorded in the node list; the target node is used for running the target virtual machine;

the asynchronously loading metadata corresponding to the plurality of target virtual machines includes:

and asynchronously loading metadata corresponding to the target virtual machines through the target nodes.

In an embodiment, the method further comprises:

if the node list is empty, determining a plurality of available nodes from a back-end cluster, and writing the available nodes into the node list;

the step of selecting a number of target nodes from a number of available nodes recorded by the node list is performed.

In an embodiment, a plurality of available nodes in the node list carry designation marks, where the designation marks indicate that the available nodes are target nodes when a virtual machine is started last time;

the selecting a plurality of target nodes from a plurality of available nodes recorded by the node list comprises:

and if the target virtual machines are the virtual machines started last time, using the available nodes carrying the specified marks as target nodes.

In one embodiment, the asynchronously loading metadata corresponding to the plurality of target virtual machines includes:

respectively allocating corresponding timers for the virtual disks of each target virtual machine; the callback time of the plurality of timers is different;

and responding to a callback event triggered by any timer, and loading metadata from the virtual disk corresponding to the timer.

In one embodiment, the timer periodically triggers the callback event;

the loading metadata from the virtual disk corresponding to the timer includes:

and loading metadata from the virtual disk corresponding to the timer according to a preset loading progress strategy.

In an embodiment, before the loading the metadata from the virtual disk corresponding to the timer, the method further includes:

and judging whether a loading limiting condition is met, if so, executing the step of loading the metadata from the virtual disk corresponding to the timer.

In an embodiment, the method further comprises:

and acquiring console information of each target virtual machine, and returning the console information to front-end equipment, so that the front-end equipment establishes VNC connection with the started target virtual machine based on the console information.

In an embodiment, the obtaining console information of each target virtual machine includes:

if any target virtual machine is located locally, calling a local specified interface to obtain the console information;

if any target virtual machine is located at other target nodes, calling the designated interfaces of other target nodes through a remote process to obtain the console information.

In another aspect, the present application provides a virtual machine starting apparatus, including:

the determining module is used for responding to a virtual machine starting instruction and determining a plurality of target virtual machines indicated by the virtual machine starting instruction;

the loading module is used for asynchronously loading the metadata corresponding to the target virtual machines;

and the starting module is used for starting the target virtual machine based on the loaded metadata after the metadata of any target virtual machine is loaded.

In addition, the present application also provides an electronic device, including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to execute the method for starting the virtual machine.

Further, the present application also provides a computer-readable storage medium, where the storage medium stores a computer program, and the computer program is executable by a processor to perform the method for starting the virtual machine.

According to the scheme, the metadata of each target virtual machine is loaded through an asynchronous loading mechanism, so that the blockage caused by loading the metadata of all the target virtual machines at the same time can be avoided, and the target virtual machine is started after the metadata of any target virtual machine is loaded, so that the starting time of each target virtual machine is staggered, and the starting speed is improved on the whole.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required to be used in the embodiments of the present application will be briefly described below.

Fig. 1 is a schematic view of an application scenario of a method for starting a virtual machine according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

fig. 3 is a schematic flowchart of a method for starting a virtual machine according to an embodiment of the present application;

fig. 4 is a schematic flowchart of a metadata asynchronous loading method according to an embodiment of the present application;

fig. 5 is a schematic diagram of a metadata asynchronous loading method according to an embodiment of the present application;

FIG. 6 is a diagram illustrating a comparison of metadata loading provided by an embodiment of the present application;

fig. 7 is a schematic diagram illustrating an acquisition method of console information according to an embodiment of the present application;

fig. 8 is a schematic overall flowchart of virtual machine startup according to an embodiment of the present application;

fig. 9 is a block diagram of a starting apparatus of a virtual machine according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

Like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only for distinguishing the description, and are not to be construed as indicating or implying relative importance.

Fig. 1 is an application scenario schematic diagram of a method for starting a virtual machine according to an embodiment of the present application. As shown in fig. 1, the application scenario includes a front-end device 20, a master node 30, and a slave node 40; the front-end device 20 may be a host, a mobile phone, a tablet computer, or other user terminal, and is configured to send a virtual machine start instruction to the main control node 30; the master node 30 and the slave node 40 may be servers, the master node 30 and the slave node 40 form a backend cluster, and the master node 30 may respond to a virtual machine start instruction to start a virtual machine on the backend cluster.

As shown in fig. 2, the present embodiment provides an electronic apparatus 1 including: at least one processor 11 and a memory 12, one processor 11 being exemplified in fig. 2. The processor 11 and the memory 12 are connected by a bus 10, and the memory 12 stores instructions executable by the processor 11, and the instructions are executed by the processor 11, so that the electronic device 1 can execute all or part of the flow of the method in the embodiments described below. In an embodiment, the electronic device 1 may be the main control node 30, and is configured to execute a method for starting a virtual machine.

The Memory 12 may be implemented by any type of volatile or non-volatile Memory device or 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.

The present application also provides a computer-readable storage medium, which stores a computer program executable by the processor 11 to perform the method for starting a virtual machine provided by the present application.

Referring to fig. 3, a flowchart of a method for starting a virtual machine according to an embodiment of the present application is shown, as shown in fig. 3, the method may include the following steps 310 to 330.

Step 310: in response to the virtual machine start instruction, a plurality of target virtual machines indicated by the virtual machine start instruction are determined.

When the Virtual machine needs to be started, an operator may enter a VNC (Virtual Network Console) page at the front-end device, and select a plurality of Virtual machines to start by operating on the VNC page. The front-end device may send a virtual machine start instruction to the back-end cluster in response to the operation.

After receiving the virtual machine starting instruction, the main control node of the back-end cluster can analyze a plurality of target virtual machines from the virtual machine starting instruction. Here, the target virtual machine is a virtual machine that needs to be started as indicated by the virtual machine start instruction.

Step 320: and asynchronously loading metadata corresponding to the plurality of target virtual machines.

After a plurality of target virtual machines are determined, the main control node can control the back-end cluster, start a corresponding qemu process for each target virtual machine, and load metadata from a virtual disk of the target virtual machine through the qemu process. Here, the virtual disk may be in a qcow2 mirror format. The metadata may include index tables, reference tables, and the like.

When the metadata of a plurality of target virtual machines are loaded, an asynchronous loading mechanism is adopted, and the metadata of different target virtual machines are loaded at different moments.

In an embodiment, the metadata in the virtual disk of each target virtual machine may be written into the cache in advance, and in this case, when the metadata is read from the virtual disk, the metadata may be directly read from the cache, so that the metadata loading is completed more quickly.

Step 330: after the metadata of any target virtual machine is loaded, the target virtual machine is started based on the loaded metadata.

And when the metadata of the target virtual machine is loaded to a certain degree, starting can be carried out. In the process of asynchronously loading metadata of a plurality of target virtual machines, if the metadata loading progress of any target virtual machine meets the starting condition, the target virtual machine can be started through a qemu progress corresponding to the target virtual machine.

By the measures, the metadata of each target virtual machine is loaded by the asynchronous loading mechanism, so that the blockage caused by loading the metadata of all the target virtual machines at the same time can be avoided, and the target virtual machine is started after the metadata of any target virtual machine is loaded, so that the starting time of each target virtual machine is staggered, and the starting speed is improved on the whole.

In an embodiment, before asynchronously loading metadata corresponding to a plurality of target virtual machines, the backend cluster may determine a number of target nodes. Here, the target node is a node running the target virtual machine, and the target node may be selected from a master node and a slave node.

The master node may detect whether the preset node list is empty. Here, the node list is used to record available nodes in the backend cluster that can run the virtual machine. The node list may be stored in a database of the back-end cluster, and the master node may read the node list from the database. In an embodiment, the node list may be written into the cache in advance, and in this case, the master node directly obtains the node list from the cache, so that the target virtual machine can be started more quickly.

In one aspect, if the node list is empty, the master node may determine a number of available nodes from the back-end cluster. The master control node can traverse the back-end cluster according to the preset filtering condition and judge whether each node meets the filtering condition. If any node (master or slave) does not satisfy the filter condition, it may be recorded that the node is not available. If any node satisfies the filtering condition, the node can be determined to be an available node, and the available node can be written into the node list. After updating the node list, the step of selecting a number of target nodes from a number of available nodes recorded by the node list may be continued.

On the other hand, if the node list is not empty, the master node may select a number of target nodes from a number of available nodes recorded by the node list. The master control node may traverse each available node recorded in the node list according to a preset screening condition, and determine whether the available node satisfies the screening condition. If the available node does not satisfy the screening condition, the available node can be filtered. If the node meets the screening condition, the available node can be used as the target node. After traversing the node list, the master node may determine a number of target nodes.

After the target node is obtained, the master control node may control the target node to asynchronously load metadata corresponding to the plurality of target virtual machines, so as to run the target virtual machines on the target node.

Through the measures, the available nodes are recorded in advance by the node list, so that the screening range of the target nodes is narrowed, the speed of determining the target nodes is improved, and the starting time of the target virtual machine is shortened. In addition, when the node list is written into the cache, the node list can be obtained more quickly so as to start the target virtual machine more quickly.

In an embodiment, a number of available nodes in the node list carry instruction flags, and the specified flags indicate that the available nodes are target nodes when the virtual machine is started last time.

When selecting a plurality of target nodes from a plurality of available nodes recorded in the node list, if a plurality of target virtual machines which are started at this time are virtual machines which are started at the last time, the screening condition is not changed, and in this case, the master control node can directly use the available nodes carrying the designated marks as the target nodes.

Through the measure, the main control node can determine the target node more quickly, so that the starting time of the target virtual machine is shortened.

In an embodiment, referring to fig. 4, a flowchart of a metadata asynchronous loading method provided in an embodiment of the present application is shown, as shown in fig. 4, when asynchronously loading metadata corresponding to multiple target virtual machines, the following steps 321 to 322 may be performed.

Step 321: respectively allocating corresponding timers for the virtual disks of each target virtual machine; wherein the callback time of the plurality of timers is different.

After the corresponding qemu process is started for each target virtual machine, a corresponding timer can be allocated for the virtual disk of the corresponding target virtual machine through the qemu process. The callback time of different timers is different and can be randomly divided into preset time intervals. Illustratively, the time interval is 2 minutes, and the callback time of the plurality of timers is evenly distributed within 2 minutes.

Step 322: and in response to a callback event triggered by any timer, loading metadata from the virtual disk corresponding to the timer.

Each timer may trigger a callback event when the callback time is reached. When a timer of a virtual disk corresponding to any target virtual machine triggers a callback event, a qemu process corresponding to the target virtual machine can monitor the callback event, so that metadata starts to be loaded from the virtual disk corresponding to the timer.

By the measures, asynchronous loading of metadata corresponding to the multiple target virtual machines can be achieved.

In an embodiment, the timer may trigger the callback event periodically, where the period duration may be a preconfigured empirical value. Illustratively, the cycle duration is 20 ms.

When the metadata is loaded from the virtual disk corresponding to the timer in response to the callback event triggered by the timer, the metadata may be loaded from the virtual disk corresponding to the timer according to the loading progress policy. Wherein the load progress policy may indicate progress of the loaded metadata each time a callback event is responded. For example, the loading progress policy may indicate a ratio of metadata loaded each time to all metadata in the virtual disk; alternatively, the load progress policy may indicate the content of the metadata loaded at each time. Such as: the metadata of the virtual disk comprises an index table and a reference table, and the loading is carried out by 10 times, the index table is loaded by 8 times, and the reference table is loaded by 2 times.

By the aid of the method, when the metadata of the target virtual machines are asynchronously loaded, the metadata of the target virtual machines can be gradually loaded, so that the target virtual machines can be started when the metadata is loaded to meet starting conditions, and the starting speed of the target virtual machines is integrally improved.

In an embodiment, before loading metadata from a virtual disk corresponding to a timer, it may be determined whether a load restriction condition is satisfied through a qemu process of allocating the timer. The loading limitation condition is used for limiting the loaded virtual disk.

On one hand, if the loading limit condition is not met, the loading task of the virtual disk is finished, and the operation of the corresponding timer of the virtual disk is stopped. On the other hand, if the loading limitation condition is satisfied, the step of loading the cloud data from the virtual disk corresponding to the timer may be executed.

Referring to fig. 5, which is a schematic diagram of a metadata asynchronous loading method provided in an embodiment of the present application, as shown in fig. 5, when a back-end cluster asynchronously loads metadata, a timer may be allocated to virtual disks corresponding to N target virtual machines. The initial trigger time of the timers is uniformly distributed within 5 to 7 minutes after the virtual machine starting instruction is issued. When any timer reaches the callback time and triggers the callback time, the qemu process corresponding to the target virtual machine can judge whether the loading limiting condition is met.

First, it can be determined whether the virtual disk in the qcow2 mirror format is closed. Here, shutdown is debug mode and integrity check of the virtual disk. If the virtual disk is closed, the loading work of the virtual disk can be finished, and the work of the timer is stopped.

If not, judging whether the target virtual machine corresponding to the timer is the destination virtual machine which is in the live migration. If the target virtual machine is being live migrated, the load operation on the virtual disk may be ended.

If the target virtual machine is not live migrated, it may be determined whether the amount of metadata in the virtual disk is greater than 16 Terabbyte. If the size is larger than 16 Terabbyte, the virtual disk is set to load the metadata of the first 16 Terabbyte only.

If the metadata is not greater than 16 Terabbyte, whether the metadata in the current virtual disk is loaded completely or not can be judged. If the loading is completed, the timer may be stopped.

If the load is not completed, it can be determined whether an IO (Input/Output) error is stored during the loading process. If the IO error exists, ending the loading work, and returning to the stage of waiting for the timer to trigger. And if no IO error exists, loading the metadata from the virtual disk, and returning to the stage of waiting for the timer to trigger after loading a part of the metadata according to the loading progress strategy.

Referring to fig. 6, a schematic diagram illustrating metadata loading according to an embodiment of the present application, as shown in fig. 6, in an old version process, metadata of multiple target virtual machines is loaded from virtual disks corresponding to the multiple target virtual machines simultaneously by using a synchronous loading mechanism. According to the scheme, the target virtual machine can be started only after all metadata are loaded, the efficiency is low, and a large amount of time is consumed.

In the new version process of the scheme, the metadata of the multiple target virtual machines adopt an asynchronous timing loading mechanism, and the metadata loading time of different target virtual machines can be staggered, so that the target virtual machines can be started when the metadata of any one target virtual machine is loaded to a certain degree, and the starting speed of the target virtual machines is increased.

In an embodiment, after issuing the virtual machine start instruction, the front-end device may initiate a console information acquisition request to the back-end cluster, where the console information acquisition request is used to request the back-end cluster to return console information of each target virtual machine. The console information may include a VNC port of the target virtual machine, a URL (Uniform Resource Locator) address, and the like.

The master control node of the back-end cluster may obtain console information of each target virtual machine in response to the console information obtaining request. After the target virtual machine is started, the main control node may obtain console information of the target virtual machine, and return the console information to the front-end device. If the target virtual machine is not started, the main control node can repeatedly try to acquire the console information of the target virtual machine until the acquisition is successful. Or, if the target virtual machine is not started, the front-end device may initiate a console information acquisition request for the target virtual machine for multiple times until receiving console information returned by the main control node, under the condition that the console information is not received.

After receiving console information of any target virtual machine, the front-end device may establish VNC connection with the target virtual machine according to the console information. After the VNC connection is established, a VNC page available to the front-end device may enter a boot screen of the target virtual machine.

On the basis of asynchronous loading of metadata of the target virtual machine, the front-end equipment starts to acquire console information of the target virtual machine before the target virtual machine is started, can acquire the console information in time after the target virtual machine is started, and establishes VNC connection with the target virtual machine. Under the condition, the front-end equipment quickly enters a Basic Input Output System (BIOS) page of the target virtual machine, so that the problems of a long-time black screen state and no response of a mouse and a keyboard can be avoided.

In an embodiment, when the console information of each target virtual machine is obtained, the master node may determine whether the target virtual machine is running locally. If any target virtual machine is located locally, the main control node can directly call a local specified interface to obtain the console information of the target virtual machine. The designated interface may be restful api, which is used to obtain console information of the virtual machine.

If any target virtual machine is located in other target nodes, the master control node may Call (RPC) the designated interfaces of other target nodes through a Remote Procedure Call (RPC), so as to obtain console information of the target virtual machines located in other target nodes.

Referring to fig. 7, which is a schematic diagram of a method for acquiring console information according to an embodiment of the present disclosure, as shown in fig. 7, a ui (user interface) represents a front-end device, and the front-end device may issue a console information acquisition request to a master control node of a back-end cluster. After receiving the console information acquisition request, the master control node can directly acquire console information such as a VNC port and the like by calling a 'Get/V1/port/port _ id { } interface' for a local target virtual machine, and returns the console information to the front-end device; for target virtual machines located on other target nodes, console information such as VNC ports of the target virtual machines on other target nodes can be obtained by calling "Get/V1/port/port _ id { } interfaces" of other target nodes through a remote procedure.

Through the measures, compared with a mode of calling the shell script in the related technology, the console information of the target virtual machine can be acquired more quickly, and therefore the speed of establishing VNC connection between the front-end equipment and the target virtual machine is improved.

Referring to fig. 8, which is a schematic overall flow chart of virtual machine startup provided in this embodiment of the present application, as shown in fig. 8, a backend node may first receive a virtual machine startup instruction issued by a front-end device, and may start a right check of a virtual machine, where the check content may include content such as a serial number and a user operation right. After the check is passed, it can be judged that the single node or the back-end cluster processes the virtual machine starting instruction. In one case, if it is a single node, the single node may perform the steps performed by the master node as described above, and at this time, the single node runs all the target virtual machines. In another case, if the virtual machine is a backend cluster, a plurality of target nodes running the target virtual machine may be selected from the backend cluster, and the boot-up operation may be executed through the target nodes. See the above description for a specific selection. The dashed box in fig. 8 indicates the position of the improvement in the present solution in the overall flow.

After the boot command is executed, the virtual machine startup parameters are analyzed, and the virtual machine hardware is initialized, the metadata of the target virtual machine can be loaded. Furthermore, when the VNC connection is established, the designated interface is called, and when the VNC connection is established, the designated interfaces of other target nodes are called through remote process call, so that console information is obtained, and the VNC connection is completed. The details of this are described in the related description.

After the VNC connection is established, the front-end device may enter a virtual machine boot screen, and at this time, the virtual machine is started.

Fig. 9 is an apparatus of a starting apparatus of a virtual machine according to an embodiment of the present invention, and as shown in fig. 9, the apparatus may include:

a determining module 910, configured to determine, in response to a virtual machine starting instruction, a plurality of target virtual machines indicated by the virtual machine starting instruction;

a loading module 920, configured to asynchronously load metadata corresponding to the multiple target virtual machines;

a starting module 930, configured to, after the metadata of any target virtual machine is loaded, start the target virtual machine based on the loaded metadata.

The implementation process of the functions and actions of each module in the above device is specifically detailed in the implementation process of the corresponding step in the above method for starting a virtual machine, and is not described herein again.

In the embodiments provided in the present application, the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. 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). 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 and/or flowchart illustration, and combinations of blocks in the block diagrams and/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.

In addition, functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Claims

1. A method for starting a virtual machine, comprising:

2. The method of claim 1, wherein prior to the asynchronously loading metadata corresponding to the plurality of target virtual machines, the method further comprises:

3. The method of claim 2, further comprising:

4. The method according to claim 2, wherein a number of available nodes in the node list carry a designated flag indicating that the available nodes are target nodes at the last virtual machine startup;

5. The method of claim 1, wherein the asynchronously loading metadata corresponding to the plurality of target virtual machines comprises:

6. The method of claim 5, wherein the timer periodically triggers the callback event;

the loading metadata from the virtual disk corresponding to the timer includes:

7. The method of claim 5, wherein prior to said loading metadata from the virtual disk corresponding to the timer, the method further comprises:

8. The method of claim 1, further comprising:

9. The method of claim 8, wherein obtaining console information for each target virtual machine comprises:

10. A starting apparatus of a virtual machine, comprising:

11. An electronic device, characterized in that the electronic device comprises:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to perform the method of booting a virtual machine of any one of claims 1-9.

12. A computer-readable storage medium, characterized in that the storage medium stores a computer program executable by a processor to perform the method of starting a virtual machine according to any one of claims 1 to 9.