WO2018157543A1

WO2018157543A1 - Timer implementation method and related device

Info

Publication number: WO2018157543A1
Application number: PCT/CN2017/094935
Authority: WO
Inventors: 杨华志; 熊鹰; 吴昊
Original assignee: 华为技术有限公司
Priority date: 2017-02-28
Filing date: 2017-07-28
Publication date: 2018-09-07
Also published as: CN108512780B; CN108512780A

Abstract

The present application relates to the field of computers, and more specifically to timer implementation technology. In a timer implementation method, a virtual machine receives a packet queue comprising a timer packet, wherein the timer packet is inserted at fixed time according to a precision timer outside the virtual machine; the virtual machine parses the packet in the packet queue, determines the type of the parsed packet, and executes a preset timer action in response to the type of the parsed packet being a timer packet. Compared with the prior art, in the solution provided by the present application, the manner of executing a timer action using a timer inside a virtual machine is abandoned, while the manner of executing a preset timer action according to a timer packet is used. The timer packet is inserted at fixed time according to the precision timer outside the virtual machine, and therefore, the timer packet will not be influenced by the virtual machine being unable to work, and the timer action executed according to the timer packet is punctual.

Description

Timer implementation method and related device

The present application claims the priority of the Chinese Patent Application, filed on Feb. 28, 2017, the application Serial No. .

Technical field

This application relates to the field of computers and, more particularly, to timer implementation techniques.

Background technique

The virtualization technology of virtual machine software (VMware), Kernel-based Virtual Machine (KVM) and other environments is to virtualize the physical resources of one physical machine into multiple virtual machines (Virtual Machine). , VM), so that each VM can implement the functions of the physical machine.

In the current mode, the virtual machine performs a preset timer action according to an internal timer. The above timer actions may include, for example, timing refresh information, timing execution of specific actions, calculation of accurate time intervals, and the like.

However, virtual machine work depends on the scheduling of the physical CPU (that is, running on the physical CPU). If multiple virtual machines are deployed on a physical CPU, the virtual CPU may not be scheduled in time for a virtual machine. For example, the physical CPU may not be scheduled in time due to preemption by other processes. When the virtual machine is not scheduled in time, the internal timer of the virtual machine cannot work normally, which affects the on-time execution of the timer action.

Summary of the invention

In view of this, the purpose of the embodiments of the present application is to provide a timer implementation method and related apparatus to solve the above problem.

To achieve the above objective, the embodiments of the present application provide the following technical solutions:

In one aspect, an embodiment of the present application provides a timer implementation method, including: receiving a message queue; wherein the message queue includes a timer message, and the timer message is based on an external precision timer. And the timer is inserted into the packet queue; the packet in the packet queue is parsed to determine the type of the parsed packet; and the preset timer is executed in response to the type of the parsed packet being a timer packet. action. The above method can be applied to a virtualized scenario and executed by a virtual machine. In this scenario, in one example, a timer packet can be generated by the virtual switch OVS and periodically inserted into the message queue. In the virtualization scenario, the method for implementing the timer provided by the embodiment of the present application discards the manner in which the timer is executed by using the timer inside the virtual machine, and the preset timer action is performed according to the timer message. The timer message is inserted according to the timing of the virtual external precision timer. Therefore, the timer message is not affected by the virtual machine being inoperable. The timer action executed according to the timer message is punctual. In addition, the above method can also be applied to a non-virtualized scenario, which is performed by the receiver of the message. The receiver of such a message can also perform timer actions without using its internal timer.

In a possible design, when applied to a virtualization scenario, the above external precision timer is the host. Timer. Since the timer on the host can guarantee the accuracy, it is guaranteed that the timer action performed according to the timer message is punctual.

In a possible design, the timer message is periodically inserted into the message queue by the virtual switch OVS according to the host timer. In this way, as long as the messages in the message queue can be processed in sequence, the preset timer action can be executed on time.

