Patent Description:
In a high availability (HA) virtual machine system, when resources in the virtual machine system are permitted, an HA process is allowed to be triggered to remotely recreate a virtual machine when the virtual machine in a source device is faulty, to further restore a corresponding service. However, in the virtual machine HA process, that the virtual machine in the source device is faulty should be ensured. Otherwise, if the virtual machine is incorrectly considered faulty but actually the virtual machine runs normally, after the virtual machine is recreated remotely, two virtual machines that use a same IP address and operate on a same volume exist in the system. To be specific, the virtual machines are called split-brain virtual machines. Because the split-brain virtual machines simultaneously operate on a same storage resource, unexpected abnormality may occur. In the prior art, two manners are usually used to determine whether a virtual machine in a source device is faulty, probe whether a network from a management node to a server in which the virtual machine is located is normal, or use a shared storage for a virtual machine in a cluster, and probe, in a storage plane, whether the virtual machine is faulty. However, incorrect determining or a failure may occur in both the manners.

Therefore, how to improve reliability of probing whether a virtual machine in the source device is faulty is an urgent problem to be resolved.

<CIT> relates to a method for live synchronization and management of virtual machines across computing and virtualization platforms to support disaster recovery. An "incremental forever" approach is combined with deduplication and synthetic full backups to speed up data transfer and update the disaster recovery sites.

<CIT> relates a method for sharing a JAVA virtual machine having multiple tenants. The method comprises allocating an IP address to each of the multiple tenants, respectively and creating a separate virtual network interface for each of the multiple tenants and configuring the allocated IP address. Respectively, for each of the multiple tenants, its network operation is performed via the virtual network interface created for that tenant.

This application provides a virtual machine status probe method and a device, to improve reliability of probing whether a virtual machine in the source device is faulty, thereby effectively avoiding occurrence of a virtual machine split brain.

The subject-matter for which protection is sought is defined by the appended claims. According to a first aspect, a virtual machine status probe method is provided. The method is used to: when a high availability procedure of a first virtual machine is triggered, determine whether to recreate the first virtual machine in a destination device, and the method is performed by the destination device, and includes:.

Therefore, if a virtual machine high availability procedure is triggered, the destination device in which the first virtual machine needs to be recreated sends a probe packet to the source device in which the first virtual machine is located, where the probe packet is used to probe whether the first virtual machine runs in the source device. The destination device determines, based on the feedback information sent by the source device, whether to configure the first virtual machine in the destination device. This improves reliability of probing whether the virtual machine in the source device is faulty, and effectively avoids occurrence of a virtual machine split brain.

With reference to the first aspect, in some implementations of the first aspect, when a probe port of the source device and a probe port of the destination device are located in a same virtual local area network, the probe packet is a broadcast packet, and the probe packet includes a probe virtual local area network VLAN identifier of a service plane in which the first virtual machine is located.

With reference to the first aspect, in some implementations of the first aspect, the method further includes: receiving the probe virtual local area network VLAN identifier that is of the first service plane in which the first virtual machine is located and that is sent by a management device, configuring the probe port in the first service plane, and configuring the probe virtual local area network VLAN identifier for the probe port; and
the sending a probe packet by running the probe script includes: sending the probe packet through the probe port.

With reference to the first aspect, in some implementations of the first aspect, when the source device communicates with the destination device through an overlay network, the probe packet is a unicast packet, and the probe packet includes an identifier of a tunnel port of the source device.

With reference to the first aspect, in some implementations of the first aspect, the method further includes: obtaining, from the management device based on the identifier of the first virtual machine, the identifier of the tunnel port corresponding to the source device; and the sending a probe packet by running the probe script includes: sending the probe packet through a tunnel port of the destination device.

With reference to the first aspect, in some implementations of the first aspect, before the obtaining an invocation message, the method further includes: sending a first message to a server, where the first message is used to request disk storage information of the first virtual machine in the server, and is used to determine a status of the first virtual machine by probing a storage plane of the first virtual machine; and receiving no feedback information from the server within a predetermined time period.

In this case, when a high availability procedure of the virtual machine is triggered, if the system in which the virtual machine is located supports storage plane probe, the storage plane probe may be performed first. If the storage plane probe fails, the destination device in which the first virtual machine needs to be recreated may further send a probe packet to the source device in which the first virtual machine is located, to probe whether the first virtual machine runs normally in the source device. Therefore, if incorrect determining or a failure occurs when whether the virtual machine is faulty is probed in the storage plane, the destination device further sends the probe packet to the source device in which the first virtual machine is located, to probe whether the first virtual machine runs normally in the source device. This improves reliability of probing whether the virtual machine in the source device is faulty, and effectively avoids occurrence of a virtual machine split brain.

With reference to the first aspect, in some implementations of the first aspect, the determining, based on the feedback information, whether to recreate the first virtual machine in the destination device includes:.

According to a second aspect, a virtual machine status probe method is provided. The method is used to: when a high availability procedure of a first virtual machine is triggered, determine whether to recreate the first virtual machine in the destination device, and the method is performed by a source device, and includes: receiving a probe packet sent by the destination device, where the probe packet is used to probe a status of the first virtual machine in the source device, and the probe packet includes an identifier of the first virtual machine; querying for the status of the first virtual machine based on the probe packet; and sending feedback information to the destination device, where the feedback information is used to indicate the status of the first virtual machine in the source device.

With reference to the second aspect, in some implementations of the second aspect, when a probe port of the source device and a probe port of the destination device are located in a same virtual local area network, the probe packet is a broadcast packet, and the probe packet includes a probe virtual local area network VLAN identifier of a service plane in which the first virtual machine is located.

With reference to the second aspect, in some implementations of the second aspect, the method further includes: receiving the probe virtual local area network VLAN identifier that is of the first service plane in which the first virtual machine is located and that is sent by a management device, configuring the probe port in the first service plane, and configuring the probe virtual local area network VLAN identifier for the probe port; and the receiving a probe packet sent by the destination device includes: receiving, through the probe port, the probe packet sent by the destination device.

With reference to the second aspect, in some implementations of the second aspect, when the source device communicates with the destination device through an overlay network, the probe packet is a unicast packet, and the probe packet includes an identifier of a tunnel port of the source device.

With reference to the second aspect, in some implementations of the second aspect, the receiving a probe packet sent by the destination device includes: receiving, through the probe port, the probe packet sent by the destination device.

According to a third aspect, a system is provided. The system includes a destination device and a source device, and includes:.

