CN112965790A

CN112965790A - PXE protocol-based virtual machine starting method and electronic equipment

Info

Publication number: CN112965790A
Application number: CN202110334502.8A
Authority: CN
Inventors: 周崟宏; 朱从林
Original assignee: Huayun Data Holding Group Co Ltd
Current assignee: Shanghai Huayun Mutual Data Technology Co ltd
Priority date: 2021-03-29
Filing date: 2021-03-29
Publication date: 2021-06-15
Anticipated expiration: 2041-03-29
Also published as: CN112965790B

Abstract

The invention relates to the technical field of computers, and provides a virtual machine starting method and electronic equipment based on a PXE protocol, wherein the method comprises the following steps: matching out a mirror image virtual network for establishing communication between the virtual machine and the TFTP server for the virtual machine through a mirror image virtual network dispatcher, selecting an idle virtual host by the mirror image virtual network dispatcher after receiving a virtual machine starting instruction, selecting a unique TFTP server according to the resource overhead of a candidate TFTP server, configuring the mirror image virtual network corresponding to the finally selected TFTP server as the virtual machine, and starting a PXE protocol to start the virtual machine. The invention obviously improves the flexible creation and hot migration of the virtual machines in the virtual host in the high-availability virtualization cluster, and ensures the timeliness and reliability of service response.

Description

PXE protocol-based virtual machine starting method and electronic equipment

Technical Field

The invention relates to the technical field of computers, in particular to a PXE protocol-based virtual machine starting method and electronic equipment.

Background

In order to reduce the influence of physical machine downtime on the virtual host, the virtual host is usually deployed in a cluster mode, and FC-SAN, NFS or iSCSI is adopted among nodes in the cluster to realize shared distributed storage. The applicant indicates that the deployment and operation cost of the virtual host is high, and the virtual host is not suitable for a small network application environment. However, although the DAS storage can achieve a high cost performance, the direct connection mode also makes it very difficult to increase the storage capacity while the DAS storage brings a simple architecture, and the later management cost is very high.

Meanwhile, DAS storage (direct connection storage) depends on a server host operating system to perform IO read-write and storage maintenance management of data, data backup and recovery require to occupy server host resources (including CPU, system IO and the like), data flow needs to flow back to a tape unit (library) connected with a server after a host, and data backup usually occupies 20-30% of the server host resources, so that daily data backup of many enterprise users is often performed at night or when a service system is not busy, and the operation of a normal service system is not affected. The larger the amount of data stored in the direct connection, the longer the backup and restore time, and the greater the dependency and impact on the server hardware. The connection channel between the direct connection type storage and the server host is generally connected by iSCSI, the space of the storage hard disk is larger and larger along with the stronger and stronger processing capacity of the CPU of the server, the number of the hard disks of the array is larger and larger, and the iSCSI channel can become an IO bottleneck; the server host iSCSI ID resources are limited and therefore the number of connections that can be established over an iSCSI channel is limited. Finally, the DAS storage cannot effectively support High Availability (HA) and live migration, which brings great difficulties to live migration of virtual machines among nodes according to a load balancing policy.

In view of the above, there is a need to improve the virtual machine startup method in the highly available virtualization cluster created in the distributed storage system constructed based on DAS storage in the prior art to solve the above problems.

Disclosure of Invention

The invention aims to disclose a PXE protocol-based virtual machine starting method and electronic equipment, which are used for creating a PXE protocol-based high-availability virtualization cluster in a distributed storage system built based on DAS storage, enabling Virtual Machines (VMs) in virtual hosts in the high-availability virtualization cluster to be flexibly created and thermally migrated, and achieving fault switching of the virtual machines deployed by the virtual hosts when the virtual hosts are down, so as to ensure timeliness and reliability of service response.

In order to achieve one of the above objects, the present invention provides a virtual machine starting method based on a PXE protocol, including the following steps:

s1, creating TFTP servers deployed in mutually independent mirror image virtual networks in the virtual host;