In a possible design, the content of the timer message includes at least the current time information. The timer packet contains the current time information, which is beneficial for the virtual machine to obtain the time interval between the two timer packets, and determines whether to perform some timer actions according to the time interval. In addition, when needed, the virtual machine can also update the current time of the system according to the time information in the timer message.

In a possible design, the timer packet is an Ethernet packet to be consistent with the service packet.

In another aspect, the embodiment of the present application provides a method for implementing a timer executed by a virtual switch OVS, the method includes: receiving a packet; and when the received packet needs to be sent to a virtual machine, placing the packet The packet is forwarded to the packet queued by the virtual machine; the timer packet is periodically inserted into the packet queue; the timer packet is used by the virtual machine to perform a preset timer action; Message queue. In an example, the timing insertion timer message includes: inserting a timer message according to a host timer timing.

In another aspect, an embodiment of the present application provides a timer implementation apparatus, where the timer implementation apparatus has a function of implementing virtual machine behavior in the actual method. The functions may be implemented by hardware or by corresponding software implemented by hardware.

In another aspect, an embodiment of the present application provides a timer implementation apparatus, where the timer implementation apparatus has a function of implementing a virtual switch behavior in the actual method. The functions may be implemented by hardware or by corresponding software implemented by hardware.

In another aspect, the embodiment of the present application provides a host Host, where the Host includes: an OVS running on the Host and an intermediate software layer Hypervisor, where the Hypervisor runs at least one virtual machine VM; Method The function of virtual machine behavior in practice.

In another aspect, the embodiment of the present application provides a host Host, where the Host includes: an OVS running on the Host and an intermediate software layer Hypervisor, where the Hypervisor runs at least one virtual machine VM; the OVS has the above implementation. The method actually functions in OVS behavior.

In still another aspect, the present application provides a computer readable storage medium having instructions stored therein that, when executed on a computer, cause the computer to perform the methods described in the above aspects.

In still another aspect, the present application provides a computer program product comprising instructions that, when run on a computer, cause the computer to perform the methods described in the various aspects above.

Compared with the prior art, in the solution provided by the present application, the manner in which the timer action is executed by using the timer inside the virtual machine is discarded, and the preset timer action is performed according to the timer message. The timer message is inserted according to the timing of the virtual external precision timer. Therefore, the timer message is not affected by the virtual machine being inoperable. The timer action executed according to the timer message is punctual.

DRAWINGS

1 is a schematic diagram showing an example of a structure of a virtualization system based on a physical host provided by an embodiment of the present application;

2 is a schematic diagram of an application scenario of an OVS and a VM according to an embodiment of the present application;

3 and 5 are interaction flowcharts of a method for implementing a timer according to an embodiment of the present application;

FIG. 4a is a diagram showing a virtual machine refresh and packet reception when a virtual machine is scheduled in time in the existing mode;

Figure 4b shows the virtual machine refresh and packet reception when the virtual machine is not scheduled in time in the existing mode;

FIG. 4c is a packet receiving situation of the virtual machine during t0 to t2 when the virtual machine is not scheduled in time according to the embodiment provided by the present application;

FIG. 6 is an exemplary structural diagram of a virtual machine according to an embodiment of the present application;

FIG. 7 is an exemplary structural diagram of a virtual switch according to an embodiment of the present application.

detailed description

The embodiment of the present application provides a timer implementation method and related devices (a timer implementation device, a host device, a physical host, and a virtual host system based on a physical host) to solve the problem that the timer action cannot be performed on time.

The physical host may include the hard disk 110, the central processing unit 111, the network interface card 112, and the memory 113 shown in FIG.

A possible structural diagram of the virtualization system 104 built on the above physical host can be seen in FIG. 1 and includes three parts, namely, a hardware platform 100 (or a hardware layer), an intermediate software layer (Hypervisor) 101, and a virtual device. Machine execution space 102.

A hard disk 110, a central processing unit 111, a network interface card 112, and a memory 113 may be included in the hardware platform 100.

Hypervisor 101 and virtual machine execution space 102 provide a hardware platform and a software platform for the virtual machine, respectively. Hypervisor 101 runs on the host and is an intermediate layer of software running between the physical server and the operating system, allowing multiple operating systems and applications to share a single set of physical hardware.

