Device simulation method and computing device

Abstract

The embodiment of the application discloses a device simulation method and a computing device, wherein the device simulation method comprises the following steps: receiving a multicast message sent by a first virtual machine, the multicast message being used for obtaining device information of a device simulator, and the multicast message being received by a virtual machine network card of a second virtual machine; forwarding the multicast message to a virtual network bridge in the second virtual machine according to a multicast routing between the virtual machine network card of the second virtual machine and the virtual network bridge, at least one container in the second virtual machine being mounted on the virtual network bridge; sending the multicast message to the device simulator in the at least one container through the virtual network bridge; and sending a response message sent by the device simulator in one or more containers in the at least one container to the first virtual machine, wherein the response message comprises the device information of the device simulator. According to the application, the device simulation is implemented through the container, large-scale device simulation can be realized, and resources are saved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a device simulation method and a computing device. BACKGROUND

[0002] In a computer network, there is usually multicast of messages, for example, using multicast messages to query device information in a local network, for example, multicasting system information or information that changes, etc. In the industry, virtualization technology is usually used to simulate devices. Traditional device simulation schemes generally use virtual machines to simulate devices, and each virtual machine can only simulate one device. However, a single virtual machine consumes a lot of resources such as CPU and memory, so the traditional device simulation scheme requires a lot of resources. SUMMARY

[0003] In the embodiments of the present application, a device simulation method and a computing device are provided, which can realize large-scale device simulation and save resources by using containers to simulate devices.

[0004] In a first aspect, the embodiments of the present application provide a device simulation method, comprising:

[0005] receiving a multicast message sent by a first virtual machine, the multicast message being used to obtain device information of a device simulator, the multicast message being received by a virtual machine network card of a second virtual machine;

[0006] forwarding the multicast message to a virtual network bridge in the second virtual machine according to a multicast routing between the virtual machine network card of the second virtual machine and the virtual network bridge, at least one container in the second virtual machine being mounted on the virtual network bridge;

[0007] sending the multicast message to a device simulator in the at least one container through the virtual network bridge;

[0008] sending a response message sent by the device simulator in one or more containers of the at least one container to the first virtual machine, the response message including device information of the device simulator.

[0009] By implementing the method of the first aspect, when the virtual machine network card of the second virtual machine receives the multicast message of the first virtual machine, the multicast message is forwarded to the virtual network bridge according to the multicast routing between the virtual machine network card of the second virtual machine and the virtual network bridge, so that the virtual network bridge sends the multicast message to the device simulator in the at least one container mounted on the virtual network bridge. The device simulator in one or more containers of the at least one container can send a response message carrying device information to the first virtual machine. The implementation of the present application can realize that the multicast message enters the container, so that the device simulation is performed by using the container, resources are saved, and batch device simulation can also be performed.

[0010] In a possible implementation, the virtual bridge comprises at least one first virtual network card, one container of the at least one container comprises a second virtual network card, and the first virtual network card of the virtual bridge and the second virtual network card of the one container communicate through a connection channel;

[0011] The sending of the multicast message to the at least one container through the virtual bridge comprises:

[0012] The sending of the multicast message to the at least one container through the at least one connection channel between the at least one first virtual network card of the virtual bridge and the second virtual network card of the at least one container.

[0013] The method is implemented, the virtual bridge comprises at least one first virtual network card, and the at least one virtual network card respectively has a connection channel with a second virtual network card of at least one container. The multicast message can be sent to a container of a virtual machine through the connection channel between the at least one virtual network card of the virtual bridge and the virtual network card of the at least one container, so that the multicast message enters the container, and the device is simulated by using the container.

[0014] In a possible implementation, the method further comprises:

[0015] The multicast routing of the virtual network card of the second virtual machine to the virtual bridge is configured by a multicast routing tool.

[0016] The method is implemented, and the multicast routing between the virtual network card of the virtual machine and the virtual bridge of the virtual machine is configured, so that the multicast message enters the container.

[0017] In a possible implementation, the second virtual machine comprises a container creation engine, and the method further comprises:

[0018] At least one container image comprising a device simulator image is obtained, the container image is run based on the container creation engine, and the at least one container comprising the device simulator is created in the second virtual machine.

[0019] The method is implemented, and the at least one container image comprising the device simulator image is run by the container creation engine, so that the at least one container comprising the device simulator is created.

[0020] In a possible implementation, the method further comprises:

[0021] An Internet Protocol (IP) address segment is allocated for the container in the second virtual machine.

[0022] An IP address is respectively allocated for the at least one container from the IP address segment.

[0023] The response message sent by one or more containers in the at least one container to the first virtual machine comprises an IP address of the container sending the response message.

[0024] The method is implemented to allocate an IP address segment to the container in the virtual machine, so that when the container is created, an IP address can be allocated to the created container from the IP address segment, and when the container replies to a response message, the source of the response message can be identified through the IP address.