s2, matching a mirror image virtual network for the virtual machine through the mirror image virtual network dispatcher so as to establish communication between the virtual machine and the TFTP server;

s3, receiving a virtual machine starting instruction, selecting an idle virtual host by a mirror image virtual network scheduler, and selecting a plurality of candidate TFTP servers according to the logic position of a mirror image file of the virtual machine when the virtual machine is started;

s4, selecting a unique TFTP server according to the resource cost of the candidate TFTP server, and configuring the mirror image virtual network corresponding to the TFTP server selected finally as a virtual machine;

and S5, starting the PXE protocol and acquiring the IP address according to the DHCP server to start the virtual machine.

As a further improvement of the present invention, the step S2 further includes: the two virtual hosts execute mutual access to the mirror image files of the virtual machines stored in the opposite virtual host through mutually independent mirror image networks;

the mirror image virtual network is controlled by a mirror image virtual network dispatcher, and the mirror image virtual network dispatcher issues a unique virtual network IP address to the virtual machine.

As a further improvement of the present invention, the virtual host mounts one or more disks through a SCSI protocol or an FC protocol, and the disks mounted by all the virtual hosts are used as shared storage;

the step S2 further includes: and constructing the RAID through all the disks to execute backup operation of the image files of the virtual machines in the disks mounted by the virtual hosts.

As a further improvement of the invention, the image file of the virtual machine is copied to a disk which forms a shared storage and is mounted by an adjacent virtual host through an SCP protocol.

As a further improvement of the present invention, the image file of the virtual machine determines, by using an SCP protocol, the number of copies to be copied to a disk mounted by an adjacent virtual machine host according to a virtual machine selection logic, where the copies are image files of the same virtual machine.

As a further improvement of the present invention, after the step S5 is completed, the method further includes:

determining whether a virtual host where the started virtual machine is operated is down or not, and isolating the down virtual host;

scanning the remaining and alive virtual hosts, and determining the virtual hosts containing the image files corresponding to the virtual machines running on the down virtual host from the remaining and alive virtual hosts according to the virtual host selection logic;

and directly calling image files in the remaining and alive virtual hosts through mutually independent image networks, starting a PXE protocol and acquiring an IP address according to a DHCP server so as to start the virtual machine created in the down virtual host.

As a further improvement of the present invention, the operation of selecting a unique TFTP server according to the resource overhead of the candidate TFTP server in step S4 is performed by a mirror virtual network scheduler, wherein the mirror virtual network scheduler comprises virtual host selection logic;

the virtual host selection logic is as follows: and taking the connection number of the TFTP servers and the TFTP server with the lowest mirror virtual network occupancy rate configured by the TFTP server as the basis for selecting the only TFTP server.

As a further improvement of the invention, the method also comprises the following steps: and storing the virtual hosts, the mirror image files of the virtual machines stored in the virtual hosts and the attributes of the mirror image virtual network into a database logically independent of each virtual host, wherein the database is communicated with a mirror image virtual network dispatcher.

Based on the same inventive concept, the present application further discloses an electronic device, comprising:

processor, memory device comprising at least one memory unit, and

a communication bus establishing a communication connection between the processor and the storage device;

the processor is configured to execute one or more programs stored in the storage device to implement a PXE-protocol-based virtual machine starting method as disclosed in any one of the inventions of the above.

Compared with the prior art, the invention has the beneficial effects that:

by the method and the device, the Virtual Machines (VM) in the virtual hosts in the high-availability virtualization cluster can be flexibly created and thermally migrated, and the virtual machines are switched over when the virtual hosts are down, so that timeliness and reliability of service response are guaranteed.

Drawings

FIG. 1 is a flowchart illustrating a virtual machine booting method based on PXE protocol according to the present invention;

FIG. 2 is a topology diagram of a virtualization cluster operating the PXE protocol-based virtual machine starting method shown in FIG. 1;

fig. 3 is a topology diagram of multiple virtual hosts in a virtualization cluster directly connecting independent disks via a SCSI protocol or a FC protocol;