With reference to the third aspect, in some implementations of the third aspect, when a probe port of the source device and a probe port of the destination device are located in a same virtual local area network, the probe packet is a broadcast packet, and the probe packet includes a probe virtual local area network VLAN identifier of a first service plane in which the first virtual machine is located.

With reference to the third aspect, in some implementations of the third aspect, the system further includes a management device. The management device receives the probe virtual local area network VLAN identifier of the first service plane, and sends the probe virtual local area network VLAN identifier to the source device and the destination device.

With reference to the third aspect, in some implementations of the third aspect, the destination device receives the probe virtual local area network VLAN identifier; the destination device configures the probe port in the first service plane, and configures the probe virtual local area network VLAN identifier for the probe port; and that the destination device sends a probe packet by running the probe script includes: the destination device sends the probe packet through the probe port.

With reference to the third aspect, in some implementations of the third aspect, the source device receives the probe virtual local area network VLAN identifier sent by the management device; the source device configures the probe port in the first service plane, and configures the probe virtual local area network VLAN identifier for the probe port; and that the source device receives the probe packet sent by the destination device includes: the source device receives, through the probe port, the probe packet sent by the destination device.

With reference to the third aspect, in some implementations of the third aspect, the system further includes a switch; the controller sends the probe virtual local area network VLAN identifier that is of the first service plane in which the first virtual machine is located to the switch; the switch receives the probe virtual local area network VLAN identifier that is of the first service plane in which the first virtual machine is located and that is sent by the controller; the switch associates the VLAN identifier with an overlay network identifier; and the switch converts, based on the associated VLAN identifier and overlay network identifier, a packet that is received by the switch and that includes the VLAN identifier into a packet in an overlay form for sending.

With reference to the third aspect, in some implementations of the third aspect, when the source device communicates with the destination device through an overlay network, the probe packet is a unicast packet, and the probe packet includes an identifier of a tunnel port of the source device.

With reference to the third aspect, in some implementations of the third aspect, the system further includes a management device; the destination device obtains, from the management device based on the identifier of the first virtual machine, the identifier of the tunnel port corresponding to the source device; and that the destination device sends a probe packet by running the probe script includes: the destination device sends the probe packet through a tunnel port of the destination device.

With reference to the third aspect, in some implementations of the third aspect, that the source device receives the probe packet sent by the destination device includes: the source device receives the probe packet through the tunnel port of the source device.

With reference to the third aspect, in some implementations of the third aspect, before that the destination device invokes the invocation message, the method further includes: the destination device sends a first message to a server, where the first message is used to request disk storage information of the first virtual machine in the server, and is used to determine a status of the first virtual machine by probing a storage plane of the first virtual machine; and the destination device receives no feedback information from the server within a predetermined time period.

With reference to the third aspect, in some implementations of the third aspect, that the destination device determines, based on the feedback information, whether to recreate the first virtual machine in the destination device includes: the destination device determines, when the feedback information indicates that the status of the first virtual machine in the source device is normal, not to recreate the first virtual machine in the destination device; or the destination device determines, when the feedback information indicates that the status of the first virtual machine in the source device is faulty, to recreate the first virtual machine in the destination device.

According to a fourth aspect, a virtual machine fault probe method is provided. The method is used to: when a high availability procedure of a first virtual machine is triggered, determine whether to recreate the first virtual machine in a destination device, and the method is performed by a switch, and includes:.

According to a fifth aspect, a destination device is provided. The destination device includes: an obtaining module, configured to obtain an invocation message, where the invocation message is used to probe the first virtual machine, where the obtaining module is further configured to obtain an identifier of the first virtual machine; an invocation module, configured to invoke a probe script based on the invocation message, and transfer the identifier of the first virtual machine to the probe script; a sending module, configured to send a probe packet by running the probe script, where the probe packet is used to probe a status of the first virtual machine in the source device, and the probe packet includes the identifier of the first virtual machine; a receiving module, configured to receive feedback information sent by the source device, where the feedback information is used to indicate the status of the first virtual machine; and a determining module, configured to determine, based on the feedback information, whether to recreate the first virtual machine in the destination device.

With reference to the fifth aspect, in some implementations of the fifth aspect, when a probe port of the source device and a probe port of the destination device are located in a same virtual local area network, the probe packet is a broadcast packet, and the probe packet includes a probe virtual local area network VLAN identifier of a service plane in which the first virtual machine is located.

With reference to the fifth aspect, in some implementations of the fifth aspect, the receiving module is further configured to receive the probe virtual local area network VLAN identifier that is of the first service plane in which the first virtual machine is located and that is sent by a management device; and the destination device further includes a configuration module, configured to: configure the probe port in the first service plane, and configure the probe virtual local area network VLAN identifier for the probe port; and
the sending module is specifically configured to: send the probe packet through the probe port.

With reference to the fifth aspect, in some implementations of the fifth aspect, when the source device communicates with the destination device through an overlay network, the probe packet is a unicast packet, and the probe packet includes an identifier of a tunnel port of the source device.

With reference to the fifth aspect, in some implementations of the fifth aspect, the obtaining module is further configured to obtain, from the management device based on the identifier of the first virtual machine, the identifier of the tunnel port corresponding to the source device; and
the sending module is specifically configured to: send the probe packet through a tunnel port of the destination device.

With reference to the fifth aspect, in some implementations of the fifth aspect, the sending module is further configured to send a first message to a server, where the first message is used to request disk storage information of the first virtual machine in the server, and is used to determine a status of the first virtual machine by probing a storage plane of the first virtual machine; and the receiving module is further configured to receive no feedback information from the server within a predetermined time period.

With reference to the fifth aspect, in some implementations of the fifth aspect, the determining module is specifically configured to: determine, when the feedback information indicates that the status of the first virtual machine in the source device is normal, not to recreate the first virtual machine in the destination device; or determine, when the feedback information indicates that the status of the first virtual machine in the source device is faulty, to recreate the first virtual machine in the destination device.

According to a six aspect, a source device is provided. The source device includes: a receiving module, configured to receive a probe packet sent by a destination device, where the probe packet is used to probe a status of the first virtual machine in the source device, and the probe packet includes an identifier of the first virtual machine; a query module, configured to query for the status of the first virtual machine based on the probe packet; and a sending module, configured to send feedback information to the destination device, where the feedback information is used to indicate the status of the first virtual machine in the source device.

