Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

h the VR will be without ant >> config but that can be documented. >> >> -Original Message- >> From: Remi Bergsma [mailto:rberg...@schubergphilis.com] >> Sent: Thursday, 4 June 2015 19:56 >> To: dev@cloudstack.apache.org >> Subject: Re: [DISCUSS

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

gt; Sent: Thursday, 4 June 2015 19:56 > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not? > > +1 > > On 04 Jun 2015, at 14:29, Rohit Yadav > mailto:rohit.ya...@shapeblue.com>> wrote: > > Hi, > > On 04-

RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

. -Original Message- From: Remi Bergsma [mailto:rberg...@schubergphilis.com] Sent: Thursday, 4 June 2015 19:56 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not? +1 On 04 Jun 2015, at 14:29, Rohit Yadav mailto:rohit.ya...@shapeblue.com

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

In case of #1 timing of reboot will also have impact and may result to undesired behaviour as both CloudStack and native HA trying to act on same VM. Regards, Anshul On 04-Jun-2015, at 2:35 pm, Remi Bergsma mailto:rberg...@schubergphilis.com>> wrote: To summarise: #1. rebooting VR is needed f

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

On 04 Jun 2015, at 16:50, Koushik Das mailto:koushik@citrix.com>> wrote: Thanks for the clarification Daan. So as I understand - after VR reboot outside of CS if there is any config differences (between persisted ones and DB) then MS will immediately push the config from DB to VR. Is that

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

Thanks for the clarification Daan. So as I understand - after VR reboot outside of CS if there is any config differences (between persisted ones and DB) then MS will immediately push the config from DB to VR. Is that correct? Is there any document/write-up available for the persistence changes?

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

+1 On 04 Jun 2015, at 14:29, Rohit Yadav mailto:rohit.ya...@shapeblue.com>> wrote: Hi, On 04-Jun-2015, at 11:05 am, Remi Bergsma mailto:rberg...@schubergphilis.com>> wrote: To summarise: #1. rebooting VR is needed for hypervisors that have their own DR (like VMware and Hyperv) as a restart o

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

Hi On 04.06.2015 14:29, Rohit Yadav wrote: > Hi, > >> On 04-Jun-2015, at 11:05 am, Remi Bergsma >> wrote: >> >> To summarise: >> #1. rebooting VR is needed for hypervisors that have their own DR (like >> VMware and Hyperv) as a restart outside of CloudStack makes it lose its >> config hence t

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

Hi, > On 04-Jun-2015, at 11:05 am, Remi Bergsma wrote: > > To summarise: > #1. rebooting VR is needed for hypervisors that have their own DR (like > VMware and Hyperv) as a restart outside of CloudStack makes it lose its > config hence the VR is unavailable > #2. rebooting is NOT needed for suc

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

On Thu, Jun 4, 2015 at 1:27 PM, Koushik Das wrote: > Is there a possibility for VR config and DB config to go out of sync? If so > how is the config in the VR and DB kept in sync? Koushik, the db is leading and conversion is applied to the state of the router. On differences, newly sent config

RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

hursday, 4 June 2015 15:41 To: dev@cloudstack.apache.org Cc: Daan Hoogland Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not? resist should be persist. Do not answer mails on iphones ;) > On 04 Jun 2015, at 11:31, Ian Southam wrote: > > The idea is to resist

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

resist should be persist. Do not answer mails on iphones ;) > On 04 Jun 2015, at 11:31, Ian Southam wrote: > > The idea is to resist everything. > > If stuff does not persist then it can be viewed as a bug ;). > > — > Ian > > On 04 Jun 2015, at 09:54, Daan Hoogland > mailto:daan.hoogl...@g

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

The idea is to resist everything. If stuff does not persist then it can be viewed as a bug ;). — Ian On 04 Jun 2015, at 09:54, Daan Hoogland mailto:daan.hoogl...@gmail.com>> wrote: By design all config is persisted but let's double check on that. @Ian: sir, can you confirm?

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

To summarise: #1. rebooting VR is needed for hypervisors that have their own DR (like VMware and Hyperv) as a restart outside of CloudStack makes it lose its config hence the VR is unavailable #2. rebooting is NOT needed for successful live migrations on _any_ hypervisor (since there was no rest

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

One more thing on VR config persistence, the configuration is persisted only on reboot not in VR stop, start am I right ? @Wilder Can please point me to the FS ? -Jayapal On 04-Jun-2015, at 1:33 PM, Wilder Rodrigues wrote: > There was a bug in the persistent stuff that was fixed here: > ht

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

There was a bug in the persistent stuff that was fixed here: https://issues.apache.org/jira/browse/CLOUDSTACK-4605 User data, IP tables, guest networks and pretty much everything else will be persisted. Cheers, Wilder On 04 Jun 2015, at 09:54, Daan Hoogland mailto:daan.hoogl...@gmail.com>> w

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

On Thu, Jun 4, 2015 at 8:15 AM, Jayapal Reddy Uradi wrote: > 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 ? By design all config is persisted but let's do

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

On Thu, Jun 4, 2015 at 6:39 AM, Koushik Das wrote: > The VR configurations are not persisted and so these are not present when out > of band movement happens outside of CS. When a VR is recreated/rebooted from > CS all the configurations are read from DB and pushed to the VR. This is not neede

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