FIG. 4 is a detailed flowchart of the present invention for starting up a virtual machine and for the virtual machine VM3 running in Host3 to reselect a new virtual Host from the remaining non-down virtual hosts after Host3 is down;

FIG. 5 is a detailed flowchart of the virtual machine VM3 performing a live migration in Host3 and Host 1;

FIG. 6 is a topology diagram of a virtualized cluster and database;

FIG. 7 is a topology diagram of a DHCP server monitoring a virtual machine started in a virtualization cluster via mutually independent mirror virtual networks;

FIG. 8 is a topology diagram of an electronic device of the present invention.

Detailed Description

The present invention is described in detail with reference to the embodiments shown in the drawings, but it should be understood that these embodiments are not intended to limit the present invention, and those skilled in the art should understand that functional, methodological, or structural equivalents or substitutions made by these embodiments are within the scope of the present invention.

The definitions and explanations necessary for technical terms and abbreviations in the various embodiments appearing in the specification are made before the detailed description of the various embodiments of the present application.

Term "img": mirror Image or virtual machine mirror Image, and has the same meaning as "Image".

Term "Host": a virtual host. Referring to fig. 2, three virtual hosts (i.e., Host1 to Host3) included in the virtualization cluster 100 may be formed by one physical machine or physical server through virtualization software, or may be formed by two or more physical machines or physical servers through virtualization software.

Term "OVS Bridge": a virtual bridge based on an open source virtual switch.

Term "PIF": a physical network card.

Term "VIF": and (5) a virtual network card.

Term "Image Network": the virtual network is mirrored.

Term "VM": and (4) a virtual machine.

The first embodiment is as follows:

fig. 1 to fig. 7 illustrate an embodiment of a virtual machine starting method (hereinafter referred to as "method") based on a PXE protocol according to the present invention.

When a client in the traditional PXE service is started, a broadcast packet is uniformly sent to acquire DHCP information and a system bootstrap program in TFTP service, and then a system image stored on a shared file server is loaded according to an address in a system additional file. In the prior art, multiple DHCP servers are not allowed in the same network environment, so that under the condition of high concurrent requests, a single-point PXE service has a problem of high pressure and slow response, which results in long virtual machine startup time and slow system loading. Meanwhile, due to the single-point PXE server, if a service fails, all virtual machines in the same network cannot be started. DHCP is a short for Dynamic Host Configuration Protocol, a DHCP server is a Dynamic Host Configuration Protocol server, a Dynamic Host Configuration Protocol is a network Protocol of a local area network, which means that a server controls a segment of IP address range, and a client can automatically obtain an IP address and a subnet mask allocated by the DHCP server when logging in a virtualization cluster 100 similar to that in this embodiment.

The method aims to create and live-migrate a virtual machine in a plurality of virtual hosts in a high-availability virtualization cluster 100, and implement failover of the virtual machine deployed by the virtual host for the virtual machine when the virtual host is down, thereby implementing High Availability (HA). Referring to fig. 2, for simplicity of description, only a specific scenario of the virtualization cluster 100 including the Host1 to the Host3 is shown, and in an actual application scenario, the virtualization cluster 100 may deploy a larger number of virtual hosts. Each virtual host is configured by virtualization software (e.g., KVM virtualization software) based on a physical device (e.g., a physical server).

In this embodiment, a virtual machine starting method based on a PXE protocol includes the following steps.

Step S1, creating TFTP servers deployed in mirror virtual networks independent of each other in the virtual host. Specifically, the virtual Host1 mounts one or more disks via SCSI protocol or FC protocol, and all the disks mounted by the virtual Host are used as shared storage. Preferably, in this embodiment, the step S2 further includes: and constructing the RAID through all the disks to execute backup operation of the image files of the virtual machines in the disks mounted by the virtual hosts. The TFTP servers 31 to 33 in fig. 3 are used for storing image files of virtual machines, and communicate with the PXE service by using TFTP (simple file transfer protocol). And the image file of the virtual machine is copied to a disk which forms shared storage and is mounted by the adjacent virtual host through an SCP protocol.

