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:
snip
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
it.
Thanks
Gary
Thanks
Mark.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
