Virtualized bridged networking with Macvtap

http://blog.csdn.net/hshl1214/article/details/50628947

Introduction

A virtual machine typically needs to being connected to is network to a useful. Because a virtual machine runs as a application inside the host computer, connecting it to the outside world needs T from the host operating system. There are a number of options for networking a virtual machine, both on the Link Layer and the network Layer. Please refer to the documentation of the virtualization system for you are using (e.g. QEMU, KVM, etc.) The references list below also contains pointers to additional information. Macvtap

In this article we'll focus on a relatively new Linux device driver designed to ease the task of networking virtual Machin Es:mavtap. Macvtap is essentially a combination of the Macvlan driver and a Tap device. This probably does is not say much of the to the uninitiated and so let's is the what it all means.

The Macvlan driver is a separate Linux kernel driver this macvtap driver on. Macvlan makes it possible to create virtual network interfaces, "cling on" a physical network. Each virtual interface has it own MAC address distinct from the physical ' s MAC address. Frames sent to or in the virtual interfaces are mapped to the physical interface, which is called the lower interface.

TAP interfaces

A Tap interface is a software-only interface. Instead of passing frames to and from a physical Ethernet card, the frames are read and written by a user space program. The kernel makes the Tap interface available via THE/DEV/TAPN device file, where N is the index of the network interface.

A Macvtap interface combines the properties of these two; It is the virtual interface with a Tap-like software interface. A Macvtap interface can be created using the IP command:

$ sudo ip link add link eth0 name macvtap0 type Macvtap

This adds a new interface called Macvtap0 as can is seen in the following listing:

$ IP Link
1:lo: <LOOPBACK,UP,LOWER_UP> MTU 16436 qdisc noqueue State UNKNOWN mode DEFAULT
 link/loopback 00: 00:00:00:00:00 BRD 00:00:00:00:00:00
2:eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1500 QDISC-Pfifo_fast State up mode DEFAULT Qlen 1000
 link/ether 00:1f:d0:15:7b:e6 brd ff:ff:ff:ff:ff:ff 3:macvtap0@eth0
: < Broadcast,multicast> MTU 1500 Qdisc noop State down mode DEFAULT Qlen/link/ether 42:96:80:ee:2d:23 BRD ff:ff:ff
 : Ff:ff:ff

The device file corresponding to the new Macvtap interface with index 3 IS/DEV/TAP3. This device the file is created by Udev.

$ ls-l/dev/tap3
 crw-------1 root 252, 1 Oct 12:10/dev/tap3

A User space program can open this device file and use it to send and receive Ethernet frames over it. When the kernel transmits a frame via the interface macvtap0 instead of sending it to a physical Ethernet it Makes it available for reading to the user space program. Correspondingly, when the user spaces program writes the content of a Ethernet frame to the FILE/DEV/TAP3, the kernel ' s n Etworking code sees the frame as if it had been received via the device macvtap0.

The user is normally a emulator like QEMU, which virtualizes network cards to the guest operating systems. When QEMU reads an Ethernet frame using the file descriptor, it emulates what a real network card would do. Typically it triggers a interrupt in the virtual machine, and the guest operating system can then read the frame from the Emulated network card. The exact details on the "How ' is" dependent on the emulator and the guest operating system. This article.

Macvtap is implemented in the Linux kernel, and must being configured when compiling the kernel, either as a module or as a B Uilt-in feature. The setting can be found under Device drivers→network Device Support→mac-vlan based tap driver. The tap driver is dependent on ' mac-vlan support ' same category, so you need to enable that too.

A Macvtap device can function in one of three modes:virtual Ethernet Port aggregator (VEPA) mode, bridge mode, and privat E mode. The modes determine how the tap endpoints communicate between all other. 1. Virtual Ethernet Port Aggregator mode

In this mode, which are the default, data between endpoints on the same lower device are sent via the lower device (Etherne T card) to the physical switch the lower device are connected to. This mode requires the switch supports ' reflective Relay ' mode, also known as ' hairpin ' mode. Reflective Relay means the switch can send back a frame on the same port it received it. Unfortunately, most switches today does not yet support this mode.

Hairpin mode

2. Bridge mode

When the MACVTAP device was in bridge mode, the endpoints can communicate directly without sending the "data out via" ER device. When using this mode, there are no need for the physical switch to support reflective Relay mode. 3. Private Mode

In Private mode the nodes on the same MACVTAP device can never talk to all other, regardless if the physical switch Suppo RTS Reflective Relay mode or not. Use this mode if you are want to isolate the virtual machines connected to the "endpoints from" Utside Network.

At a-a-glance, the VEPA mode seems a bit odd. What makes it a good idea to send out of frames on the physical wire, with only to being sent back to the Ethernet card via the same Port on the switch? Vepa mode simplifies the task of the host computer by letting the physical switch does the switching, which the switch is VE Ry good at. A further advantage is so network administrators can monitor traffic between virtual machines using familiar tools on a Managed switch, which would not be possible if the data never entered the switch.

Switches have not traditionally supported reflective Relay mode, because the spanning tree Protocol (STP) has prevented it , and before the advent of virtualization it made no sense for a frame to is passed back through port. Using Macvtap with Libvirt

If you are are using the Libvirt (libvirt.org) toolkit to manage your virtual machines, add a network interface definition lik E The following in your domain XML file:

<devices>
<interface type= ' direct ' >
<mac address= ' d0:0f:d0:0f:00:01 '/>
<s Ource dev= ' eth0 ' mode= ' Vepa '/>
</interface>
   <!--more devices ...--> </devices
>

Change the "mode" to "bridge" if you don ' t have a VEPA capable switch. Also make sure each tap interface has a unique and sensible value to the MAC address.

This is directive causes Libvirt to create a MACVTAP device associated with the specified source device. Libvirt also opens the corresponding device file (as described above) and passes the file descriptor to QEMU. Thus, when using Libvirt, there is no need to create the tap interfaces by hand, as being shown in the example above. Conclusion

Connecting virtual machines to a virtual switch as described above makes them present on the local network just as if they Were physical machines connected to the LAN. They belong to the same subnet as the physical machines and their IP addresses can is configured by the same DHCP server A s the physical machines. The "Connection is" at the "Data Link Layer" (L2) and is thus independent to which network layer protocol is used on Top of it. The network protocol can is IPv4, IPv6 or even IPX, if you wish. References

kernelnewbies.org Linux Virtualization Wiki-macvtap

Linux information for IBM systems-virtualization blueprints

Libvirt Domain XML Format

Tun/tap Interface Tutorial (background information on the Tap interface)

Wikibon-edge Virtual Bridging