On 23/01/14 5:48 PM, "Florin Dumitrascu" <florin.dumitra...@intunenetworks.com> wrote:
>Hi Murali, Tuna, > >Thank you for this piece of information. All starts to make sense now. >I am wondering if there is a better way to communicate this issue to end >users. It would save others a couple of weeks struggling. >If GRE is not just a technology preview (meaning it has been explicitly >mentioned in previous release notes), the known issues lists for 4.2.0 >and 4.2.1 should be explicitly updated. > >Leaving 4.2 behind now, which will be the first release to include GRE >refactoring with OVS service provider ? Ideally Tuna's fix (to make OVS as Connectivity service provider) should have gone into 4.2.1. Looks like they did not go into 4.2.1 Tuna, Can you please ensure your fixes (excluding support for KVM/XCP) went into 4.2, 4.3 branches as well. Thanks, Murali > >Regards, >Florin > >-----Original Message----- >From: ng.t...@gmail.com [mailto:ng.t...@gmail.com] On Behalf Of Nguyen >Anh Tu >Sent: Thursday, January 23, 2014 11:56 AM >To: Murali Reddy >Cc: dev@cloudstack.apache.org; Chiradeep Vittal; Sebastien Goasguen >Subject: Re: Create GRE tunnel failed in 4.2 with XenServer. > >Wow... I thought everything was done in XenServer before my submitted >patch. > >--Tuna > >Sent from my GT-N7000 >On Jan 23, 2014 6:49 PM, "Murali Reddy" <murali.re...@citrix.com> wrote: > >> Please see the thread >> >> https://www.mail-archive.com/dev@cloudstack.apache.org/msg17396.html >> >> >> >> On 23/01/14 5:10 PM, "Florin Dumitrascu" >> <florin.dumitra...@intunenetworks.com> wrote: >> >> >Hi, >> > >> >Just want to add a few of my observations to what Tuna said. >> > >> > >> >a. I managed to have GRE isolation working with CloudStack 4.1.1 >> >and a quick patch to bypass "enableXenserverNetwork" method. >> > >> > >> > >> >b. I tried GRE isolation with CloudStack 4.2.1 with the same quick >> >patch for bypassing "enableXenserverNetwork". >> > >> >Once that method was bypassed, guest VMs came up, but the tunnel was >> >not created. It seems to me that OvsElement methods (implement, >> >prepare) are not invoked. >> > >> >Did something change in 4.2 to affect this ? I am setting >> >"sdn.ovs.controller=true" in global settings and select GRE isolation >> >method in the guest physical network. >> > >> > >> >Thank you, >> >Florin >> > >> > >> > >> >From: ng.t...@gmail.com [mailto:ng.t...@gmail.com] On Behalf Of >> >Nguyen Anh Tu >> >Sent: Thursday, January 23, 2014 10:15 AM >> >To: dev@cloudstack.apache.org; Sebastien Goasguen; Chiradeep Vittal; >> >Florin Dumitrascu >> >Subject: Create GRE tunnel failed in 4.2 with XenServer. >> > >> > >> >Guys, >> > >> >Florin raised a problem in creating GRE tunnel with ACS 4.2 release >> >and XenServer 6.2. I found the problem come from >> >enableXenserverNetwork method. CloudStack made a tricky to create >> >network when plugging a VIF to >> >dom0 and then unplugging immediately. With XCP version I done in >> >GSOC, I bypassed that step so that no problem. >> > >> >Didn't know why we need that tricky and how to solve it. I'm working >> >on it. Any help or explaination? >> > >> >Thanks, >> > >> >--Tuna >> > >> >Sent from my GT-N7000 >> > >> >IMPORTANT NOTE: The information in this e-mail (and any attachments) >> >is confidential. The contents may not be disclosed or used by anyone >> >other than the addressee. If you are not the intended recipient, >> >please notify the sender immediately or telephone: +353 (0)1 6204700. >> >We cannot accept any responsibility for the accuracy or completeness >> >of this message as it has been transmitted over a public network. If >> >you suspect that the message may have been intercepted or amended, >>please call the sender. >> > >> >> >> > >IMPORTANT NOTE: The information in this e-mail (and any attachments) is >confidential. The contents may not be disclosed or used by anyone other >than the addressee. If you are not the intended recipient, please notify >the sender immediately or telephone: +353 (0)1 6204700. We cannot accept >any responsibility for the accuracy or completeness of this message as it >has been transmitted over a public network. If you suspect that the >message may have been intercepted or amended, please call the sender. >
