[ovs-dev] OVS-Hyper-V-Discovery-Agent Design Document

[Alin Serdean]

Sorry for the late reply. We had a few days of bank holiday last week.

> -----Original Message-----
> From: Ben Pfaff [mailto:blp at ovn.org]
> Sent: Tuesday, November 29, 2016 2:28 AM
> To: Nithin Raju <nithin at vmware.com>
> Cc: Yin Lin <yinlin10 at gmail.com>; dev at openvswitch.org; Alin Serdean
> <aserdean at cloudbasesolutions.com>; Justin Pettit <jpettit at ovn.org>
> Subject: Re: [ovs-dev] OVS-Hyper-V-Discovery-Agent Design Document
> 
> OK, I understand now.
> 
> Having ovs-vswitchd itself add ports would be unprecedented.  Normally, we
> depend on some part of the system integration to do that: libvirt does it in
> modern KVM environments (as you say), a hook script does it on XenServer,
> and so on.
[Alin Serdean] I think we need to look at a bigger picture on what we are trying to achieve.
AFAIK, in the case of libvirt/Xen, someone asks them to create an adapter and after it is created the result is added to OVSDB.
On Windows, someone asks vmms (https://technet.microsoft.com/en-us/library/dd582295(v=ws.10).aspx) to create a port on a switch, rename the port which was created, and after add it to OVSDB afterwards.
In the case of Windows+OpenStack (with or without OVN) things are already handled since the code for port renaming is already there. If someone wants to integrate it in his solution, he could use/reuse/implement the code in the powershell script which is in our repository (1).
This daemon is targeted for unexperienced users which do not want/do not know how to do the extra step of renaming the port name. This will give us better user experience.
The reasons I would like to add the functionality in vswitchd are simplicity and speed (we see the port creation in the windows datapath, after it was created by vmms, and during an upcall we could add the port).
> 
> My preference would be to keep these details of the system integration
> separate from ovs-vswitchd, since it matches the implementation
> elsewhere.  I'd expect this to be a pretty simple daemon, which probably
> wouldn't use much CPU or memory.
> 
[Alin Serdean] My main problem with the current implementation is that WMI calls are slow. Using vswitchd or another monitor that reuses the netlink implementation would be better IMO.

(1) https://github.com/openvswitch/ovs/blob/master/datapath-windows/misc/OVS.psm1