Among them, the hypervisor 101 includes virtual machine monitors 120a, 120b ̈ ̈ 120n. Hypervisor is the middle layer between physical hardware and virtual machines, and is responsible for coordinating the access of each virtual machine to the hardware platform. The virtual machine monitor includes a virtual hardware platform that implements the virtual machine.

In FIG. 1, the virtual machine monitor 120a includes a virtual hardware platform 121a. The virtual hardware platform includes a virtual memory 122, a central processing unit 123, a hard disk 124, a graphics card 125, a network interface card 126, and the like. A plurality of virtual machines 103a, 103b ̈ ̈ 103n are run in the virtual machine execution space 102. The software system of the virtual machine 103a runs on the virtual hardware platform 121a of the virtual machine monitor 120a, and the software systems of the other virtual machines also run on the virtual hardware platform of the corresponding virtual machine monitor.

The guest operating system 110 runs in the virtual machine 103a. The guest operating system 110 includes a device driver layer 132. The device driver layer 132 is installed with drivers such as a virtual display driver 134 and a network interface card driver 136.

A virtual switch (Opens Switch, OVS) is also running on the host.

Figure 2 shows an application scenario of OVS and VM: VMs (VM1, VM2) on different physical hosts, one as a client and one as a server, which can communicate through OVS.

Of course, in other application scenarios, the two VMs on the same physical host can also communicate through the OVS.

OVS is an open source Open Switch-based softswitch that can be deployed on Linux servers. OVS and VM running on the same physical host can form a small switching network. In non-through mode or pass-through mode (such as Single-Root I/O Virtualization (SR-IOV)) deployment, OVS is often connected under virtual firewalls and virtual routers.

OVS works like a physical switch. The physical network card and multiple virtual network cards are connected to the two ends of the OVS. At the same time, the OVS maintains a mapping table, and searches for the corresponding virtual machine link according to the MAC address to complete data forwarding.

The virtual machines 103a, 103b ̈ 103n can perform timer operations. The above timer actions may include, for example, timing refresh information, timing execution of specific actions, calculation of accurate time intervals, processing of traffic rate sensitive services, and the like.

The timer implementation method provided in the embodiments shown in FIG. 3 and FIG. 5 can be implemented by the interaction between the OVS and the VM.

From the hardware point of view, the central processing unit 111 executes the program stored in the memory 113, and calls other devices, and can be used to implement the timer implementation method provided in the embodiments shown in FIG.

The embodiments of the present application will be further described in detail below based on the common aspects of the present application.

FIG. 3 illustrates an exemplary interaction flow of the above timer implementation method, including:

300, OVS receives the message;

The OVS can receive service packets from different senders, for example, can receive service packets sent by other physical devices. The physical host where the OVS is located and the other physical devices can be connected through a mobile communication system, a data network, or the like.

More specifically, referring to Figure 2, OVS2 running on Host B can receive service packets sent by VM1 on other physical hosts.

In addition, the OVS can also receive service packets sent by VMs on the same physical host.

301. When the received message needs to be sent to the VM, the OVS puts the message into the message queue.

More specifically, the OVS can find a corresponding VM according to the Medium/Media Access Control (MAC) address of the packet, and put the packet into the packet queue corresponding to the VM.

Each virtual machine has at least one virtual network card, each virtual network card has a MAC address, and the MAC addresses of different virtual network cards are different from each other.

The OVS generates a queue corresponding to the virtual network card included in the virtual machine for the virtual machine running on the same physical host as the OVS. It can be understood that each generated message queue corresponds to the MAC address of the virtual network card.

After receiving the packet, the OVS obtains the destination MAC address of the packet and searches for the queue corresponding to the destination MAC address. And put the message into the queue that was found.