The PXE client sends an IP request to a local area network (i.e., "mirror image virtual network" in this embodiment) through the PXE network card, and then the DHCP server provides the PXE client with an IP address and a file required for system installation, and then performs system installation using the received file. The installation process requires resources provided by other servers, such as yum sources, kernel files, etc. After the virtual host acquires the resources, the installation and configuration of the virtual machine can be realized. The TFTP servers 31-33 as a whole are considered as equivalent technical features to the DHCP server in FIG. 7.

Disk-1, disk-2, and disk-3 in fig. 3 are mounted to Host1, Host2, and Host3 respectively through an SCSI protocol or an FC protocol, so as to form DAS-type distributed storage, and disk-1 to disk-3 form shared storage, thereby ensuring that a virtual machine created and deployed on each virtual Host can run in any virtual Host, reducing the dependence of virtualization cluster 100 on the adoption of distributed storage and/or centralized storage, and providing a precondition for high availability and hot migration capability of the virtual machine. Disk-1, disk-2, and disk-3 respond to client requests based on the TFTP protocol. In this embodiment, the client may be regarded as a computer device (e.g., a mobile phone or a personal computer) connected to the virtualization cluster 100 or any terminal device capable of receiving a user input instruction and executing a program or a service.

Step S2, matching out mirror image virtual networks for the virtual machine to establish communication between the virtual machine and the TFTP server, that is, the mirror image virtual network 201 to the mirror image virtual network 203, by the mirror image virtual network scheduler 301. Specifically, the step S2 further includes: the two virtual hosts execute mutual access to the image files of the virtual machines stored in the opposite virtual host through mutually independent image networks. The mirror virtual network is controlled by the mirror virtual network scheduler 301, and the mirror virtual network scheduler 301 issues a unique virtual network IP address to the virtual machine. Wherein "Virtual host located at opposite end"means that the Image file of the virtual machine is saved in a copy form to another virtual host in addition to the TFTP server (i.e., a plurality of Image _ TFTPs with different IP addresses shown in fig. 2) in the original virtual host for saving the Image file (e.g., img1) of the virtual machine.

The mirror virtual network scheduler 301 has global knowledge of how many physical devices are in the virtualization cluster 100 and the virtual hosts formed based on the physical devices. How many different mirror image virtual networks are stored in the TFTP server of each virtual host, and the mirror image files formed by the virtual machines are connected with the TFTP server which can be connected with the TFTP server.

When a user wishes to create a virtual machine at Host3 and the image of the virtual machine is Img1, the image virtual network dispatcher 301 first senses that the image files are saved on the local storage (i.e., disk-1 and disk-2 directly mounted via SCSI protocol or FC protocol) of the current Host1 and Host 2. The mirrored virtual network 201 points to the TFTP server 31 in Host1, the mirrored virtual network 202 points to the TFTP server 32 in Host2, and the mirrored virtual network 203 points to the TFTP server 33 in Host 3. At this time, the mirror virtual network scheduler 301 selects a unique TFTP server from the two mirror virtual networks, and configures the mirror virtual network corresponding to the finally selected TFTP server as a virtual machine. By this, if there is no mirror virtual network corresponding to the TFTP server, the mirror virtual network is configured by the mirror virtual network scheduler 301 in a new manner.

Referring to fig. 2, a VM1 and a VM5 are created in Host1, a VM2 and a VM4 are created in Host2, and a VM3 is created in Host 3. The mirror virtual network scheduler 301 is responsible for matching an appropriate mirror virtual network for each of the aforementioned virtual machines (VM 1-VM 5), and the mirror virtual network performs communication between the virtual machine and the TFTP server. When a physical device is added to the virtualization cluster 100 (e.g., a virtual host can be formed by KVM virtualization software), a mirror virtual network is newly created in the virtualization cluster 100, and the IP address of the mirror virtual network is different from the IP address of the mirror virtual network that has been created previously (see 10:100:1.0/24 to 10:100:3.0/24 in fig. 7). Thus, the number of mirrored virtual networks in the virtualization cluster 100 is equal to the number of virtual hosts.

