for stable/essex the patach is here https://review.openstack.org/#/c/11986/,
2012/8/25 Sam Su <susltd...@gmail.com>: > That's great, thank you for your efforts. Can you make a backport for essex? > > Sent from my iPhone > > On Aug 24, 2012, at 7:15 PM, heut2008 <heut2...@gmail.com> wrote: > >> I have fixed it here https://review.openstack.org/#/c/11925/ >> >> 2012/8/25 Sam Su <susltd...@gmail.com>: >>> Hi, >>> >>> I also reported this bug: >>> https://bugs.launchpad.net/nova/+bug/1040255 >>> >>> If someone can combine you guys solution and get a perfect way to fix this >>> bug, that will be great. >>> >>> BRs, >>> Sam >>> >>> >>> On Thu, Aug 23, 2012 at 9:27 PM, heut2008 <heut2...@gmail.com> wrote: >>>> >>>> this bug has been filed here https://bugs.launchpad.net/nova/+bug/1040537 >>>> >>>> 2012/8/24 Vishvananda Ishaya <vishvana...@gmail.com>: >>>>> +1 to this. Evan, can you report a bug (if one hasn't been reported yet) >>>>> and >>>>> propose the fix? Or else I can find someone else to propose it. >>>>> >>>>> Vish >>>>> >>>>> On Aug 23, 2012, at 1:38 PM, Evan Callicoat <diop...@gmail.com> wrote: >>>>> >>>>> Hello all! >>>>> >>>>> I'm the original author of the hairpin patch, and things have changed a >>>>> little bit in Essex and Folsom from the original Diablo target. I >>>>> believe I >>>>> can shed some light on what should be done here to solve the issue in >>>>> either >>>>> case. >>>>> >>>>> --- >>>>> For Essex (stable/essex), in nova/virt/libvirt/connection.py: >>>>> --- >>>>> >>>>> Currently _enable_hairpin() is only being called from spawn(). However, >>>>> spawn() is not the only place that vifs (veth#) get added to a bridge >>>>> (which >>>>> is when we need to enable hairpin_mode on them). The more relevant >>>>> function >>>>> is _create_new_domain(), which is called from spawn() and other places. >>>>> Without changing the information that gets passed to >>>>> _create_new_domain() >>>>> (which is just 'xml' from to_xml()), we can easily rewrite the first 2 >>>>> lines >>>>> in _enable_hairpin(), as follows: >>>>> >>>>> def _enable_hairpin(self, xml): >>>>> interfaces = self.get_interfaces(xml['name']) >>>>> >>>>> Then, we can move the self._enable_hairpin(instance) call from spawn() >>>>> up >>>>> into _create_new_domain(), and pass it xml as follows: >>>>> >>>>> [...] >>>>> self._enable_hairpin(xml) >>>>> return domain >>>>> >>>>> This will run the hairpin code every time a domain gets created, which >>>>> is >>>>> also when the domain's vif(s) gets inserted into the bridge with the >>>>> default >>>>> of hairpin_mode=0. >>>>> >>>>> --- >>>>> For Folsom (trunk), in nova/virt/libvirt/driver.py: >>>>> --- >>>>> >>>>> There've been a lot more changes made here, but the same strategy as >>>>> above >>>>> should work. Here, _create_new_domain() has been split into >>>>> _create_domain() >>>>> and _create_domain_and_network(), and _enable_hairpin() was moved from >>>>> spawn() to _create_domain_and_network(), which seems like it'd be the >>>>> right >>>>> thing to do, but doesn't quite cover all of the cases of vif >>>>> reinsertion, >>>>> since _create_domain() is the only function which actually creates the >>>>> domain (_create_domain_and_network() just calls it after doing some >>>>> pre-work). The solution here is likewise fairly simple; make the same 2 >>>>> changes to _enable_hairpin(): >>>>> >>>>> def _enable_hairpin(self, xml): >>>>> interfaces = self.get_interfaces(xml['name']) >>>>> >>>>> And move it from _create_domain_and_network() to _create_domain(), like >>>>> before: >>>>> >>>>> [...] >>>>> self._enable_hairpin(xml) >>>>> return domain >>>>> >>>>> I haven't yet tested this on my Essex clusters and I don't have a Folsom >>>>> cluster handy at present, but the change is simple and makes sense. >>>>> Looking >>>>> at to_xml() and _prepare_xml_info(), it appears that the 'xml' variable >>>>> _create_[new_]domain() gets is just a python dictionary, and xml['name'] >>>>> = >>>>> instance['name'], exactly what _enable_hairpin() was using the >>>>> 'instance' >>>>> variable for previously. >>>>> >>>>> Let me know if this works, or doesn't work, or doesn't make sense, or if >>>>> you >>>>> need an address to send gifts, etc. Hope it's solved! >>>>> >>>>> -Evan >>>>> >>>>> On Thu, Aug 23, 2012 at 11:20 AM, Sam Su <susltd...@gmail.com> wrote: >>>>>> >>>>>> Hi Oleg, >>>>>> >>>>>> Thank you for your investigation. Good lucky! >>>>>> >>>>>> Can you let me know if find how to fix the bug? >>>>>> >>>>>> Thanks, >>>>>> Sam >>>>>> >>>>>> On Wed, Aug 22, 2012 at 12:50 PM, Oleg Gelbukh <ogelb...@mirantis.com> >>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Is it possible that, during snapshotting, libvirt just tears down >>>>>>> virtual >>>>>>> interface at some point, and then re-creates it, with hairpin_mode >>>>>>> disabled >>>>>>> again? >>>>>>> This bugfix [https://bugs.launchpad.net/nova/+bug/933640] implies that >>>>>>> fix works on spawn of instance. This means that upon resume after >>>>>>> snapshot, >>>>>>> hairpin is not restored. May be if we insert the _enable_hairpin() >>>>>>> call in >>>>>>> snapshot procedure, it helps. >>>>>>> We're currently investigating this issue in one of our environments, >>>>>>> hope >>>>>>> to come up with answer by tomorrow. >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Oleg >>>>>>> >>>>>>> On Wed, Aug 22, 2012 at 11:29 PM, Sam Su <susltd...@gmail.com> wrote: >>>>>>>> >>>>>>>> My friend has found a way to enable ping itself, when this problem >>>>>>>> happened. But not found why this happen. >>>>>>>> sudo echo "1" > >>>>>>>> /sys/class/net/br1000/brif/<virtual-interface-name>/hairpin_mode >>>>>>>> >>>>>>>> I file a ticket to report this problem: >>>>>>>> https://bugs.launchpad.net/nova/+bug/1040255 >>>>>>>> >>>>>>>> hopefully someone can find why this happen and solve it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sam >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jul 20, 2012 at 3:50 PM, Gabriel Hurley >>>>>>>> <gabriel.hur...@nebula.com> wrote: >>>>>>>>> >>>>>>>>> I ran into some similar issues with the _enable_hairpin() call. The >>>>>>>>> call is allowed to fail silently and (in my case) was failing. I >>>>>>>>> couldn’t >>>>>>>>> for the life of me figure out why, though, and since I’m really not >>>>>>>>> a >>>>>>>>> networking person I didn’t trace it along too far. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Just thought I’d share my similar pain. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> - Gabriel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From: >>>>>>>>> openstack-bounces+gabriel.hurley=nebula....@lists.launchpad.net >>>>>>>>> >>>>>>>>> [mailto:openstack-bounces+gabriel.hurley=nebula....@lists.launchpad.net] >>>>>>>>> On >>>>>>>>> Behalf Of Sam Su >>>>>>>>> Sent: Thursday, July 19, 2012 11:50 AM >>>>>>>>> To: Brian Haley >>>>>>>>> Cc: openstack >>>>>>>>> Subject: Re: [Openstack] VM can't ping self floating IP after a >>>>>>>>> snapshot is taken >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for your support. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I checked the file nova/virt/libvirt/connection.py, the sentence >>>>>>>>> self._enable_hairpin(instance) is already added to the function >>>>>>>>> _hard_reboot(). >>>>>>>>> >>>>>>>>> It looks like there are some difference between taking snapshot and >>>>>>>>> reboot instance. I tried to figure out how to fix this bug but >>>>>>>>> failed. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> It will be much appreciated if anyone can give some hints. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Sam >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jul 19, 2012 at 8:37 AM, Brian Haley <brian.ha...@hp.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 07/17/2012 05:56 PM, Sam Su wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Just This always happens in Essex release. After I take a snapshot >>>>>>>>>> of >>>>>>>>>> my VM ( I >>>>>>>>>> tried Ubuntu 12.04 or CentOS 5.8), VM can't ping its self floating >>>>>>>>>> IP; before I >>>>>>>>>> take a snapshot though, VM can ping its self floating IP. >>>>>>>>>> >>>>>>>>>> This looks closely related to >>>>>>>>>> https://bugs.launchpad.net/nova/+bug/933640, but >>>>>>>>>> still a little different. In 933640, it sounds like VM can't ping >>>>>>>>>> its >>>>>>>>>> self >>>>>>>>>> floating IP regardless whether we take a snapshot or not. >>>>>>>>>> >>>>>>>>>> Any suggestion to make an easy fix? And what is the root cause of >>>>>>>>>> the >>>>>>>>>> problem? >>>>>>>>> >>>>>>>>> It might be because there's a missing _enable_hairpin() call in the >>>>>>>>> reboot() >>>>>>>>> function. Try something like this... >>>>>>>>> >>>>>>>>> nova/virt/libvirt/connection.py, _hard_reboot(): >>>>>>>>> >>>>>>>>> self._create_new_domain(xml) >>>>>>>>> + self._enable_hairpin(instance) >>>>>>>>> self.firewall_driver.apply_instance_filter(instance, >>>>>>>>> network_info) >>>>>>>>> >>>>>>>>> At least that's what I remember doing myself recently when testing >>>>>>>>> after a >>>>>>>>> reboot, don't know about snapshot. >>>>>>>>> >>>>>>>>> Folsom has changed enough that something different would need to be >>>>>>>>> done there. >>>>>>>>> >>>>>>>>> -Brian >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mailing list: https://launchpad.net/~openstack >>>>>>>> Post to : openstack@lists.launchpad.net >>>>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~openstack >>>>>> Post to : openstack@lists.launchpad.net >>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : openstack@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~openstack >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : openstack@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~openstack >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>> >>> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp