On Mon, 25 Jan 2010, Anthony Liguori wrote:
Date: Mon, 25 Jan 2010 11:38:15 -0600
From: Anthony Liguori <aliguori@xxxxxxxxxxxxxxxxxx>
To: Vivek Kashyap <kashyapv@xxxxxxxxxx>
Cc: Daniel P. Berrange <berrange@xxxxxxxxxx>,
Chris Wright <chrisw@xxxxxxxxxx>,
"libvir-list@xxxxxxxxxx" <libvir-list@xxxxxxxxxx>,
Michael S. Tsirkin <mst@xxxxxxxxxx>, Arnd Bergmann <ARNDB@xxxxxxxxxx>
Subject: Re: [libvirt] Re: Supporting vhost-net and macvtap in libvirt for
QEMU
On 01/21/2010 03:13 PM, Vivek Kashyap wrote:
.....
....
Proposal:
--------
To support the above combinations we need to be able to define the bridge
to be used, the 'uplink' it is associated with, and the interface type
that the VM will use to connect to the bridge.
Currently in libvirt we define a bridge and can associate an ethernet
with it (which is the uplink to the network). In the 'macvlan' and the
'sr-iov' cases there is no creation of the bridge itself. In 'sr-iov' it
is embedded in the 'nic', and in the case of macvlan the function is
enabled when the virtual interface is created.
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.
See Stefan's post - we moved away from 'bridge.xml' to network xml since
the bridge is abstract in this case.
Makes sense, the following wouldn't:
<interface type='bridge' name='br0'>
<bridge mode='VEPA'>
<interface type='ethernet' name='eth0'/>
<interface type='ethernet' name='eth1'/>
</bridge>
</interface>
The above would if you had only one device, the 'uplink' associated. It
creates the bridge object (in libvirt) associated with the physical
device 'eth0' on the host.
<interface type='bridge' name='br0'>
<bridge mode='VEPA'>
<interface type='ethernet' name='eth0'/>
</bridge>
</interface>
In the VM xml, then all one does is reference the above bridge. There is
no need to specify the interface or bridge mode in VM xml. The only
place that comes in is if the bridge supports 'all' (like macvlan
drivers does - vepa, pepa or bridge). In such a case the VM could
request a 'target mode'.
thanks
Vivek
I think the only use of the interface tag that would make sense is:
<interface type='ethernet' name='eth0'>
<vepa/>
</interface>
And then in the VM definition, instead of:
<interface type='direct'>
<source physical='eth0'>
...
</interface>
You can imagine doing something similar with SR-IOV:
<interface type='ethernet' name='eth0>
<sr-iov/>
</interface>
and in the guest:
<interface type='direct'>
<source physical='eth0'>
...
</interface>
The 'type' and 'mode' need not be specified. libvirt could default to the
virtual bridge in the hypervisor. Similarly, the supported modes may be
determined dynamically by libvirt.
Or, we could invent a new type for macvlan or sr-iov based switching:
<interface type ='physical' name='pbr0'/>
<source dev='eth0'/>
<type='embedded|ethernet'/> <mode='all|VEPA|PEPA|VEB'/> // all is
default if supported.
</interface>
IIUC, when you do macvlan/macvtap, there is no 'pbr0' interface. It's
fundamentally different than standard bridging and I think ought to be
treated differently.
Regards,
Anthony Liguori
__
Vivek Kashyap
Linux Technology Center, IBM
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list