cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jayapal Reddy Uradi <jayapalreddy.ur...@citrix.com>
Subject Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
Date Thu, 04 Jun 2015 06:15:12 GMT

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.das@citrix.com>
 wrote:

> 
> On 04-Jun-2015, at 12:04 AM, Remi Bergsma <RBergsma@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 <mail@renemoser.net<mailto:mail@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.
>> 
>> 
>> 
>> 
>> 
> 


Mime
View raw message