As you can see, the policy is mostly independent from the qemu
implementation and even from the kernel implementation. Naming the
macvtap code in qemu '-net vepa' would completely mix up things
for people that want to use vepa with an SR-IOV card, or macvtap
in bridge mode!
Qemu can continue to name the interface '-net tap'. libvrt can invoke it
as '-net tap, fd=x', whether the fd is of type tap or macvtap.
The SR-IOV/VMdq/macvlan are all 'offloading' the briding function
to a particular physical device. In the case of the 'vepa' (or even the
pepa) mode the offload is to an external switch on the network.
The sriov nic's embedded bridge can also be put into VEPA mode or be
used as a bridge for packets among the virtual functions. The embedded
bridge might even support the 'pepa' mode.
Similarly, the 'macvlan' driver can support the bridge mode for packets
among the macvlan interfaces, or support vepa/pepa modes where the
packes are sent out on the wire without bridging function.
Therefore, we define an interface type that can be linked to a
specific NIC (source dev), and a set of supported modes defined. Expanding
on Daniel's suggestion earlier in this thread on 'physical'
type, we can do the following:
<interface type ='physical' name='somename'/>
<source dev='eth0'/>
<type='sr-iov|vmdq|ethernet'/> // it can be of one type
<mode='vepa|pepa|bridge'/>
</interface>
The 'mode' can be left blank since the same NIC can support differnt
modes per VM's network inteface defined in the domain xml. The 'mode' can
however be used to restrict the supported modes for the particular named
instance.
With the above, in the domain xml, we specify:
<interface type='physical'/>
<name='somename'/>
<type='macvtap|tap'/> // one of the two to be specified
<target mode='vepa|pepa|bridge'/> //specify the mode needed for the VM
</interface>
With the above, when instantiating a guest libvirt will determine the
type of interface. Example: for a 'vepa' on device eth0, libvirt will
create a macvtap interface while setting the mode to vepa.
This fd is what is passed to qemu. Since macvtap/tap appear the same to
qemu we should not have to modify anything beyond libvirt.
thoughts?
Vivek/Stefan/Gerhard
__
Vivek Kashyap
Linux Technology Center, IBM
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