[0025] In a possible implementation, the IP address is an IPV6 address or an IPV4 address.

[0026] In a second aspect, an embodiment of the present application provides a device emulator deployment method, comprising:

[0027] creating a virtual machine network card and a virtual bridge in a virtual machine, the virtual machine network card being connected to the virtual bridge, and the virtual bridge comprising at least one first virtual network card;

[0028] deploying at least one container in the virtual machine, the container comprising a device emulator and at least one second virtual network card, and one first virtual network card of the virtual bridge and one second virtual network card of one container communicating through a connection channel, the container being configured to receive a multicast message through the connection channel and send device information of the device emulator.

[0029] In a third aspect, an embodiment of the present application provides a computing device, wherein a virtual machine is deployed in the computing device, the virtual machine comprising a virtual machine network card, a virtual bridge and at least one container, the virtual machine network card being connected to the virtual bridge, and the at least one container being mounted on the virtual bridge.

[0030] The virtual machine network card is configured to receive a multicast message and forward the multicast message to the virtual bridge.

[0031] The virtual bridge is configured to send the multicast message to a device emulator in the at least one container.

[0032] The at least one container is configured to respond to the multicast message, send a response message through the virtual bridge and the virtual machine network card, and the response message comprises device information of the device emulator.

[0033] In a possible implementation, the virtual bridge comprises at least one first virtual network card, one container in the at least one container comprises a second virtual network card, and one first virtual network card of the virtual bridge and one second virtual network card of one container communicate through a connection channel.

[0034] In a fourth aspect, an embodiment of the present application provides a computing device, comprising: a processor, a memory, the memory storing program instructions, the processor executing the program instructions to implement the method described in the first aspect or any possible implementation of the first aspect, or to implement the method described in the second aspect or any possible implementation of the second aspect.

[0035] In a fifth aspect, an embodiment of the present application further provides a computer storage medium, including computer instructions, when the computer instructions are run on a computing device, causing the computing device to execute the method described in the first aspect or any possible implementation of the first aspect, or causing the computing device to execute the method described in the second aspect or any possible implementation of the second aspect.

[0036] In a sixth aspect, an embodiment of the present application further provides a computer program product, when the computer program product is run on a computing device, causing the computing device to execute the method described in the first aspect or any possible implementation of the first aspect, or causing the computing device to execute the method described in the second aspect or any possible implementation of the second aspect.

[0037] It can be understood that the device emulator deployment method of the second aspect, the computing device of the third aspect, the fourth aspect, the computer storage medium of the fifth aspect and the computer program product of the sixth aspect all can implement the method of the first aspect. Therefore, the beneficial effects achieved thereby can refer to the corresponding beneficial effects in the first aspect, which will not be described here. BRIEF DESCRIPTION OF DRAWINGS

[0038] Figure 1A is an architecture schematic diagram of a computing device provided by an embodiment of the present application;

[0039] Figure 1A is an architecture schematic diagram of another computing device provided by an embodiment of the present application;

[0040] Figure 2A is a system architecture diagram of an SSDP device simulation provided by an embodiment of the present application;

[0041] Figure 2A is another system architecture diagram of an SSDP device simulation provided by an embodiment of the present application;

[0042] Figure 3A is a flow schematic diagram of a device simulation method provided by an embodiment of the present application;

[0043] Figure 3A is a schematic diagram of a virtual network card of a docker0 bridge and a virtual network card of a container provided by an embodiment of the present application;

[0044] Figure 4is a flowchart of another device simulation method provided by an embodiment of the present application;

[0045] Figure 5 is a schematic diagram of a SSDP device simulation system architecture provided by an embodiment of the present application;

[0046] Figure 6 is a flowchart of a device simulator deployment method provided by an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described below with reference to the drawings.

[0048] The terms "first" and "second" and the like in the specification of the present application, claims, and drawings are used only to distinguish different objects, and are not used to describe a particular order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device, etc. including a series of steps or units is not limited to the listed steps or units, but can optionally include other steps or units not listed, or can optionally include other steps or units inherent to the process, method, product, or device, etc.

[0049] In this document, "embodiment" means that the specific features, structures, or characteristics described in connection with the embodiment can be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily mean the same embodiment is referred to, nor does it mean that other embodiments are mutually exclusive or alternative to the one described. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0050] In the present application, "at least one" means one or more, "multiple" means two or more, "at least two" means two or three and more, and "and / or" is used to describe the association relationship of the associated objects, which means that there can be three relationships, for example, "A and / or B" can mean: only A, only B, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects. "At least one of the following" or similar expressions means any combination of these items. For example, at least one of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c".

[0051] Before introducing the specific embodiments of the present application, the terms of the present application are explained:

[0052] 1, SSDP

