cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <>
Subject Re: Review Request: CLOUDSTACK-2327: make cloud-setup-agent ovs aware
Date Wed, 29 May 2013 06:26:46 GMT
On Tue, May 28, 2013 at 11:17 PM, Hiroaki KAWAI <>wrote:

> Hi,
> Thank you for comments;
> (2013/05/29 9:32), Sheng Yang wrote:
>> I saw it a bit late...
>> But I just found it need to depends on
>> network.bridge.type=**openvswitch
>> How would that happen if user didn't add host before?
> It defaults to native linux bridge.
>  Maybe we would just try "ovs-vsctl show" to see if we can find bridge
>> for ovs or not, then overwrite the network.bridge.type?
> What I thought was the XenServer ovs configuration process.
> I remember I explicitly configured the hypervisor to use
> openvswitch as a backing briding system.

Yes. It's a part of XenServer configruation(not done by CS). And ovs should
be used by default after 6.0 release.

> One more reason was to allow people use native bridging
> even one has accidentally installed openvswitch package.

Bridge created on ovs is different from bridge created on native linux
bridge. For later, ovs-vsctl shouldn't show any bridge/switch(e.g.
cloudbr0), but brctl would. And I remember they're probably
exclusive(openvswitch kernel module vs bridge module)?

> I think you're suggesting making it more few setup steps
> for enabling ovs. And I completly agree with it. So we might
> need some more improvements here...

In fact, I am thinking about preconfigured ovs environment(KVM or Xen). I
think openvswitch enabling shouldn't be part of work of cloudstack(e.g.
it's not a part of adding XenServer host). For KVM, user can loaded
openvswitch module(without brcompat module), unload bridge module, and
start openvswitch service to enable ovs. We should add some steps in manual
for that.

I am agree we need more investigation here, to find a proper way tell if
user want to use ovs or not.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message