JP2019062491A - Virtualization communication apparatus and virtualization communication method - Google Patents

Abstract

To reduce the management cost due to information dependent on individual hardware of a physical port in a virtualized communication apparatus for operating a virtual machine.SOLUTION: A physical machine 1 includes an NIC port 50 that is a communication interface, a virtual IF 21 recognized as a virtual communication interface from a virtual machine 10 operating in the physical machine 1, a queue abstraction process 22 for performing packet transfer processing between each virtual machine 10 and each queue 51. The queue abstraction process 22 includes a queue-side driver 36b dependent on hardware of the NIC port 50 for performing packet transfer processing with the queue 51 and an IF-side driver 36a dependent on hardware of the NIC port 50 for performing packet transfer processing with the virtual machine 10 via the virtual IF 21.SELECTED DRAWING: Figure 2

Description

  The present invention relates to a virtualized communication apparatus and a technology of a virtualized communication method.

There has been an effort called Network Functions Virtualization (NFV) to build network functions on physical machines using virtualization technology. By operating functions realized with dedicated hardware as software by virtualization technology, versatility can be improved and flexible system construction can be achieved.
Communication performed by a VM (Virtual Machine), which is a virtual machine built on a physical machine, includes communication with other VMs on the same physical machine (VM-VM communication), and is installed in the physical machine. Communication (NIC-VM communication) with another physical machine via a network interface card (NIC). For packet transfer in these communications, inter-VM communication (IVC), which is an inter-virtual machine cooperation technology, is used.

FIG. 4 is a block diagram of a physical machine to which IVC is applied.
The physical machine 101 has two virtual machines 110 (110-1 and 110-2), an IVC 120, and two NIC ports 150. The IVC 120 has a switching function that mediates communication between the virtual machines 110 and communication between the virtual machines 110 and other devices via the NIC port 150. For example, in FIG. 4, the flow in which a packet input from the NIC port 150 arrives at the virtual machine 110-1 via the IVC 120 is indicated by a bold arrow.

Also, in order to distinguish between the functional unit configured by hardware in the physical machine 101 and the functional unit configured by software, the functional unit (NIC port 150) configured by hardware is surrounded by a thick line.
Hereinafter, as details of the implementation system of the IVC 120 illustrated in FIG. 4, virtual switch systems described in Non-Patent Documents 1 and 2 will be described in FIG. 5, and SR-IOV (Single Root I) described in Non-Patent Documents 3-5. The (/ O Virtualization) method is described in FIG.

FIG. 5 is a block diagram of a virtual switch system.
A virtual switch including two virtual IFs 121 (121-1, 121-2) in the physical machine 102 and a switching unit 146 corresponds to the IVC 120 in FIG. Each virtual IF 121 is associated with the virtual machine 110 in charge of transmission / reception in one-to-one correspondence. For example, the virtual machine 110-1 corresponds to the virtual IF 121-1, and the virtual machine 110-2 corresponds to the virtual IF 121-2.

As indicated by thick arrows in FIG. 5, the physical machine 102 once terminates the packet received by the NIC port 150 at the switching unit 146. Then, the switching unit 146 performs software processing of distributing traffic in the terminated packet to the virtual machine 110 based on an identifier (such as a MAC address) of the virtual machine 110.
Although not shown, packets transmitted from the virtual machine 110 to another device via the NIC port 150, and packets between the virtual machines 110-1 and 110-2 looped back inside the same physical machine 102 are the same. Are distributed as software by the switching unit 146.

  The switching unit 146 includes an address learning unit 142, an address table 143, and an address comparison unit 144. In the address table 143, the MAC address of each virtual machine 110 is registered. The address collating unit 144 collates the address information described in the header of the arrived packet with the address table 143 (address matching) to determine the transfer destination of the packet. The address learning unit 142 updates MAC address information registered in the address table 143 according to the address information described in the header of the packet passing through the switching unit 146.

