MacVTap driver considerations

From purely a performance perspective, based on the workloads tested and the Linux® and KVM levels measured, the MacVTap driver consistently demonstrated higher throughputs and better CPU efficiency.

The MacVTap driver provides exceptional transactional throughput and operations/sec results (up to 10-50%) better than either of the two software bridges. Additionally, throughput of MacVTap scales up with load more quickly compared to using a software bridge. This means that MacVTap is more CPU efficient, consuming less CPU resources to complete the same amount of work. Stated another way, MacVTap can do more work using the same amount of CPU resources.

Although MacVTap is the best performing, it suffers from a couple of issues that may limit the use cases where it would be a suitable choice.

The first limitation is that MacVTap can not readily enable network communication between the KVM host and any of the KVM guests using MacVTap.

• This issue can be overcome in two different ways. The first way to avoid this limitation is to use a special hardware switch that supports hairpin mode to connect the IBM Z system to the outside world. However, hairpin mode is not a common feature in most hardware switches and those switches that do have this feature tend to be significantly more expensive.
• The second way to enable KVM host to guest communications is by having multiple network interfaces in the KVM host. Configure the second KVM host interface on the same segment with a different subnet from the first host interface. MacVTap only restricts traffic flow to the same subnet shared between host and guest. While this method works w/o purchasing additional costly hardware, it still requires that a second interface be available and appropriately configured in the KVM host and each KVM guest.

A second limitation of MacVTap is that it must attach to a physical host interface. MacVTap, unlike software bridges, provides no way to enable KVM guests to communicate without first being attached to a host interface which is active and externally facing. In other words, KVM guests using MacVTap will be external facing and exposed to external network traffic. This is not necessarily a bad thing. It just doesn't provide KVM host only isolation and connectivity for KVM guests that other choices allow.