In this embodiment, after the image file of the virtual machine VM1 (hereinafter referred to as "image file of VM 1") is saved to Host1, the image file is saved to the virtual Host2 in a copy form, at this time, both Host1 and Host2 save img1, and the number of copies of img1 is 2. Therefore, the two virtual hosts (Host1 and Host2) perform mutual access to the image files of the virtual machines stored in the opposite virtual Host through mutually independent image networks, the img1 is the local image file relative to the Host1, the img1 is the image file of the virtual machine stored in the opposite virtual Host relative to the Host2, and the img2 and the img3 are similar to each other.

After the image file (i.e., img2) of the VM2 is saved in the Host2, the image file is saved in the virtual Host1 in a copy form, at this time, both the Host1 and the Host2 save img2, and the number of copies of the img2 is 2. After the image file (i.e., img3) of the VM3 is saved in the Host3, the image file is saved in the virtual Host2 in a copy form, at this time, both the Host2 and the Host3 save img2, and the number of copies of the img2 is 2. Finally, img1 and img2 are stored in the Host1, img1, img2 and img3 are stored in the Host2, and img3 is stored in the Host 3. The Img1 and the Img2 are logically saved in the TFTP server 31 of the Host 1; img1, img2 and img3 are logically saved to the TFTP server 32 of Host 2; the img3 is logically stored in the TFTP server 33 of the Host3, and each TFTP server corresponds to a mirrored virtual network of IP addresses.

Referring to fig. 2, mirrored virtual network 201 points to TFTP server 31, mirrored virtual network 202 points to TFTP server 32, and mirrored virtual network 203 points to TFTP server 33. The TFTP servers need to be located in different mirrored virtual networks to ensure that different VMs can connect and access to a specified TFTP server through different mirrored virtual networks. Meanwhile, the number of copies formed by copying and storing the image files to the opposite virtual host can be 3 or more than 3. Meanwhile, in the present embodiment, the mirror virtual network scheduler 301 serves as a management controller during migration of the virtual machines in each virtual Host, which globally manages all the virtual hosts (Host1 to Host3) and creates or allocates mirror virtual networks for the virtual machines, and the number of mirror virtual networks is not limited to three shown in fig. 2.

Referring to FIG. 2, if Host3 goes down, since the image file img3 of VM3 is already synchronously copied to Host2, it can be recovered through img 2. If the Host2 goes down, since the image file img2 of the VM2 is synchronously copied into the Host1, the recovery can be carried out through the img2 in the Host 1. If the Host1 is down, because the image file img1 of the VM1 is synchronously copied into the Host2, the image file img can be directly recovered through the img1 in the Host 2.

Step S3, receiving a virtual machine start instruction, selecting an idle vm by the mirror virtual network scheduler 301, and selecting a plurality of candidate TFTP servers according to the logical location of the mirror file of the virtual machine when the virtual machine is started. The basis for selecting the idle vm in step S3 is determined individually or collectively according to one or more of the following criteria of the physical devices that constitute the vm. The index may be a CPU overhead degree, a memory overhead degree, a storage overhead degree, a network traffic, and the like of the physical device. Generally, if the aforementioned four indexes of a certain physical device are taken as a whole or by setting a threshold value, a relatively idle virtual host is determined. Since this section is a relatively mature prior art, it will not be described in detail here.

Step S4, selecting a unique TFTP server according to the resource overhead of the candidate TFTP servers, and configuring the mirror virtual network corresponding to the TFTP server selected finally as a virtual machine. The operation of selecting a unique TFTP server according to the resource overhead of the candidate TFTP server in step S4 is performed by the mirroring virtual network scheduler 301, where the mirroring virtual network scheduler 301 includes virtual host selection logic. The virtual host selection logic is: and taking the connection number of the TFTP servers and the TFTP server with the lowest mirror virtual network occupancy rate configured by the TFTP server as the basis for selecting the only TFTP server. After the step S4 is completed, the mirror virtual network corresponding to the TFTP server may be automatically associated with the virtual machine.