With reference to the six aspect, in some implementations of the six aspect, when a probe port of the source device and a probe port of the destination device are located in a same virtual local area network, the probe packet is a broadcast packet, and the probe packet includes a probe virtual local area network VLAN identifier of a service plane in which the first virtual machine is located.

With reference to the six aspect, in some implementations of the six aspect, the receiving module is further configured to receive the probe virtual local area network VLAN identifier that is of the first service plane in which the first virtual machine is located and that is sent by a management device; and the source device further includes a configuration module, configured to: configure the probe port in the first service plane, and configure the probe virtual local area network VLAN identifier for the probe port; and
the receiving module is specifically configured to: receive, through the probe port, the probe packet sent by the destination device.

With reference to the six aspect, in some implementations of the six aspect, when the source device communicates with the destination device through an overlay network, the probe packet is a unicast packet, and the probe packet includes an identifier of a tunnel port of the source device.

With reference to the six aspect, in some implementations of the six aspect, the receiving module is specifically configured to: receive, through the tunnel port of the source device, the probe packet.

According to a seventh aspect, a destination device is provided. The destination device includes at least one processor, a memory, and an interface, where the interface is used for communication with a source device, the memory is configured to store computer program code, the computer program code includes an instruction, and the stored instruction is directly or indirectly executed by the at least one processor, so that the destination device can perform the method in any one of the first aspect or the optional implementations of the first aspect.

According to an eighth aspect, a source device is provided. The source device includes at least one processor, a memory, and an interface, where the interface is used for communication with a destination device, the memory is configured to store computer program code, the computer program code includes an instruction, and when the at least one processor executes the instruction, the source device performs the method in any one of the second aspect or the optional implementations of the second aspect.

According to a ninth aspect, a chip system is provided. The chip system includes at least one processor. The at least one processor is configured to execute a stored instruction, so that a destination device can perform the method in any one of the first aspect or the optional implementations of the first aspect.

According to a tenth aspect, a chip system is provided. The chip system includes at least one processor. The at least one processor is configured to execute a stored instruction, so that a source device can perform the method in any one of the second aspect or the optional implementations of the second aspect.

According to an eleventh aspect, a computer program product is provided. The computer program product includes an instruction, and when the instruction is executed, a destination device can be enabled to perform the method in any one of the first aspect or the optional implementations of the first aspect.

According to a twelfth aspect, a computer program product is provided. The computer program product includes an instruction, and when the instruction is executed, a source device can be enabled to perform the method in any one of the second aspect or the optional implementations of the second aspect.

According to a thirteenth aspect, a computer storage medium is provided. The computer storage medium stores a program instruction, and when the instruction is executed, the destination device can perform the method in any one of the first aspect or the optional implementations of the first aspect.

According to a fourteenth aspect, a computer storage medium is provided. The computer storage medium stores a program instruction, and when the instruction is executed, the source device can perform the method in any one of the second aspect or the optional implementations of the second aspect.

The technical solutions of the embodiments of this application may be applied to various communications systems, such as a global system for mobile communications (GSM) system, a code division multiple access (CDMA) system, a wideband code division multiple access (WCDMA) system, a general packet radio service (GPRS) system, a long term evolution (LTE) system, an LTE frequency division duplex (FDD) system, an LTE time division duplex (TDD) system, a universal mobile telecommunications system (UMTS), a worldwide interoperability for microwave access (WiMAX) communications system, a 5th generation (<NUM>) system, and a new radio (NR) system.

A destination device and a source device in the embodiments of this application may be referred to as user equipment, an access terminal, a subscriber unit, a subscriber station, a mobile station, a mobile console, a remote station, a remote terminal, a mobile device, a user terminal, a terminal, a wireless communications device, a user agent, or a user apparatus. The terminal device may further be a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having a wireless communication function, a computing device, another processing device connected to a wireless modem, a vehicle-mounted device, a wearable device, a terminal device in a future <NUM> network, a terminal device in a future evolved public land mobile network (PLMN), or the like. This is not limited in the embodiments of this application.

<FIG> is a schematic block diagram of an architecture of a system <NUM> for a virtual machine status probe method and a device according to this application. As shown in <FIG>, the architecture of the system <NUM> includes a management device <NUM>, a destination device <NUM>, and a source device <NUM>. Different virtual machines may be created in the destination device <NUM> and the source device <NUM>. The management device <NUM> is configured to manage the destination device <NUM> and the source device <NUM>, for example, send, to the destination device <NUM> and the source device <NUM>, some configuration information used to create and configure a virtual machine, and the like.

It should be noted that, <FIG> is merely a diagram of an example architecture. In addition to function units shown in <FIG>, a plurality of other physical devices may further be included in the architecture of the system. This is not limited in this embodiment of this application.

A virtual machine status probe method provided in this application may be applied to a destination device and a source device. The destination device and the source device each include a hardware layer, an operating system layer running on the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and a memory (also referred to as a main memory). The operating system may be any one or more types of computer operating systems that process a service by using a process , for example, a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a windows operating system. The application layer includes applications such as a browser, a contact list, text processing software, and instant communication software.