FIG. 6 is a block diagram of the SR-IOV system.
A function corresponding to the IVC 120 in FIG. 4 is installed as hardware in the NIC port 150 in the physical machine 103. Physically, one NIC port 150 is divided into a plurality of logical port units VF (Virtual Function) 155 using a hardware function.
The NIC port 150 includes two VFs 155 (155-1 and 155-2) and a switching unit 156. Each VF 155 is associated 1: 1 with the VF driver 111 in the virtual machine 110 in charge of transmission and reception. For example, the VF driver 111-1 and the VF 155-1 in the virtual machine 110-1 correspond to each other, and the VF driver 111-2 and the VF 155-2 in the virtual machine 110-2 correspond to each other. That is, each VF 155 is directly connected to the associated virtual machine 110 without passing through a virtualization layer such as the virtual switch of FIG.

  The switching unit 156 is a hardware implementation of the function of the switching unit 146 of FIG. That is, the switching unit 156 includes the address learning unit 152 having the function of the address learning unit 142, the address table 153 having the function of the address table 143, and the address collating unit 154 having the function of the address collating unit 144. ing. The switching unit 156 enables hardware distribution of traffic by MAC address.

Not only the method of updating the address table 153 in the NIC port 150 by learning by the address learning unit 152, but also a mechanism capable of directly updating the contents of the address table 153 from the outside of the NIC port 150 has been proposed.
For example, “Generic Flow API” described in Non Patent Literatures 6 and 7 enables control of the address table 153 (Flow Table) from outside in the communication acceleration technology called DPDK (Data Plane Development Kit) provided by Intel. It is a specification to

Ben Pfaff et al., "The Design and Implementation of Open vSwitch.", In: NSDI. 2015. p. 117-130. Reza Rahimi et al., "A High-Performance OpenFlow Software Switch", In: High Performance Switching and Routing (HPSR), 2016 IEEE 17th International Conference on. IEEE 2016. p.93-99. PCI-SIG, "Single Root I / O Virtualization and Sharing Specification Revision 1.0", [online], September 11, 2007, [September 15, 2017 Search], Internet <URL: http://pcisi.com / single-root-io-virtualization-and-sharing-specification-revision-10> Intel, "PCI-SIG Single Root I / O Virtualization (SR-IOV) Support in Intel Virtualization Technology for Connectivity", [online], [September 15, 2017 search], Internet <URL: https: // www. intel.com/content/dam/doc/white-paper/pci-sig-single-root-io-virtualization-support-in-virtualization-technology-for-connectivity-paper.pdf> Yaozu Dong et al., "High Performance Network Virtualization with SR-IOV", Journal of Parallel and Distributed Computing 2012 72.11: 1471-1480. Intel, "Intel Ethernet Flow Director", [online], [search September 15, 2017], Internet <URL: https://www.intel.co.jp/content/www/jp/en/ethernet-products /ethernet-flow-director-video.html> Data Plane Development Kit (DPDK), “9. Generic flow API (rte_flow)”, [online], [September 15, 2017 search], Internet <URL: http://dpdk.org/doc/guides/prog_guide /rte_flow.html>

  The SR-IOV method of FIG. 6 generally improves the performance because the hardware in the NIC port 150 bears the packet transfer processing compared to the virtual switch method of FIG.

On the other hand, in the SR-IOV method of FIG. 6, since the NIC port 150 of hardware is provided by a plurality of vendors, the implementation of each vendor requires the VF driver 111 depending on the individual hardware. Therefore, an operator who operates application software on the virtual machine 110 needs to be aware of the VF driver 111 depending on the individual hardware.
Therefore, taking advantage of the characteristic of an abstract operating environment in which hardware dependency information such as virtual machine 110 is concealed, the manager's management cost can be avoided by making the operator not aware of the information depending on specific individual hardware. To reduce the

  Therefore, the present invention has as its main object to reduce the management cost due to the information that depends on the individual hardware for the physical port in the virtualized communication device that operates the virtual machine.

