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

[Vivek Kashyap]

On Mon, 25 Jan 2010, Anthony Liguori wrote:

> Date: Mon, 25 Jan 2010 11:38:15 -0600
> From: Anthony Liguori <aliguori at linux.vnet.ibm.com>
> To: Vivek Kashyap <kashyapv at us.ibm.com>
> Cc: Daniel P. Berrange <berrange at redhat.com>,
>     Chris Wright <chrisw at redhat.com>,
>     "libvir-list at redhat.com" <libvir-list at redhat.com>,
>     Michael S. Tsirkin <mst at redhat.com>, Arnd Bergmann <ARNDB at de.ibm.com>
> 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