Taking OVS 2 in FIG. 2 as an example, since VM2 has only one virtual network card in FIG. 2, OVS 2 generates a queue corresponding to the virtual network card of VM2, and the queue corresponds to the MAC address of the virtual network card of VM2. After receiving the packet, the OVS 2 obtains the destination MAC address of the packet. If the destination MAC address of the packet is the same as the MAC address of the virtual network adapter of the VM2, the packet is placed in the queue corresponding to the virtual network adapter of the VM2. .

302. The OVS periodically inserts a timer packet in the message queue.

The above timer message can be inserted according to the precision timer outside the VM. In one example, since the OVS is running on the Host, the OVS can periodically insert timer messages according to the Host timer. The Host timer is accurate, which ensures the accuracy of subsequent VMs performing timer actions based on timer messages.

In addition, in other embodiments of the present application, in addition to the timer on the Host where the OVS is located, the timer message may be inserted according to other precision timers. For example, in a high-speed link, a timer message can be inserted into a transmitted message by the sender of the message. Alternatively, timer messages can be inserted periodically by an independent timer module on the host.

The timer message is interspersed in the service packet and is used by the VM to perform a preset timer action. The timer action will be introduced later in this article and will not be described here.

303. The OVS forwards the packet to the VM and inserts a packet queue of the timer packet.

More specifically, the OVS can forward packets in the message queue according to the mapping table.

The VM receives the message queue (including the timer message), and the "receive message queue" can be understood as the message in the received message queue.

More specifically, the message in the message queue can be received by the virtual network card of the VM, and the message is stored in a fixed storage area.

304. The VM parses the packet in the packet queue to determine the type of the parsed packet.

In one example, the message may be parsed by a Guest application (eg, a message processing application or a message forwarding application) in the VM to determine the type of the message.

It should be noted that the guest application needs to process the packets in the message queue in sequence, so that the time interval between two adjacent timer messages is fixed.

305. The VM performs a preset timer action in response to the type of the parsed message being a timer message.

Most of the current servers use Ethernet interfaces. The service packets received by the VM are also Ethernet packets. The timer packet can also be a standard Ethernet packet, so that the service packet can be consistent with the service packet.

The packet format of the timer packet is shown in the following Table 1:

Table 1

In Table 1, 0xffffffffffff indicates a broadcast address. For the case where the VM internal service processing has a Mac address filtering function, using the broadcast address as the destination MAC ensures that all VMs can receive the timer message without being filtered out.

The protocol type in Table 1 is used to characterize the type of timer message. In a specific implementation, a non-universal protocol type may be selected to represent the type of the timer message to avoid confusion with the service message using the general protocol.

In one example, the content of the timer message can include at least the current time information. The current time information here may refer to the generation time of the timer message.

The current time information is included in the timer packet, which facilitates the VM to calculate the time interval between the two timer packets, and determines whether to perform some timer actions according to the time interval. The interval between two adjacent timers is set to milliseconds by default. The exact level can be configured as required.

Assume that on the VM, the first timer action corresponding to service A is to refresh the information every 10 milliseconds, and the second timer action corresponding to service B is to send heartbeat information every 20 milliseconds, and so on. And assume two adjacent timers The interval between messages is 10 milliseconds. then:

Each time a timer message is determined, a first timer action is performed; each time a timer message is determined, a second timer action is performed.

More specifically, the Guest application can notify the corresponding execution module to perform a timer action. In the previous example, the guest application can notify the execution module of the service A to perform the first timer action, and notify the execution module of the service B to perform the second timer action.

In addition, the VM can update the current time of the system according to the time information in the timer message when needed.

It can be seen that, compared with the prior art, in the solution provided by the present application, the manner in which the timer action is executed by using the timer inside the virtual machine is discarded, and the preset timer action is performed according to the timer message. At the same time, the timer packet is inserted according to the timing of the virtual external precision timer. Therefore, the timer packet is not affected by the virtual machine being inoperable. The timer action performed according to the timer packet is punctual.

The following will be explained by way of example comparison. Compared with the prior art, the solution provided by the present application makes the timer action on time.