[0053] SSDP is an application layer simple service discovery protocol, which is one of the core protocols of the universal plug and play technology. The simple service discovery protocol provides a mechanism for discovering devices in a local network.

[0054] The SSDP client (i.e. the client receiving services) can query the devices providing specific services in the local network where the client is located according to its own needs by using the SSDP. The SSDP device (i.e. the server providing services) can also announce its existence to the SSDP client in the local network where the device is located by using the SSDP protocol.

[0055] 2. Container creation engine

[0056] The container creation engine can be an open source application container engine, which is a technology for realizing resource isolation between applications by means of virtualization technology of an operating system, so that the application can be quickly and conveniently packaged and deployed anywhere. It is like a container that stores the files required by the application. This standardization process of the application is called "containerization".

[0057] The Linux container technology can package or isolate the application and its entire runtime environment (including all required files) together. Thus, the application can be easily migrated between different environments (such as development, testing and production environments), while the entire functions of the application are preserved.

[0058] In some embodiments, the container creation engine in the embodiments of the present application can be a Docker engine.

[0059] 3. Static multicast router (SMCRoute)

[0060] SMCRoute is a static multicast routing daemon that provides fine-grained control over the Multicast Forwarding Cache (MFC) in the UNIX kernel. The SMCRoute technology is generally applied to the forwarding of multicast routing between network cards.

[0061] 4. Virtual machine

[0062] The virtual machine software can simulate one or more virtual computers on a physical computer, and these virtual computers work like real computers. The operating system and application programs can be installed on the virtual machine, and the virtual machine can access network resources.

[0063] For example, Figure 1AAs shown, it is a schematic diagram of the architecture of a computing device provided in an embodiment of the present application. The computing device 100 can be a server, or a gateway device or network device such as a base station or a router, or a terminal device such as a laptop, a desktop computer, a tablet computer, or a mobile phone. Among them, the server can be a file server, a domain control server, a database server, a mail server, a web server, a multimedia server, a communication server, a terminal server, an infrastructure server, a virtualization server, etc. The server can be tower-type, rack-type, blade-type, etc. The computing device 100 can adopt, but is not limited to, an X81 architecture, a reduced instruction set computer (RISC) architecture, an advanced reduced instruction set machine (ARM) architecture, etc.

[0064] like Figure 1A As shown, the computing device 100 includes a processor 110 , a communication interface 120 , and a memory 130 , wherein the processor 110 , the communication interface 120 , and the memory 130 are interconnected via an internal bus 140 .

[0065] The processor 110 may be composed of one or more general-purpose processors, such as a central processing unit (CPU), or a combination of a CPU and a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0066] The internal bus 140 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The internal bus 140 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 1A only one line is used, but it does not mean that there is only one bus or only one type of bus.

[0067] The memory 130 can include a volatile memory, such as a random access memory (RAM); the memory 130 can also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); the memory 130 can also include a combination of the above types.

[0068] It should be noted that the memory 130 stores a virtualization software program and other program modules. The virtualization software program is read and run by the processor 110 to virtualize hardware resources, including creating multiple virtual machines, etc.

[0069] The processor 110 executes computer instructions stored in the memory 130, which can implement the steps in the embodiments of the device simulation method. Here, it will not be repeated that the memory 130 can also store data.

[0070] It should be understood that the computing device 100 can use an embedded system, such as a Linux system, etc. The computing device 100 can adopt a layered architecture, which can include but is not limited to an application layer, a system layer, a driver layer, and a hardware layer, etc.

[0071] The specific implementation of each component can also be referred to the related description in the subsequent method embodiments, which will not be repeated here.

[0072] As shown in FIG. 1, the computing device 100 includes a processor 110, a memory 130, and an internal bus 140. Figure 1B As shown in FIG. 2, another architecture schematic diagram of a computing device provided by the embodiments of the present application is shown; as shown in FIG. 3, the computing device is sequentially from bottom to top a hardware layer, a virtualization layer Hypervisor, a virtual machine, and a container deployed in the virtual machine. Figure 1B

[0073] ​The hardware layer provides a hardware platform for the virtualization environment to operate. The hardware layer may include, for example, a processor (such as a CPU) and memory, and may also include a network card, storage, high-speed / low-speed input / output (I / O) devices, etc.

[0074] The virtualization layer is responsible for virtualizing hardware resources and can virtualize multiple guest operating systems (Guest OS). One guest operating system corresponds to one virtual machine, and the virtualization layer can manage each virtual machine.

[0075] Furthermore, a container is deployed in the Guest OS of the virtual machine. In the embodiment of the present application, the SSDP device can be containerized to provide a mechanism for discovering the device in the local network.

[0076] like Figure 2A The following is a system architecture diagram of SSDP device simulation. Figure 2A In the process, virtual machines are deployed on the hypervisor of the virtualization layer, and an SSDP device simulator is deployed in each virtual machine.

