cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Bergsma <>
Subject Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not?
Date Thu, 04 Jun 2015 09:05:13 GMT
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.;a=commitdiff;h=c3515c9


On 04 Jun 2015, at 10:03, Wilder Rodrigues <<>>

There was a bug in the persistent stuff that was fixed here:

User data, IP tables, guest networks and pretty much everything else will be persisted.


On 04 Jun 2015, at 09:54, Daan Hoogland <<><>>

On Thu, Jun 4, 2015 at 8:15 AM, Jayapal Reddy Uradi
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)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message