On Thu, Jun 4, 2015 at 7:45 AM, Koushik Das wrote: > 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. Yes, in this case it is needed, no discussion the

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

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 wrote: > > On 04-Jun-2015, at 12:04 AM, Remi Ber

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

On 04-Jun-2015, at 12:04 AM, Remi Bergsma 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 i

RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

/configuration is pushed to it by on start by MS. -Original Message- From: Rene Moser [mailto:m...@renemoser.net] Sent: Wednesday, 3 June 2015 20:28 To: dev@cloudstack.apache.org Subject: RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not? Sorry for not answering in the thread, I was

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

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 f

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

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 f

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

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

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

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. The new persistent config code in the 4.6 branch will definitely prevent this behaviour as, the config will be preserved even if the machines is r

RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

Sorry for not answering in the thread, I was not on the dev ML so I could not reply I reported this current behavior to be an issue on the user ML and wanted to ask Koushik Das about his experiences. I would not agree, in an Vmware environment live migrations, e.g. Vmware DRS breaks IPtables norm

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

trix.com>: > > -Original Message- > > From: Koushik Das [mailto:koushik@citrix.com] > > Sent: Wednesday, June 3, 2015 6:08 PM > > To: dev@cloudstack.apache.org > > Subject: RE: [DISCUSS] Out of Band VR migration, should we reboot VR or > not? > &

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

18:10 > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or > not? > > that does negate the regression in xen, i'm afraid > > Op wo 3 jun. 2015 om 14:38 schreef Koushik Das : > > > I think as a design principle we

RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

> -Original Message- > From: Koushik Das [mailto:koushik@citrix.com] > Sent: Wednesday, June 3, 2015 6:08 PM > To: dev@cloudstack.apache.org > Subject: RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not? > > I think as a design principle we s

RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

Yes. -Original Message- From: Remi Bergsma [mailto:rberg...@schubergphilis.com] Sent: Wednesday, 3 June 2015 18:13 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not? I think the aggregate approach is much better (missed that mail

RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

Is there any issue reported in XS due to this? -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, 3 June 2015 18:10 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not? that does negate the

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

age- > From: Remi Bergsma [mailto:rberg...@schubergphilis.com] > Sent: Wednesday, 3 June 2015 17:54 > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not? > > This is a VMware specific problem, right? > We could also limit the

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

dev@cloudstack.apache.org > Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or > not? > > This is a VMware specific problem, right? > We could also limit the fix to this hypervisor only. > > Regards, > Remi > > > On 03 Jun 2015, at 14:12, Koushik Das

RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

ve HA provided by HV. -Original Message- From: Remi Bergsma [mailto:rberg...@schubergphilis.com] Sent: Wednesday, 3 June 2015 17:54 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not? This is a VMware specific problem, right? We could

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

I think we should revert for 4.4 as it creates a serious regression. As reverting it would create a regession for vmware users on 4.4.3 we must create an alternative. For 4.5 we should use the aggregate command and as Sudhansu says we can for 4.4. as well. that and for 4.6+ we have persistent confi

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

That’s great, sounds like the best way to do it then :-) > On 03 Jun 2015, at 14:21, Sudhansu Sahu wrote: > > The aggregate command was introduced in 4.4 so we can implement this in > 4.4 as well. > > > Regards > Sudhansu Sahu > CPG-Orchestration > T: +91-4044308412 | M: +91-9989334676 > sudha

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

---Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Wednesday, 3 June 2015 17:18 To: dev Subject: [DISCUSS] Out of Band VR migration, should we reboot VR or not? Hi all, Recently a behaviour was reported for ACS 4.5.1, where out of band VR migration would cause rebo

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

The aggregate command was introduced in 4.4 so we can implement this in 4.4 as well. Regards Sudhansu Sahu CPG-Orchestration T: +91-4044308412 | M: +91-9989334676 sudhansu.s...@citrix.com Powering mobile workstyles and cloud servic

RE: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

If it can be used to apply rules on VR without a reboot then that should work as well. -Koushik -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Wednesday, 3 June 2015 17:18 To: dev Subject: [DISCUSS] Out of Band VR migration, should we reboot VR or not? H

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

Instead of RebootTask we should implement an AgrregationExecutionTask which will push the network rules. If we revert the current change(RebootTask), without implementing AgrregationExecutionTask then VR will not have a desired state(missing rules) after HA. Regards Sudhansu Sahu CPG-Orchestrat

Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?

Hi all, If I understand correctly, this is also in 4.4.3 (and the upcoming 4.4.4). The report on user list: http://markmail.org/message/nth7qck27s2chwoc?q=VMsync+issues+with+VRs%3F As VPCs are non-redundant, a sudden reboot

[DISCUSS] Out of Band VR migration, should we reboot VR or not?

Hi all, Recently a behaviour was reported for ACS 4.5.1, where out of band VR migration would cause rebooting of VR. It seems this is a desired behaviour as per this issue: https://issues.apache.org/jira/browse/CLOUDSTACK-7994 It was shared on the thread on users ML that since CloudStack now su