On Wed, 27 Jan 2010, Daniel P. Berrange wrote:
.....
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.
ok, thanks for this clarification. We can use the similar setup using a
different construct - maybe physical or direct.
Vivek
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 :|
__
Vivek Kashyap
Linux Technology Center, IBM
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list