On Tue, May 28, 2013 at 11:17 PM, Hiroaki KAWAI <ka...@stratosphere.co.jp>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 >> agent.properties: 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. --Sheng