And step S5, starting the PXE protocol and acquiring the IP address according to the DHCP server to start the virtual machine. The image files of the virtual machines determine the number of copies copied to a disk mounted by an adjacent virtual machine host according to the virtual machine selection logic through an SCP (Secure Copy protocol), wherein the copies are the image files of the same virtual machine. After the virtual machine is started, the IP address can be obtained according to the DHCP server, the IP address and the appointed TFTP server are communicated with each other, and finally an operating system of the virtual machine is downloaded and started. The VM selection logic in step S5 participates in step S4.

As shown in connection with FIG. 7, VMs 1-3 boot up based on the PXE protocol. After the VMs 1-3 are started, the DHCP clients included in the PXE server corresponding to the virtual machines send packets to the mirror image virtual networks 201-203 to search the DHCP servers 31-33, the DHCP servers 31-33 return a DHCP ACK acknowledgement packet, the acknowledgement packet includes an IP address, and the IP address is broadcast and sent to the PXE clients of all the physical devices. The PXE client logically runs in the memory of the physical device. All virtual machines are configured with VIFs and communicate with each other through PIFs of physical devices and through mirror image virtual networks 201-203. The VIF and the PIF are connected through OVS Bridge.

Each Host contains a separate TFTP server and is used to store the image file. VM1 in Host1 and VM3 in Host3 communicate with each other via mirrored virtual network 201, and VM1 in Host1 and VM2 in Host2 communicate with each other via mirrored virtual network 202. The virtual machines in the virtual hosts access the PIF of the virtual host through the OVS Bridge and access the image files stored in the disks (such as disk-1 to disk-3) through the PIF.

The shared storage in each of the VMs in FIG. 7 is logically formed by the disks directly mounted by each VM. After VM1 is created, mirror virtual network scheduler 301 configures VIF for VM1, tags VLAN102 for the VIF of VM1, and connects the Bridge device (i.e., OVS Bridge) of Host1, and the packet forwarded by VM1 in Host1 is connected to the PIF of Host2 via mirror virtual network 202. Thereby establishing communication between the respective TFTP servers of Host1 and Host 2. Similarly, VM1 in Host1 and VM3 in Host3 are executed in accordance with the above-described procedure.

The DHCP server monitors the DHCP request and the acknowledgement packet of the DHCP ACK in each mirror image virtual network, so that the mirror image file of the virtual machine is found out to be stored in the TFTP server of which virtual host through the mirror image virtual network, and the virtual machine is finally created and started. After the virtual machines in each virtual host are created, the mirror virtual network scheduler 301 writes the mirror virtual networks, IP addresses, and MAC addresses corresponding to the virtual machines into a database (i.e., DB40), so that when a virtual host goes down (a lower concept of failure), a virtual host can be recovered from the available virtual hosts according to the mirror virtual networks and the mirror files, and the recovered virtual machines can be redeployed to the recovered virtual hosts after the virtual host that goes down is recovered.

Preferably, after the step S5 is completed, the method further includes:

and determining whether the virtual host where the started virtual machine is operated is down, and isolating the down virtual host.

And scanning the remaining and alive virtual hosts, and determining the virtual hosts containing the image files corresponding to the virtual machines running on the down virtual host from the remaining and alive virtual hosts according to the virtual host selection logic. The virtual host selection logic is described with reference to step S4 above.

Referring to fig. 6, in the present embodiment, the method further includes: the virtual hosts, the image files of the virtual machines and the attributes of the image virtual networks stored in the virtual hosts, or the configuration data (such as power parameters, the number of cores of a CPU, the specification of a memory, control IDEs, Boot Options, and the like) required for creating and starting the virtual machines are stored in the database 40 logically independent of the virtual hosts, and the database 40 is communicated with the image virtual network scheduler 301.