Taking a VM as a virtual gateway (virtual firewall or virtual router) as an example, the virtual gateway needs to run traffic rate sensitive services such as distributed denial of service (DDOS) defense services and bandwidth limiting services. These traffic rate sensitive services rely on "unit time rate", such as "number of packets per second", "number of connections per second", and so on.

The unit time rate in turn depends on the exact time interval and the amount of traffic processed in the exact time interval. Taking the number of packets per second as an example, assuming that the number of packets per second required for a type A packet is 100, the virtual machine allocates 100 forwarding rights for the type A packet every second. The virtual machine needs to refresh the forwarding permission every 1 second (reconfigure the forwarding permissions to 100).

In one second, each time a message of type A is forwarded, the forwarding authority is decremented by one. If the forwarding permission drops to 0 but has not yet reached 1 second, the VM discards the type A packets that have not been forwarded. That is, if the number of A-type packets received by the virtual machine in one second is 200, then 100 packets need to be discarded and not forwarded when forwarding.

In the existing method, since the forwarding authority is refreshed according to the timer inside the VM, the internal timer of the VM cannot work normally if the VM cannot be scheduled in time. As a result, packet loss of the traffic rate service is caused.

Referring to Figure 4a, assume that the VM should refresh the forwarding rights at times t ₀ , t _{1 ,} and t ₂ when scheduled in time. For the sake of simplicity, it is assumed that 200 A type messages are received in the two periods t ₀ to t ₁ and t ₁ to t ₂ , respectively.

Then at time t _1, 100 forwards a refresh permission, will after a period t ₀ ~ t ₁ of type A 200 receives packets forwarding: the first 100 packets are forwarded, the packet 100 It will be discarded. Similarly, at time t ₂ , the forwarding permission update will be refreshed to 100, and then the same forwarding processing will be performed on the 200 A-type packets received during the t ₁ to t ₂ period. Therefore, between t ₀ and t ₂ , a total of 200 messages are discarded.

And if the VM has not been scheduled in time, see Figure 4b, assuming VM not scheduled at time t _1, is scheduled at time t _2, the VM can not refresh permission to forward at time t _1, at time t ₂ while the refresh permission to forward . At this time, the VM is to process the 400 Type A packets received during the period from t ₀ to t ₂ , and the virtual machine discards 300 Type A packets according to the forwarding authority.

It can be seen that compared with the case of timely scheduling, the existing method will result in an additional 100 packets that cannot be forwarded, resulting in packet loss. Moreover, during the period from t ₀ to t ₂ , only 100 packets are forwarded, and the number of packets per second becomes 50, so that the requirements of the traffic rate sensitive service cannot be met.

Similarly, other timer actions may become inaccurate due to the virtual machine not being scheduled in time.

The use of the present embodiment is provided herein, refer to Figure 4C, still assuming _a VM is not scheduled at time t, is scheduled at time t _2. Then the VM receives 400 Type A packets during the period from t ₀ to t ₂ . In addition, in the 400 Type A packets, two timer messages are interspersed, one is the OVS inserted at time t ₁ One is that OVS is inserted at time t ₂ . For the sake of distinction, it may be referred to as a first timer message and a second timer message.

In fact, the ability of the VM to process messages is very powerful and can process multiple messages quickly. As the two timer packets are interspersed with the packets of the type A, the VM will discard the first 100 packets before the first timer packet. When the second timer packet is determined, the last 100 packets between the first timer packet and the second timer packet are discarded. In this way, compared with the case of timely scheduling, the solution provided by the present application also discards a total of 200 messages. Thus, the solution provided by the present application does not discard additional messages compared to the existing methods. The number of packets per second is still 100, which meets the requirements of traffic rate sensitive services.

It should be noted that, in the present application, the unit time rate depends on the “relative” time interval and the number of services processed in the “relative” time interval, and the “relative” time interval is determined according to the adjacent two timer messages. . The timer packet is inserted according to the timing of the external precision timer. The relative time interval determined by the timer packet is also accurate. This ensures the accuracy of the unit time rate and ensures the accuracy of the traffic rate sensitive service. .

