Custom vnet driver

Development
1

Hi,

I’m trying to develop my own custom vnet driver (vxlanxovs) to use vxlan AND ovs.

Everything is almost done, the driver creates the OVS bridge if needed, create a new vxlan interface, and add it to the bridge. The inteface is correctly hotplugged to the VM, I had to modify attach_nic script to add my custom driver and do the same configuration (virtualport) as if it was the ovswitch driver.
But it only works when the VM is running.

When I stop/start the VM, the XML definition sent to libvirt is not using the virtualpost ovs type configuration. It uses a native bridge configuration. I guess if my driver was named ovswitch it would be ok. Do you know where this part is generated ?
Do you know how a driver can modify the VM XML definition ?

Best regards,
Edouard

2

An example, the interface bloc in my deploiement.X is like:

<interface type='bridge'>
  <source bridge='br0'/>
  <mac address='02:00:90:d4:4a:ce'/>
  <target dev='one-870-0'/>
  <model type='virtio'/>
</interface>

I need something like:

<interface type='bridge'>
  <virtualport type='openvswitch'/> 
  <source bridge='br0'/>
  <mac address='02:00:90:d4:4a:ce'/>
  <target dev='one-870-0'/>
  <model type='virtio'/>
</interface>
3

I’m afraid it is in the src/vmm/LibVirtDriverKVM.cc

if (VirtualNetwork::str_to_driver(vn_mad) == VirtualNetwork::OVSWITCH)
{
file << "\t\t\t<virtualport type='openvswitch'/>" << endl;

Could someone confirm that ? or help me to change this from my custom driver ?

4

is there a way to develop custom vnet driver, may be thru inheritance, to make it detected as a VirtualNetwork::OVSWITCH vn_mad by oned ?

Is there a documentation ?

Or, as a workaround, is there a way I can patch the deploy file (XML libvirt VM definition) from my pre/post/clean script in my driver ?

Please I really need help, I’m just missing this 1 line in the XML definition :frowning:

5

Hi Edouard,

I am afraid that the ovswitch is hardcoded in the sources.

Regarding a workaround. I’m using the option in the VM_MAD section to set custom script for local execution(the -l flag) instead of the mainstream one.
This way you can replace the vm_mad/deploy script with your custom script that will be executed on the backend instead of the KVM host. There you’ll receive the final deploy XML, so you can edit it and then you must copy it to the KVM host and run the virsh command there(as alternative after editing the VM’s XML you can pass it to the native deploy script on the remote kvm host). Probably you’ll need to catch the add network too.

Hope this helps.

Kind Regards,
Anton Todorov

6

Thanks Anton, this is looking quite complicated. It’s sad that ovswitch is hard coded, that means noone can do custom drivers dealing with OVS.

So I will try an other way. I will modify the ovswitch driver provided by OpenNebula and add some key in the vnet template so I can do what I want only with some specific vnet.

What I want to achieve:

  • Automatic creation if OVS bridge doesn’t exist
  • Create a VXLAN interface using VNI attribute from my vnet template (OpenNebula uses VLAN_ID which is a wrong term)
  • Add this VXLAN interface in the OVS to make a multicast tunnel (OVS only supports VXLAN p2p tunnels)

that’s all. then the classic ovswitch driver features can be used (tags/vlan/openflow).

The problem with overriding the deploy script (or using hooks) is to know which NIC is using the OVS+VXLAN. And since 95% of the code is from the ovswitch driver, I will try to patch this one. Not the best way since I’m sure that each OpenNebula update will break that.

7

Hi Edouard,

I think you missed the detail that the script is run on the front-end where you can easily query OpenNebula for details. So before editing the xml you can query opennebula for anything you want. You can even rebuild the entire deployment XML and then pass it to the driver on the kvm host.
But your alternative to extend the ovswitch driver sounds much better. Then you can create feature/pull request and the code could be merged upstream. Unfortunately judging by indirect signs based on my experience it looks like the developers are preparing for next release. So such change could be considered for merging after next release though.

Kind Regards,
Anton Todorov

8

Thank you Anton, I was missing all the detail about the custom script. If I can succeed with patching the ovswitch native driver I will try this way.
I would be glad to contribute. May be I should open a ticket to give some feedback about the OVS driver, and the inability to use custom drivers with the OVS because of the hardcoded value in LibVirtDriverKVM.cc.
Anyway all of this is very interesting, it helps me to have a better insight of OpenNebula.