In order to solve the above-mentioned subject, a virtualization communication device of the present invention has the following features.
The present invention comprises a packet buffer for storing a packet to be transmitted to and received from a virtual machine for each virtual machine operating in the virtualized communication apparatus, and a communication interface mounted as hardware in the virtualized communication apparatus. Physical port, which is
A virtual IF recognized as a virtual communication interface from the virtual machine operating in the virtualized communication device;
A port abstraction process for performing packet transfer processing between each of the virtual machines and each of the packet buffers;
A packet transfer between a port side driver that depends on the hardware of the physical port for performing a packet transfer process with the packet buffer by the port abstraction process, and a packet transfer between the virtual machine via the virtual IF And a hardware-independent IF-side driver of the physical port for performing processing.

  As a result, the virtual IF and the IF driver are used from the virtual machine as a general communication device that does not depend on individual hardware, because information dependent on the individual hardware is absorbed on the port side driver side. can do. Therefore, the operator of the virtual machine does not have to be aware of the information that depends on the individual hardware for the physical port of the virtualized communication device that operates the virtual machine, so the information that depends on the individual hardware depends on it. Management costs can be reduced.

  The present invention is characterized in that each of the virtual machines configures the port abstraction process and the virtual IF, which are in charge of its own packet transfer processing, separately from the other virtual machines.

  Thus, even when a plurality of virtual machines operate in one physical machine, a plurality of sets of port abstraction processes and virtual IFs are prepared for each virtual machine. Therefore, the processing load is properly distributed since the plurality of port abstraction processes independently perform packet transfer processing.

  In the present invention, the packet arrived by the physical port collating the address information of the packet that has arrived in the physical port of its own with the unique address information of each virtual machine registered in the address table. And an address collating unit for distributing the packet to each of the packet buffers.

  As a result, transfer performance can be improved by offloading the main and high-load address collating process in the packet transfer process to an address collating unit provided in hardware called a physical port.

  In the present invention, a table setting for the virtualized communication apparatus to further register unique address information for each virtual machine set for each of the port abstraction processes from outside the physical port in the address table It has a part.

  As a result, since it is not necessary to provide a learning function for updating the address table as an internal configuration of the physical port, the versatility of the hardware is improved by simplifying the function required for the physical port.

  According to the present invention, in a virtualized communication apparatus for operating a virtual machine, it is possible to reduce the management cost due to the information depending on the individual hardware for the physical port.

It is a block diagram of the physical machine which operate | moves as a virtualization communication apparatus concerning this embodiment. It is a detailed block diagram of the physical machine of FIG. 1 concerning this embodiment. It is a flowchart which shows operation | movement of the queue abstraction process concerning this embodiment. It is a block diagram of the physical machine which applied IVC. It is a block diagram of a virtual switch system. It is a block diagram of SR-IOV system.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

FIG. 1 is a block diagram of a physical machine 1 operating as a virtualized communication device.
The physical machine 1 is configured as a computer having a CPU (Central Processing Unit), a memory, a storage unit (storage unit) such as a hard disk, and a network interface.
The computer operates a control unit (control means) configured of each processing unit by the CPU executing a program (also called an application or an abbreviation of the application) read into the memory.
It is also possible to construct a communication system in which a plurality of physical machines 1 shown in FIG. 1 are connected.

The physical machine 1 shares its functions in the following three layers.
(1) Three virtual machines 10 (10-1, 10-2, 10-3) exist as virtual guest layers.
(2) One virtual IF 21 and a queue abstraction process (port abstraction process) 22 connected to the virtual IF 21 exist for one virtual machine 10 as a virtual host layer.
(3) As a hardware layer, one queue (packet buffer) 51 exists for one virtual machine 10, and the queue 51 is formed in one of the NIC ports (physical port) 50. The queue 51 is a packet buffer that temporarily stores packets to be transmitted to and received from the virtual machine 10, and is implemented by, for example, a ring buffer.

The virtual machine 10, the virtual IF 21, the queue abstraction process 22, and the queue 51 are in one-to-one correspondence. For example, the virtual IF 21-1, the queue abstraction process 22-1, and the queue 51-1 are associated with the virtual machine 10-1 (thick arrows).
Similarly, the virtual IF 21-2, the queue abstraction process 22-2, and the queue 51-2 are associated with the virtual machine 10-2 (broken line arrow). Furthermore, the virtual IF 21-3, the queue abstraction process 22-3, and the queue 51-3 are associated with the virtual machine 10-3 (broken line arrow).
Here, the queue 51-1 and the queue 51-2 are prepared in the first NIC port 50-1, and the queue 51-3 is prepared in the second NIC port 50-2. Thus, the NIC port 50 to which each queue 51 belongs may be any NIC port 50 in the physical machine 1.

