Re: Introducing Vishwas

Welcome Vishwas. Regards. From: Vishwas Pathak Sent: 24 February 2017 14:38:10 To: d...@cloudstack.apache.org; users@cloudstack.apache.org Subject: Introducing Vishwas Hello CloudStack team, My name is Vishwas Pathak and I am

Re: VPC Site to Site VPN

We can change the default parameter to 20 for creating 20 s2s vpn connections with external gateways. On Tue, Feb 7, 2017 at 10:00 PM, Rafael Weingärtner < rafaelweingart...@gmail.com> wrote: > Isn't this only a matter of changing the parameter "site2site.vpn.vpnga"? > The number 4 seems to be

Re: CloudStack Advanced networking doubt

Sorry Dag, I probably did not express myself clearly. I knew that ACS had nothing to do with it. I wanted only to check the underlying structure requirements, so the scenario I described would work. Thanks for your explanation, I now understood it ;) On Tue, Feb 28, 2017 at 2:09 PM, Simon

Re: CloudStack Advanced networking doubt

So, it's actually a higher level than that. Each vlan is a broadcast domain (it's a virtual LAN). Managed switches support the ability of tagging (or trunking depending on the vendor) various sets of vlans to physical ports. When you need a vlan to be sent to a different switch and you want to

Re: CloudStack Advanced networking doubt

Hi Rafael, I think you’re overcomplicating things a bit. As Simon said – all switches used in the same zone need to be configured to trunk the same VLAN range. If your zone uses VLANs 100-200 then all switches serving the PODs and clusters in that zone need to be able to trunk VLANs 100-200,

Re: CloudStack Advanced networking doubt

Ok, let’s see if I understood what we are doing. Within a switch domain, we send packets using the mac address of network interface cards. The switch has a table matching mac addresses to ports they are being used in; therefore, it can efficiently execute the forwarding. When you say that we

Re: CloudStack Advanced networking doubt

Rafael, ACS expects the same layer 2 broadcast domain across all pods in a zone. So your switches have to trunk all vlans. This can get really nasty for larger typologies (due to vlan limits and spanning tree), hence why technologies like vxlan, stt and gre were invented. - Si

Re: CloudStack Advanced networking doubt

Great, thanks for the explanation Dag. So, for two VMs that are on the same virtual network, but different PODs (consequently in a different layer -2 domain switch) how does ACS handle in this situation? On Tue, Feb 28, 2017 at 1:36 PM, Dag Sonstebo wrote: > Hi

Re: CloudStack Advanced networking doubt

Hi Rafael, in the confines of that zone yes. All switches serving one zone need to trunk the same VLANs, no matter how you configure your PODs or clusters. Regards, Dag Sonstebo Cloud Architect ShapeBlue On 28/02/2017, 18:31, "Rafael Weingärtner" wrote: You

Re: CloudStack Advanced networking doubt

You mean, once a user allocates a VLAN’s (let’s say tag 1), in all of the switches this VLAN tag is reserved? On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo wrote: > Hi Rafael, > > Keep in mind for an advanced zone the broadcast domain for VLANs is the > zone rather

Re: CloudStack Advanced networking doubt

Hi Rafael, Keep in mind for an advanced zone the broadcast domain for VLANs is the zone rather than the POD, i.e. VMs in the new POD would use the same VLANs as the previous VMs in the original POD. Regards, Dag Sonstebo Cloud Architect ShapeBlue On 28/02/2017, 16:16, "Rafael Weingärtner"

CloudStack Advanced networking doubt

Hi folks, I was checking some information regarding ACS advanced networking deployment mode, and I ran into this figure [1]. This made me wonder, what would happen with the following scenario. Let`s say I have a similar scenario as the one depicted in figure [1], a set of pods with a set of

Re: Ubuntu 16.04, Openvswitch networking issue

Did you configure the parameter “system.vm.default.hypervisor”? If so, ACS will try to deploy only on hosts of the hypervisor type configured there. If the parameter is not configured, ACS will get the first it finds. After it deployed the VR (let’s say on KVM host of cluster "x"), if a redeploy

Re: Re: 退订

退订这个邮件列表，是发送邮件至： 至于还有用cloudstack的，还是推荐留下来。 ---引用-- // To remove your address from the list, send a message to: //

KVM VirtualRouter broken NIC deployment

Hi, we're running into a strange error deploying a virtual router on KVM. The router ends up with 4 nics like eth0 - eth3. The agent log looks like: 2017-02-28 11:48:16,108 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null) (logid:9e499072) Request:Seq 247-4546946773783937036: { Cmd ,

Re: Ubuntu 16.04, Openvswitch networking issue

Dear Rafael, thank you very much. I am wondering why just KVM is tried in our case? The Zone got 3 clusters, one 3 node Xenserver 6.5, one 1 node Xenserver 7.0 and one 3 node KVM cluster. Is there some Setting we have to edit? All the best, Florian