On 11/15/2012 08:56 PM, huntxu wrote:
On Thu, 15 Nov 2012 17:54:42 +0800, Gary Kotton <gkot...@redhat.com>
I think it's better to continue this discussion after we get the first
draft of ovs integration page done
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
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.
Both ifup/down scripts shipped with upstream ovs and bridge compatible
1. Boot process with binding to physical NICS to the OVS
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
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.
as Gary suggested.
I have submit a patch for it: http://gerrit.ovirt.org/#/c/7915/ It would
be appreciated if you could review
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
Isn't providing another choice better than only one? Could we implement a
generic layer providing consistent APIs for management, as well as
different low-level libs/tools among environments which requirements
from one to another?
vdsm-devel mailing list