With reference to fig. 2, fig. 4 and fig. 5, the applicant describes a detailed process of each virtual machine that has been created in the virtual host in executing a failover and live migration scenario, so as to exemplify how the high availability and timeliness and reliability of the service response of the virtualization cluster 100 can be achieved by the above technical means. The failover and live migration scenario according to this embodiment refers to a process of executing migration and copy on a virtual machine when each virtual host is not stopped. Although this embodiment shows only three VMs, the virtualization cluster 100 may be configured with a greater number of VMs. Meanwhile, in order to prevent redundancy of the image files, the number of copies of the image files of the virtual machine is generally set as the principle that the number of the virtual hosts is reduced by one or N; wherein the parameter N is a positive integer greater than or equal to one. The number of copies is at least greater than or equal to two.

Assuming that the Host3 is down, the Host1 and the Host2 are normal, and the DHCP server detects that the Host3 is down. The mirror virtual network scheduler 301 detects the resource overhead of the Host1 and the Host2 as the candidate TFTP server, selects a unique TFTP server, and configures the mirror virtual network corresponding to the finally selected TFTP server as a virtual machine. The resource overhead may be CPU and/or memory usage. The mirrored virtual network scheduler 301 accesses the database 40. Since the synchronous backup operation of the image files of the virtual machine has been completed before, the logical paths saved by the different image files and the number of copies formed by the image files are determined in the database 40 by means of database table lookup. The DHCP server is informed by the mirroring virtual network scheduler 301 during the restart of the VM3 to assign an IP address to the VM3 and determine the final mirroring virtual network 201. In this embodiment, the specific process of creating and starting a virtual machine in each virtual Host and restarting VM3 according to the image file of VM3 by copying the image file of VM3 in Host3 to the TFTP server in Host2 when Host3 goes down in Host1 is shown in fig. 4.

Referring to fig. 5, a detailed flowchart of the virtual machine VM3 performing the live migration in Host3 and Host1 is shown. In the virtual machine live migration process, if the VM3 is specified to be executed live migration from the Host3 and migrated to the Host 1. Referring to fig. 7, the VM3 in the Host3 communicates with the PIF of the Host3, the mirror virtual network 201, and the PIF of the Host 1. After the data copy operation of the VM3 is completed in the memory of the Host1, the Host3 suspends the VM 3. Then, clock signals corresponding to memories in Host1 and Host3 are synchronized to ensure reliability and stability of data reading and writing, so that VM3 is finally started in Host1, and a hot migration operation on VM3 is finally completed.

In summary, the virtual machine starting method based on the PXE protocol disclosed in this embodiment significantly improves the flexibility in creating and live migrating Virtual Machines (VMs) in virtual hosts in a highly available virtualized cluster, and realizes the failover of the VMs deployed by the virtual hosts when the virtual hosts are down, thereby ensuring the timeliness and reliability of the response to services.

Example two:

referring to fig. 8, the embodiment further discloses an electronic device 500, which includes:

a processor 51, a memory device 52 consisting of at least one memory unit, and a communication bus 53 establishing a communication connection between the processor 51 and the memory device 52. The processor 51 is configured to execute one or more programs stored in the storage device 52 to implement the PXE protocol-based virtual machine starting method according to an embodiment of the disclosure.

Specifically, the storage device 52 may be composed of a storage unit 521 and a storage unit 52j, where the parameter j is a positive integer greater than or equal to 1. The processor 51 may be an ASIC, FPGA, CPU, MCU or other physical hardware or virtual device with instruction processing functions. The form of the communication bus 53 is not particularly limited, I²The C bus, the SPI bus, the SCI bus, the PCI-E bus, the ISA bus, etc., and may be changed reasonably according to the specific type and application scenario requirements of the electronic device 500. The communication bus 53 is not the point of the invention of the present application and is not set forth herein.