In FIG. 1, a path until the packet received by the NIC port 50-1 is transferred to the virtual machine 10-1 is illustrated by a thick arrow. The following description will be made along this route.
First, the address comparison unit 54 in the NIC port 50 refers to the address table 53 to determine which queue 51 the received packet is to be stored. That is, packets transmitted to and received from different virtual machines 10 are stored in different queues 51.
Here, the configuration of the switching unit 156 (address collating unit 154, address table 153) used in the NIC port 150 of FIG. 6 may be diverted to the NIC port 50 of the physical machine 1 of FIG. That is, the physical machine 1 uses the address table 153 of FIG. 6 as the address table 53 of FIG. 1 and uses the address comparison unit 154 of FIG. 6 as the address comparison unit 54 of FIG.
Thus, the throughput performance of the packet transfer process can be improved by offloading (releasing) the address matching process of the transfer packet to the hardware (address collating unit 54).

Next, the packet stored in the queue 51-1 is transferred to the queue driver 36 b-1 in the queue abstraction process 22-1 corresponding to the queue 51-1. The queue driver (port driver) 36 b is a driver for transmitting and receiving packets to and from the corresponding queue 51, and is prepared in advance depending on the hardware of the NIC port 50 accommodating the queue 51.
The packet transfer unit 36 is a processing unit that transfers a packet between the IF driver 36 a and the queue driver 36 b. In FIG. 1, the packet transfer unit 36-1 transfers the packet received from the queue driver 36b-1 to the IF driver 36a-1.

The IF driver 36 a is a driver for transmitting and receiving packets to and from the corresponding virtual machine 10, and is a (general) driver independent of the hardware of the NIC port 50. In FIG. 1, the IF driver 36a-1 transfers a packet to the corresponding virtual machine 10-1 via the virtual IF 21-1.
As described above, the queue abstraction process 22 is provided between the virtual machine 10 and the physical device NIC port 50, and the virtual IF 21 is provided for each queue abstraction process 22 to increase the hardware abstraction level. The hardware dependency of the virtual machine 10 can be reduced.

FIG. 2 is a detailed block diagram of the physical machine 1 of FIG.
The queue abstraction process 22 of the physical machine 1 includes the setting input unit 31, the setting list 32, and the address creating unit 33 in addition to the IF driver 36a, the packet transfer unit 36, and the queue driver 36b shown in FIG. The driver creation unit 34, the virtual IF creation unit 35, the queue search unit 37, and the NIC setting unit 38 are included.
Furthermore, a queue management table 23 and a table setting API (table setting unit) 24 exist as the (2) virtual host layer of the physical machine 1 described above.