The following provides a more detailed description of the solution provided by the present application by taking the scenario shown in FIG. 2 as an example.

The scenario shown in Figure 2 is based on the aforementioned SR-IOV. SR-IOV technology is a hardware-based virtualization solution that allows efficient sharing of Peripheral Component Interconnect Express (PCIe) devices between VMs, and it is implemented in hardware, creating new Virtual machines allow VMs to be directly connected to I/O devices for I/O performance comparable to native performance.

In Figure 2, VM1 and VM2 are two virtual firewalls or routers, one as a client and one as a server, which are respectively deployed on hosts of different physical hosts. The two physical hosts communicate through a physical switch (SWITCH).

OVS is running on both Hosts (Host A and Host B).

The physical network card and the virtual network card are respectively connected to the two ends of the OVS. A virtual network card layer (tap) device is connected between the OVS and the VM's virtual network card. The tap device is a virtual network interface device on Linux, which is equal to the Ethernet device. OVS can send packets to the virtual network card of the VM through tap.

FIG. 5 illustrates another exemplary interaction flow of a timer implementation method based on the scenario illustrated in FIG. 2, including:

501. VM1 sends a service packet to the queue of Host A through the internal driver, the virtual network card 1 and the tap1.

502. The OVS1 on the Host A forwards the packet according to the forwarding table (or the mapping table), and the packet is sent to the physical network card 1.

503. The packet is sent out from the physical network card 1, and the physical network card 2 receives the packet.

Any physical NIC can send or receive packets in the existing mode. Of course, there is no new way to send or receive packets in the future.

The packet received by physical NIC 2 is sent to OVS2 on Host B.

504. The OVS2 on the Host B finds that the received packet needs to be sent to the VM2 and puts the packet into the packet queue.

Section 504 is similar to step 301 of the foregoing embodiment. For related descriptions, refer to the foregoing description, and details are not described herein.

505. The OVS2 periodically inserts a timer packet in the message queue.

In one example, step 505 may be performed by adding a timer processing unit to the OVS.

Step 505 is configured to periodically inject a timer message before the packet is sent to the VM.

In other embodiments of the present application, the timer processing unit may be directly integrated on various virtualized or non-virtualized interfaces, and the timer message is injected periodically before the packet queue is sent to the VM.

505 is similar to step 302 of the previous embodiment. For related description, refer to the foregoing description, and details are not described herein.

506. The OVS2 sends the message queue inserted into the timer packet to tap2.

507. Tap2 sends the message queue to the virtual network card of VM2.

Steps 506 and 507 are specific implementations of the foregoing step 303. For related descriptions, refer to the foregoing description, and details are not described herein.

508. The internal service of VM2 receives the packet through the Data Plane Development Kit (DPDK) or the socket (socket), and then parses the packet, forwards the service, and parses the packet. When the type is timer message, the preset timer action is executed.

For related descriptions, refer to the description of steps 304-305 of the foregoing embodiment, and details are not described herein.

More specifically, step 508 can be completed by a message processing application or a message forwarding application running on the VM. The message processing application or the message forwarding application can perform preset timer actions during the processing of the message. In this process, it is not necessary to maintain the internal timer asynchronously.

It should be noted that, besides the non-virtualized scenario, a non-virtualized scenario can adopt a similar solution:

The timer sender can periodically insert a timer message into the message queue, and the receiver of the message performs a preset timer action according to the timer message. In this way, even if the internal timer of the message receiver is inaccurate, the accuracy of the timer action can be guaranteed.

The embodiment of the present invention also claims a physical host. An exemplary structure of the physical host can be seen in FIG. 1 , including a hardware layer and a Host running on the hardware layer. OVS and Hypervisor are running on the Host, and at least one VM is running on the Hypervisor.

Among them, the VM has the function of realizing the virtual machine behavior in the above method, and the OVS has the function of realizing the OVS behavior in the above method.

The embodiment of the present invention also claims the foregoing Host. As mentioned above, there are OVS and Hypervisor running on the Host and at least one VM running on the Hypervisor.