[0077] The SSDP client can also be deployed in a virtual machine. The SSDP client sends an M-SEARCH multicast message. After receiving the multicast message, the SSDP device simulator sends a response message to the SSDP client. This response message includes the SSDP device simulator's device information. The SSDP client receives the device information contained in the response message to complete device discovery.

[0078] In this implementation, a virtual machine simulates an SSDP device simulator. Although the virtual machine can isolate many "sub-computers", it occupies a large amount of space. The virtual machine generally requires several GB to dozens of GB of space. In addition, each virtual machine can only simulate one SSDP device. The deployment and implementation process is relatively complicated, and batch simulation of SSDP devices cannot be achieved.

[0079] against Figure 2A To solve the problem that simulating one SSDP device with one virtual machine takes up a lot of space and cannot simulate SSDP devices in batches, this application simulates SSDP devices through a single container. Compared with the traditional use of virtual machines to simulate SSDP devices, this application can achieve fast batch simulation of SSDP devices through multicasting into containers, and the resource consumption of simulating SSDP devices is greatly reduced.

[0080] like Figure 2B As shown in FIG, another system architecture diagram of SSDP device simulation provided by an embodiment of the present application is shown in FIG. Figure 2BAs shown, multiple containers can be deployed in each virtual machine, and an SSDP device simulator is deployed in each container, i.e., the SSDP device is containerized. The SSDP client can also be deployed in a virtual machine. The SSDP client sends an M-SEARCH multicast message, and the virtualization layer of the computing device forwards the multicast message from the physical network card of the computing device to each virtual machine. Since the M-SEARCH multicast message cannot enter the container network, the application further configures the multicast routing of the virtual network card of the virtual machine to the docker0 bridge through the routing forwarding tool (e.g., SMCRoute), so as to realize forwarding the M-SEARCH multicast message to the container in the virtual machine. After the SSDP device simulator in the container of the virtual machine receives the multicast message, it replies to the SSDP client with a response message, which includes the device information of the SSDP device simulator. The SSDP client receives the device information contained in the response message to complete the discovery of the device.

[0081] Compared with Figure 2A In the application, the SSDP device is simulated by a virtual machine, Figure 2B In the application, the virtual machine is simulated by a container. Since the virtual machine generally requires several GB to several tens of GB of space, while the container only requires MB or even KB, compared with the virtual machine simulating the SSDP device, the use of the container simulating the SSDP device occupies less space. And the use of a single container to simulate the SSDP device in the application can achieve the effect of fast batch simulation of the SSDP device.

[0082] Please refer to Figure 3A A flowchart of a device simulation method provided by an embodiment of the application is shown. As shown in Figure 3A The method can include but is not limited to steps 301-304, and the execution order of each step is not limited by the embodiments of the application. As shown in Figure 3A The device simulation method of the embodiments of the application includes but is not limited to the following steps:

[0083] 301, receiving a multicast message sent by an SSDP client in a first virtual machine through a virtual machine network card of a second virtual machine.

[0084] In the embodiments of the application, the SSDP client can be deployed in the guest operating system (Guest OS) of the first virtual machine. The SSDP client sends a multicast message, which is used to obtain the device information of the SSDP device simulator in the local area network, so as to further realize the management of the SSDP client to the SSDP device simulator in the local area network.

[0085] In some embodiments, the multicast message can be a periodically sent message, and the multicast message can include a multicast address and indication information indicating a service type that needs to be queried, for example, the multicast message can be an M-SEARCH multicast message.

[0086] The SSDP client in the first virtual machine can send the multicast message to at least one second virtual machine, and the virtual machine network card of each corresponding second virtual machine receives the multicast message sent by the SSDP client. Specifically, the multicast message can be forwarded to each second virtual machine by the virtualization layer of the computing device. For ease of description, one of the second virtual machines is taken as an example.

[0087] 302, according to the pre-configured multicast routing of the virtual machine network card of the second virtual machine to the virtual bridge, the multicast message is forwarded to the virtual bridge, and the virtual bridge is the gateway of the container in the second virtual machine.

[0088] For example, when the multicast message is received, it can be judged whether the multicast address is included in the multicast message, if the multicast address is included in the multicast message, according to the pre-configured multicast routing of the virtual machine network card of the second virtual machine to the virtual bridge, the multicast message is forwarded to the virtual bridge, if the multicast address is not included in the multicast message, the multicast message is directly processed by the virtual machine, that is, the multicast message does not enter the container.

[0089] In some embodiments, the virtual bridge can be a docker0 bridge. The docker0 bridge is a virtual bridge in the virtual machine after the docker engine is installed in the virtual machine, and the containers in the same virtual machine are connected to the same docker0 bridge.

[0090] In the embodiments of the present application, the multicast routing of the virtual machine network card of the second virtual machine to the virtual bridge can be pre-configured by a multicast routing forwarding tool, for example, the SMCRoute. When the multicast message is received, the multicast message can be forwarded to the virtual bridge through the pre-configured multicast routing of the virtual machine network card of the second virtual machine to the virtual bridge.

