[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Supporting vhost-net and macvtap in libvirt for QEMU



On Tue, Jan 26, 2010 at 07:15:05PM -0800, Vivek Kashyap wrote:
> On Mon, 25 Jan 2010, Anthony Liguori wrote:
> 
> >>Describing the bridge and modes:
> >>--------------------------------
> >>So, we can define the bridge function using a new type or maybe extend
> >>the bridge.xml itself.
> >>
> >><interface type='bridge' name='br0'>
> >><bridge>
> >><type='hypervisor|embedded|ethernet'/> //hypervisor is default
> >><mode='all|VEPA|PEPA|VEB'/>          // 'all' is default if supported.
> >><interface type='ethernet' name='eth0'/>
> >></bridge>
> >></interface>
> >
> >Does this really map to how VEPA works?
> >
> >For a physical bridge, you create a br0 network interface that also has 
> >eth0 as a component.
> 
> Right. So a bridge has at least one 'uplink'. In this case the bridge is
> an abstract concept. It still has an 'uplink' which is the device (eth0
> in this instance).
> 
> >
> >With VEPA and macv{lan,tap}, you do not create a single "br0" interface. 
> >Instead, for the given physical port, you create interfaces for each tap 
> >device and hand them over.  IOW, while something like:
> >
> ><interface type='bridge' name='br0'>
> ><bridge>
> ><interface type='ethernet' name='eth0'/>
> ><interface type='ethernet' name='eth1'/>
> ></bridge>
> ></interface>
> 
> The above is not in the domain xml but was proposed in the bridge xml.
> 
> The advantage of using the bridge concept is that it appears the same
> for macvlan and the virtual Linux host bridge. The 'macvlan' interface
> itself can support 'bridge' mode in addition to the 'vepa' mode.
> 
> Therefore, one is creating the bridge, attaching it to the physical
> device. This device is the one which provides the 'uplink' i.e. is
> either the sr-iov card or is the device associated with the macvlan driver. 
> The domain xml can now point to the above bridge.  For the interfaces it 
> creates it can associate target names.

The main issue with this, is that when using VEPA/macvlan there's
no actual host device being created as there is when using the
linux software bridge. The <interface> descriptions here are mapped
straight into the  /etc/sysconfig/networking-scripts/ifcfg-XXX files
that trigger creation & setup of the physical, bridge, bonding & vlan
interfaces. Since there is no actual bridge interface, there's no
ifcfg-XXX to map onto in the VEPA case.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]