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 <rberg...@schubergphilis.com<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 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 restart everything still works) #3. CloudStack 4.6 has persistent config in VR, so rebooting is never needed The current behaviour in 4.4.3, 4.5.1 and master: - always rebooting VR when out-of-band detected ==> Works great for #1, but makes case #2 not work The previous behaviour: - never rebooting VR when out-of-band detected ==> Works great for #2, but makes case #1 not work We need something that works for both cases :-) About #1 and #2: Can we detect in another way that a VR became unreachable/non-functional and do an action based on that? So, if a VR lives on a VMware hypervisor that happens to crash, VMware HA will start it on another available hypervisor but without config it will not be reachable on the control network. If we want to do it generic, I’d say that when a VR is not controllable any more we could reboot it. We could also make this a setting ‘systemvm auto reboot on control failure’ or whatever we call it. This would then also be a useful feature in 4.6 About #3: I’d suggest at least reverting the commit to master, as it makes no sense since the VR is persistent already. https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java#L2638 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c3515c9 Regards, Remi On 04 Jun 2015, at 10:03, Wilder Rodrigues <wrodrig...@schubergphilis.com<mailto:wrodrig...@schubergphilis.com>> wrote: 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 <daan.hoogl...@gmail.com<mailto:daan.hoogl...@gmail.com><mailto:daan.hoogl...@gmail.com>> wrote: On Thu, Jun 4, 2015 at 8:15 AM, Jayapal Reddy Uradi <jayapalreddy.ur...@citrix.com<mailto:jayapalreddy.ur...@citrix.com><mailto:jayapalreddy.ur...@citrix.com>> 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 double check on that. @Ian: sir, can you confirm? -- Daan (being to lazy/busy to check the code)