[0091] 303, based on at least one connection channel between at least one virtual network card of the virtual bridge and the virtual network card of at least one container in the second virtual machine, the multicast message is sent to the SSDP device simulator in the at least one container. There is a connection channel between a virtual network card of a virtual bridge and a virtual network card of a container, that is, a pair of virtual network cards is formed between a virtual network card of a virtual bridge and a virtual network card of a container, and the pair of virtual network cards intercommunicate through the connection channel.

[0092] Exemplarily, if the virtual network bridge is a docker0 network bridge, the connection channel between the at least one virtual network card of the docker0 network bridge and the virtual network card of the at least one container can be based on VethPair technology for communication.

[0093] The SSDP device simulator in the embodiment of the present application can be a baseboard management controller (BMC) simulator, or a switch simulator, a smart home device simulator, and the like, that is, a device that needs to be queried in a local area network can be used as the SSDP device simulator.

[0094] Exemplarily, taking the virtual network bridge as the docker0 network bridge as an example, the at least one container is mounted on the docker0 network bridge. The docker0 network bridge includes at least one virtual network card, for the convenience of description, one virtual network card of the docker0 network bridge is referred to as a first virtual network card, and each container includes one virtual network card, for the convenience of description, the virtual network card of each container is referred to as a second virtual network card. One first virtual network card of the docker0 network bridge and one second virtual network card of one container are connected based on VethPair technology. As shown in Figure 3B The first virtual network card of the docker0 network bridge and the second virtual network card of container 1 are connected, and the other first virtual network card of the docker0 network bridge and the second virtual network card of container 2 are connected. Among them, the connection between the virtual network cards can be understood as that the message forwarding between the network cards can be realized without routing configuration.

[0095] When the multicast message is forwarded to the docker0 network bridge, the first virtual network card of the docker0 network bridge and the second virtual network card of each container are connected, and the multicast message can be forwarded from the docker0 network bridge to each container, that is, the multicast message is forwarded to the SSDP device simulator in each container. The multicast message is realized into the container, and the SSDP device simulator is simulated through the container, so that a large number of SSDP device simulators are deployed.

[0096] 304, sending the response message of the container to the SSDP client in the first virtual machine, the response message including the device information of the SSDP device simulator in the container.

[0097] The SSDP device simulator in the container receives the multicast message, and in some embodiments, the SSDP device simulator can determine, by a protocol type of the multicast message, that the multicast message is used to obtain device information of the SSDP device simulator, and the protocol type of the multicast message can be an M-SEARCH multicast message. The SSDP device simulator of the container sends a response message to the SSDP client, and the response message includes device information of the SSDP device simulator in the container.

[0098] In some embodiments, the SSDP device simulator can determine, by indication information in the multicast message, a service type that needs to be queried, and if a service type of a service provided by the SSDP simulator matches the service type indicated by the indication information, a response message is sent, and the response message includes device information of the SSDP device simulator.

[0099] For example, the device information can include, but is not limited to, at least one of the following: a service name of a service provided by the SSDP device simulator and belonging to the service type that needs to be queried, a uniform resource identifier (URI) of the service, a survival time of the SSDP device simulator, and the like.

[0100] The response message of the container can be sent to the virtual network bridge through the virtual machine network card of the second virtual machine and the virtual network card between the container, and the virtual network bridge further sends the response message to the virtual machine network card of the virtual machine according to a destination address (i.e., an address of the SSDP client in the first virtual machine) in the response message, and the virtual machine network card of the virtual machine sends the response message to the SSDP client in the first virtual machine.

[0101] In the embodiments of the present application, the multicast message can enter the container network, a single container can simulate an SSDP device, the resource consumption of the SSDP device simulation can be reduced, and since one container can simulate an SSDP device, the effect of fast batch simulation of the SSDP device can also be achieved.

[0102] Please refer to Figure 4 Another device simulation method provided by the embodiments of the present application is shown in the flowchart. As Figure 4 shown, the method can include, but is not limited to, steps 401-409, and the execution order of each step is not limited in the embodiments of the present application. As Figure 4 shown, the device simulation method of the embodiments of the present application includes, but is not limited to, the following steps:

[0103] 401, install a container creation engine in a virtual machine, and create a virtual network bridge on the virtual machine based on the container creation engine.

[0104] Exemplarily, the virtual bridge can be a docker0 bridge.

[0105] The container creation engine can be an open source application container engine, which is a technology for realizing resource isolation between applications by means of virtualization technology of an operating system, so as to enable the application to be packaged and deployed anywhere quickly and conveniently. It is like a container that stores the files required by the application. This standardization process of the application is called "containerization". The container creation engine can be a docker engine.

