On 11/15/2012 08:56 PM, huntxu wrote:
On Thu, 15 Nov 2012 17:54:42 +0800, Gary Kotton <gkot...@redhat.com> wrote:

On 11/14/2012 05:42 PM, Mark Wu wrote:
On 11/14/2012 07:53 PM, Gary Kotton wrote:
On 11/14/2012 11:53 AM, Livnat Peer wrote:
On 14/11/12 00:28, Adam Litke wrote:
On Sun, Nov 11, 2012 at 09:46:43AM -0500, Alon Bar-Lev wrote:
Can we just start with running ovs in standalone mode at first?

Yes, most certainly.
It could have the basic forward function based on MAC-learning and bond/vlans/tunnel function by specifying related options when adding a new port. We could connect each physical nic for vm network with an ovs bridge, and then the VM can get external network access. I agree with that without adding a controller, we can't get a unified control panel. But I think the standalone mode could fit current oVirt network model well.
Gary, please correct me if I am wrong or any suggestions from you?

You are correct. This is certainly one way of achieving a first step for integrating with the OVS. My concerns are as follows (maybe some of them do not exist :)):
+1 for a standalone ovs as a first step.

1. Boot process with binding to physical NICS to the OVS
Both ifup/down scripts shipped with upstream ovs and bridge compatible mode
work well in my test.

2. The OVS maintains a database. This may need to be cleaned of tap devices when the appliance reboots - lets take an edge case into account - say the appliance has a number of VMs running - there will be tap devices for these VMs registered with the OVS. If there is a exception or power failure the appliance will reset. These devices will still be registered when the appliance reboots. Who cleans them and when?
Yes, I also prefer the ovs database be clean every time it starts. It
should know nothing about the configuration when starting, except for
essential ones for the host to connect to the management end. In my mind,
vdsm/ovs should configure the machine only if requested by the management
end. The configuration, however, is centralized.

I think it's better to continue this discussion after we get the first draft of ovs integration page done
as Gary suggested.
3. What about the traditional bridged network - will these be migrated to OVS.
I don't think we are going to drop the traditional bridged network support.
Isn't providing another choice better than only one? Could we implement a
generic layer providing consistent APIs for management, as well as calling different low-level libs/tools among environments which requirements varies
from one to another?
I have submit a patch for it: http://gerrit.ovirt.org/#/c/7915/ It would be appreciated if you could review



vdsm-devel mailing list

Reply via email to