FIG. 6 shows an exemplary structure of the above VM, including:

The first receiving unit 61 is configured to receive a message queue.

The packet queue includes a timer packet, and the timer packet is periodically inserted into the packet queue according to an accurate timer external to the VM.

For related descriptions, please refer to the foregoing descriptions herein, and no further details are provided herein.

The parsing unit 62 is configured to parse the packet in the packet queue, and determine the type of the parsed packet;

The executing unit 63 is configured to perform a preset timer action in response to the type of the parsed message being a timer message.

Fig. 7 shows an exemplary structure of the above OVS, including:

a second receiving unit 71, configured to receive a message;

The message distribution unit 72 puts the message into the message queue when the received message needs to be sent to the virtual machine.

The packet queue is forwarded to the virtual machine.

The timer processing unit 73 is configured to periodically insert a timer message in the message queue, where the timer message is used by the virtual machine to perform a preset timer action;

The forwarding unit 74 is configured to forward a message queue in which the timer packet is inserted.

The second receiving unit 71 is configured to perform the step 300 of the embodiment shown in FIG. 3, and receive the service packet sent by the physical network card 2 in step 503 of the embodiment shown in FIG. 5;

The message distribution unit 72 can be used to perform step 301 of the embodiment shown in FIG. 3, and step 504 of the embodiment shown in FIG. 5;

The timer processing unit 73 can be used to perform step 302 of the embodiment shown in FIG. 3, and step 505 of the embodiment shown in FIG. 5;

The forwarding unit 74 is configured to perform the step 303 of the embodiment shown in FIG. 3 and the step 506 of the embodiment shown in FIG. 5; the first receiving unit 61 is configured to receive the message queue forwarded by the forwarding unit 74;

The parsing unit 62 can be used to perform step 304 of the embodiment shown in FIG. 3, and the parsing operation in step 508 of the embodiment shown in FIG. 5;

The executing unit 63 can be used to perform step 305 of the embodiment shown in FIG. 3, and can perform the service forwarding and the preset timer action in step 508 of the embodiment shown in FIG. 5.

The embodiment of the present application also claims a timer implementation device. Specifically, the timer implementation device may be the aforementioned VM or the aforementioned OVS.

When the timer implementation device is a VM, an exemplary structure thereof can be referred to FIG. 6; and when the timer implementation device is an OVS, an exemplary structure thereof can be seen in FIG. 7.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with embodiments of the present application are generated in whole or in part. The computer can be universal Computer, special purpose computer, computer network or other programmable device. The computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage. For example, the computer instructions can be routed from one website site, computer, server or data center to another website via wire (eg, coaxial cable, fiber optic, digital subscriber (DSL)) or wireless (eg, infrared, wireless, microwave, etc.) Transfer from a site, computer, server, or data center. The computer readable storage medium can be any available media that can be accessed by a computer or a data storage device such as a server, data center, or the like that includes one or more available media. The usable medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a Solid State Disk (SSD)).

The specific embodiments of the present invention have been described in detail with reference to the specific embodiments of the present application. It is to be understood that the foregoing description is only The scope of protection, any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the present application are included in the scope of protection of the present application.

Claims

A method for implementing a timer, which is characterized by being applied to a virtual machine, including:

Receiving a message queue, wherein the message queue includes a timer message, and the timer message is periodically inserted into the message queue according to an accurate timer external to the virtual machine;

Parsing the packet in the packet queue to determine the type of the parsed packet;

In response to the type of the parsed message being a timer message, a preset timer action is performed.
The method of claim 1 wherein said external precision timer is a host timer.
The method of claim 2, wherein the timer message is periodically inserted into the message queue by the virtual switch OVS according to a host timer.
The method of claim 1, wherein the content of the timer message includes at least current time information.
The method according to any one of claims 1 to 4, wherein the timer message is an Ethernet message.
A timer implementation method is characterized in that it is applied to a virtual switch OVS, including:

Receiving a message;

When the received packet needs to be sent to the virtual machine, the packet is placed in the packet queue forwarded to the virtual machine;

