[virt-tools-list] [RFC] enable direct interface selection

Cole Robinson crobinso at redhat.com
Tue Apr 5 13:58:28 UTC 2011


On 04/05/2011 08:37 AM, Gerhard Stenzel wrote:
> On Fri, 2011-04-01 at 12:21 -0400, Cole Robinson wrote:
>>
>> Just to make sure I understand this correctly, a 'direct' interface in this
>> context uses macvtap/macvlan to fake a single nic into having multiple MAC
>> addresses, with the kernel multiplexing the network traffic as necc. Guests
>> will get IP addresses from the host network, similar to using a shared bridge.
>> Does this work with all hardware? Are there any downsides or caveats? Right
>> now you hardcode vepa mode, what is the functional difference between bridge
>> and vepa mode?
> 
> The difference between vepa and bridge is documented here:
> http://libvirt.org/formatdomain.html 
> 
> see Direct attachment to physical interface
> 
> ...
> vepa
>         All VMs' packets are sent to the external bridge. Packets whose
>         destination is a VM on the same host as where the packet
>         originates from are sent back to the host by the VEPA capable
>         bridge (today's bridges are typically not VEPA capable).
> bridge
>         Packets whose destination is on the same host as where they
>         originate from are directly delivered to the target macvtap
>         device. Both origin and destination devices need to be in bridge
>         mode for direct delivery. If either one of them is in vepa mode,
>         a VEPA capable bridge is required.
> ...
> 

I'm having difficulty decoding this. What is the functional difference
between these two modes? Can both modes talk to network, host, and host
VMs? The bridge caveat that both devices be in bridge mode, if that
isn't the case, can packets not be delivered, or are they just delivered
sub-optimally?

Thanks,
Cole




More information about the virt-tools-list mailing list