[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-API] VIF creation

  • To: "xen-api@xxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxx>
  • From: Ranjeet R <rranjeet@xxxxxxxxxxx>
  • Date: Wed, 6 Nov 2013 23:12:28 +0000
  • Accept-language: en-US
  • Delivery-date: Wed, 06 Nov 2013 23:36:19 +0000
  • List-id: User and development list for XCP and XAPI <xen-api.lists.xen.org>
  • Thread-index: Ac7bRagiVCGSUu+0TU+2auNXRBm1IA==
  • Thread-topic: VIF creation

I am currently working on the OpenContrail team integrating Cloudstack orchestrator with Xen.
In OpenContrail, the OVS is replaced by a similar forwarding plane called vRouter. The OpenContrail vRouter is a forwarding plane (of a distributed router) that runs in the hypervisor of a virtualized server. It extends the network from the physical routers and switches in a data center into a virtual overlay network hosted in the virtualized servers.
Now in XAPI, when the CloudStack orchestrator triggers a new VM instance, it results in XAPI calls to vif-create which are handled by the “vif” script which internally calls the “ovs-vsctl” which configures the OpenVSwitch to create and associate VIFs. Similarly, the “vif” script handles calls to delete, hotplug and hotunplug a VIF which in turn makes reference calls to “ovs-vsctl” tool.
Now, can you please validate my understanding -
  • Assuming vRouter has management interfaces to create VIFs as OpenVSwitch, is it sufficient to replace the calls to ovs-vsctl in the vif script to the corresponding calls to vRouter. I see that the call to OVS is based on the underlying network infrastructure configured in /etc/xensource/network.conf and we can base the decision to call the corresponding management tool based on configuration.
  • From what I learnt from reading the XAPI code, I don’t have to touch anything in OCAML code since it seems to be abstracted away from the underlying implementation. Is this statement valid?
Your input/thoughts are highly appreciated.
Xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.