Inserting a timer packet periodically in the packet queue; the timer packet is used by the virtual machine to perform a preset timer action;

Forwards the packet queue for inserting timer packets.
The method according to claim 6, wherein the timing insertion timer message comprises: inserting a timer message according to a timer of the host machine.
The method according to claim 6 or 7, wherein the content of the timer message includes at least current time information.
A timer implementation device, comprising:

a first receiving unit, configured to receive a message queue, where the message queue includes a timer message, and the timer message is inserted into the newspaper according to an accurate timer external to the timer implementation device. Queue

a parsing unit, configured to parse the packet in the packet queue, and determine a type of the parsed packet;

The executing unit is configured to execute a preset timer action in response to the type of the parsed message being a timer message.
The apparatus of claim 9 wherein said external precision timer is a host timer.
The apparatus according to claim 10, wherein the timer message is periodically inserted into the message queue by the virtual switch OVS according to a host timer.
The apparatus according to claim 9, wherein the content of the timer message includes at least current time information.
The device according to any one of claims 9 to 12, wherein the timer message is an Ethernet message.
A timer implementation device, comprising:

a second receiving unit, configured to receive a message;

The message distribution unit, when the received message needs to be sent to the virtual machine, puts the message into the message queue; the message queue will be forwarded to the virtual machine;

a timer processing unit, configured to periodically insert a timer message in the message queue; the timer message is used by the virtual machine to perform a preset timer action;

A forwarding unit is configured to forward a message queue in which a timer packet is inserted.
The device of claim 14, wherein the timer processing unit is configured to insert a timer message according to a timer of the host timer.
A host machine Host, characterized in that it comprises:

a virtual switch OVS running on the Host and an intermediate software layer Hypervisor, where the hypervisor runs at least one virtual machine VM;

Wherein the VM comprises:

a first receiving unit, configured to receive a message queue, where the message queue includes a timer message, and the timer message is periodically inserted into the message queue according to an accurate timer external to the VM. ;

a parsing unit, configured to parse the packet in the packet queue, and determine a type of the parsed packet;

The executing unit is configured to execute a preset timer action in response to the type of the parsed message being a timer message.
The host according to claim 16, wherein the timer message is periodically inserted into the message queue by the virtual switch OVS according to a host timer.
A host machine Host, characterized in that it comprises:

a virtual switch OVS running on the Host and an intermediate software layer Hypervisor, where the hypervisor runs at least one virtual machine VM;

Wherein the OVS comprises:

a second receiving unit, configured to receive a message;

The message distribution unit puts the message into the message queue forwarded to the VM when the received message needs to be sent to the VM;

a timer processing unit, configured to periodically insert a timer message in the message queue; the timer message is used by the VM to perform a preset timer action;

A forwarding unit is configured to forward a message queue in which a timer packet is inserted.
The host according to claim 18, wherein in the timing of inserting a timer message, the timer processing unit is specifically configured to: insert a timer message according to a timer of the host.
A physical host, comprising: a hardware layer, a host Host running on the hardware layer, a virtual switch OVS running on the Host, and an intermediate software layer Hypervisor, the Hypervisor running at least a virtual machine VM;

Wherein the VM is used to:

Receiving a message queue, wherein the message queue includes a timer message, and the timer message is periodically inserted into the message queue according to an accurate timer external to the virtual machine;

Parsing the packet in the packet queue to determine the type of the parsed packet;

In response to the type of the parsed message being a timer message, a preset timer action is performed.
A physical host, comprising: a hardware layer, a host Host running on the hardware layer, a virtual switch OVS running on the Host, and an intermediate software layer Hypervisor, the Hypervisor running at least a virtual machine VM; where

The OVS is used to:

Receiving a message;

When the received packet needs to be sent to the virtual machine, the packet is placed in the packet queue forwarded to the virtual machine;

Inserting a timer packet periodically in the packet queue; the timer packet is used by the virtual machine to perform a preset timer action;

Forwards the packet queue for inserting timer packets.