[libvirt] Re: Supporting vhost-net and macvtap in libvirt for QEMU
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