In VR configuration persistence (4.6) only iptables rules are persisted ? There are other configuration (interface ips, routes etc in VR will be lost on reboot) are these taken care ?
Thanks, Jayapal On 04-Jun-2015, at 11:15 AM, Koushik Das <koushik....@citrix.com> wrote: > > On 04-Jun-2015, at 12:04 AM, Remi Bergsma <rberg...@schubergphilis.com> wrote: > >> Hi all, >> >> I just had a look at this more closely and had a chat with Ian about it. The >> only way for the original problem to happen (losing iptables rules) is if >> the live migrate would fail and the hypervisor rebooted the vm. The cause is >> the non-persistance of the router configuration, which is fixed in 4.6 by >> the way. I would say failing live migrations does not happen often (I have >> never seen it happening). >> > > What about native HA in Vmware and HyperV? Say the original host has failed, > Vmware will bring up the VR on another host as part of native HA. In this > case also the configuration is lost. > >> Anyway, once this happens to the router, it is stuck in a state where it >> does not have the linklocal configuration any more. Would CloudStack be able >> to issue a aggregate command while it cannot reach it? Rebooting might be >> the only way out after all. It’s just that rebooting by default in case of >> out-of-band migrations I’d say is a little bit too much. CloudStack would >> detect the problem anyway, as it cannot reach the linklocal anymore. >> >> The interesting situation is that we have releases out there that now reboot >> by default. >> >> My proposal to solve it in 4.4 and 4.5: >> - Implement a setting ‘reboot systemvm when out-of-band migration detected’. >> The default should be false and release notes should mention a changed >> behaviour from 4.4.3 and 4.5.1. To get the old behaviour, switch to true. A >> small group of people should be interested in this. >> >> I guess this is the best of both worlds. Do you guys agree? >> >> The other option I see is to revert the commit, as I think that serves most >> people. >> >> Who is willing to help implement it? >> >> Regards, Remi >> >> >> On 03 Jun 2015, at 17:42, Rene Moser >> <m...@renemoser.net<mailto:m...@renemoser.net>> wrote: >> >> Hi >> >> On 03.06.2015 17:06, Ian Southam wrote: >> If the machine crashes and/or rebooted during the oob migration by a party >> that is not the orchestrator, (read vCenter) then the rules will be lost. >> >> I fully agree, a reboot due a failing live migration, would cause a >> reboot. So what? Then we blame VMware, the orchestration will reboot the >> VR and everything is fine. This would cause seconds of outage. >> >> But then the missing persistence of the iptables would be the problem, >> not the live migration task, right? >> >> We should fix the persistence of the rules during reboot and not try to >> be more clever then the hypervisor cluster orchestration. >> >> Just my 2 cents. >> >> >> >> >> >
