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

Yin Lin yinlin10 at gmail.com
Thu Dec 8 22:14:47 UTC 2016


Hi Alin,

Sorry for the late response. I somehow that the message slip by.

How do you use vswitchd/netlink to watch VIF creation/deletion and Hyper-V
switch changes? Note that through WMI, we monitor the following events:
1. VIF creation/deletion.
2. Hyper-V switch creation/deletion.
3. OVS extension enable/disable on a Hyper-V switch.

Also, note that we only register a callback with WMI so that we are
passively notified when a change we are interested in happens. We do not
run WMI calls in a loop.

If you have a better solution, do you mind elaborate a little more on your
idea?

Best regards,
Yin Lin

On Mon, Dec 5, 2016 at 12:05 PM, Alin Serdean <
aserdean at cloudbasesolutions.com> wrote:

> 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
>
>


More information about the dev mailing list