[0106] The docker engine is installed in the virtual machine, and a virtual bridge is created on the virtual machine when the docker engine is started. The virtual bridge is actually a bridge of the container in the virtual machine, and the container can communicate with the virtual machine and other containers through the virtual bridge.

[0107] Further optionally, an Internet Protocol (IP) address segment is allocated to the container in the virtual machine by the docker engine, that is, the IP address of the virtual network card of the container created subsequently can be allocated from the IP address segment.

[0108] Exemplarily, the ipv6 function or the ipv4 function of the docker engine can be started. If the ipv6 function is started, the IP address segment allocated above is an IPV6 address segment. It can be understood that the source address of the response message sent by the SSDP device simulator in the container is an IPV6 address. If the ipv4 function is started, the IP address segment allocated above is an IPV4 address segment. The source address of the response message sent by the SSDP device simulator in the container is an IPV4 address.

[0109] 402, configure the multicast routing of the virtual machine network card of the virtual machine to the virtual bridge by using a multicast routing tool.

[0110] In the embodiments of the present application, in order to enable the multicast message to be forwarded to the container of the virtual machine, the multicast routing forwarding tool can be used to configure the multicast routing of the virtual machine network card of the virtual machine to the virtual bridge. Specifically, the multicast routing forwarding tool can be SMCRoute, and through the SMCRoute, the message forwarding rule and / or message forwarding path of the virtual machine network card of the virtual machine to the virtual bridge can be configured. The message forwarding rule can include but is not limited to: when the multicast message contains the multicast address ff05::c, the virtual machine network card of the virtual machine forwards the multicast message to the virtual bridge; if the multicast message does not contain the multicast address ff05::c, the multicast message does not need to be forwarded to the container of the virtual machine, but is processed by the virtual machine and a response message is returned, in other words, when the multicast message does not contain the multicast address ff05::c, the virtual machine network card of the virtual machine does not forward the multicast message to the virtual bridge. For example, the multicast routing of the virtual machine network card of the virtual machine to the virtual bridge can be configured through the command "smcroutectl -I smcroute add ens160 ff05::c docker0".

[0111] 403. According to the hop number of the virtual machine network card of the virtual machine to the virtual bridge, the value of the life cycle parameter of the multicast message is updated, and the life cycle parameter is used to indicate the forwarding hop number of the multicast message.

[0112] In the embodiments of the present application, in order to enable the multicast message to be further forwarded from the virtual machine to the container, the Time To Live (TTL) parameter of the multicast routing can be updated according to the hop number of the virtual machine network card of the virtual machine to the virtual bridge. For example, the TTL parameter is updated from a first value to a second value, the first value is used to indicate the hop number of the multicast message from the SSDP client to the virtual machine, and the second value is used to indicate the hop number of the multicast message from the SSDP client to the container of the virtual machine. For example, the first value can be 1, and the second value can be 2, and the process of updating the TTL parameter is to add 1 to the value of the TTL parameter. It can be understood that the difference between the second value and the first value is used to indicate the hop number of the multicast message from the virtual machine to the virtual bridge.

[0113] 404. At least one container is created and mounted on the virtual bridge, and each container includes a device emulator.

[0114] The device emulator in the embodiments of the present application can be an SSDP device emulator. For example, the device emulator can be a Baseboard Management Controller (BMC) emulator, a switch emulator, a smart home appliance emulator, etc., which is not limited in the present application.

[0115] In the embodiment of the present application, a container image including a device emulator image is obtained, and the container image is run based on a container creation engine to create at least one container including a device emulator. It can be understood that each container has a container identifier for identifying the container. The at least one container is mounted on a virtual bridge created by the container creation engine, that is, the at least one container can communicate with other containers and virtual machines through the virtual bridge.

[0116] 405, respectively, create a second virtual network card in each container, and create a first virtual network card corresponding to each second virtual network card in the virtual bridge, the first virtual network card and the second virtual network card communicate based on a connection channel.

[0117] When running the container image and creating the container, an IP address can be allocated to each container from the IP address segment allocated in step 401, which can be an IPV6 address or an IPV4 address. Further, a second virtual network card eth0@ifxxx is created in each container, and a first virtual network card vethxxx corresponding to each second virtual network card is created in the virtual bridge. The first virtual network card and the second virtual network card communicate through a connection channel, for example, the first virtual network card and the second virtual network card communicate based on a VethPair technology.

[0118] 406, receive the multicast message sent by the SSDP client through the virtual machine network card of the virtual machine.

[0119] 407, according to the pre-configured multicast routing from the virtual machine to the virtual bridge, forward the first message to the virtual bridge.

[0120] 408, based on the connection channel between the at least one first virtual network card of the virtual bridge and the second virtual network card of the at least one container, send the multicast message to the device emulator in the at least one container.

[0121] 409, send the response message of the container to the SSDP client, the response message including the device information of the device emulator in the container.

