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

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.