The storage device 52 may be based on a distributed file system such as Ceph or GlusterFS, may also be a RAID 0-7 Disk array, and may also be configured as one or more hard disks or removable storage devices, a database server, an SSD (Solid-state Disk), an NAS storage system, or an SAN storage system. The electronic device 500 may be configured as a super-converged all-in-one machine, a computer, a server, a data center, a virtual cluster, a portable mobile terminal, a Web system, a financial payment platform or an ERP system, a virtual online payment platform/system, and the like; the ultra-convergence all-in-one machine is a high-performance multi-node server, mainly adopts a distributed storage and server virtualization technology, highly integrates computing nodes, storage resources and network switching into a 1U, 2U or 4U server, and provides ultra-convergence infrastructure facilities for enterprises or terminal users so as to comprehensively improve the IT (information technology) capability of the enterprises.

In particular, an electronic device 500 disclosed in this embodiment may reliably respond to one or more parallel tasks corresponding to an access request or an operation initiated by a user at a client (e.g., to a Virtual Machine (VM) in the virtualized cluster 100 in a wired or wireless manner) based on the PXE-protocol-based virtual machine starting method disclosed in the first embodiment, and especially in a scenario with severe requirements on real-time performance and security, such as an online payment system of a shopping website, a settlement system of a financial institution, an electronic ticket purchasing system, and the like, the electronic device 500 has an extremely important technical application value.

An electronic device 500 disclosed in this embodiment may be understood as a physical device (e.g., a POS machine, an atm machine) having a physical form, a software system (a financial system or an ERP system) or an internet online application (APP software) running a PXE protocol-based virtual machine starting method disclosed in this embodiment, or even two or more computer systems/data centers forming a direct connection topology, a tree topology, or a star topology that may be interconnected through an optical fiber or a network. Please refer to the description of the first embodiment, which will not be repeated herein, regarding the technical solutions of the same parts in the electronic device 500 disclosed in the present embodiment and the first embodiment.

The above-listed detailed description is only a specific description of a possible embodiment of the present invention, and they are not intended to limit the scope of the present invention, and equivalent embodiments or modifications made without departing from the technical spirit of the present invention should be included in the scope of the present invention.

It will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned.

Furthermore, it should be understood that although the present description refers to embodiments, not every embodiment may contain only a single embodiment, and such description is for clarity only, and those skilled in the art should integrate the description, and the embodiments may be combined as appropriate to form other embodiments understood by those skilled in the art.

Claims

1. A virtual machine starting method based on a PXE protocol is characterized by comprising the following steps:

2. The virtual machine starting method according to claim 1, wherein the step S2 further includes: the two virtual hosts execute mutual access to the mirror image files of the virtual machines stored in the opposite virtual host through mutually independent mirror image networks;

3. The virtual machine starting method according to claim 1, wherein the virtual host mounts one or more disks by a SCSI protocol or an FC protocol, and the disks mounted by all the virtual hosts are used as shared storage;

4. The virtual machine boot method according to claim 3, wherein the image file of the virtual machine is copied to a disk forming the shared storage and mounted by the adjacent virtual host through an SCP protocol.

5. The virtual machine starting method according to claim 4, wherein the image file of the virtual machine determines, according to the virtual machine selection logic, the number of copies to be copied to the disk mounted by the adjacent virtual machine host through the SCP protocol, and the copies are image files of the same virtual machine.

6. The virtual machine starting method according to claim 5, wherein after the step S5 is completed, the method further comprises:

7. The virtual machine boot method according to claim 6, wherein the operation of selecting the only TFTP server according to the resource overhead of the candidate TFTP server in step S4 is performed by a mirroring virtual network scheduler, the mirroring virtual network scheduler comprising virtual host selection logic;

8. The virtual machine starting method according to any one of claims 1 to 7, further comprising: and storing the virtual hosts, the mirror image files of the virtual machines stored in the virtual hosts and the attributes of the mirror image virtual network into a database logically independent of each virtual host, wherein the database is communicated with a mirror image virtual network dispatcher.

9. An electronic device, comprising:

processor, memory device comprising at least one memory unit, and

the processor is configured to execute one or more programs stored in the storage device to implement the PXE-based virtual machine starting method according to any one of claims 1 to 8.