[0122] It can be understood that the source address of the response message is the IP address of the container corresponding to the device emulator.

[0123] The steps 406-409 of the embodiment of the present application refer to the steps 301-304 of the method 300, and will not be described here. Figure 3A

[0124] ​In the embodiment of the present application, the docker engine can be installed in the virtual machine, and the virtual bridge can be created on the virtual machine based on the docker engine, so as to further configure the multicast routing of the virtual machine to the virtual bridge, so that the multicast message can be forwarded to the container mounted on the virtual bridge, and the single container can simulate the SSDP device.

[0125] Please refer to Figure 5 , which is a schematic diagram of an SSDP device simulation system architecture provided by the embodiment of the present application. As shown in Figure 5 , the SSDP client 10 can be deployed in the first virtual machine, the SSDP client 10 sends the multicast message, the second virtual machine receives the multicast message through the virtual machine network card 11, and further, the multicast routing of the virtual machine network card 11 of the virtual machine to the docker0 bridge 12 is pre-configured, so that the multicast message is further forwarded from the virtual machine network card 11 to the docker0 bridge 12. Since the first virtual network card 13 of the docker0 bridge 12 and the second virtual network card 15 of the container intercommunicate based on the connection channel, and the first virtual network card 14 of the docker0 bridge 12 and the second virtual network card 16 of the container intercommunicate based on the connection channel. Therefore, after the multicast message is forwarded to the docker0 bridge 12, the multicast message is forwarded to the SSDP device simulator 17 in the container through the connection channel between the first virtual network card 13 of the docker0 bridge 12 and the second virtual network card 15 of the container. The multicast message is forwarded to the SSDP device simulator 18 in the container through the connection channel between the first virtual network card 14 of the docker0 bridge 12 and the second virtual network card 16 of the container.

[0126] Correspondingly, the SSDP device simulator 17 and the SSDP device simulator 18 in the container receive the multicast message. The SSDP device simulator 17 and the SSDP device simulator 18 send the response message to the SSDP client according to the multicast message, and the response message includes the device information of the SSDP device simulator. The related description of the device information is described in the foregoing embodiment, and will not be described here.

[0127] Please refer to Figure 6 , which is a flowchart of a device simulator deployment method provided by the embodiment of the present application. As shown in Figure 6 , the device simulator deployment method includes but is not limited to the following steps:

[0128] 501, creating a virtual machine network card and a virtual bridge in a virtual machine, the virtual machine network card being connected with the virtual bridge, and the virtual bridge including at least one first virtual network card.

[0129] The virtual machine network card can be configured to receive multicast messages, and the virtual machine network card can forward the received multicast messages to the virtual network bridge according to a pre-configured multicast routing of the virtual machine network card of the virtual machine to the virtual network bridge. The multicast routing can be pre-configured by a multicast routing forwarding tool. The virtual network bridge can include at least one first virtual network card.

[0130] 502. deploying at least one container in the virtual machine, the container including a device emulator and at least one second virtual network card, a first virtual network card of the virtual network bridge and a second virtual network card of the container being in communication via a connection channel, the container being configured to receive multicast messages via the connection channel and send device information of the device emulator.

[0131] The virtual machine includes at least one container, each container including a device emulator configured to emulate a device and a second virtual network card, a first virtual network card of the virtual network bridge and a second virtual network card of the container being in communication via a connection channel, in other words, the first virtual network card of the virtual network bridge and the second virtual network card are interconnected. The virtual network bridge can send multicast messages to the device emulator in the at least one container via the connection channel between the at least one first virtual network card and the at least one second virtual network card. The device emulator in one or more of the at least one container can send a response message including device information of the device emulator via the connection channel between the first virtual network card of the virtual network bridge and the second virtual network card of the container.

[0132] It should be noted that each of the technical solutions (or referred to as each embodiment) of the present application can be independently implemented or can be implemented based on certain internal relationship. The present application is not limited. And the various terms and definitions between the embodiments can be mutually quoted. In each embodiment of the present application, different implementations can be combined or independently implemented.

[0133] The present application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, when the computer program is executed by a processor, can realize part or all steps of any one of the methods described in the above method embodiments.

[0134] The present application also provides a computer program, the computer program includes instructions, when the computer program is executed by a computer, so that the computer can execute part or all steps of any one of the methods for power control.

[0135] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0136] It is noted that, for the foregoing method embodiments, the acts as variously set forth can be understood broadly, and enumerated orders of acts should be viewed as flexible process actions that can be rearranged, pruned, combined between and / or across enumerated processes, unless a particular ordering is explicitly required by specific language. Further, it is noted that the processes described with or without specified orderings can be understood and performed as separate processes or as sub-parts of a larger method. It is also noted that, as used in this specification, the singular forms“a,”“an,” and“the” include plural referents unless the context clearly dictates otherwise. Further, to make it clear that the terms“comprise,”“comprises,” and“comprising” are used herein to mean including but not limited to, the terms“consist,”“consists,” and“consisting” are used herein to mean including and limited to.

