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
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.
3. What about the traditional bridged network - will these be migrated
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?
vdsm-devel mailing list