In addition, aspects or features of this application may be implemented as a method, an apparatus, or a product that uses standard programming and/or an engineering technology. The term "product" used in this application covers a computer program that can be accessed from any computer-readable component, carrier or medium. For example, the computer-readable medium may include but is not limited to: a magnetic storage component (for example, a hard disk, a floppy disk, or a magnetic tape), an optical disc (for example, a compact disc (CD), a digital versatile disc (DVD), a smart card, and a flash memory component (for example, an erasable programmable read-only memory (EPROM), a card, a stick, or a key drive). In addition, various storage media described in this specification may indicate one or more devices and/or other machine-readable media that are configured to store information. The term "machine-readable media" may include but is not limited to various media that can store, contain, and/or carry an instruction and/or data.

<FIG> is a schematic block diagram of a physical host according to this application. An example in which the physical host is the destination device <NUM> is used for description. The physical host <NUM> includes a hardware layer <NUM>, a virtual machine monitor (VMM) <NUM> running on the hardware layer <NUM>, and one or more virtual machines (VM) <NUM> running on the VMM <NUM>. The hardware layer <NUM> may include a processor <NUM>, a physical memory <NUM>, a hard disk <NUM>, and a network interface device <NUM>. There may be one or more processors <NUM>. The network interface device <NUM> may be a network adapter or a network interface card, configured to connect to any connectable network such as the internet or an enterprise network. The VM <NUM> may include a virtual processor <NUM>, a virtual memory <NUM>, a virtual hard disk <NUM>, and a guest operating system (Guest OS) <NUM>, where the Guest OS <NUM> is an operating system running on virtual devices such as the virtual processor <NUM>, the virtual memory <NUM>, and the virtual hard disk <NUM>.

It should be understood that the physical host shown in <FIG> is merely an example, and should not constitute a special limitation on the embodiments of this application. The physical host shown in <FIG> may be the destination device or the source device in this application. The destination device may also be referred to as a destination device, and the source device may also be referred to as a source device.

The following describes in detail a virtual machine status probe method provided in this application with reference to <FIG> is a schematic flowchart of a virtual machine status probe method <NUM> according to an embodiment of this application. The method <NUM> may be applied to the system shown in <FIG>, or certainly may be applied to another system. This is not limited in this embodiment of this application.

As shown in <FIG>, the method <NUM> includes the following content.

In <NUM>, when a high availability procedure of a first virtual machine is triggered, the destination device obtains invocation message, where the invocation message is used to probe the first virtual machine.

In <NUM>, the destination device obtains an identifier of the first virtual machine.

In <NUM>, the destination device invokes a probe script based on the invocation message, and transfers the identifier of the first virtual machine to the probe script.

In <NUM>, the destination device sends a probe packet by running the probe script, where the probe packet is used to probe a status of the first virtual machine in the source device, and the probe packet includes the identifier of the first virtual machine.

In <NUM>, the source device receives the probe packet sent by the destination device.

In <NUM>, the source device queries for the status of the first virtual machine based on the probe packet.

In <NUM>, the source device sends feedback information to the destination device, where the feedback information is used to indicate the status of the first virtual machine in the source device.

In <NUM>, the destination device receives the feedback information sent by the source device.

In <NUM>, the destination device determines, based on the feedback information, whether to recreate the first virtual machine in the destination device.

Therefore, in this embodiment of this application, if in an HA system, a virtual machine creation procedure is triggered in a destination device, the destination device in which a first virtual machine needs to be recreated sends a probe packet to a source device in which the first virtual machine is located, where the probe packet is used to probe whether the first virtual machine runs in the source device. The destination device determines, based on the feedback information sent by the source device, whether to configure the first virtual machine in the destination device. This improves reliability of probing whether the virtual machine in the source device is faulty, and effectively avoids occurrence of a virtual machine split brain.

It should be understood that the probing a virtual machine status means probing a running status of the virtual machine in the source device, that is, whether the virtual machine is faulty and cannot run normally in the source device.

Optionally, when a probe port of the source device and a probe port of the destination device are located in a same virtual local area network, the probe packet is a broadcast packet, and the probe packet includes a probe virtual local area network (VLAN) identifier of a first service plane in which the first virtual machine is located.

Optionally, the destination device receives the probe virtual local area network VLAN identifier. The destination device configures the probe port in the first service plane, and configures the probe virtual local area network VLAN identifier for the probe port. That the destination device sends a probe packet by running the probe script includes: the destination device sends the probe packet through the probe port.

Optionally, the source device receives the probe virtual local area network VLAN identifier sent by a management device. The source device configures the probe port in the first service plane, and configures the probe virtual local area network VLAN identifier for the probe port. That the source device receives the probe packet sent by the destination device includes: the source device receives, through the probe port, the probe packet sent by the destination device.

Optionally, when the source device communicates with the destination device through an overlay network, the probe packet is a unicast packet, and the probe packet includes an identifier of a tunnel port of the source device.

Optionally, the system further includes a management device. The destination device obtains, from the management device based on the identifier of the first virtual machine, the identifier of the tunnel port corresponding to the source device. That the destination device sends a probe packet by running the probe script includes: the destination device sends the probe packet through a tunnel port of the destination device.

Optionally, that the source device receives the probe packet sent by the destination device includes: the source device receives the probe packet through the tunnel port of the source device.

Optionally, before that the destination device sends an invocation message, the method further includes: the destination device sends a first message to a server, where the first message is used to request disk storage information of the first virtual machine in the server, and is used to determine a status of the first virtual machine by probing a storage plane of the first virtual machine; and the destination device receives no feedback information from the server within a predetermined time period.

Optionally, that the destination device determines, based on the feedback information, whether to recreate the first virtual machine in the destination device includes: when the feedback information indicates that the status of the first virtual machine in the source device is normal, the destination device determines not to recreate the first virtual machine in the destination device; or when the feedback information indicates that the status of the first virtual machine in the source device is faulty, the destination device determines to recreate the first virtual machine in the destination device.

For clearer understanding of this application, the following describes the method <NUM> in detail in different application scenarios, for example, a VLAN scenario, an overlay scenario, and a scenario of interconnection with a third-party software-defined network (SDN) controller.

<FIG> is a schematic block diagram of an application scenario <NUM> of a virtual machine status probe method according to this application. The application scenario <NUM> is a virtual local area network (VLAN). A VLAN is a logical network segment divided from a local area network. A VLAN field (VLAN ID, VID) is used to identify a VLAN. A length of the VID is <NUM> bits and a value range is from <NUM> to <NUM>. <NUM> and <NUM> are reserved values and cannot be used by a user. Therefore, one Ethernet can be divided into a maximum of <NUM> VLANs. The application scenario <NUM> includes a management interface <NUM>, a management node <NUM>, a source device <NUM>, and a destination device <NUM>.

The management interface <NUM> is an interface-based installation and deployment tool, and an administrator uses the management interface <NUM> to configure a physical plane of a virtual machine and a probe identifier (where the probe identifier may also be referred to as a probe VLAN) of the physical plane.

The management node <NUM> includes a management configuration service module. The module is mainly configured to: receive configuration information that is delivered by the administrator by using the management interface <NUM>, and trigger, based on the configuration information, a client in a corresponding host to implement configuration or modify a corresponding configuration. The management node <NUM> is responsible for monitoring a running status of a virtual machine in each host, and when the management node <NUM> finds that a virtual machine in a host is faulty, an HA procedure may be triggered to re-configure the virtual machine in another host.

A first virtual machine (Virtual Machine <NUM>, VM <NUM>) is configured in the source device <NUM>, and the source device further includes a probe module <NUM>, a client <NUM>, and a probe port <NUM>. The probe module <NUM> may provide a capability of sending a user-defined broadcast probe packet, and receive a probe packet to probe whether a virtual machine is alive. The client <NUM> is configured to: receive the configuration information sent by the management node <NUM>, and perform a related operation to complete a configuration change. The probe port <NUM> is a probe port of a corresponding physical plane, and the probe module <NUM> sends and receives a packet through the probe port <NUM>.

The destination device <NUM> includes a probe module <NUM>, a client <NUM>, a probe port <NUM>, and a management module <NUM>. For the probe module <NUM>, the client <NUM>, and the probe port <NUM>, refer to corresponding descriptions of those in the source device <NUM>. The management module <NUM> is responsible for computing virtualization management, and is configured to create and manage a virtual machine deployed in the destination device.

It should be understood that the application scenario shown in <FIG> is merely for clearer understanding of this application, and should not constitute a special limitation on this embodiment of this application. For example, in addition to the source device <NUM> and the destination device <NUM>, another host may further be managed by the management node, and the application scenario <NUM> may further include another management node. Other virtual machines may be further configured in the source device <NUM> and the destination device <NUM>. Modular units configured in the source device <NUM> and the destination device <NUM> should be consistent. The source device <NUM> may alternatively be a destination device, and the destination device <NUM> may alternatively be a source device. For example, if a VM <NUM> is configured in the destination device <NUM>, and if the VM <NUM> needs to be configured in the source device <NUM> in an HA application scenario, the destination device <NUM> may be referred to as a source device, and the source device <NUM> may be referred to as a destination device.

For clearer understanding of this application, the following describes a specific procedure of this application in detail.

The identifier of the service plane in which the VM <NUM> is located is determined by obtaining, by the management module <NUM>, a network used by the VM to perform communication and based on a mapping relationship between the network and a physical plane.

Optionally, the invocation message may be an application programming interface (API), and the application programming interface triggers the probe module <NUM> to execute the probe script.

Optionally, before the management module <NUM> in the destination device <NUM> sends the invocation message to the probe module <NUM>, the destination device <NUM> triggers storage plane probe for the VM <NUM>, but receives no feedback information from a storage server <NUM> within a specified time. Further, the management module <NUM> sends the invocation message to the probe module <NUM>, and probes the virtual machine in the service plane.

The following describes, with reference to <FIG>, how the destination device <NUM> performs storage plane probe. As shown in <FIG>, the application scenario <NUM> may further include a server <NUM>. The server <NUM> is a shared storage unit in the application scenario <NUM>. Each virtual machine in the application scenario <NUM> uses shared storage. A storage space in the server <NUM> is allocated to each virtual machine, and when the virtual machine runs normally, the storage space corresponding to the virtual machine is locked. The storage space corresponding to the virtual machine is not locked only when the virtual machine is abnormal. For example, at a moment t<NUM>, the VM <NUM> is created in the source device <NUM>, the VM <NUM> obtains a storage space <NUM> in the server <NUM>, and the storage space <NUM> is locked at the moment t<NUM>. If the HA application scenario is caused by a non-virtual machine fault, when the destination device <NUM> determines to configure the VM <NUM>, the destination device <NUM> obtains the storage space <NUM> from the server <NUM> when creating the VM <NUM>, but the storage space <NUM> is locked. Therefore, the destination device <NUM> no longer creates the VM1. This can avoid occurrence of a virtual machine split brain.

However, the storage plane probe depends on the shared storage. If the virtual machine uses local storage, the storage plane probe cannot be performed. In addition, if the server that provides the shared storage is faulty, or a software application scenario of the shared storage is faulty, probe on the storage plane may be affected. Therefore, when the storage plane probe is abnormal, or the application scenario in which the virtual machine is located does not support the storage plane probe, a virtual machine running status may be probed by using a service plane in which the virtual machine is located, in other words, as described above, in the HA application scenario, when the destination device <NUM> determines to configure the VM <NUM>, the management module <NUM> in the destination device <NUM> sends an invocation message to the probe module <NUM>, where the invocation message is used to trigger the probe module <NUM> to execute a probe script, and the invocation message includes the identifier of the VM <NUM> and the identifier of the service plane in which the VM <NUM> is located. Therefore, if incorrect determining or a failure occurs when whether the virtual machine is faulty is probed in the storage plane, the destination device further sends a probe packet to the source device in which the first virtual machine is located, to probe whether the first virtual machine runs normally in the source device. This improves reliability of probing whether the virtual machine in the source device is faulty, and effectively avoids occurrence of a virtual machine split brain.

Optionally, the identifier of the VM <NUM> may be an IP address of the VM <NUM>, or may be a label of the VM <NUM>, or a type of mark information. In this embodiment of this application, an example in which the identifier of the VM <NUM> is the IP address of the VM <NUM> is used for description.

The probe module <NUM> in the destination device <NUM> sends the probe packet to the probe port <NUM>. The probe packet is a broadcast packet, and the probe packet includes the identifier of the VM <NUM> and the identifier of the service plane in which the VM <NUM> is located.

Optionally, a destination MAC address of the probe packet is "ff:ff:ff:ff:ff:ff', indicating that the probe packet is the broadcast packet.

The probe packet is received through the probe port <NUM>, of the service plane physnet <NUM>, in the source device <NUM>.

After the probe packet sent by the destination device <NUM> is received through the probe port <NUM>, of the service plane physnet <NUM>, in the source device <NUM>, the probe packet is sent to the probe module <NUM>, and the probe module <NUM> obtains the identifier of the VM <NUM> carried in the probe packet, queries, by using a libvirt interface, whether the corresponding VM <NUM> runs normally, and feeds back a query result to the destination device <NUM>. A transfer path of the feedback information is opposite to a transfer path of the probe packet. To be specific, the probe module <NUM> sends the feedback information to the probe port <NUM>, the probe port <NUM> of the destination device <NUM> receives the feedback information, and sends the feedback information to the probe module <NUM>, and the probe module <NUM> transfers the feedback information to the management module <NUM>.

Optionally, a command for querying, by using the libvirt interface, whether the corresponding VM <NUM> runs normally may be:
(libvirt. open("qemu:///system"). lookupByUUIDString(vm_uuid). isActive()).

When receiving the command, the VM <NUM> sends feedback information to the probe module <NUM> based on a running status of the VM <NUM>, where the feedback information may be true or false, where true indicates that the virtual machine VM <NUM> runs normally, and false indicates that the virtual machine VM <NUM> is faulty.

The management module <NUM> in the destination device <NUM> determines, based on whether the VM <NUM> runs normally that is fed back by the source device <NUM>, whether to configure the virtual machine VM <NUM> in the destination device <NUM>; and.

Therefore, in this embodiment of this application, if in an HA application scenario, a virtual machine creation procedure is triggered in a destination device, the destination device in which a first virtual machine needs to be recreated sends a probe packet to a source device in which the first virtual machine is located, where the probe packet is used to probe whether the first virtual machine runs in the source device. The destination device determines, based on the feedback information sent by the source device, whether to configure the first virtual machine in the destination device. This improves reliability of probing whether the virtual machine in the source device is faulty, and effectively avoids occurrence of a virtual machine split brain.

<FIG> is schematic block diagram of an application scenario <NUM> of a virtual machine status probe method according to this application. The application scenario <NUM> is an overlay network. An existing overlay network mainly includes a virtual extensible local area network (virtual extensible LAN, VxLAN), network virtualization using generic routing encapsulation (NVGRE), and stateless transport tunneling (STT). The application scenario <NUM> includes a management node <NUM>, a source device <NUM>, and a destination device <NUM>.

The management node <NUM> includes a network management service module, and the network management service module is mainly configured to create and manage a related network resource.

A first virtual machine (Virtual Machine <NUM>, VM <NUM>) is configured in the source device <NUM>, and the source device further includes a probe module <NUM> and a tunnel <NUM> (where the tunnel <NUM> may also be referred to as a data network plane interface). The probe module <NUM> may provide a capability of sending a user-defined broadcast probe packet, and receive a probe packet to probe whether a virtual machine is alive. The tunnel <NUM> is configured to send and receive a packet.

The destination device <NUM> includes a probe module <NUM>, a tunnel <NUM>, and a management module <NUM>. For the probe module <NUM> and the tunnel <NUM>, refer to corresponding descriptions of those in the source device <NUM>. The management module <NUM> is responsible for computing virtualization management, and is configured to create and manage a virtual machine deployed in the destination device.

Optionally, the management module <NUM> in the destination device <NUM> may obtain, based on an API provided by the management node <NUM>, the identifier of the tunnel in the source device <NUM> in which the VM1 is located.

Optionally, the identifier of the tunnel may be an IP address of the tunnel, or may be a label of the tunnel, or may be a type of mark information. In this embodiment of this application, an example in which the identifier of the tunnel is the IP address of the tunnel is used for description.

Optionally, before the management module <NUM> in the destination device <NUM> obtains, from the network management service module in the management node <NUM>, the identifier of the tunnel in the source device <NUM> in which the VM <NUM> is located, the destination device <NUM> triggers storage plane probe for the VM <NUM>, but receives no feedback information from a storage server within a specified time. Further, the management module <NUM> obtains, from the network management service module in the management node <NUM>, the identifier of the tunnel in the source device <NUM> in which the VM <NUM> is located.

For a specific process in which the destination device <NUM> triggers storage plane probe for the VM <NUM>, refer to related descriptions in <FIG>. To avoid repetition, details are not described herein again.

The management module <NUM> in the destination device <NUM> sends an invocation message to the probe module <NUM>, where the invocation message is used to trigger the probe module <NUM> to send a probe packet, and the invocation message includes an identifier of the VM <NUM> and the identifier of the tunnel in the source device <NUM> in which the VM <NUM> is located.

The probe module <NUM> in the destination device <NUM> sends the probe packet, where the probe packet is a unicast probe packet, a destination address of the probe packet is an IP address of the source device <NUM>, and the probe packet further includes the identifier of the virtual machine.

The probe packet is received through the tunnel <NUM> in the source device <NUM>.

The probe packet is sent to the probe module <NUM> through the tunnel <NUM> in the source device <NUM>.

The probe module <NUM> obtains the identifier of the VM <NUM> carried in the probe packet, queries, by using a libvirt interface, whether the corresponding VM <NUM> runs normally, and feeds back a query result to the destination device <NUM>. A transfer path of the feedback information is opposite to a transfer path of the probe packet. To be specific, the probe module <NUM> sends the feedback information to the tunnel <NUM>, the tunnel <NUM> of the destination device <NUM> receives the feedback information, and sends the feedback information to the probe module <NUM>, and the probe module <NUM> transfers the feedback information to the management module <NUM>.

<FIG> is schematic block diagram of an application scenario <NUM> of a virtual machine status probe method and a device according to this application. The application scenario <NUM> is a virtual extensible local area network (virtual extensible LAN, VxLAN) in virtual interconnection with a third-party software-defined network (SDN). The application scenario <NUM> includes a management node <NUM>, a configuration interface <NUM>, a management interface <NUM>, a source device <NUM>, a destination device <NUM>, a switch <NUM>, a switch <NUM>, and a third-party controller <NUM>. In this application scenario, a VxLAN network is mapped as a VLAN network. It should be understood that the VxLAN network is only a form of an overlay network. In this application, another overlay may alternatively be mapped as the VLAN network. For a specific implementation of mapping the another overlay as the VLAN network, refer to a process of mapping the VxLAN network as the VLAN network.

The management node <NUM> includes a network management service module <NUM> and a management configuration service module <NUM>. The network management service module <NUM> is mainly configured to create and manage a related network resource. The management configuration service module <NUM> is mainly configured to receive configuration information delivered by an administrator by using the management interface <NUM>, and trigger, based on the configuration information, a client in a corresponding host to implement configuration or modify a corresponding configuration. When a virtual machine is created, when an administrator specifies a service network of the virtual machine as a VxLAN network, the network management service module <NUM> maps the VxLAN network as a VLAN network through hierarchical binding, so that a packet of the virtual machine can be forwarded in a manner in the VLAN network, and when the packet is sent to a switch, the packet is forwarded in a manner of forwarding the packet in the VxLAN network.

For the configuration interface <NUM>, the administrator may perform, by using the configuration interface <NUM>, interconnection configuration between a third-party SDN controller and the VxLAN. The administrator sends, by using the configuration interface <NUM> to the network management service module <NUM> in the management node <NUM>, an identifier of a service plane mapped from the VxLAN network. The network management service module <NUM> stores a mapping relationship of the service plane mapped from the VxLAN network.

The management interface <NUM> is an interface-based installation and deployment tool. The administrator sends, by using the management interface to the destination device <NUM>, the identifier of the service plane mapped from the VxLAN network. The management module <NUM> in the destination device <NUM> records the mapping relationship of the service plane mapped from the VxLAN network. The administrator uses the management interface <NUM> to configure a physical plane of a virtual machine and a probe identifier (where the probe identifier may also be referred to as a probe VLAN) of the physical plane.

A first virtual machine (Virtual Machine <NUM>, VM <NUM>) is configured in the source device <NUM>, and the source device further includes a probe module <NUM>, a client <NUM>, and a probe port <NUM>. The probe module <NUM> may provide a capability of sending a user-defined broadcast probe packet, and receive a probe packet to probe whether a virtual machine is alive. The client <NUM> is configured to receive the configuration information sent by the management node <NUM>, and perform a related operation to complete a configuration change. The probe port <NUM> is a probe port of a corresponding physical plane, and the probe module <NUM> sends and receives a packet through the probe port <NUM>.

The switch <NUM> and the switch <NUM> are configured to transmit a packet.

The third-party controller <NUM> may implement configuration of the switch <NUM> and the switch <NUM>.

It should be understood that the application scenario shown in <FIG> is merely for clearer understanding of this application, and should not constitute a special limitation on this embodiment of this application. For example, in addition to the source device <NUM> and the destination device <NUM>, another host may further be managed by the management node, and the application scenario <NUM> may further include another management node. Other virtual machines may be further configured in the source device <NUM> and the destination device <NUM>. Modular units configured in the source device <NUM> and the destination device <NUM> should be consistent. The source device <NUM> may alternatively be a destination device, and the destination device <NUM> may alternatively be a source device.

Optionally, before the management module <NUM> in the destination device <NUM> sends the invocation message to the probe module <NUM>, the destination device <NUM> triggers storage plane probe for the VM <NUM>, but receives no feedback information from a storage server within a specified time. Further, the management module <NUM> sends the invocation message to the probe module <NUM>, and probes the virtual machine in the service plane.

For a specific procedure in which the destination device <NUM> triggers storage plane probe for the VM <NUM>, refer to related descriptions in <FIG>.

The broadcast packet sent by the probe port <NUM> is transferred to the switch <NUM>, and the switch <NUM> identifies the probe packet based on a VLAN probe identifier carried in the probe packet, encapsulates the probe packet from an original VLAN network packet format into a VxLAN network packet format, and sends the encapsulated packet to the switch <NUM>.

Specifically, the packet format of the VLAN probe packet is shown in <FIG>. The packet format is defined in an <NUM>. 1Q standard, and the VLAN packet includes a destination MAC address, a source MAC address, an <NUM>. 1Q tag, a type, data, and a check bit FCS. 1Q field is added to an Ethernet frame format defined in the <NUM>. 1Q standard based on a traditional Ethernet frame format. The field includes four parts: Type, PRI, CFI, and VID. Meanings of the four parts are as follows:.

Type has a length of two bytes, and indicates a frame type. A Type field in an <NUM>. 1Q tag frame has a fixed value of 0x8100. If a device that does not support <NUM>. 1Q receives an <NUM>. 1Q frame, the device discards the frame.

A priority (PRI) field has a length of three bits, indicates a priority of the Ethernet frame, and has a value ranging from <NUM> to <NUM>. A larger value indicates a higher priority. When transmission congestion occurs in a switch or router, the switch or router preferentially sends a high-priority data frame.

A canonical format indicator (CFI) has a length of one bit, and indicates whether a MAC address is in a classic format. A CFI having a value of <NUM> indicates that a MAC address is in a classic format. A CFI having a value of <NUM> indicates that a MAC address is not in a classic format. This field is used to distinguish between an Ethernet frame, an FDDI frame, and a token ring network frame. In the Ethernet frame, a CFI has a value of <NUM>.

A local area network ID (VLAN ID, VID) has a length of <NUM> bits, and has a value ranging from <NUM> to <NUM>. <NUM> and <NUM> are reserved values and cannot be used. This field uniquely identifies a VLAN. The VID having a length of <NUM> bits can represent <NUM> different values. One Ethernet can be divided into a maximum of <NUM> VLANs other than VlANs of the two reserved values.

The VxLAN encapsulates, in a physical network, a data frame for communication in a logical network for transmission, and a process of encapsulation and decapsulation is completed by the switch <NUM>. After adding a VxLAN header to the data frame in the logical network, the VxLAN encapsulates the data frame into a UDP packet in the physical network for transmission. A format of the VxLAN header is shown in <FIG>. The VxLAN header includes eight bytes, and the first byte is a flag bit. If a flag bit I is set to <NUM>, it indicates that the VXLAN header is valid. Other flags are reserved and should be set to <NUM> during transmission. The second byte to the fourth byte are reserved. The fifth byte to the seventh byte are VXLAN identifiers, used to indicate a unique logical network. The eighth byte is also a reserved field and is not used temporarily.

After adding the VxLAN header to the data frame of the logical link network, the switch <NUM> sequentially adds a user datagram protocol (UDP) header, an IP header, and an Ethernet frame header, and then sends the data frame to the switch <NUM>.

It should be understood that if there are a plurality of hosts managed by the management node, and each host corresponds to a corresponding switch, the encapsulated packet is sent to the plurality of switches.

The switch <NUM> sends the encapsulated packet to the switch <NUM>.

The switch <NUM> sends the probe packet to the source device <NUM>.

The probe port <NUM>, of the service plane physnet <NUM>, in the source device <NUM>, receives the probe packet.

After receiving the probe packet sent by the destination device <NUM>, the probe port <NUM>, of the service plane physnet <NUM>, in the source device <NUM>, sends the probe packet to the probe module <NUM>, and the probe module <NUM> obtains the identifier of the VM <NUM> carried in the probe packet, queries, by using a libvirt interface, whether the corresponding VM <NUM> runs normally, and feeds back a query result to the destination device <NUM>. A transfer path of the feedback information is opposite to a transfer path of the probe packet. To be specific, the probe module <NUM> sends the feedback information to the probe port <NUM>, then the switch <NUM>, the switch <NUM>, and the probe port <NUM> that is of the destination device <NUM> sequentially receive the feedback information, and the probe port <NUM> sends the feedback information to the probe module <NUM>, and the probe module <NUM> transfers the feedback information to the management module <NUM>.

The management module <NUM> in the destination device <NUM> determines, based on whether the VM <NUM> runs normally that is fed back by the source device <NUM>, whether to configure the virtual machine VM <NUM> in the destination device <NUM>.

This application further provides a system. The system includes a destination device and a source device, and includes:.

The destination device obtains invocation message when a high availability procedure of a first virtual machine is triggered, where the invocation message is used to probe the first virtual machine. The destination device obtains an identifier of the first virtual machine. The destination device invokes a probe script based on the invocation message, and transfers the identifier of the first virtual machine to the probe script. The destination device sends a probe packet by running the probe script, where the probe packet is used to probe a status of the first virtual machine in the source device, and the probe packet includes the identifier of the first virtual machine. The source device receives the probe packet sent by the destination device. The source device queries for the status of the first virtual machine based on the probe packet. The source device sends feedback information to the destination device, where the feedback information is used to indicate the status of the first virtual machine in the source device. The destination device receives the feedback information sent by the source device. The destination device determines, based on the feedback information, whether to recreate the first virtual machine in the destination device.

Optionally, when a probe port of the source device and a probe port of the destination device are located in a same virtual local area network, the probe packet is a broadcast packet, and the probe packet includes a probe virtual local area network identifier of a first service plane in which the first virtual machine is located.

Optionally, the system further includes a management device. The management device receives the probe virtual local area network VLAN identifier of the first service plane, and sends the probe virtual local area network VLAN identifier to the source device and the destination device.

Optionally, the destination device receives the probe virtual local area network VLAN identifier.

The destination device configures the probe port in the first service plane, and configures the probe virtual local area network VLAN identifier for the probe port. That the destination device sends a probe packet by running the probe script includes: the destination device sends the probe packet through the probe port.

Optionally, the source device receives the probe virtual local area network VLAN identifier sent by the management device. The source device configures the probe port in the first service plane, and configures the probe virtual local area network VLAN identifier for the probe port. That the source device receives the probe packet sent by the destination device includes: the source device receives, through the probe port, the probe packet sent by the destination device.

Optionally, the system further includes a switch. The controller sends the probe virtual local area network VLAN identifier of the first service plane in which the first virtual machine is located to the switch. The switch receives the probe virtual local area network VLAN identifier that is of the first service plane in which the first virtual machine is located and that is sent by the controller, associates the VLAN identifier with an overlay network identifier, and converts, based on the associated VLAN identifier and overlay network identifier, a packet that is received by the switch and that includes the VLAN identifier into a packet in an overlay form for sending.

It should be understood that, for understanding of the source device and the destination device in the system, refer to the descriptions in the foregoing embodiments. To avoid repetition, details are not described herein again.

<FIG> is a schematic block diagram of a destination device <NUM> according to this application. As shown in <FIG>, the destination device includes the following modules:.

Optionally, the obtaining module <NUM>, the invocation module <NUM>, the sending module <NUM>, the receiving module <NUM>, and the determining module <NUM> are configured to perform the operations of the virtual machine fault probe method <NUM> in this application. For brevity, details are not described herein again.

<FIG> is a schematic block diagram of a source device <NUM> according to this application. As shown in <FIG>, the source device includes the following modules:.

Optionally, the receiving module <NUM>, the query module <NUM>, and the sending module <NUM> are configured to perform the operations of the virtual machine fault probe method <NUM> in this application. For brevity, details are not described herein again.

The foregoing destination device and source device completely correspond to the destination device and the source device in the method embodiments. Corresponding modules perform corresponding steps. For details, refer to the corresponding method embodiments.

<FIG> is a schematic block diagram of a device <NUM> according to this application. The device <NUM> includes:
a memory <NUM>, a processor <NUM>, and an input/output interface <NUM>. The memory <NUM>, the processor <NUM>, and the input/output interface <NUM> are connected by using an internal connection path. The memory <NUM> is configured to store a program instruction. The processor <NUM> is configured to execute the program instruction stored in the memory <NUM>, to control the input/output interface <NUM> to receive input data and information, and output data such as an operation result.

Optionally, when the program instruction is executed, the processor <NUM> may implement the operations of the method <NUM>. For brevity, details are not described herein again. The input/output interface <NUM> is configured to perform, under driving of the processor <NUM>, specific signal receiving and sending.

The device <NUM> may be the foregoing source device or destination device, and performs operations of the determining module, the query module, and the invocation module. The input/output interface <NUM> performs corresponding steps of the sending module and the receiving module.

It should be understood that, in this embodiment of this application, the processor <NUM> may be a central processing unit (CPU), or the processor <NUM> may be another general purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or another programmable logic device, a discrete gate or a transistor logic device, a discrete hardware component, or the like.

A person of ordinary skill in the art may be aware that, in combination with units and algorithm steps of the examples described in the embodiments disclosed in this specification, this application may be implemented by electronic hardware or a combination of computer software and electronic hardware.

For example, the described apparatus embodiments are merely examples. For example, the unit division is merely logical function division and may be other division during actual implementation.

When the functions are implemented in the form of a software function unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of this application essentially, or the part contributing to the prior art, or some of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium, and includes several instructions for instructing a computer device (which may be a personal computer, a server, a network device, or the like) to perform all or some of the steps of the methods described in the embodiments of this application. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc.

Claim 1:
A virtual machine status probe method in a system comprising
a destination device having a probe port; and
a source device having a probe port and running a first virtual machine, wherein the first virtual machine is located in a first service plane;
wherein the probe port of the source device (<NUM>) and the probe port of the destination device (<NUM>) are located in a same VLAN;
a management device storing a probe virtual local area network VLAN identifier of the service plane in which the first virtual machine is located;
wherein the method is performed by the destination device (<NUM>), and comprises:
when a high availability procedure of the first virtual machine is triggered,
obtaining (<NUM>), (<NUM>) from the management device (<NUM>) an invocation message comprising an identifier of the first virtual machine and the probe virtual local area network VLAN identifier of the first service plane;
configuring the probe port of the destination device (<NUM>) in the first service plane, and configuring the probe virtual VLAN identifier for the probe port of the destination device (<NUM>);
sending (<NUM>) a probe packet through the probe port of the destination device (<NUM>) to the source device (<NUM>), wherein the probe packet is used to probe a status of the first virtual machine in the source device (<NUM>), the probe packet is a broadcast packet, and the probe packet comprises the obtained identifier of the first virtual machine and the obtained identifier of the probe VLAN;
receiving (<NUM>) feedback information sent by the source device (<NUM>), wherein the feedback information is used to indicate the status of the first virtual machine; and
determining, based on the feedback information, whether to recreate the first virtual machine in the destination device (<NUM>).