[0137] The terminology used in the above description merely describes particular embodiments and is not intended to limit the application. As used in this specification and the appended claims, the singular forms“a,”“an,” and“the” include plural referents unless the context clearly dictates otherwise. It will be further understood that the terms“comprises,”“comprising,”“includes,” and / or“including,” as used herein, specify the presence of stated features, items, components, elements, and / or steps, but do not preclude the presence or addition of one or more other features, items, components, elements, and / or steps.

[0138] As used in the above description, the term“when” can be interpreted as meaning“if” or “after” or “in response to a determination” or “in response to detecting” depending on the context. Similarly, the phrase“determining when” or“if [a stated condition or event] is detected” can be interpreted as meaning“if it is determined that” or “in response to a determination that” or “upon determining that” or “in response to detecting [a stated condition or event].”

[0139] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented 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, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk) and the like.

[0140] Those of ordinary skill in the art understand that all or part of the processes in the above embodiments can be implemented by a computer program to instruct the relevant hardware, which can be stored in a computer readable storage medium. The program can include the processes of the above method embodiments when executed. The aforementioned storage medium includes ROM or random access memory (RAM), magnetic disk or optical disk, and various media that can store program codes.

Claims

1. A device simulation method, characterized by, The method comprises: receiving a multicast message sent by a first virtual machine, the multicast message being used to obtain device information of a device emulator, the multicast message being received by a virtual machine network card of a second virtual machine; forwarding the multicast message to a virtual bridge in the second virtual machine according to a multicast routing between the virtual machine network card of the second virtual machine and the virtual bridge, at least one container in the second virtual machine being mounted on the virtual bridge; the virtual bridge comprising at least one first virtual network card, one container of the at least one container comprising a second virtual network card, one first virtual network card of the virtual bridge and the second virtual network card of one container communicating through a connection channel; sending the multicast message to a device emulator in the at least one container through at least one connection channel between the at least one first virtual network card of the virtual bridge and the second virtual network card of the at least one container; sending a response message sent by the device emulator in one or more containers of the at least one container to the first virtual machine, the response message comprising device information of the device emulator.

2. The method of claim 1, wherein, The method further comprises: configuring the multicast routing from the virtual machine network card of the second virtual machine to the virtual bridge through a multicast routing tool.

3. The method of claim 1 or 2, wherein, The second virtual machine comprises a container creation engine, and the method further comprises: obtaining at least one container image comprising a device emulator image, creating the at least one container comprising the device emulator in the second virtual machine based on running the container image based on the container creation engine.

4. The method of claim 1 or 2, wherein, The method further comprises: allocating an Internet Protocol (IP) address segment for the containers in the second virtual machine; allocating an IP address for each of the at least one container from the IP address segment; wherein the response message sent by one or more containers of the at least one container to the first virtual machine comprises an IP address of the container sending the response message.

5. The method of claim 4, wherein, The IP address is an IPV6 address or an IPV4 address.

6. A device emulator deployment method, characterized by, The method comprises: creating a virtual machine network card and a virtual bridge in a virtual machine, the virtual machine network card being connected to the virtual bridge, the virtual bridge comprising at least one first virtual network card; forwarding a multicast message to the virtual bridge according to a multicast routing between the virtual machine network card and the virtual bridge, at least one container in the virtual machine being mounted on the virtual bridge, the multicast message being used to obtain device information of a device emulator; the container comprising the device emulator and at least one second virtual network card, one first virtual network card of the virtual bridge and the second virtual network card of one container communicating through a connection channel, the container being used to receive the multicast message and send the device information of the device emulator through the connection channel.

7. A computing device, comprising: The computing device is deployed with a virtual machine, the virtual machine comprising a virtual machine network card, a virtual bridge, and at least one container, the virtual machine network card being connected to the virtual bridge, the at least one container being mounted on the virtual bridge; The virtual machine network card is configured to receive a multicast message and forward the multicast message to the virtual bridge according to a multicast route between the virtual machine network card and the virtual bridge; the virtual bridge includes at least one first virtual network card, one of the at least one container includes a second virtual network card, and the first virtual network card of the virtual bridge communicates with the second virtual network card of the container via a connection channel; The virtual network bridge is configured to send the multicast message to the device simulator in the at least one container through at least one connection channel between at least one first virtual network card of the virtual network bridge and the second virtual network card of the at least one container; The at least one container is used to respond to the multicast message and send a response message through the virtual bridge and the virtual machine network card, wherein the response message includes device information of the device simulator.

8. A computing device, comprising: The computing device includes a processor and a memory, wherein the memory stores program instructions, and the processor executes the program instructions to implement the method according to any one of claims 1 to 5 or 6.

Images