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

[Arnd Bergmann]

On Thursday 17 December 2009, Daniel P. Berrange wrote:
> On Wed, Dec 16, 2009 at 07:48:08PM -0600, Anthony Liguori wrote:
>
> > The more interesting invocation of vhost-net though is one where the 
> > vhost-net device backs directly to a physical network card.  In this 
> > mode, vhost should get considerably better performance than the current 
> > implementation.  I don't know the syntax yet, but I think it's 
> > reasonable to assume that it will look something like -net 
> > tap,dev=eth0.   The effect will be that eth0 is dedicated to the guest.
> 
> Ok, so in this model you have to create a dedicated ethXX device for
> every guest, no sharing ?

I think so, but it could be any of
* a physical NIC dedicated to the guest, e.g. if you want to run a firewall
  on that guest and provide connectivity to all other guests to that, or if
  you have lots of real NICs
* an IOV adapter with separate physical or virtual functions
* a VMDq adapter that shows multiple queues on the same PCI function
  as separate network interfaces
* a macvlan device in VEPA or bridge mode

The creation for each of these is different, but once it's there, using it
should be possible in identical ways. I think an important question here is
if libvirt should at all be responsible for creating the devices, or just for
opening the sockets or taps on them.
 
> Yes, since the hardware doesn't allow for any usable configurability of
> the number of VFs, we'll guest assume that they have already been setup.
> Likely the kernel can just enable the max # of VFs at all times.

In macvlan, there is no such limitation. How many would you create?

> > Another model would be to have libvirt see an SR-IOV adapter as a 
> > network pool whereas it handled all of the VF management.  Considering 
> > how inflexible SR-IOV is today, I'm not sure whether this is the best model.
> 
> Agreed, given the hardware limitations I don't see that it is worth the
> bother. 
> 
> This new mode is not really what we'd call 'bridging' in libvirt network
> XML format, so I think we'll want to define a new type of network config
> for it in libvirt. Perhaps 
> 
>   <network type='physical'>
>     <source dev='eth0'/>
>   </network>
> 
> Or type='passthru'

You should also have a parameter mode={'vepa'|'bridge'|'private'} like
macvlan now has. Even if SR-IOV nics today only support bridge mode,
they should support at least vepa mode in the future.

	Arnd