The setting input unit 31 stores the setting contents of the queue abstraction process 22 to which the own belongs, input from the administrator, as the setting list 32. The following is an example of the setting list 32.
(Setting 1) own ID number. For example, “id”: 3 ”is registered in the setting list 32 as content indicating that the queue abstraction process 22 of its own is the“ 3 ”.
(Setting 2) Information of the NIC port 50 and the queue 51 corresponding to the own queue abstraction process 22. For example, when using the “1” queue 51 in the “0” NIC port 50, ““ nic ”: {“ port ”: 0,“ queue ”: 1}” is registered in the setting list 32 .
(Setting 3) Information of the virtual IF 21 and the virtual machine 10 corresponding to its own queue abstraction process 22. For example, when making virtual machine 10 use virtual IF 21 (vNIC port) of MAC address “A0-B1-C3-A4-B5-C6” from directory path “/ tmp / vhost0”, ““ vhost ”: {“ mac “:“ A0-B1-C3-A4-B5-C6 ”,“ path ”:“ / tmp / vhost0 ”} is registered in the setting list 32.

  The address creating unit 33 does not overlap with the MAC address already used in the virtual machine 10 in order to reduce the trouble of manually entering the MAC address of (setting 3) from the setting input unit 31 to the administrator (unique An address is created, for example, as random data. That is, the MAC address of (setting 3) is used as unique information for uniquely identifying each virtual machine 10.

Note that FIG. 6 shows the address learning unit 152 that updates the data contents of the address table 153 in the NIC port 150. In FIG. 2, as a means for updating the data contents of the address table 53 instead of the address learning unit 152, a table setting API 24 independent of the NIC setting unit 38 for each queue abstraction process 22 and the queue abstraction process 22. And.
The NIC setting unit 38 sets a matching rule indicating a notification flow of a packet flow in the physical machine 1 in the address table 53 in the NIC port 50 (setting 2) via the table setting API 24. The matching rule is a rule to transfer a packet in which the MAC address of (setting 3) is specified to the queue 51 of (setting 2).
The setting rule of the matching rule is, for example, the time of initialization of the physical machine 1 (when the power is turned on) and the time of changing the contents of the address table 53 thereafter.

The table setting API 24 is, for example, “Generic Flow API” described in Non-Patent Documents 6 and 7, and is an API for writing a matching rule directly in the address table 53 from the outside of the NIC port 50.
For example, when the dst MAC (destination MAC address) of the packet is “A0-B1-C3-A4-B5-C6” for the NIC port 50 of physical port “1”, the packet is placed in the “2” -th queue 51 The matching rule for loading packets is set by the following command via the table setting API 24.
"Flow create 1 ingress pattern eth / eth dst is a0-b1-c3-a4-b5-c6 / end actions queue index 2 / end"
This matching rule is set in the address table 53 as, for example, a rule “0”. The following is a response message indicating the setting result.
"Flow rule # 0 created"

The driver creating unit 34 creates the queue driver 36 b according to (setting 2) of the setting list 32 and creates the IF driver 36 a according to (setting 3) of the setting list 32.
The virtual IF creating unit 35 creates the virtual IF 21 corresponding to the IF driver 36a according to (setting 3) of the setting list 32.
The queue searching unit 37 searches the queue 51 of (setting 2) to be associated with the own queue abstraction process 22 from the member list of the usable queues 51 registered in the queue management table 23.

  The queue management table 23 is a table that exists for each physical machine 1 independently of the number of queue abstraction processes 22. The queue management table 23 includes a member list of available NIC ports 50 (port) in the physical machine 1, an available queue 51 in the NIC port 50, and an unavailable queue 51. Maintain a member list. Hereinafter, a setting example of the queue management table 23 will be exemplified by a structured text file. In this example, six usable queues 51 of “1, 2, 4, 5, 6, 8” exist in the “0” NIC port 50, and the “1” NIC port 50 exists. It indicates that there are five usable queues 51 of “0, 1, 4, 6, 7”.

FIG. 3 is a flow chart illustrating the operation of the queue abstraction process 22.
As S11, the physical machine 1 receives an instruction for activating the queue abstraction process 22, and activates the queue abstraction process 22 in accordance with the following arguments associated with the instruction.
The ID number of the queue abstraction process 22 registered in the setting list 32 as (setting 1).
The number of the NIC port 50 registered in the setting list 32 as (Setting 2).
The ID (directory path) of the virtual IF 21 to be registered in the setting list 32 as (Setting 3).
The MAC address of the virtual IF 21 (specific information of the virtual machine 10) registered in the setting list 32 as (Setting 3).

  As S12, the queue search unit 37 searches the queue management table 23 for an available (currently unused) queue 51 to be assigned to the queue abstraction process 22 started in S11. This usable queue 51 is searched from the queue 51 belonging to the NIC port 50 designated as (setting 2) in S11. The queue search unit 37 proceeds to S13 when the usable queue 51 can be searched in S12 (Yes), and proceeds to S25 when the search can not be performed (No).

The determination process of Yes / No in S12 is performed, for example, depending on whether the return value from the subroutine implementing the function of the queue search unit 37 is a value indicating success or a value indicating failure.
Further, when the result of S12 is Yes and the process proceeds to S13, the queue searching unit 37 registers the searched queue 51 in the setting list 32 as the queue 51 of (setting 2). Further, the driver creating unit 34 creates the queue driver 36 b corresponding to the queue 51 registered in the setting list 32.

  As S13, the virtual IF creating unit 35 creates the virtual IF 21 based on the directory path registered as (setting 3) of the setting list 32. If the virtual IF creation unit 35 succeeds in creating the virtual IF 21 (Yes), it proceeds to S14, and if it fails (No), it proceeds to S24. When the determination in S13 is YES and the process proceeds to S14, the driver creating unit 34 creates the IF driver 36a for the created virtual IF 21.

  In S14, the NIC setting unit 38 sets the matching rule described above with reference to FIG. 2 in the address table 53 in the NIC port 50 registered as (setting 2) in the setting list 32. If the NIC setting unit 38 succeeds in this setting (Yes), it proceeds to S15, and if it fails (No), it proceeds to S23.

As S15, the packet transfer unit 36 starts packet transfer between the virtual machine 10 and the NIC port 50. As described in FIG. 1, the IF driver 36 a is used for packet transmission and reception between the packet transfer unit 36 and the virtual machine 10 (virtual IF 21). The queue driver 36 b is used for packet transmission and reception between the packet transfer unit 36 and the NIC port 50 (queue 51).
As S16, the physical machine 1 determines whether an instruction for stopping the queue abstraction process 22 has been received. The physical machine 1 proceeds to S21 if Yes in S16, and continues transfer of S15 if No.

At S21, the packet transfer unit 36 stops the packet transfer started at S15.
As S22, the NIC setting unit 38 deletes the setting of the NIC port 50 set in S14.
As S23, the virtual IF creating unit 35 deletes the virtual IF 21 created in S13. The driver creating unit 34 also deletes the IF driver 36 a corresponding to the deleted virtual IF 21.
As S24, the queue search unit 37 releases the queue 51 acquired in S12. That is, the queue search unit 37 registers in the queue management table 23 that the status of the queue 51 is to be shifted from "in use" to "unused (usable)". The driver creating unit 34 also deletes the queue driver 36 b corresponding to the deleted queue 51.
As S25, the physical machine 1 stops the queue abstraction process 22 started in S11.

  In the present embodiment described above, by providing a mechanism for solving the following problems in the virtual switch system of FIG. 5 and the SR-IOV system of FIG. 6, the balance between improvement of communication performance and reduction of management cost is achieved. Achieve well.

First of all, the system of this embodiment described in FIG. 1 and FIG. By providing them, transfer performance is improved.
For example, the address comparison unit 144 in FIG. 5 has realized the packet matching process using the MAC address or the like as software. On the other hand, in FIG. 1, since the packet matching process can be offloaded to the address comparison unit 54 in the NIC port 50 which is physical hardware, the throughput performance of the entire system can be improved.

Further, in the virtual switch system of FIG. 5, the process of one switching unit 146 is performing packet transfer processing via a plurality of (two) virtual IFs 121. Therefore, when the number of virtual IFs 121 increases, the processing load is concentrated on the process of one switching unit 146, and the transfer performance is degraded.
On the other hand, in FIG. 1, one virtual IF 21 and one queue abstraction process 22 are generated for one virtual machine 10. That is, since the three queue abstraction processes 22 independently (in parallel) perform packet transfer processing for the three virtual machines 10, the processing load is properly distributed. This can improve the scalability of the entire system. Furthermore, as described above, since the packet matching process is offloaded to the address comparison unit 54 in the NIC port 50, the load on the queue abstraction process 22 alone can be reduced.

Next, against the problem that the operation cost increases due to the high dependency of the SR-IOV method on the physical hardware of FIG. 6, the method of the embodiment of the present invention described in FIG. 1 and FIG. The above-mentioned (2) virtual host layer is appropriately provided to absorb physical hardware dependency between 10 and the NIC port 50. This suppresses the dependence on physical hardware and improves versatility.
For example, in the SR-IOV method of FIG. 6, since the VF driver 111 corresponding to each NIC port 50 is required in each virtual machine 110, the type of NIC port 50 mounted on the physical machine 103 is considered. The virtual machine 110 needs to be built. As a result, it is necessary for the operator to manage which virtual machine 110 operates on which physical machine 103, and the role of virtualization for concealing physicality is partially lost.

On the other hand, in the present embodiment, as the transmission / reception driver created by the driver creation unit 34, a configuration is adopted in which the queue driver 36b including hardware dependency information and the IF driver 36a not including hardware dependency information are separately prepared. did. Then, the hardware-dependent information for the queue driver 36 b is input in advance by the administrator or the like in addition to the instruction for activating the queue abstraction process 22 in S 11.
As a result, the information depending on the individual hardware is absorbed on the side of the queue driver 36b, so that the virtual IF 21 and the IF driver 36a are virtual machines as general communication devices not depending on the individual hardware. Emulated from 10.
For example, it is assumed that the manufacturing vendor A provides the first NIC port 50-1 and the manufacturing vendor B provides the second NIC port 50-2 in FIG. The hardware specifications of the manufacturing vendor A are reflected in the queue drivers 36b-1 and 36b-2, and the hardware specifications of the manufacturing vendor B are reflected in the queue drivers 36b-3. On the other hand, drivers independent of the vendors A and B can be used as the three IF drivers 36a (36a-1, 36a-2, 36a-3).

Further, in the SR-IOV method of FIG. 6, since it is necessary to prepare the function of the switching unit 156 as a full set inside the NIC port 50, the cost of the NIC port 50 becomes high, and the usable NIC port 50 is limited. There was a problem of being
On the other hand, in the present embodiment, although the address collating unit 54 is provided as a function in the NIC port 50, a learning function (corresponding to the address learning unit 152) for updating the address table 53 referred to by the address collating unit 54 is provided. Functions may be present but not required. In FIG. 2, a means for updating the address table 53 via the table setting API 24 from the NIC setting unit 38 outside the NIC port 50 is used. As a result, the number of functions required of the NIC port 50 can be smaller than that of the SR-IOV method, and the versatility of the hardware is improved.

As described above, in the present embodiment, the IVC 120 used for packet forwarding between the virtual machines 10 or between the virtual machines 10 and the NIC port 50 has the configuration shown in FIGS. In this configuration, the queue abstraction process 22 is activated (distributed) for each virtual machine 10, and packets are transmitted and received from the queue abstraction process 22 through the virtual IF 21. As a result, since the virtual machine 10 does not need to be aware of the NIC port 50 which is a specific hardware, it is possible to reduce the hardware dependency.
Furthermore, by offloading the packet transfer processing to the address comparison unit 54 in the NIC port 50 (using hardware acceleration), the throughput performance can be improved.

  In the present embodiment, as an internal configuration of the virtualization communication apparatus according to the present invention, three virtual machines 10 shown in FIG. 1, three queue abstraction processes 22, three queues 51, and two. Although the NIC port 50 has been described, it is not limited to these numbers and configurations. Further, according to the present invention, general computer hardware resources can be realized by a program operated as each means of the resource management system. Then, this program can be distributed via a communication line, or recorded and distributed in a recording medium such as a CD-ROM.

1 Physical machine (virtualized communication device)
10 virtual machine 21 virtual IF
22 Queue abstraction process (port abstraction process)
23 queue management table 24 table setting API (table setting part)
31 setting input unit 32 setting list 33 address creating unit 34 driver creating unit 35 virtual IF creating unit 36 packet transfer unit 36 a IF driver 36 b queue driver (port driver)
37 queue search unit 38 NIC setting unit 50 NIC port (physical port)
51 queue (packet buffer)
53 address table 54 address collation unit 56 switching unit

Claims (5)

A physical port that is a communication interface mounted as hardware in the virtualized communication device, including a packet buffer for storing packets transmitted to and received from the virtual machine for each virtual machine operating in the virtualized communication device When,
A virtual IF recognized as a virtual communication interface from the virtual machine operating in the virtualized communication device;
A port abstraction process for performing packet transfer processing between each of the virtual machines and each of the packet buffers;
The port abstraction process transfers a packet between a port side driver that depends on the hardware of the physical port for performing packet transfer processing to and from the packet buffer, and the virtual machine via the virtual IF. A virtualized communication apparatus comprising: an IF-side driver that does not depend on the hardware of the physical port for performing processing. The virtual communication according to claim 1, wherein each of the virtual machines configures the port abstraction process and the virtual IF that are in charge of its own packet transfer processing separately from the other virtual machines. apparatus. The physical port compares the address information of the packet that has arrived in the physical port of its own with the unique address information of each of the virtual machines registered in the address table, so that each packet has arrived. The virtualized communication apparatus according to claim 1, further comprising an address collation unit for allocating to a buffer. The virtualized communication apparatus further includes a table setting unit for registering unique address information of each virtual machine set for each of the port abstraction processes from the outside of the physical port in the address table. The virtualized communication device according to claim 3. The virtualized communication device is
Each virtual machine operating in the virtualized communication apparatus has a packet buffer for storing a packet to be transmitted to or received from the virtual machine, and a physical is a communication interface mounted as hardware in the virtualized communication apparatus. With port
A virtual IF recognized as a virtual communication interface from the virtual machine operating in the virtualized communication device;
A port abstraction process for performing packet transfer processing between each of the virtual machines and each of the packet buffers;
The port abstraction process transfers a packet between a port side driver that depends on the hardware of the physical port for performing packet transfer processing to and from the packet buffer, and the virtual machine via the virtual IF. Packet transfer processing is performed using an IF-side driver that does not depend on the hardware of the physical port for processing.

Images