I hope the following answers your questions. Alin. From: Shashank Ram [mailto:[email protected]] Sent: Thursday, December 15, 2016 10:27 PM To: Alin Serdean <[email protected]>; [email protected] Subject: Re: [ovs-dev] [PATCH 1/3 v7] Windows: Add internal switch port per OVS bridge
Thanks Alin. I had a few other questions. 1. For new ports being added to a bridge, will the ports be created only if its type=internal? [Alin Serdean] I don't quite understand the question, but I will try to explain the best I can: If a new port is added with type=internal and the OVS extension will is enabled, we will create a new Vswitch internal port. For types of port things are not changed 2. Is there a reason to disable the adapter to rename it? If the adapter was previously enabled, why is it left to the user to enable it? [Alin Serdean] The idea is to not create traffic once the adapter is created so it does not polute with packets unless the user actually wants to enable it. The port renaming is to keep the ovs names in sync with the created windows port names. If the adapter is already created we do not disable it. The code follows the following path: If its a port type=internal=>check if ovs is enabled and running=>check if the port exists, if not try to add it=> if adding was succesful disable/rename. ________________________________ From: Alin Serdean <[email protected]<mailto:[email protected]>> Sent: Thursday, December 15, 2016 12:12:59 PM To: Shashank Ram; [email protected]<mailto:[email protected]> Subject: RE: [ovs-dev] [PATCH 1/3 v7] Windows: Add internal switch port per OVS bridge Hi Shashank, Ovs-vsctl add-br <bridge_name > does not change the current behaviour. Ovs-vsctl add-br creates an internal port automatically (think of specifying type=internal automatically). Same applies for ovs-vsctl del-br <bridge_name> Please view the output of the command: ovsdb-client dump -f html in the attachment (both windows and linux). Thanks, Alin. From: Shashank Ram [mailto:[email protected]] Sent: Thursday, December 15, 2016 9:46 PM To: Alin Serdean <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [ovs-dev] [PATCH 1/3 v7] Windows: Add internal switch port per OVS bridge Hi Alin, please find my comments inline. Thanks, Shashank ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Alin Serdean <[email protected]<mailto:[email protected]>> Sent: Thursday, December 15, 2016 11:36 AM To: [email protected]<mailto:[email protected]> Subject: [ovs-dev] [PATCH 1/3 v7] Windows: Add internal switch port per OVS bridge This patch updates the following commands in the vswitch: ovs-vsctl add-br br-test ovs-vsctl del-br br-test ovs-vsctl add-br br-test: ---> Shashank: This command should not change its current behavior. Internal ports should only be created if "--set interface type=internal" is set for the port in the interface table. This command will now create an internal port on the MSFT virtual switch using the WMI interface from Msvm_VirtualEthernetSwitchManagementService leveraging the method AddResourceSettings. Before creating the actual port, the switch will be queried to see if there is not a port already created (good for restarts when restarting the vswitch daemon). If there is a port defined it will return success and log a message. After checking if the port already exists the command will also verify if the forwarding extension (windows datapath) is enabled and on a single switch. If it is not activated or if it is activated on multiple switches it will return an error and a message will be logged. After the port was created on the switch, we will disable the adapter on the host and rename to the corresponding OVS bridge name for consistency. The user will enable and set the values he wants after creation. ovs-vsctl del-br br-test --> Shashank: The MSFT internal port should only be removed if the interface type=internal. This command will remove an internal port on the MSFT virtual switch using the Msvm_VirtualEthernetSwitchManagementService class and executing the method RemoveResourceSettings. Both commands will be blocking until the WMI job is finished, this allows us to guarantee that the ports are created and their name are set before issuing a netlink message to the windows datapath. This patch also includes helpers for normal WMI retrievals and initializations. Appveyor and documentation has been modified to include the libraries needed for COM objects. This patch was tested individually using IMallocSpy and CRT heap checks to ensure no new memory leaks are introduced. Tested on the following OS's: Windows 2012, Windows 2012r2, Windows 2016 Signed-off-by: Alin Gabriel Serdean <[email protected]<mailto:[email protected]>> Acked-by: Paul Boca <[email protected]<mailto:[email protected]>> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
